I did my first carve of kiri-generated code today. It went well! I have to say, the visualization you get from the slicing/previewin and animation saved me a lot of mill time.
But there was one problem, which wasn’t a killer since contouring takes such small passes, but it should be fixed.
You can see the problem in the pictures. In the photo, the lowered shelf in the stock, between the arms of the ‘U’, shouldn’t be there. It was formed by the contouring pass which was going over each end of the ‘U’, and traversing the shelf in between, without going up to a full save Z height.
You can see the contour passes in this screenshot of the preview screen. I didn’t use outlining – just roughing.
Using roughing without outlining also shows another buglet – I had “leave stock” set in the roughing pass, and the contouring cleaned it up, just as outlining would have, except for a narrow band at the base of the part which isn’t curved – it’s a very short vertical wall before the semicircular cross-section starts. You can see this very small “shelf” in the photo. (I used roughing because outlining doesn’t offer a step over setting, which I (at least thought I) wanted.)
I think I see. You chose curves only and it ended up making an unsafe rapid move? Perhaps you could annotate the images with circles or something to show the areas of interest so there’s no confusion.
I think you’ve got it. But here they are again, highlighting the problem area. In the photo, I’ve marked where the contouring pass unexpectedly cut through deep uncleared stock. In the kiri screen shot, I’ve shown the passes that did this.
While we’re at it – I was a little surprised at all of the seemingly “extra” Z moves during contouring of this part. The results are fine, but it seems that when it comes to the area on top of the domed profile that it decides is flat (?), it raises the head and skips it, rather than simply traversing. Obviously this falls into “optimization”, not “bug”. (When your mill is as slow as mine is, and you’re wondering whether you can get a carve in before dinnertime, these things matter. )
Yep. I know how to fix this. But it’s part of a much larger refactor of path routing. I kind of figured it out last night, but don’t want to change that much code this close to the 2.4 final. So it’ll be some of the earliest 2.5 code changes.
Also, just fixed the above original big report above for today’s release.
If the fix didn’t make it into D11, then ignore all this.
But assuming it did make it in, then the fix is incomplete. I don’t know if the profile/workspace you have from yesterday will show it. Probably will, but I’ve made a few changes: bigger tabs, different bit for every pass. I’ll send you a new export if you need it.
The errant moves are gone if curves-only is set, and outlining is disabled.
If either of those settings is changed, the problem returns to varying degrees.
all part of the same issue. I’ve added additional bounds checks for tonight’s D12 release. this kind of thing is maddeningly difficult to regression test. thanks for that.
)
