YATC. Yet Another Tool Crash !

Here's the place for discussion related to CAM/CNC and the development of the Path module.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Post Reply
User avatar
freman
Veteran
Posts: 2201
Joined: Tue Nov 27, 2018 10:30 pm

YATC. Yet Another Tool Crash !

Post by freman »

Yet Another Tool Crash !

Once again I have a broken tool and trashed work piece after being caught out by drilling paths which refuse to apply safety heigh and clearance height.

This is quite a complex part into which I've already invested a lot of time and a large chunk of metal. I will try to remain polite but I'm, let's say, not happy.

What is the point in having safety/clearance heights defined in an operation if the Path WB just ignores them !?

This issue has been discussed several times in recent years and never gets resolved. The inconsistency from one path tool to another on what FC actually does makes it even more likely that you get caught out or forget to open the file and hand edit in the REAL safety height so that it does slam you tools in the clamps and/or work piece at full speed rapid movement.

I recall last time this came up ChrisB layed out a very thorough list of questions which need to be addressed in assessing where this needs to be applied and the various options for each circumstance. This seemed like a very serious, methodical approach but sadly it just ended there and once again got swept under the rug.

There are plenty of things that can be a bit annoying or various limitations of the capability of Path WB this catastrophic destruction NEEDS fixing. Smashing work pieces and tools is not an acceptable "limitation".

Here is the gcode produced without the post processor.

Code: Select all

(centreDrilling135)
(Begin Drilling)
G0 F0.000000 Z90.409167
G90
G98
G0 F0.000000 X-12.000000 Y-10.001000
G0 F0.000000 Z59.000000
G81 F2.000000 R59.000000 X-12.000000 Y-10.001000 Z48.000000
G0 F0.000000 X-174.000000 Y-10.001000
G0 F0.000000 Z59.000000
G81 F2.000000 R59.000000 X-174.000000 Y-10.001000 Z48.000000
G80
G0 F0.000000 Z78.409167
G0 Z90.409167
https://www.cnccookbook.com/g98-g-code- ... ate-modes/

G0 F0.000000 X-12.000000 Y-10.001000 is fine but why does it then move to start depth BEFORE the drilling command G81, which already has that move implicit in it?

With G98 in force , G81 F2.000000 R56.000000 Z48.000000 would rapid to 56 ( start depth ) and rapid retract to Z90.409167 ( safety height ) to clear the work and clamp before moving to the second hole.


I'm running current master but this has remained a problem since at least two years ago, probably longer.

Code: Select all

OS: Fedora Linux 36 (Thirty Six) (LXQt/lxqt)
Word size of FreeCAD: 64-bit
Version: 0.21.0.32468 (Git)
Build type: Release
Branch: master
Hash: 30e815a69d339421367ad7b5ef0391833ba8e497
Python 3.10.10, Qt 5.15.8, Coin 4.0.0, Vtk , OCC 7.6.3
Locale: English/United Kingdom (en_GB)
Installed mods: 
  * FreeCAD_Assembly4 0.11.10
  * FreeCAD_assembly3
Attachments
trashed-tool.jpeg
trashed-tool.jpeg (117.36 KiB) Viewed 854 times
Last edited by freman on Fri Mar 24, 2023 9:30 pm, edited 3 times in total.
Syres
Veteran
Posts: 2893
Joined: Thu Aug 09, 2018 11:14 am

Re: YATC. Yet Another Tool Crash !

Post by Syres »

but sadly it just ended there and once again got swept under the rug.
Please log it in the GitHub Issues if you're certain it hasn't already been done then it can be kept updated with all testing and any PRs submitted are automatically linked.
User avatar
freman
Veteran
Posts: 2201
Joined: Tue Nov 27, 2018 10:30 pm

Re: YATC. Yet Another Tool Crash !

Post by freman »

The trouble is this is not a bug it's broken by design. That is why there needs to be a clear discussion and criteria to be set for what it should be doing, hopefully consistency between drilling , helix etc., and correct documentation.

If I do a helix path on the same two holes, I get a safe clearance height between them and don't break my endmills.

Code: Select all

G0 F0.000000 X-12.000000 Y-10.001000 Z19.000000
G0 F0.000000 Z56.000000
G0 F0.000000 Z90.409167
G0 F0.000000 X-174.000000 Y-10.001000 Z90.409167
viewtopic.php?t=51887&start=10#p445766
[Rant on]

Unfortunately, an occasional forum participant dropped in a bit more than a year ago and made arguments to greatly change the behavior of canned cycles, G81 and G83. He then proceeded to create pull requests which were accepted, against my vehement arguments. The result was that the industry standard behavior of these canned cycles was completely destroyed. Each hole drilled is followed by cancellation of the canned cycle. Then a new canned cycle is started. Makes no sense, but that's the way it is.

That is why the height behavior is so strange.

I fixed the problem through custom mods, so I no longer care. But it is still a big problem overall for the Path WB.

[Rant off]
I second Gene's rant. This silly, non standard and inconsistent behaviour is smashing tools and work.

What we have here is two separate canned cycles which are constructed in such a way as ignore the G98 by rigging it to be the same as G99.

The preceding XY move is redundant as well since that is the first thing a G81 does ( unless we are catering to defective Gcode interpreter which does not do this correctly, and that should be dealt with in a post-proc if that's the case).
jbraun
Posts: 252
Joined: Fri Sep 18, 2020 5:41 pm

Re: YATC. Yet Another Tool Crash !

Post by jbraun »

Hopefully I have not downsized the included image to unreadable.
My frustration with drilling isn't a crash but relates to R.
drill_ink.png
drill_ink.png (7.64 KiB) Viewed 690 times
The red bars indicate where I would like to set R in relation to the top of the holes. This would eliminate feeding through empty space.
The code FreeCAD posted works okay for linuxcnc with this exception. Honestly I can live with doing some small edits but thinking through this problem may lead to a rethink of some other parts of drill op.

Code: Select all

(Begin Drilling) 
G0 Z0.4000 
G90 
G98 
G0 X0.5000 Y0.5000 
G0 Z0.1181 
G81 X0.5000 Y0.5000 Z-2.0000 F20.0000 R0.1000       <<< changed to R-0.9 
G0 X2.5000 Y0.5000 
G0 Z0.1181 
G81 X2.5000 Y0.5000 Z-2.0000 F20.0000 R0.1000      <<< changed to R-0.4
G0 X4.0000 Y0.5000 
G0 Z0.1181 
G81 X4.0000 Y0.5000 Z-2.0000 F20.0000 R0.1000      <<<changed to  R-0.9
G80 
G0 Z0.1181 
G0 Z0.4000 
(finish operation: Drilling)
Z0 is top of part because..... well, I won't get started on that controversy again :)
This code tests okay for linuxcnc, possibly it's garbage in other controls ?
For English help on youtube check out Joko Engineering or Mango Jelly Solutions.
Look for recent videos, this software is updated at a rapid pace.
User avatar
freman
Veteran
Posts: 2201
Joined: Tue Nov 27, 2018 10:30 pm

Re: YATC. Yet Another Tool Crash !

Post by freman »

This would eliminate feeding through empty space.
Do you mean rapids or cutting feed rates? G0/G1.

FreeCAD is a mess in this area because it uses G98 and has been hacked to make it more like G99. As a result it does neither correctly.

The lines like for following are redundant because G81 does that anyway , it just messes up the "current_z" value which G98 uses to retract to.

Code: Select all

G0 X0.5000 Y0.5000 
G0 Z0.1181 
Without that, it would have returned to safe height without being explicitly told to. This should NOT be the R value of the drilling command. That should be close to the surface or whatever you set "start depth" to.

Wsk8 did a PR about a year back which added a "keep tool down" check box. I did not support the PR at the time because it did not resolve the G98/G99 issue and the discussion got dropped entirely instead of being fixed.

I'm currently trying add this check box use it to control G98/99 and get FC to deal with both cases correctly and in accordance with NIST specification instead of attempting to redefine it.

If you are doing your example as one operation it will have the same drilling start height for all three. If you want to avoid cutting air you'll need three ops. Set one up, use clone path tool and edit the start height of the clone.
jbraun
Posts: 252
Joined: Fri Sep 18, 2020 5:41 pm

Re: YATC. Yet Another Tool Crash !

Post by jbraun »

Cam generated will seldom be as concise and clear as good manual coding.
I gather some changes to drill op have been made for the worse(?) but don't know the 'why' of those changes.

According to the wiki 'Start Depth' is 'Starting depth of Tool - first cut depth in Z'
To avoid crashing I ignore that definition and set Start to a clear height, which results in the air drilling which wouldn't happen.............
IF there was an option to set R relative to top of holes-----as found in other Cam software. Working g-code for this is shown above and can be seen in the output of other Cam.

So yes 'Start Depth' should work logically and I'm veering off into an extra capability. If my python skills were above Crayon level I would offer to help. Unfortunately those skills are what they are.
For English help on youtube check out Joko Engineering or Mango Jelly Solutions.
Look for recent videos, this software is updated at a rapid pace.
User avatar
freman
Veteran
Posts: 2201
Joined: Tue Nov 27, 2018 10:30 pm

Re: YATC. Yet Another Tool Crash !

Post by freman »

According to the wiki 'Start Depth' is 'Starting depth of Tool - first cut depth in Z'
Due to inconsistencies, what wiki says about safety height does not apply. Also 'Start Depth' is not what is used with drilling because it adds stocksheet.safety offset for some reason, again ignoring what the user entered.
----as found in other Cam software.
What software is that? Does it specify an offset for all holes in an op or let you specify an offset for each hole?

I'll be glad if we can get these changes accepted to fix G98/99, I double any restructuring to apply different values will happen. The best solution for your needs would be cloning the path to a single hole and editing the start depth. At least that would be saved in FCStd and you would not need to remember each time you process a path. That is susceptible to error.
jbraun
Posts: 252
Joined: Fri Sep 18, 2020 5:41 pm

Re: YATC. Yet Another Tool Crash !

Post by jbraun »

freman wrote: Mon Mar 27, 2023 5:34 pm What software is that?
Fusion 360 has that option.
Also Mastercam although my memory is it being a bit of a chore. I don't have access to Mastercam now but used it daily long ago.
Does it specify an offset for all holes in an op or let you specify an offset for each hole?
Selected all holes at once in Fusion. The way I've done it results in a few G80's inside the op but not all possibilities were explored.

FreeCAD doesn't seem to have a convenient way to sort the sequence of holes ? If true that's a more serious limitation than my 'feature request' and limits the usefulness of that request. I cancel my request and now ask for hole sorting :)
Thanks for working on the G98/G99 confusion as the way this (doesn't) works now is plain silly.
For English help on youtube check out Joko Engineering or Mango Jelly Solutions.
Look for recent videos, this software is updated at a rapid pace.
User avatar
freman
Veteran
Posts: 2201
Joined: Tue Nov 27, 2018 10:30 pm

Re: YATC. Yet Another Tool Crash !

Post by freman »

Yes, hole order sorting would really be an advantage. I've suggested this myself about a year ago.

I looked into the code needed to implement it because it should be relatively simple to drag elements in the list to reorder them.

Sadly at the time I looked into it, the Qt widgets used for that kind of UI list were BUGGY and drag and drop did not work. At that point I gave up. I have not looked at whether this issue has been fixed since.
Post Reply