The Mysteries of RhinoCAM/VisualMill speeds ...

[trakwebster]

I'm working out how to use Rhino to create simple models so as to generate simple cuts in wood stock. (Poplar and Maple)

I can fairly easily create the Rhino model, but am a little puzzled by the 'speeds' being fed to ShopBot by the RhinoCAM post-processor.

The RhinoCAM milling program is, I understand, the same thing as VisualMill, but stuck in the middle of the Rhino interface.

Everything goes fine, until we come to a page requesting speed information. It asks me for:

Spindle Speed
Plunge Feed
Approach Feed
Engage Feed
Cut Feed
Retract Feed
Departure Feed

I know it doesn't matter what the spindle speed, as shopbot cannot change the speed of my Makita router. However these other terms are fairly mysterious.

There are a bunch of speeds that one can load from a table, but they apply to various metals.

By choosing one of these metals, writing down the speeds appearing in the boxes, translating them from inches per minute to inches per second as ShopBot does, I have attempted to figure out what's being done with these input speed values. This is so that I can work backwards to put in speed values which will, when post processed, be sensible speeds for cutting poplar and maple on my PRT machine.

However, the resultant post-processed file is less than clear.

Early in the beginning, for example, I see code that might look like the following (*my comments added) --

SA 'Set to Absolute
'Horizontal Roughing
JS,3.5,1.7 'These jog speeds don't seem
'to have
'come from anything I input in
'RhinoCAM

&Tool = 2 'apparently RhinoCAM thinks
'ShopBot can load the bit
JZ,1.8750
J2,1.6293,5.1773 'we go to the starting place
MS,0.3,0.2
MS,1.3,0.6
MS,1.,0.5 'Three moving-speed
'in a row, only the last of
'which will affect ShopBot
'at all. Why?
'And from which "speed" in
'RhinoCAM did these come?
M3,1.6288,6.3734,1.4396
M3,1.6985,6.3735,1.4143 'We make two cuts
MS,1.3,0.6 'A different move speed
M3,1.6964,1.6275,1.4143
M3,1.6306,1.6275,1.4143
M3,1.6288,6.3734,1.4143
M3,1.6985,6.3735,1.4143
M3,1.8235,6.3734,1.4143 etc, etc
'and now a bunch of cuts
'as is proper

I tried working backwards and some of these numbers correspond to the RhinoCAM input screen, and some of them don't.

It's late and I'm tired. Perhaps this will be more clear in the morning.

But, in the meantime, has somebody else already worked this out? Anybody just know what numbers to pump into RhinoCAM's 'speeds' fields so that ShopBot gets reasonable values for cutting wood? Or anybody worked out what each of these RhinoCAM inputs corresponds to among the ShopBot Move, Jog, and Ramp speeds?

I'd be grateful for any info, thanks.

[mikejohn]

Arthur
The simple answer is put in anything, then delete them (MS or JS) from the cut file.
Then the Shopbot will use the speeds you put in direct.

.............Mike

[Mike Windsor]

To understand the feeds and speeds dialogue in VM look closely at the illustration beside the dialogue window in the speeds window .It has a description of all of the types of moves . Also note that VM uses inches per minute i.e 60 ipm = 1 ips. As far as manually changing the speeds in the shopbot file ---, that is going to be a lot of work , because VM inserts a move speed change into the file every time that the tool is transfering position without cutting , or ramping into or out of a cut . --- Once you get used to the feeds and speeds you can get a lot more efficient times out of your files . I have a prt and usually cut at 90 ipm and transfer at 180 ipm .

[mikejohn]

mike
Are you suggesting different jog speeds/move speeds for different parts of a file?
I though that if you use the maximum Jog speed you are comfortable with, this gives you the shortest jog time possible.
Cutting speed and ramping are so inter-related I am happy to leave it up to the Shopbot software.

...........Mike

[rexh]

I am not sure exactly what features the Rhinocam version of VM has, but basically, you go into the cut parameters dialogue and zero out the boxes for engage and retract moves. This tells the machine to just do a basic plunge and cut, without extra moves. When you go into the Feeds/Speeds dialogue, just set all of them to the same value. I like to have a faster retract value, but setting them all the same simplifies things in the program. Make some changes in these values, post the program and look at it to see what VM is telling your machine. Of course, you will have to make a speed conversion for Shopbot from VM's IPM standard. Cutting speeds depend on how much material is being removed, and size of the bit- a larger (less prone to breakage) ball-nose can remove more material, but may be programmed slower to hog out material; the next cut with a smaller tool removes much less material, but can move through it faster.
Plunge, engage and approach feed can be set to the same value; 100 IPM works well for most wood cutting. Retract and departure speed can be the same, and a little bit higher (150), because the tool is leaving the wood, and not in contact. Cutting speed will be variable.
Hope this helps.

[btk]

Arthur,

Most of the stored speed variables in RhinoCam only come into effect only when using certain types of toolpath strategies.
However the basic two are Cut Feed (cf) which will effect the main "MS".
And Transfer Feed (Tf) which is Shopbot "JS"

If you look at some of the tabs on certain strategies (i.e. profiling), you will see ways to configure the Approach Angle, Engage Length, etc.
If you work with these, then you will se that the MS will drop down (or up) before these operations and then immediatly after will be set back to the Cf.

For Speeds, I think that you should make them all as fast as possible for your material/depth of cut/bit, etc (perhaps around 102 ipm) and down from there as you see a need.
I usually keep these speeds all the same as one another except for Tf should be higher (perhaps 200 ipm).

Also, if you do not set the speeds (i.e. everthing 0.0 ipm), then the resultant sbp file will not have speeds and will use the setting from your SBP control user interface.

Brian

[frank_hav]

I use Visual Mill and I have changed the post so that it does not process Jog and Feed rates. I put the Partwizard "Starting and Ending" code in the appropriate comments areas in VM Post.

Pro's... I get one set of speeds I can vary. Also I don't need to remove hundreds of "MS" text. It also lets you keep any adjustments you make on the fly, as it is the only rate in the code.

Con's... Other than possibly not optimal cycle time, I have not found any. I don't believe that it runs any slower only because it is not ramping up and down the feed as much.

Frank

[stevem]

All posted feed rates can more easily be edited in Notepad or Wordpad by using edit>replace>replace all. Just copy and paste the feedrate and then change to the new feedrate.

[trakwebster]

Wow!

What a lot of helpful information! Thank you!

I would have simply followed Mike John's idea of just editing the code file, except that, as Mike Windsor points out, the post-processor sticks a *lot* of these speeds into the file. For example on a Horizontal roughing, it uses 2-3 at the beginning of one layer, then it starts the next layer with all the same set of speeds (or a different set!), and then at the next layer, it does it again, for every layer.

Also, since it's using many different speeds, a global 'replace' is likely to miss lots of them, plus this is not a good way for the human to operate, trying to correct the machine while making no human mistakes! Not our strong point!

Therefore, I'm going to mostly concentrate on either changing the post-processor -- I didn't know a person could do that! -- and explore telling it all zeros to see what it does. And I will examine that little graph now that I have a bit more explanation of what the RhinoCAM labels mean in terms of ShopBot's move/jog/ramp labels.

I also very much appreciate BTK's idea of concentrating on 'cf' and 'tf' as generators of shopbot's "move" and "jog" speeds. I'll go through the resulting code with this in mind.

And last, I very much appreciate the suggested speeds, as I have absolutely no basis of experience on this. I would probably have left the ShopBot running at it's defaults until they caused a problem. In other words, probably for years.

Thanks again for all the prompt and useful help!

[trakwebster]

I think this is starting to work.

I had a couple of failures:
(1) Tried to make a modified post-processor to substitute for RhinoCAM's 'shopbot.spm' file. I changed only the speed conversion, so that it would not change inches per minute to inches per second. I thought that I could at least temporarily remove that particular confusion so I could see what it was doing. However, though I've done lots of programming and had to change only one line, my modified shopbot.spm file would produce no output. So that didn't work.

(2) Then I went through some experiments where it appeared that no matter what different values I input into the RhinoCAM speeds panel, it still produced the same old values. Discouraging!

However, I finally noticed that if I closed out the program, and reloaded Rhino and redid everything that it appeared to accept the values I input on the speeds panel. I don't know if this is a stupid bug. Or perhaps a stupid human, at this point.

At any rate, it now produces sane and (I think) workable output. I am following the suggested speeds of 90 inches per minute (=1.5 ips) cutting speed, and 180 inches per minute (=3.0 ips) jogging speed.

I'm entering the panel's requested values like this --

============ BEGIN SPEED PANEL ENTRIES ==========
Spindle Speed = 8000 (my makita's slowest speed, not that it matters as shopbot can't control it)

Plunge Feed = 90
Approach Feed = 90
Engage Feed = 90
Cut Feed = 90 *** Spozed to be the Move Speed ***
Retract Feed = 90
Departure Feed = 90

Transfer Rate (SET button on) = 180 *** Spozed to be the Jog Speed ***
============ END SPEED PANEL ENTRIES ==========


These values now create cut files that appear sensible, making 'jogs' at 3 ips, and making horizontal cuts ('moves') at 1.5 ips, and plunging cuts of the Z axis at 0.8 ips.

However, I learned something about how RhinoCAM/VisualMill writes a cut file (shopbot part file).

Although RhinoCAM does place an honorary JS (jog speed) instruction early in the file, it then never uses jogs at all.

Instead, when it's time to move quickly, with the bit out of the material, RhinoCAM issues a MS (move speed) instruction with the 'jog' rate. It looks like: MS, 3.0, 1.5
Then it issues a move command, such as:
M3, someXvalue, someYvalue, someZvalue

Then when it's arrived at the place to cut, RhinoCAM issues a new, slower MS (move speed) instruction with the 'cut' rate.

For example, a plunge into the material might proceeded by a move speed instruction such as:
MS,0.8,0.4

Or, for a different example, a horizontal cut might be preceeded by a move speed instruction such as:
MS,1.5,0.7

And, for a last example, sometimes RhinoCam does a 'lateral plunge', meaning it moves from the surface of the material in an X or Y direction, and plunges the Z into the material at the same time. In those cases, it seems to choose the normal cut speed (such as MS, 1.5, 0.7).

And I think that the reason it sometimes has a couple of move-speed instructions in a row is in a case where, for example, it sets up a move-speed instruction for a plunge. But then there is no plunge. Then it sets up a new move-speed instruction for a 'lateral plunge', and then it makes a lateral plunge.

With my new values as given above, I have no incidences of three move-speeds in a row, so I suppose those seen in my earlier attempts were caused by RhinoCAM attempting to give me more control over what ShopBot calls 'ramps.' However, at this stage, I'm quite happy to let ShopBot work out the ramps. At this point, the machine knows more about cutting than I do.

But it's making some sense now. So thanks again for those who helped make sense of this! And maybe the info in this thread might be useful to other folks down the road.

[dingenis]

arthur

"Also, since it's using many different speeds, a global 'replace' is likely to miss lots of them"
just a suggestion
replace MS by " 'ms "(this will find them all and stops the line from being executed)
and put your shopbot (ms/js) code where you want it.

[trakwebster]

Hello, dingenis,

Smart idea!

Of course, editing the part file was exactly what I was hoping I didn't need to do, and it appears that the correct input eliminates the need to edit. However, this is a good idea for tracking down mysteries! Thanks!

[hespj]

Arthur, in the speed settings table I put different speeds in the boxes - I figure I might as well make use of all the facilities the software offers. The figures loaded from a table give an indication of which should be fastest, I just upped them somewhat for wood (the supplied figures are for metals). As you hint, it is good if the cutter eases into a new level rather than crashing straight in at full speed, so approach and engage are lower than cut feed. Retract and Departure are faster.

Also note that in the Post-Processor Generator, max and min speeds are defined, despite what you might have entered elswhere.

You soon get very adept at dividing by 60 to get inches (or mm in my case) per second. Maybe we should suggest a feedrate option "per second" to MecSoft.

Did you know there is a Mecsoft forum:

http://www.mecsoft.com/cgi/teemz/teemz.cgi

By the way, I use much faster cutting speeds than you. Horizontal Roughing can take a long time and there's no need for a good finish on this cut. I suggest experiment cutting as fast as you can and then slowing down if necessary.

[wayne_walker]

I have drawn a part in AUTOCAD and saved it as a DXF-R14. When I go to bring it into Part Wizard to a create a toolpath it says "run time error '13' - type mismatch".
I have looked in the search section, but did not see anything that will help me out. Anyone have this happen??

Thanks

Wayne

[trakwebster]

Hello, John Hesp,

Probably I will experiment as you suggest. So far, as a newbie, as of today I actually made the first cuts using these speeds. The 'lateral plunge' seems to work ok, cutting poplar wood. I'm guessing that the roughing could run faster.

But I am reminded of a note I once saw in a computer manual. It has been a rule of thumb for me for many years --

"I prefer to confuse one issue at a time!"

[hespj]

Very wise Arthur.

Wayne, try saving as a R12 dxf. (Oh, I see on another thread that you did).

[trakwebster]

Another twist in the Saga of Speed and Feed --

As of today, I am importing into Rhino, a 2D *.dxf file created with ShopBot's 'copy machine.' It imports into Rhino just fine, and I've found the place to make sure it's in inches.

Everything is working fine, except that when I'm doing the RhinoCAM speeds and feeds, the speeds and feeds panel now insists on having the info in millimeters/minute rather than in inches/minute as it has been doing previously.

I have reread the entire manual, examined every icon on every RhinoCAM panel, searched their help file and their forum. Not a clue.

Anybody know how to get it give me inches rather than millimeters in the RhinoCAM speeds and feeds panel. I can work out this conversion, but this is just silly.

Why has the behaviour changed? How can I regain entry in inches per minute rather than millimeters?

Advice?

[btk]

Arthur,

Just double check that your Rhino Units are set to Inches (this is found on the "Units" section of the "Options Interface"-the yellow gear icon on toolbar)
If this is set to inches and RhinoCam is asking for MM, I think that you should contact MesSoft on their Forum and report as a bug.

Brian

[trakwebster]

Yes, Rhino units are set to inches in the options interface. And if I select the polyline and check the File | Properties | Units menu, that is also set to inches. That's why it's puzzling.

I will follow up with MecSoft, but I wanted to ask here, because I know that many times the same questions arise. Thanks!

[trakwebster]

This newest puzzle -- feeds & speeds in millimeters -- has vanished as of today.

It must have been a side-effect of some of my first bumbling around, and then continuing to work with that file.

The following procedure works without error, as of today --

I open a new file, using the 'inches' template, then do an import of the *.dwf file that shopbot's 'copy machine' created. (I can check that inches are being displayed via File | Properties | Display Properties | Units.)

I can then set-up box stock, choose a tool, in 'MOps' select my XYZ origin, and then choose feeds and speeds, and the panel arises in 'inches/min' as it should. Then generate toolpaths, peek at them in the stock window, and finally post-process to the shopbot processor. Works fine.

Thank you again for the helpful info.

PS: I learned that *.dwf files contain no units information from a fellow's posting on the VisualMill forum. Which kind of makes better sense of some of this importing behavior. I guess if you import the *.dwf into a millimeter document it plots 40 mm long but if you import the same *.dwf into an inches document it plots 40 inches long.