An idea: slow down for slots?

A brief search proves this is not a new idea but I don’t recall seeing it mentioned here.

When clearing pockets or wide cut-outs the first loop at a new Z depth is a slot. Subsequent loops at the same Z level are cut with some fractional stepover. That limits the feed rate for the entire operation when the second and following loops could feed faster than the first. (edit: “entire operation” at each Z level)

Naively, it seems like the first path circuit after a Z feed down can be defined unambiguously. How about an option to reduce the feed rate for that circuit? If selected, then set either a second rate parameter or a fraction to reduce the op feed rate?

Really the desired effect is to speed up the latter loops but slowing down the first/slot loop seems like the clearer way to define the op. ?.

That’s the main idea. Further thoughts:

Starting with the smallest/inner loop of a nest would maximize the speed gain (minimize the cost of slowing the first loop) at cost of time for a move when the smallest loop is not the nearest loop. Based on nothing, I’ll guess that will usually be a winning trade. Maybe when slot feed reduction is specified, that could also imply smallest-first nest order?

If smallest-first proves sometimes undesirable, then maybe it could be a further option presented when slot slowdown is selected. I suppose the nearest-vs-smallest choice could be optimized in each instance but it would probably take a lot of milling to pay back time spent thinking about that. And it might be often wrong without knowledge of acceleration.

Duplicating the slot loop to insert a half-stepdown pass might be another beneficial strategy.

My naive supposition that it’s easy to identify “slot” loops following Z downs might be overly optimistic because sometimes K:M lifts Z to move between essentially adjacent loops. Do Z lifts between adjacent loops happen only in acute inside corners with large stepovers? i.e. does <50% stepover prevent Z lifts between adjacent loops? If so: <50% stepover and faster feed after the first/slot loop sounds like a fair combination. (>50% stepover would be not wrong but could result in a lot of non-slot cutting at the slower slot feed rate. – but only with acute inside corners?)

It’s funny you mention this, but I just started adding this functionality recently. I ran into a few cases where the internal path code is sufficiently abstracted as to prevent this from being entirely accurate without some refactoring. So it’s about 50% of the way implemented now for roughing operations. I’ll try to keep improving this in 3.9 even as I do the 4.0 refactor, which should allow this to be consistently implemented.


Thanks again for your continuing effort.