Slice removal has occasional overpenetrations (Pycam 0.6.3)

[yerazunis]

Version 0.6.3 of Pycam's "slice removal" seems to occasionally insert silly little extra cuts down an extra millimeter or so.

Attachment 1 shows the Pycam rendering of the g-code of the die being sunk - there are four little pips of overcut on each side wing. They're really there in the G-code; I ran it anyway and yep, it's real.

Also attached are files to reproduce the bug including the STL and the OpenSCAD to create the STL.

Tool is 6.37mm diameter flat-end milling cutter, 1000mm/min cut rate, 80% overlap, 0.5mm stepdown, 0 material allowance, Y direction (left-to-right in the screenshot), milling style "ignore".

Making small changes (i.e. 89 to81% overlap, 0.5 to 0.49mm stepdown) still shows the bug; it's robust.

Interestingly, "surfacing" process does NOT show the bug.

Files to reproduce the bug here. Thanks; ---- Bill Yerazunis cf.zip

EDIT: Screenshot of the eight little "pips" of overcutting during slice removal; they're the eight little paths hanging down alone (four under each "wing" of cutting; they're quite real.):

[yerazunis]

Actually, I'm wrong. The "surfacing" process shows the bug too (it just hid it better - till I broke a $40 solid carbide bit).

Basically, in the model above, the high-slope parts work fine. The problem is in the low-slope ramp; the routine that finds surface intersection between a low-slope surface and a proposed path gets it wrong. So, the X direction milling paths (which never do low-slope pathing on this STL model) are fine; the Y-direction (low-slope) grossly undercuts.

To see if it's axis-dependent, I swapped X and Y in the model - and then Y was fine and X undercut.

Spiral cutting (in or out) - same result again- high slope is fine, low slope is wrong.

Changing the boundaries (inside, outside, at) and making the bounding box smaller showed the problem unchanged.

[sumpfralle]

What a pity! :(

Can you point me to a smaller x/y bounding box, that I could investigate? (it is hard to see the problem with these many moves in the big model)

[yerazunis]

No problem. Here's the male die; it's perhaps easier to see the bug here:

male_die_stl.zip

If the above doesn't work, you'll need to generate the male die (I think the model I included was the female die, just open the SCAD file in OpenSCAD, comment out line 87 "female_die();" then un-comment line 113 "male_die();" . Hit F5 to recompute, F6 to do final compute (each may take a few seconds). Then "File" -> "Export" -> "Export as STL" and give it a new name.

Get into PyCAM. I'm using the curret-today master branch. Load the above STL.

Set up to use a quarter-inch (6.37mm roundnose bit)

Set process to "surfacing", then "spiral" pattern, center to out.

Set overlap 50%

Set boundary to be the model.

Switch to tasks. Choose the male die model.

Generate toolpath.

View - you may want to toggle your model on and off, so you can see the toolpath not going up and down the shallow ramp like it should. Instead, there's a flat spot on the ramps (see the second screenshot below).

The following screenshots taken just now (20190816 - 20:55 EDT) running a fresh download of the current GitHub master:

Note the toolpath disappearing into the ramp (the ramp goes all the way up to between the two pylons):

Thanks! I was going to look into this on Monday myself. It's probably a silly little thing.

- Bill

[yerazunis]

A better angle on the screenshot, showing the paths going flat through inside the STL in the area between the pylons, where it should ride up and down the ramp instead.

[[[ sorry for the multiple edits. This is pretty much my first time using Github and I am clueless. ]]]

[sumpfralle]

Thank you for your helpful presentation of the problem! I will investigate it ...

[sumpfralle]

I think, I fixed the issue with the surface operation. Please take a look at #115 (branch 144-fix-toolpath-glitches).

Regarding the slicing issue, that you encountered: could you please try to find a smaller (or better visible) operation exposing this issue? For now I failed to see it ...

[yerazunis]

Testing against the male bending die that failed so spectacularly before:

Test cases and results against branch 144-fix-toolpath-glitches :
Surfacing with a ball tool - works correctly in spiral-in, spiral-out, grid-x, grid-y, and grid-xy. Slice removal with a ball tool - seems to work correctly in spiral-in and spiral-out (but hard to visualize). Slice removal with a flatend tool - seems to work correctly in spiral-out, grid-x, and grid-y (but again, it's not so easy to see because slice removal has lots of paths above the work surface).

In any case, note the difference between the new (sumpfraile, 144) code results shown below, and the same case with master branch (most recent screenshots above and the screenshot in the original bug report.).

I'd say this bug is well and thoroughly squashed!

• Bill

Slice removal with bug fixed:

Surfacing fixed:

[yerazunis]

(noob question- should I close this now, or wait till branch 144 is pulled into the master branch?)

[sumpfralle]

Thank you for testing my proposal! I am glad, that it fixes the surfacing issue.

But regarding the slice operation, I am quite sure, that my changes did not affect this part of the code. Maybe you want to take a good look at your next toolpath before risking another tool?

(noob question- should I close this now, or wait till branch 144 is pulled into the master branch?)

This is indeed a very good question: every project handles this differently. Within the pycam project the merge into the master branch would be the right time.

Thus I am closing the issue for now. But if you notice a problem with the slice operation (as in your original report), then please re-open it for further investigation.

Thank you for your well prepared analysis of this bug! I am glad, that it is fixed now ...