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.