It’s great to see active work on Kiri:Moto! Thanks, Mr. Allen.
I don’t know what to call the operation between “slice” & “preview” that sequences slice segments into a toolpath with connecting moves. This is about that.
I have a model, as a part in Onshape or exported as STL and loaded into grid.space/kiri, that confuses this operation.
The slicing result looks valid.
For non-depth-first paths, many but not all of the moves on the top several layers do not lift the tool. The moves that would clip the part do get lifted, so it amounts to a lot of rapid slotting through material that will be cleared later in the layer. I don’t know if it is exactly/only the moves that would clip the part that get lifted.
That continues down to the first layer where several no-lift moves do clip the part. Below that no more unlifted moves pass through the part.
There are also lesser problems including not respecting conventional milling preference.
Selecting depth-first produces a path that starts out looking great, then starts to suffer from the non-lifting move problem, including moves between shallow “depth first” pockets that pass through an extra layer of not-yet-removed material, then becomes very disordered with deep pockets cut under material that gets air-cut later and running a stack of profiles from the bottom up. By shuffling chunks of gcode in a text editor, I can re-arrange the result into a mostly-not-crashing path that appears to account for all of the slicer result.
I don’t expect this description to help much without input/output examples but don’t see an easy way to attach them.
Sidebar: it looks like a lot of needless moving back and forth between areas to clear comes from the slicer connecting some but not all “concentric” & adjacent circuits of nested groups. I can kind of see how the non-connections arise from area partitioning. Maybe it’s hard to solve?