I was using 2.3.D2 earlier, and I see that you’ve already fixed a few things from that in D3
This pic shows a problem with roughing in D2 & D3. The part grows wider from the top down to mid-height, so outside outlines expand as they go down the upper part of the part. The roughing pass clears material over the part, but does not clear material around the upper part of the the part over material that lower outlines grow out into:
(There is no hole because I wanted to rough the hole and teeth separately and I didn’t see a way to do that. Today I’m not sure I would want to separate those operations again, assuming depth-first, so this isn’t about that.)
Today in D3 the same fails with an error:
“TypeError: Cannot read property ‘clone’ of undefined”
The hexagonal example I’ve been using also induces the TypeError.
So a decision has to be made about how to resolve this. In 2.2 roughing will clear outside the part boundaries down to the surface, which can end up cutting out a part. That’s good and bad. It was some complicated code, and I can re-add it. As of now, though, roughing stays strictly inside the part boundaries. As you see, this creates a problem for outline. In order to solve the above, outline needs to perform a cut down through the actual part outline, and not just do waterline offsets. And that sort of defeats the elegance of the outline.
A bunch more fixes are coming later tonight. The TypeError you pointed out above is one of them.
I’ll cast a vote for an option to rough all the way down – with provision for not cutting out parts prematurely. Below I’ll relate that to outlining
I’d like to have the all-the-way-down roughing option with ‘leave stock’ and ‘wide cutout’ parameters.
Maybe call ‘wide cutout’ by some other name like ‘wide perimeter’. Maybe call this roughing option ‘perimeter’ or ‘exterior outline’? Lots of CAM software calls the exterior outline “profile”. One calls the the operation I’m voting for “side roughing”.
To not end up cutting out parts, “all the way down” could have modifiers. Like tabs or an “onion skin” remainder. Tabs/skin/rough/finish all orthogonal, I think.
Supposing such an off-the-part roughing capability:
For outlining, I’m thinking any instance of slope requires prior removal of overlying material, regardless of whether inside or outside the part area. Proposed general solution: when a waterline outline operation generates any deviation from a straight stack of identical outlines (mod skips for tabs) it also raises an advisory notice.
Possibly add an outline option to cut straight down to the bottom outline, but I don’t have a use case in mind.
To be nice, the notice could include advice for the user to ensure one of
some prior operation clears interfering material
interfering material won’t derail the operation
(if exists) select straight-down option
 In principle KM could check if such an an op is already configured, but hair and this doesn’t depend on that.
… and a tangentially related idea
“Z thru” (happy to see that back) could evolve into a couple more offsets:
Z top offset – exists
Z bottom rough offset
Z bottom finish offset
where either bottom offset could be >0 to prevent cut-thru or <0 to ensure cut-thru.
Orthogonal to tabs e.g. very thin onion skin for vacuum table + tabs for mechanical strengh.
non-depth-first roughing & outlining basically work & produced some useful output. Yay.
depth-first preview/export hangs at “transfer”
TypeErrors mostly fixed, as you said. I did get briefly stuck in TypeErrors in some circumstance that I don’t know how to repeat. IIRC I was trying different combinations of stepdown & Zthru and some combinations provoked the error
Slicing stops above part bottom. The pic below shows roughing at 0.15mm stepdown and outline at 0.1mm with Zthru=0.2. Zthru=0.1 added another step below the outlines shown but still inside the part. Zthru=0.15 put a slice right at or very near the bottom surface. Zthru=0.2, shown, got thru the bottom by taking a larger stepdown thru unroughed material. In this case the large stepdown didn’t stop anything but did leave a lip constricting the bottom of the hole that I had to file out.
There’s been a little oddity with slicing the small bevel gear part that I sent recently. Some outlines partway down the part side are a little bigger than outlines lower down. It hasn’t been a problem. Disabling decimation and setting “best” part quality have no obvious effect. (also an example of a big Zthru to get thru)
Z levels still appear to be quantized at 0.05mm regardless of decimation. That’s fine enough for me so far. Apart from the recent saddle-point oddity, It’s only been noticeable when I tried to make outline stepdown not a harmonic of roughing stepdown. That’s prevented at sub-mm scale, but I can’t point to any case where it actually makes a meaningful difference.
The speed scale is fun - and I can see it being useful when using a different feed for finishing. (…so even if artificial, a temporary different feed would make it easier to distinguish different operations in the same display)
Trivial UI trivia: the speed scale uses the most saturated colors in the UI. The mostly-transparent config pop-outs have worked well with muted colors behind them. Now the rough/outline/contour pop-outs draw blue checkboxes over the very blue part of the scale. I don’t care - just reporting the observation.
“What is he talking about 0.05mm stepdowns?” you ask. Viz:
(today’s pair were closer to size and less wobbly on the shaft after filing the lip out - hence interest in avoiding the oversize last stepdown)
I would like to make the 2.3 series production by the end of next week. Tonight’s D7 release should not only have full support for all features in 2.2, but many more. Until today, there were still a few things in 2.2 that hadn’t made it back into the 2.3 branch.
Non-depth-first roughing is looking good. Particularly the consistent perimeter outlines.
Path ordering for depth-first outlining is looking good.
And then there’s some other stuff.
Request: I’d still like an option to double the outermost contour in roughing ops. Also inside voids when “clear voids” not selected. Like “wide cutout” except might not be cutout if tabs or not full depth or through.
When “clear voids” not selected, roughing generates triple (two extra) outlines inside voids. Pic shows bottom slice of part on right - part is not in a pocket.
??as if intended to double perimeter outlines but second outer perimeter come out as third inner perimeters instead??
(ghost part not rendered, but ghost part to left is - more about that below)
Depth-first roughing appears to generate only layer-by-layer output – with duplication – and less orderly final toolpaths than non-depth-first roughing. Depth-first generates larger gcode files that include irregular sequencing.
Moves that didn’t drag through uncut material were moves across the center. Reviewing this sequence: 1) bottom small circle, cross center to 2) top, drag to 3) bottom left, cross center to 4) top right, drag to 5) bottom right, cross center to 6) top right, drag to 7) single loop around center, jump into 8) inner circle area (shown). After clearing the inner circle area from outside in, it clears 9) the same circle at same Z again from inside out, then jumps out and 10) clears large area starting by repeating the circle already cut (7) then stepping out from there.
(I might get to more about dragging through uncut material below.)
Roughing stoped at flat above part bottom. Here’s a part that I made with a brim to induce an earlier Dx version to rough like I wanted:
D7 roughing produced this path:
It generated the outer perimeter like it was going to cut the outline all the way down, then stopped at the flat without continuing down around the brim for which the outer perimeter was generated. If intentionally stopping here, the path around the maximal outline of the part is not needed - and I’d rather it go all the way down (mod tabs or thin remaineder). (also an example of where I’d like the “wide” outline option)
I’ll vote for prioritizing solid layer-by-layer roughing over depth-first roughing. Depth-first reduction of lifting moves adds non-essential benefits of speed over multiple (sub)pockets and reduction of localized wear on Z mechanism.
Outlining with “wide cutout” does not double interior void perimeters
bottom slice - figure is not in a pocket
Outlining with “wide cutout” does double convex interior outlines that are not void cutouts
Shows slice above pocket floor.
Speculative question: is there any use case for wide/double outlines around sloped surfaces? For a slope just above a vertical surface there may be two outlines (only) around the first few setback layers, but they are 1) the single outline and 2) the path above the maximal perimeter outline below rather than two offsets from the part surface. There might be some simplification to gain from asserting that any perimeter segment that is not directly above the maximal part perimeter below it will not have any further “wide” offsetting but only its single outline. anything else between the single outline and the max part perimeter will be normally generated area fill.
Win: depth-first outlining is doing well with order of cutting outlines - I think the incremental gain for depth-first outlining is greater than the incremental gain for depth-first roughing
I get that refactoring rendering is forward-looking work.
2.3.Dx rendering has been flakey for me. The following seems pretty consistent:
After slicing (not preview), the ghost part and slices vanish, leaving only the ghost stock box. Sometimes the top slice is vaguely rendered where it coincides with the top of the stock.
Solid or wire renderings of the part will be visible.
On selecting preview, the ghost part remains invisible but the toolpath is rendered normally.
After slicing the ghost part will be visible from below the work surface, but it occludes the toolpath as if a solid rendering.
On selecting the preview display, the ghost part and toolpath will render normally.
Viewed from above the work surface and below the level of the stock top, the ghost part may or may not be visible. When rendered it is seen through the side of the stock, but rendering depends on the viewpoint being below the stock top level rather that viewing thru the side of the stock: when the part is rendered at all at this level, rolling between just above and just below the level of the stock toggles rendering off or on.
When the sliced part is not visible from between the work surface and stock top, it becomes visible when the front clipping plane moves inside the stock. The following two pics show the sliced and preview renderings from the same viewpoint with the front clipping plane intersecting the stock side. In the sliced view a) the toolpath is rendered or not along with the ghost part, and b) where rendered, the ghost part occludes the toolpath.
Also advancing the clipping plane into a void in sliced ghost part will reveal the paths inside the void - as with a solid rendering.
Adding a second part to the work surface adds another wrinkle to rendering. After slicing one of the ghost parts and toolpath are rendered – if the view point is off vertical (i.e. “home” not “top”). While orbiting an off-vertical viewpoint around the platform, two parts alternate which one is rendered. It looks like it’s always the more distant part (more obliquely viewed). At transitions - same distance from both parts - it may be possible to find views where both or neither part are rendered. As with a single part: at some angles the top slice is vaguely rendered.
In this case, unlike the single-part case, when a ghost part - and path in slice view - are not rendered they are not rendered when view from below either so they vanish entirely.
A solid or wire model will be rendered, but in sliced view the non-rendered toolpath will remain invisible. Except that when viewed from directly below, both parts are rendered.
In preview, the ghost parts alternate rendering but both toolpaths remain rendered normally.
Often when adding a new part after clearing/removing a previously imported part, KM reports an error loading the part and calls for refresh. I’ve seen this at least once when adding a second part (without removing first), maybe after some time but as long as the Onshape inactivity timeout
I saw this once and don’t know how to reproduce it:
Colliding G0 found?
Something I mentioned in email a while back:
I’ve had gcode output with variously more or fewer colliding moves like this: G1 Z-1.9661 F2500
… G1 X99.0817 Y37.0804 G0 X162.9091 Y99.0712 Z-1.8046 F2500 G1 Z-1.9661
The G0 includes a clearance height appropriate for the lateral move, but it moves diagonally to that height above the target point, raking the part on the way, then feeds back down to complete the move.
I think I found the cause, then left it alone since you’re refactoring all around there. It looks like the relevant code has survived in mode/cam/prepare.js
The first problem is self-inflicted: when “tolerance” is set to something larger than the required Z lift, mustGoUp does not get set. Fair enough[*]. Then it should move like there’s nothing in the way. Doing the ramp up to a level that it’s already decided to not clear then feeding back down slows down for no benefit.
After mustGoUp is not set, it is tested to see if the spindle should be lifted before the lateral move: no.
Then mustGoUpor the likely condition point.z < maxz are tested to see if the lateral move should go to the higher level: yes. And so it does.
Suggestion: after lifting or not lifting before the lateral move, it should just make the move at constant Z without testing again. If point.z < maxz is a relevant condition, it shouldn’t be omitted from the pre-move lift test – ??in which case skip the comparison with tolerance??
Wishlist: An option for Onshape-like mouse button mapping – at least when running in Onshape – would simplify switching between part studio and KM tabs.
Onshape complicates that with multiple mapping options. Copying the default would help more often than not. Maybe Os exposes which mapping is selected?
Minor quibble: separate checkboxes for different milling operations seemed useful for distinguishing what’s what. Limiting checkboxes to displayed operations would help to declutter.
[*]from the above Colliding G0 question: Small values for tolerance slow things down. Large values don’t appear to affect slicing for roughing or outlining, so why not? The “profile” operations show clearly the effect of large “tolerance” values. However, the naive user may not get to see that effect in the surfacing operation if s/he doesn’t get past crashes in roughing. A simple mention to look at XY profiling for effects of tolerance values might help.
It’s going to take me a while to do justice to this post. But I wanted to say that I spent a good deal of the day on rendering issues. I resolved many (most). And only just after I pushed D8 did I find the real solution. That goes out tomorrow. Disappearing objects no more.
Can I ask you to join the Discord server and share your parts with me? You can’t drop them here, but there you can, either in direct messages or in the shared channels. Email is ok, but Discord just rocks for faster collaboration and history.
I want to solve any collision issues before 2.3 goes GA. Also if there are perverse depth-first paths with your parts, I want to poke around on that, too.
Thanks for spending so much time digging in. It definitely helps me focus and prioritize fixes.
Edit: I don’t think I can get the mapping from Onshape. But I’ll look at adding an “Onshape default” selection to the UI preferences.
Edit 2: Tolerance setting is now only used in contour xy operations. Thanks for highlighting that. A new collision method was introduced that, thanks to your post, I now realize fails for tiny parts. Will fix that tomorrow. And move tolerance under contouring. Contouring is expensive because it has to rasterize the entire surface of the object at the given resolution (tolerance)
Non-depth-first (what to call that? - “breadth-first” I guess, tho seems a bit awkward) roughing works for this part alone. But when I add a second part to the workspace, the toolpath for this part crashes between inside & outside at each layer.
…but that session timed out before I got an export - and when I tried to repeat it, roughing the smaller part alone did not work but failed as shown above. So I exported that scenario. Will try sending by discourse or fall back to email.
So that’s that. Then the example spins off some other comments/issues:
breadth-first because depth-first roughing repeats a lot of work - like going down each hole in turn as expected, then including all the holes again in each layer of surrounding geometry. These parts, for example. I think for every(?) example I’ve looked at in 2.3.Dx.
those parts have plates added to the bottom to make the “inside” area bigger to trick roughing into doing the double outline with “leave stock” that I’m looking for. And the top of the ersatz “outside” surface of the plate is nudged up a squeak so the roughing op stops just before cutting the part loose.
here’s one user who would like a way to get that get that CAM result without fudging the CAD.
which would also avoid the friction of importing the CAM-tweaked part for roughing, then clearing it and importing the plain part for surfacing ops.
Happy to be set straight if I’m missing something that’s already there.
about switching parts in the workspace: after processing a part and deleting it from the workspace, KM routinely but not always complains that it needs a refresh on attempt to import the second part - whether different part or update of same part. [specific error here if I see it before sending this]
In addition to swapping part models, doing breadth-first roughing and depth-first surfacing is also an obstacle to doing both in one run. However, I’m not thinking of a use case where I’d want to do that if depth-first roughing worked.
Parts in this example have sloped outside surfaces and one or more straight vertical holes. It’s a use case for different stepdowns between inside vertical inside outlines and sloped outside outlines - but there is no “outside only” option.
for the kids watching at home, I have repro’d this bug. it seems to involve a situation involving more than one part. it’s a bug I fixed in the past in an older version of the code. but I rewrote that recently and did not test this scenario.
the onshape session bug is known. I’m working on that first thing after the 2.3 release this week. their development model makes this especially hard to debug.
first of all, thanks for this nice tool : although I’m used to 3D printing and slicing, I’ve been somewhat puzzled when I came to milling with my usual Slic3r and PrusaSlicer, Kiri:Moto saved me.
Now, I’m using Kiri:Moto for slicing CAM parts and found a functional difference between 2.2 and 2.3 with the same configuration :
with the online 2.2 (2.2.8) version, the Z origin is set on top of the stock, then the vertical movements go downwards with negative Z, from 0 to -height (minus height).
with the online 2.3 (2.3.D11) version, the Z origin seems to be set at the lower of the stock, then the vertical movements go downwards with positive Z, from height to 0.
From my slicing and CNC homing procedure it’s much easier for me to set Z0 at the top of the stock than to its base. But maybe I’ve missed something with Kiri:Moto :
is this change normal ? or is it a functional change ?
does it exist a parameter to get the previous behavior back ?
obviously milling starts from the top and goes downwards, do I have to set either Z0 at the base of the stock, or Z at the top of it ?