Plunge and feed rate: first cut vs overlap cuts

Software MeshCAM
1

I have a doubt… When setting up plunge & feed rate, overlap, depth of cut and material information into gwizard and MC, there is no way to differentiate the “first cut” from subsequent passes into the material.

What disturbs me is that a first cut will essentially be a 0% overlap and tool deflection (driving shatter etc) will be different thanfrom subsequent overlapped cuts. This is particularly relevant to the roughing phase.

I could not find any way to specify that difference in feed and plunge rates.

It seems the safe way is to always assume 0% overlap in gwizard but

  • this yields very slow feed rates and long jobs
  • feeding too slow seems as bad as too fast (heat)

Am I missing something or overanalyzing this ?

Thanks!

2

No, that’s the sort of thing which makes CAM so difficult — see the math behind adaptive clearing strategies.

1 Like
3

To expand on my previous comment.

I’ve often thought that having some sort of physics-based model would be a neat opensource project, where one could calculate where one is along a given path, and how much (or little) material one is removing at a given point along a path and adjusting speed as appropriate.

I was kind of surprised when I first looked into the CNC Cookbook’s G-Wizard program — my initial take on it was that one would:

  • specify a material
  • load the G-code into the app
  • it would then check the paths and adjust the speed along the paths to maintain a given material removal rate

rather than the more prosaic, (but still brilliantly engineered, w/ nifty MeshCAM integration) feed-speed calculator which it is.

William

4

To expand on your expansion…

Meshcam can’t do this sort of feed in. You -can- do so with other tools, like Fusion 360’s CAM generation.

So, when you use something like gwizard to calculate good feeds/speeds, you need to do so for the “slotting” case that has 180 degree engagement if you’re going to avoid chatter (and potentially breakage) on the initial cut. This also means that you won’t be cutting at the fastest/most optimal speed for the rest of the cut at that Z-depth. At least, that’s how it seems to work out for me…I need the feed rate cut way down for the slotting part of the cut, but then that’s about 1/2 of what I should really have for the rest of the layer.

A tool like this would be interesting. I spent some time working on one that could pull in gcode and do some optimizations on it (for instance, don’t retract then plunge in the same spot). It has some kinda…sorta…working bits, but it’s not terribly useful yet.

2 Likes
5

Thank you @mikep and @WillAdams for your answers!