Cutout tabs not milled very efficiently about grid-apps HOT 5 CLOSED

I agree. at the moment, the depth-first algorithm does not distinguish between outermost polygons which include cutout tabs and inner ones.

from grid-apps.

B is better than C unless you happen to have an odd number of passes below the tab.

I'd also suggest turning the tabs into trapezoids/triangles so that the machine doesn't have to decelerate to zero, move up, accelerate across the top of the cut, decelerate to zero, move down and finally accelerate along the bottom of the cut, but can instead keep moving at full speed while it's raising and lowering the bit

from grid-apps.

@davidelang B vs C in even number of passes might also depend on lenght and overal number of passes. if you have too much passes or they are short, C might be still better. Especialy in my case, where Z is slowest axis.

Also when i combine slow Z with faster X and Y it slows down all axes anyway, since it has to move in sync. But that's not really problem, since you have to wait for Z anyway, so trapezoidal tab will surely be little better (X and Y moves little bit, while waiting for Z, so you save small amount of time), but certainly not blazing fast. Anyway trapezoids make sense. especially on machines with fast Z.

In fact i don't really mind as long as there will be no complete retracting all the way up to the safe z.

from grid-apps.

from grid-apps.

This should be substantially better now. Please test.

from grid-apps.