Improve the quality of cut for small diameter tools

[phdussud]

For small tools (tip diameter less than 0.4mm) it is far better to cut the copper using the conventional side rather than climb. It produces less burr. It turns out that FlatCAM almost gets it right. Because of the implementation of the buffer functionality in GEOS, the paths that are cutting the features are already cutting on the conventional side. However, when there are multiple passes selected in the UI, FlatCAM could also cut the "left over" copper on the conventional side (all of the features are cut on the first pass, subsequent passes only cut the left over copper). I propose that the first pass is left as is and the other passes reverse their natural path to cut the left over copper on the conventional side. I can have the change ready if desired.

[phdussud]

I am adding more explanation of the benefit of the feature With larger tools, there is enough flute volume to allow the chips to properly form and be cut free from the bulk material. When the bit gets too small, its flute volume rapidly fills with copper, redirecting the shear being applied. Instead of cutting properly, the copper smears, leading to a burr being left behind on the climb side. Even at high chiploads, the conventions side is perfectly happy while the climb side deteriorates pretty quickly.

Here is a picture showing the conventional v.s climb side cut quality

[Juan Pablo Caram]

This one might be a bit more complicated... While the geometry is perhaps consistently created in clockwise or counter-clockwise direction, the CNC Job creation will reverse the direction of the "nearest" path at any point to minimize the time the tool is in the air.

Perhaps we should investigate geometric and CNC algorithms a bit further in this issue at this time.

[phdussud]

I saw the code you are talking about. It seems that the path almost always get reversed in there. I did some experiments and always unconditionally inverted the path. It seems to change the total distance in the air completely minimally in the boards designs that I threw at it. The largest distance increase that I found was 4%. Completely negligible in my opinion. Do you know why your algorithm almost always reverse? I am talking about the following code: # If last point in geometry is the nearest # then reverse coordinates. if list(pt) == list(geo.coords[-1]): It looks like the condition for the if is almost always true. Do you have some examples where this isn't true and that makes a material difference?

[phdussud]

I looked deeper into the code you mention and the reason it almost always invert the path, is that most paths are linear rings (I am not sure which ones wouldn't be since they are a result of a buffer operation which should produce polygons), so they have the same first and last points. Since you only check for the last point, the test always succeeds and you reverse. So.... I believe that I can give you a change that would produce the right cutting direction in most cases, without compromising anything. It would be certainly better than the current state.

[Juan Pablo Caram]

Isolation routing and buffering polygons are just a specific case. In general it could be anything.

If right now, when the beginning and end of a path are the same, the end point is chosen as closer, thus reversing the direction, perhaps we can change that. But it wouldn't be a very robust change. I would depend on how GEOS chooses the direction of polygons and some tiny change in the code that someone could overlook in the future.

Do you have specific changes to the code in mind right now?

[phdussud]

I do. I will submit a pull request so you can look at the changes. I looked at the sources of GEOS, which haven't changed in 2 years and I am pretty convinced that the buffer implementation works like this by design. It would shock me if someone would change this.

[Juan Pablo Caram]

Should we change the title to this issue? I wouldn't know whats it's about just from the title.

[phdussud]

Sure! Feel free to change it anyway you want.

[Juan Pablo Caram]

I don't know much about machining. I get it that it's about the relation between the rotation of the tool, the direction of motion and where the material is. You seem to know better what this is about. I'll let you choose the title. :-)

[Juan Pablo Caram]

Did you ever get a picture of "good" results after the fix? Is this doing what you expected? In which cases? In which not?

[phdussud]

I all the cases I have tested, it gives the expected good result. I think as long as the geometry is closed, like the result of a buffer operation, everything will work. It won't be if you design some geometric elements because they are followed without a buffer operation, so there is no guarantee of which way the tool will cut. I have been thinking that maybe we should offer a "cut width" option for created geometry because you may want to isolate them like gerber elements.

[Juan Pablo Caram]

Should we close this?

[Juan Pablo Caram]

Changed priority as suspected solved.