tool path returns to origin many times

[Jipe]

Hi there,
Here we reach the limits of the software. FreeCAD cannot replace the operator in his machining process. Each tool has a typical and rational use that should be respected to obtain the expected result. The most suitable tool for making a circular hole is the drill bit. Depending on the desired precision, it will require one or two operations (before drilling + calibration).

Wanting to use an end mill for this kind of operation is a very bad choice; the chip flow is ridiculous compared to a drill bit. The geometric qualities will be catastrophic since they are subject to the bending of the tool and to the games of the axis drive system.

Given the number of holes, there is a lot of time to be saved by using the right tool. Even with a "Mickey Mouse" profile, the roughing of the cavity by drilling, in the center, makes it possible to optimize the cutting parameters for shaping the final profile.

A change of tool is often preferable to using the "magic" tool which can drill, face, contour and provide a poor result.

JP

[freecader2]

Hi,

I've run in to a similar issue, though not sure if it's the same cause. In a profile Op containing multiple shapes, the toolpath returns to 0,0 a few times unnecessarily in the middle of the Op. In my particular Profile Op, it happens three times. The base of the Op contains three holes that are too small to be milled by the Op's tool. I suspect this is related.

I found that the 0,0 gcodes come from Path.Op.Area:_buildPathArea. It gets called for each shape that results from the base of the Op, and appends gcode from Path.fromShapes to build the Op toolpath. It keeps track of where the end of that gcode moves the tool to.

However sometimes Path.fromShapes returns no gcode to move the tool, but still returns an "end_vector" with default values 0,0. (I think this is happening for the Op shapes that are too small for the tool).

When a shape produced no milling motion and returns the default 0,0 vector, _buildPathArea still keeps track of that 0,0 as if the current shape's gcode moved the tool there. So it uses 0,0 as the start point for the next shape. Which causes the tool to move to 0,0 unnecessarily before cutting the rest of the next shape.

To fix this, I propose https://github.com/FreeCAD/FreeCAD/pull/8846 to change _buildPathArea so it will only update its tracking of the shape's toolpath's end location if the shape results in any gcode to move the tool. This way it will only keep track of the tool's end location when it receives actual tool coordinates from Path.fromShapes, and not the default 0,0. This way the toolpath generated from the next shape in the Op will start at the actual location wherever the tool was left from the previous toolpath segment.

Some other techniques we could explore are:
- Avoid including shapes that won't produce gcode movement. But this might be a chicken and egg problem since this is where the gcode is generated.
- Update Path.fromShapes to return None or an exception if the shape doesn't result in any toolpath, and catch that in _buildPathArea

Any thoughts on pros/cons of these options? Or other ideas?

Thanks!

Screenshot from 2023-03-12 10-38-30.png (35.83 KiB) Viewed 331 times

Screenshot from 2023-03-12 10-36-53.png (24.45 KiB) Viewed 331 times

[GeneFC]

The obvious question is whether this will introduce tool crashes in some cases.

I certainly cannot say that it will, but it should be tested in some manner.

Gene