[Problem] Avoid dangeruos first G-code move while G49 is active #9866
Comments
…osed to be active Changed all postprocessor using G43 to set tool height compensation after tool change to not set G49 before doing the first move to "safe" height after G54, as this would take an unexpected dive if the already active tool height was significant. Fixes FreeCAD#9866.
…osed to be active Changed all postprocessor using G43 to set tool height compensation after tool change to not set G49 before doing the first move to "safe" height after G54, as this would take an unexpected dive if the already active tool height was significant. Updated tests to expect the new output. Fixes FreeCAD#9866.
…osed to be active Changed all postprocessor using G43 to set tool height compensation after tool change to not set G49 before doing the first move to "safe" height after G54, as this would take an unexpected dive if the already active tool height was significant. Updated tests to expect the new output. Fixes FreeCAD#9866.
…osed to be active Changed all postprocessor using G43 to set tool height compensation after tool change to not set G49 before doing the first move to "safe" height after G54, as this would take an unexpected dive if the already active tool height was significant. Updated tests to expect the new output. Fixes FreeCAD#9866.
|
I managed to patch the code to move the G49 from the preamble to the tool change, to avoid the dangerous move happening while G49 is active. I believe a better fix would be to get rid of "G0 Z19.000" after G54, but I was unable to figure out from the code how to do so without also removing it elsewhere. |
|
I have studied the code a bit more, and it seem to me this dangerous G-code is only generated when splitting on tools, not when splitting on fixture or operation. Most likely because of a oversight, as very similar code is duplicated three places and the fix to avoid the dangerous move is only in one of the three places. I am working on an improved patch. |
…rst fixture The issue only happen when splitting jobs on tools (orderby == Tool), and when USE_TLO was active and the preamble include G49. The first move is then done before tool height is set, and can cause damage if the existing tool height is set to more than the gap between the spindle and the table or work piece, when the machine take a sudden dive straight down. Removed move between G49 and first G43, to ensure all moves are done after G43 correctly set tool height compensation. Rewrote code to introduce new method fixtureSetup() to ensure all orderby alternatives behave the same way. Fixes FreeCAD#9866.
…rst fixture The issue only happen when splitting jobs on tools (orderby == Tool), and when USE_TLO was active and the preamble include G49. The first move is then done before tool height is set, and can cause damage if the existing tool height is set to more than the gap between the spindle and the table or work piece, when the machine take a sudden dive straight down. Removed move between G49 and first G43, to ensure all moves are done after G43 correctly set tool height compensation. Rewrote code to introduce new method fixtureSetup() to ensure all orderby alternatives behave the same way. Fixes FreeCAD#9866.
…rst fixture The issue only happen when splitting jobs on tools (orderby == Tool), and when USE_TLO was active and the preamble include G49. The first move is then done before tool height is set, and can cause damage if the existing tool height is set to more than the gap between the spindle and the table or work piece, when the machine take a sudden dive straight down. Removed move between G49 and first G43, to ensure all moves are done after G43 correctly set tool height compensation. Rewrote code to introduce new method fixtureSetup() to ensure all orderby alternatives behave the same way. Fixes FreeCAD#9866.
…rst fixture The issue only happen when splitting jobs on tools (orderby == Tool), and when USE_TLO was active and the preamble include G49. The first move is then done before tool height is set, and can cause damage if the existing tool height is set to more than the gap between the spindle and the table or work piece, when the machine take a sudden dive straight down. Removed move between G49 and first G43, to ensure all moves are done after G43 correctly set tool height compensation. Rewrote code to introduce new method fixtureSetup() to ensure all orderby alternatives behave the same way. Fixes FreeCAD#9866.
…rst fixture The issue only happen when splitting jobs on tools (orderby == Tool), and when USE_TLO was active and the preamble include G49. The first move is then done before tool height is set, and can cause damage if the existing tool height is set to more than the gap between the spindle and the table or work piece, when the machine take a sudden dive straight down. Removed move between G49 and first G43, to ensure all moves are done after G43 correctly set tool height compensation. Rewrote code to introduce new method fixtureSetup() to ensure all orderby alternatives behave the same way. Fixes FreeCAD#9866.
|
Why is FreeCAD messing with tool length compensation at all? My toolchanger also uses compensation to set the relative tool "origins" and each time you call G49 you're overriding my tool changer and, if I'm not paying attention, ruining my work. I've been hacking the linuxcnc post.py to not emit those because letting FreeCAD do it is what's dangerous on my machine. |
|
[DJ Delorie]
Why is FreeCAD messing with tool compensation *at all*? My
toolchanger also uses compensation to set the relative tool "origins"
and each time you call G40 or G49 you're overriding my tool changer
and, if I'm not paying attention, ruining my work. I've been hacking
the linuxcnc post.py to not emit those because letting FreeCAD do it
is what's dangerous on my machine.
I assume G40 is a typo for G43. Are you saying your machine has set up
M6 to call G43 automatically? It is not always the case, so other
machines like the one I am testing need explicit calls to G43. If your
M6 call G43 on your machine, you want to use --no-tlo ("suppress tool
length offset (G43) following tool changes") when calling the linuxcnc
post script. Should be no need to hack the linuxcnc post.py.
…--
Happy hacking
Petter Reinholdtsen
|
|
Yes, I implement M6 as a wrapper around M6, which does the tool selection, tool length probing, and sets a relative length with G43. I do have --no-tlo in my spec, but that just keeps freecad from adding the H parameter to tool changes. It doesn't control the G40..G49 codes in the preamble and postamble (unless my version is behind... I'm running 0.20.2 via Fedora 37) Also, since I have to add --no-tlo (or other options) to every new job, and it's VERY expensive to get it wrong, hacking the script is a cheap bit of insurance. |
|
[DJ Delorie]
Yes, I implement M6 as a wrapper around M6, which does the tool
selection, tool length probing, and sets a relative length with G43.
Not quite sure what M6 as a wrapper around M6 mean.
I *do* have --no-tlo in my spec, but that just keeps freecad from
adding the H parameter to tool changes. It doesn't control the
G40..G49 codes in the preamble and postamble (unless my version is
behind... I'm running 0.20.2 via Fedora 37)
The edition in
https://github.com/FreeCAD/FreeCAD/blob/master/src/Mod/Path/Path/Post/scripts/linuxcnc_post.py
will not emit G43 if --no-tlo is used.
I suspect your question about out why G43 is used by FreeCAD is already
answered - some machines need it -, and this patch is already in master,
so there should not be much more to add here.
…--
Happy hacking
Petter Reinholdtsen
|
|
The edition you linked to still has G49 (not G43) in the preamble. Emitting G49 breaks my tool length probing. I have yet to add support for the tools which have X and Y offsets but I assume they'd be affected by the other codes. LinuxCNC lets you re-implement some G and M codes as scripts (either NC scripts or python). Within those scripts, the original meaning of those G and M codes is available. So a toolchanger script would be used to implement M6, but still call M6 to register the actual change. |
|
[DJ Delorie]
The edition you linked to still has G49 (not G43) in the preamble.
Emitting G49 breaks my tool length probing.
Yes. It seem to have been there for a long time. This patch get rid of
the dangerous G0 move between the G49 and the G43, but did not touch any
of G49 nor G43. No idea about the history of the G49, but found it nice
to see that G43 is part of the default behaviour.
LinuxCNC lets you re-implement some G and M codes as scripts (either
NC scripts or python). Within those scripts, the original meaning of
those G and M codes is available. So a toolchanger script would be
used to implement M6, but still call M6 to register the actual change.
Aha. I assumed that would trigger endless recursion.
…--
Happy hacking
Petter Reinholdtsen
|
Ha! So did I. Took a while to wrap my head around it :-) |
Is there an existing issue for this?
Version
0.20 (Release)
Full version info
[code] OS: Debian GNU/Linux 12 (bookworm) (KDE/lightdm-xsession) Word size of FreeCAD: 64-bit Version: 0.20.2. Build type: Release Python 3.11.1, Qt 5.15.8, Coin 4.0.0, Vtk 9.1.0, OCC 7.6.3 Locale: English/United States (en_US) Installed mods: * freecad.gears 1.0.0 [/code]Subproject(s) affected?
Path
Problem description
I created a FreeCAD model and generated some Path Jobs to mill it out,
and was very surprised when the generated G-code ended up digging the
first cutter straight into the work table. This is using the linuxcnc
post processor, but is unrelated to the postprocessor used.
The model is available from
https://codeberg.org/pere/thinkpad-x230-dc-socket-bracket . I
used the G-code in the subdirectory linuxcnc-jobs in commit
ff248e59b7c44bda3e6320e6499ee9c240156dae for this failure.
I tracked this down to the first move in the generated in the G-code
file, which is a "G0 Z", which is no longer safe when the
15 cm tool height compensation has been wiped out with the G49 in the
preamble.
This is the generated G-code:
I see from https://forum.freecad.org/viewtopic.php?t=37839 the issue
has been known since 2019, and was even mentioned as an issue when the
introduction of G43 was discussed in
https://forum.freecad.org/viewtopic.php?t=27180 .
It is unclear to me why the G49 is used in the preamble to begin with.
Is it not better to put it just before the G43, and avoid any G0 move
before G43 has been used to load the correct tool height compensation?
I had used the automatic tool height measurement in the machine to set
the correct tool height compensation for the tool holder and bit in
question, and was very surprised to see that it dived straight down as
the first move. Was not able to stop it quickly enough to avoid
damage.
Anything else?
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: