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 wrote: ↑Wed Aug 31, 2022 12:02 amDrilling 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.
tool path returns to origin many times
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
- sliptonic
- Veteran
- Posts: 3459
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: tool path returns to origin many times
- sliptonic
- Veteran
- Posts: 3459
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: tool path returns to origin many times
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
Regardless, this seems to fix it.
https://github.com/FreeCAD/FreeCAD/pull/7454
Re: tool path returns to origin many times
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.sliptonic wrote: ↑Tue Sep 06, 2022 8:54 pm 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
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.
- Attachments
-
- Cut Side == Inside
- Screen Shot 2022-09-13 at 3.06.36 PM.png (114.9 KiB) Viewed 1009 times
-
- Cut Side == Outside
- Screen Shot 2022-09-13 at 3.07.01 PM.png (153.46 KiB) Viewed 1009 times
Last edited by steve123 on Wed Sep 14, 2022 2:52 pm, edited 2 times in total.
Re: tool path returns to origin many times
Here is the modified file.
- Attachments
-
- path returns to origin v2.FCStd
- (879.52 KiB) Downloaded 24 times
Re: tool path returns to origin many times
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?
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
- Veteran
- Posts: 3459
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: tool path returns to origin many times
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.steve123 wrote: ↑Wed Sep 14, 2022 2:16 pm 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?
If radius is zero, the hole is not profilable and should be skipped, possibly with a warning in the console
Re: tool path returns to origin many times
Flagging the error or preferrably just ignoring that location is fine. Changing the operation type to drilling automatically seems like a really bad idea.steve123 wrote: ↑Wed Sep 14, 2022 2:16 pm 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?
Gene
Re: tool path returns to origin many times
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?