Plunge rate

[Xxray]

Ran into a factor I have never considered before, plunge rate.

Was doing a very Z heavy 3D project and I noticed the z level was absolutely creeping compared to what it usually does.
Was thinking I may have a belt slipping or something, then I thought of plunge, which I normally just leave at a default of 30 or so, in years literally have never adjusted it.
It was at 10 for whatever reason ,,, So too late for that project, which turned a 4 hr cut into 6.5.

So I will make sure to jack it up to at least 30, my question is, could there be bad effects if I went the other way and jacked it up to 50 ? Will it only really go at 1 speed in practice, like feed rate when doing 3D ?

[IslaWW]

Doug...
When you say, "Ran into a factor I have never considered before, plunge rate.", you are not alone.

And this one: "just leave at a default of 30". There are no defaults. There IS something in the box, that may even work in some cases, but you must know to look at "the defaults" in a tool database like the picture inside a picture frame on the store shelf. Yes, there is something in the frame, but its not very likely you will use it.

Few users understand how a CNC controller works interpolating feedrates. The lesson is too long for a single post, but always comes up in our Seminars. You can try this: Instead of the z=30 and XY= 200 or 300, try setting them both at 100. Rerun the same file and look at the elapsed time.

[JasonDorie]

Something I've always wished for was a feature whereby if you specified a ramp, that it would limit the descent of the tool to the plunge rate, but allow it to move laterally at up to the feed rate. For example, if I set my plunge to 10 IPM, but my feed at 300 IPM, if I ramp into the material at a 10 degree angle, Aspire currently moves at 10 IPM, but really, it could move much faster than that. If my math is right, moving laterally at 10 IPM during a 10 degree ramp means you're only plunging vertically into the material at about 1.7 IPM - moving laterally at 60 IPM gets you a 10 IPM plunge rate.

I often use spiral ramps when doing profile cuts, but have to remember to set the plunge rate to the same as the feed rate all the time, and it's a big pain in the butt when you forget.

[Xxray]

thanks for the replies, interesting.

I dunno, maybe I have just been lucky but I've never once in years had the need to change "default" plunge rate, what ever was in the box.
How/why this one got cranked down and made me notice, I don't know. But now its got me thinking and wanting to learn more about how tweaking it affects cutting.
Alls I can say right now from experience is 10 is far too low, 30 is about right, beyond that I don't know. But I ask myself, could there be a scenario where 10 would be beneficial ? Don't know the answer to that either. If its an option, seems to me there must be an application.

[IslaWW]

Jason...
I'm not sure what controller software you are using, but that is the way most modern controllers (that I am familiar with) operate. With bot XY and Z set at 100 and a ramp in angle of 45* the bit will move at 100, and each axis at ~71. Other angles are proportionally similar based on slope angle.

The actual lateral feedrate depends on the angle of the ramp, but lets say your Z was at 100 and the XY was 300 a ramp of 30% or less would have the Z at full speed and reduce the XY, during the ramp section. The inverse is also true, you can use a slower feedrate on the Z to slowdown XY during a ramp in. Useful feature.

[Rcnewcomb]

Aspire currently moves at 10 IPM

It is actually your control software that handles this. Aspire just relays whatever feedrates you specified in your project. Most control software ensures that, if you specified a Z feedrate of 10 IPM then the Z axis will never move faster than 10ipm.

In general, for 3D work your speed is limited by the feedrate of your slowest axis. Therefore Gary's advise is sound to set the XY and the Z rates the same.

If you are interested in the math behind this I can share an example.

[IslaWW]

Doug...
In my classes I use an example of a "simple 3D", actually the VCarve of a Times New Roman letter "A". When toolpathed at 30 (Z) and 120 (XY) and allowed to run, lets say it takes a minute and a half. IF XY are increased to 180 the file is cut a few seconds quicker.

If the XY and Z are both set to 60, the file will cut in 40% of the time of the original. "Slow down to go faster"

The same principle applies to pure 3D. Based on a given file and how abrupt the Z movements are, you should find what speed your Z can withstand and then match the XY to that. You may try increasing the XY if there are larger flat areas, but in many cases the Z will control the cut time by the largest percentage

[Rcnewcomb]

For the people with ShopBots, Brady Watson wrote an excellent article Ramping, the VR Command and How to Tune Your Tool for Maximum Performance

Based on his suggestions I had different settings I used for 3D work vs 2D work.

[JasonDorie]

To be clear, I was only speaking only about profile cuts. It's quite possible that during 3D-style finishing cuts Aspire does the "right" thing, but my experience with 2.5D cuts has been otherwise.

For the original poster, if you've done a full roughing pass already and are removing a minimal amount of material, having a faster Z-plunge should be benign, and the machine controller software will limit your maximum movement rate to whatever the keeps you within bounds of the slowest axis.


Regarding profile cuts with ramps:
Sin(A) for a 10 degree angle is ~0.17, so plunge / Sin(A) should give you the max speed at which you can travel laterally while limiting the vertical plunge to that rate. End mills don't handle plunge loads well, which is why I set their plunge lower, but I don't want to limit the rate of the machine itself, because that affects retract and pre-engagement plunge rate too.

I know Aspire controls this - as I said, I have my tool database set for "normal" use, but then I will often do profile cuts as spirals, and forget to change my normally conservative plunge rate to match the XY feed rate. I know I can change this myself, but it'd be nice if Aspire had the option to have it do the math to limit the vertical component of the plunge to whatever the tool is set to, based on the angle of the ramp I specify, without me having to manually compute that every time.

For any 2.5D cut, during the plunge motion Aspire sets the feed rate to the plunge rate setting, even if the plunge move is a ramp. Once it has moved into the "cut" portion of the path, then it uses the feedrate specified. I just wish it was smarter about this - didn't mean to hijack the OP's topic.

[JasonDorie]

In my classes I use an example of a "simple 3D", actually the VCarve of a Times New Roman letter "A". When toolpathed at 30 (Z) and 120 (XY) and allowed to run, lets say it takes a minute and a half. IF XY are increased to 180 the file is cut a few seconds quicker.

If the XY and Z are both set to 60, the file will cut in 40% of the time of the original. "Slow down to go faster"

Wouldn't that run the same rate if you had simply changed Z to 60 and left XY at 120? If Z is the limiting factor here, why the need to change the others? (unless you're just using that to demonstrate that the Z is indeed what's limiting the other two).

[Rcnewcomb]

For any 2.5D cut, during the plunge motion Aspire sets the feed rate to the plunge rate setting, even if the plunge move is a ramp.

Jason,
I'm unable to see an example of this in the toolpath code that is generated. Can you provide an example?

(I noticed you are in the Bay Aea. I'm in San Jose)

[IslaWW]

Jason...
As Randall says, this is 100% set by the controller. Vectric posts put out the feedrates as the controller mfgr has requested. Mfgr requests based on what works best for that generation of control. As controllers change, so do their requirements, and therefor post processors change with them.

Your statement: "For any 2.5D cut, during the plunge motion Aspire sets the feed rate to the plunge rate setting" is patently wrong using todays standards. The speeds are set by the controller and the feedrate changes are entered as the controller mfgr has requested. The action you describe is typical of controllers of yesteryear and some of the inexpensive PC based controllers, but very few of the current PC based controls will respond that way today.

There have been dozens, if not hundreds of hardware and software updates to most controllers over the last half dozen years. The CNC boom has spurred a lot of development. The item we are talking about and the myth about "thousands of nodes" cutting differently than a G2 or G3 are machine actions from yesteryear are two of the most prolific non-desirable CNC traits that only need to live in the history books.

"Wouldn't that run the same rate if you had simply changed Z to 60 and left XY at 120?" In some cases it will help, but in most not as much as you would think. Also, when all 3 axes are equal feeds, the controller has an easier time interpolating feedrates and can actually process code faster.

[JasonDorie]

I'm at work, but I'll take a look when I'm home. It's possible they've changed this in a recent version. It may also be the post-processor that I'm using - I'm running Mach3, and I see you're on a ShopBot, which I know uses M-Code, not standard GCode. Maybe the difference is there? I'm curious to find out.

[IslaWW]

Jason...
I don't think you are going to find any recent upgrades for Mach3. I believe development stopped on that years ago. Their business model of software without hardware and little or no factory support has not proven to be successful in this decade. Most of the controllers that are succeeding have branded hardware, I/O boards and the like, that match the controller software, and the company provides support for both. There is also mfgr support for setups and configurations that are virtually plug and play with most machine frames.

ShopBot uses their own (SBP) code and also runs gcode, if needed. Along with a number of controller upgrades each year, they provide at least 3 sizes of branded, factory supported I/O boards to meet the needs of most sizes of machines.

Most of my recent experience is with WinCNC, a higher end system that uses an independent controller on the PCI buss. So the code is not generated by the PC, and the PC could be used for other purposes once a file is loaded and running. They also have multiple branded I/O options that are fully supported.

I build control boxes that use both systems, even do a field install for a few. The most common replacement is Mach3 machines and blown up Practical controllers. One ting they have in common: "Man, this machine NEVER ran like that before!" Its all in the controller.

[JasonDorie]

I'm a lowly hobbyist with a limited budget, and built my own CNC, so Mach3 was what I could afford at the time. Things have improved quite a bit since then. And I was referring to Aspire when I said they might've changed things in a more recent version. I've used a ShopBot before, and I actually found it significantly slower than my own. (It was also quite a bit heavier, so in fairness it wasn't an apples-to-apples comparison). As for Mach3, they're on Mach4 now, and development continues: http://www.machsupport.com/