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?
Hi @pmc and welcome! I can reproduce your problem if you can email me two things (sa@grid.space): the STL file and the .b64 file that you get when you choose export under the user/gear icon. Make sure you are in the CNC mode with the settings you are using to duplicate the bug when you choose export.
I see what’s happening in the simpler case. It’s going bottom up on the outside of a cone. unusual and unexpected. but I’m not 100% sure it’s a collision.
It appears to me that cutting an outline of a cone in a bottom-sequence collides with all the layers above that are not d*stepover “smaller”. That doesn’t matter in simulation or cutting very soft material where fineness of step-down is for detail, but does matter if the step-down is all a machine can eat.
Following up on up-going outlines: I agree that’s not a collision when the outline operation is finishing a pocket that is already roughed out – and not too near to vertical.
The problem is with roughing operations that appear to leave a step-over of material around the pocket to be removed by a series of outlines that gets sequenced as if all the roughing were already done. Then an up-going outline has to plow through more than a step-down of overburden.
I agree this is perhaps not optimal. I’ll need to get back into the code (which is a difficult recursive head-space) for a bit to see if I can find a relatively simple fix. I’m not entirely sure this is causing more material to be removed than a standard step-over. The current code is supposed to prevent that by ensuring that all areas above the current cut (dictated by step-over) are cleared, or otherwise disallowed.
While I’m working up a cleaner example(s?), here’s a quick pointer to the most dramatic problem with the “ps1-rough-depth-kiri.nc” example that I emailed earlier:
The 6 pockets beginning line 6964(ish) and the dozen full-depth pockets beginning line 7920 collide with material that doesn’t get cut until lines 15747-16827. In CAMotics’ simulator, when the process gets down to the 15k-16k lines they get air-cut above the then-current working level.
Moving lines 15747-16827 up just before line 6964 puts the work basically into order.
About up-going profiles at the end: note how much material the first circuit at starting at about line 23k has to remove.
I hope my recent load of fault-finding is more helpful than irritating.
@pmc have a fix. will push to production around midnight EST (the usual time). if the fix isn’t 100%, it’s because low poly solids when sliced produce rounded features that don’t always nest properly. a vertex in a circle can appear to be outside the circle above it because of the way faces are generated. sloped curves tickle this more. there is a more expensive and exhaustive fallback which requires additional searching of the poly tree, if that becomes necessary.
thanks for taking the time to find this test case.
Once it mis-interprets that a polygon in the layer above doesn’t enclose, it repeats the error down the stack. Looking more closely, I see a problem I didn’t catch last time.
Solving that would help KM CAM succeed with more kinds of surfaces that aren’t safely 2.5d.
This up/down thing is the biggest problem I’m seeing because a machine may be unable to just blunder through a whole lot of extra material, especially considering “roughing” is likely to be pretty aggressive to begin with.
About “lesser problems” not detailed up at the top of this topic, I think a couple of them are actually the same problem and it seems like it might be relatively straightforward to fix.
KM seems pretty bulletproof about the cw/ccw direction a circuit should run relative to the finish surface it’s ultimately offset from and climb/conventional preference. It looks like running groups of adjacent offset paths left-to-right relative to feed direction for climb milling and right-to-left relative to feed for conventional milling would fully solve
not following climb/conventional preference
slotting along finish surfaces and stepping away vs. starting in waste material, which may be already partly removed, and stepping over to finish surfaces. (“finish” meaning roughly so)
I’ve skimmed the code a little but haven’t really tried to get my head around it to look at some of this myself. Optimistically, that’s a tidy single-point fix. ?.
