tool path returns to origin many times

[sliptonic]

I tried to generate a drill path for the 3.175mm holes but encountered a python exception

Drilling is a bit broken for complex objects like this. The drilling operation automatically selects anything that the drill can fit into, including inappropriate openings. That is where the "curve" errors come from.

If you go in and laboriously select only the small holes the drilling works fine. Or alternatively deselect the openings that should not be drilled.

This is not correct. The isDrillable function is not selecting the micky-mouse holes. It's only selecting the regular drillable holes. There's something else going on with the shape. I suspect that it's because the Job base object is a Part and not a body or other solid. Parts don't have a Shape property.

[GeneFC]

This is not correct. The isDrillable function is not selecting the micky-mouse holes.

OK, I stand corrected.

There is definitely something not working quite correctly, but I carelessly attributed the wrong cause.

Gene

[sliptonic]

I don't know why the bug surfaces when the job is created using the Part as a base object and not when the Body is used.
Regardless, this seems to fix it.

https://github.com/FreeCAD/FreeCAD/pull/7454

[GeneFC]

Regardless, this seems to fix it.

That change does indeed seem to fix the original profile operation and the extra drilling test mentioned above.

Thanks for the quick response.

Gene

[steve123]

I don't know why the bug surfaces when the job is created using the Part as a base object and not when the Body is used.
Regardless, this seems to fix it.

https://github.com/FreeCAD/FreeCAD/pull/7454

Not sure how to tell if this PR is included in the recent weekly build #30345? This build is dated Sep 11, 2022 which is after the date the PR was merged into master. Nevertheless, I am still encountering the "return to origin" issues.

EDIT: I checked the application bundle and this PR is present.

I simplified the model and replaced the "mickey mouse" holes with simple circular holes and removed the part container. The "return to origin" occurs as shown in the screenshot commented with the "cut side" parameter is set to "outside". If I change the cut side parameter to "inside", I do not see the "return to origin" problem.

[steve123]

Here is the modified file.

[steve123]

I think GeneFC got me thinking on the right track with his comment about rounding errors though that is not exactly what is going on here. I believe I have narrowed down the issue to when the hole size is exactly the same as the tool size, then the additional "return to origin" paths are generated for circles when using a profile operation. I believe this is likely because the circular path generated to form the hole has a zero radius and therefore a zero length perimeter and this causes the undesirable output in the gcode.

Is it possible to check for a zero radius or zero perimeter when processing circles during the generation of a profile operation? If the radius or perimeter is zero, perform a drill operation instead of attempting to generate a path with an invalid radius or perimeter?

[sliptonic]

Is it possible to check for a zero radius or zero perimeter when processing circles during the generation of a profile operation? If the radius or perimeter is zero, perform a drill operation instead of attempting to generate a path with an invalid radius or perimeter?

Doing the test is possible. Automatically switching to a drill motion is a bad idea. The geometry of an endmill is quite different from a drill bit. As is the output gcode.

If radius is zero, the hole is not profilable and should be skipped, possibly with a warning in the console

[GeneFC]

Is it possible to check for a zero radius or zero perimeter when processing circles during the generation of a profile operation? If the radius or perimeter is zero, perform a drill operation instead of attempting to generate a path with an invalid radius or perimeter?

Flagging the error or preferrably just ignoring that location is fine. Changing the operation type to drilling automatically seems like a really bad idea.

Gene

[steve123]

I think the problem is the toPath method of the Area class assumes that the shape is larger than the tool size so that a path can be created that outlines the shape. There should be a check here to determine if the incoming shape and the tool are the same size?