Improve "Inkscape" cleanup to be more flexible

[tschundler]

The cleanup wasn't working for me with lots of excess plunges on SVG imports in bCNC. I think because it uses z=0 instead of a negative z. This change works well for my test cases -> #1505

Tested in Python 2.7 & 3.8

[Harvie]

What is "inkscape cleanup"?

[tschundler]

The "Postprocess Inkscape G-Code", which is really code to avoid pointless z-motion when plotting. Inkscape's gcodetools and bCNC's own SVG import produce such moves with files like the attachment in #1505. Really, it could use a better name.

[Harvie]

so basicaly you just remove z0 at the end of lines? i don't fully understand the code but it raises few little concerns:

1.) if you are already on Z0 and then another g-code line issues Z0 again, this is not actualy considered a "move". But yes, i agree it is probably completely pointless and might even be annoying.

2.) do your changes accept the fact that inkscape design can be imported with arbitrary height, not just Z0?

3.) Have you seen the flatpath plugin in CAM menu? Seems to serve very similar purpose:

[tschundler]

The actual Z value is never referenced in my update. The issue with the original is it assumed a negative Z, and so it was looking for going from negative Z to positive Z. That doesn't work when you are plotting/engraving at Z0. So this only looks at changes in z, and if there has been no X/Y motion and Z lands at the same place, remove it. The drawing/engraving plane may be 0, may be -10, maybe even +10, it doesn't care.

The problem in some SVG->GCode tools - Inkscape and bCNC itself and juicy-gcode, probably others - is anywhere a path ends, it moves Z up then back down to the same spot, doing nothing. If "down" were negative, the old code would comment out the pointless Z move, but it is an incorrect assumption that pen down is always negative Z.

If you open the example file in the bug, "Flatpath" does nothing. It makes the plane for G1s all Z0, but they were already zero. But if you run my path of the same file you'll see lots of z motion removed. (Flatpath is a nice alternative to "cut" when importing SVGs)

[Harvie]

So you remove safe-z rapids between shapes in case where the next shape starts where the previous ends?

Weird thing about this is that bCNC should automaticaly join such shapes to single block upon import. I wonder why this doesn't happen... When you import DXF with 8 lines forming two separate rectangles it will automaticaly detect two rectangles and only add safe-z rapids between the rectangles, but not between the lines. Should work similary with SVGs. However it requires two adjacent points to be precisely aligned. If there is not enough precision and there is (too big) gap between lines, it will fail to assemble the shape.

[tschundler]

It's not looking at rapids, since the original code didn't care G0 vs G1. It's removing movement where dx & dy stay ≈ 0, and z goes up or nowhere and ∑dz ≈ 0.

bCNC does not seem to do any cleanup on import of the attached file:
wingcirc.svg.zip

Flat cut or "flat path" and there are many no-op raise to safe Z and lowers. Does the fix on import maybe only work with lines and not arcs? Or maybe it assumes too much from floating point numbers. In my code, my concept of zero delta is fuzzy since expecting floating point numbers to == each other, especially after any transformation, is asking a lot. So maybe there's some other code that needs to accept fuzzy matches.

[Harvie]

bCNC has several hardcoded precision levels. if two points fall within this distance they are considered equal. Tuning this in the past was pain for me. It kinda works now, but it is not perfect and i am not sure if this can ever be fixed, because we will probably never have 100% precise calculations. Also when you relax the precision too much, you will start having oposite kinds of problems. Also various CAD software produces DXF files with various precision, overall this is PITA.

I would be happy if you can figure some improvements. (other than simply relaxing precision :-)

Here are the tolerances defined at the top of the file:
https://github.com/vlachoudis/bCNC/blob/master/bCNC/lib/bpath.py

split2contours(self, acc=EPSV) method does determine which shapes do belong together... But i am not sure, maybe the SVG import does use different code. Maybe we just need to add this to SVG import code, comparing it to DXF import code which should be handling this correctly.