Unfortunate defaults for ngcgui demos

This is an issue that perhaps should be addressed to the developers of LinuxCNC , but as I consider myself a newbie in CNC (and consequently LinuxCNC) I'd better listen to what the community has to say first...

It's all about the ngcgui demo scripts that comes with the standard installation of LinuxCNC (~linuxcnc/nc_files/ngcgui_lib/). As I found some of the scripts quite useful, I have used them for "real cutting" on both my recently retrofitted 3-axis mills. Most of the times they perform just as expected, But on a few occasions there have bin some serious "glitches", where my cutter plunges straight down to the table at full speed (rapid move) the same moment as I press the "Run" button, although I carefully made a touch off at my piece surface just before start. As a rookie, I expect to make stupid mistakes causing this kind of actions, so I simply blamed the operator (me) the first times it happened.

The crashes happens within fractions of a second and seemingly by random without any visible indication in advance. Last time it happened I had a 6mm acrylic plate clamped to the table, and my 8mm endmill plunged strait through it and just started to dig in to the (aluminium) table - at 2000mm/s... If it was my colleague hitting the E-stop, or lack of power in my not so rigid mill, that made it come to stop is unclear... Very clear was the need to find out why and how this happens.

The problem I've had is related to the handling of tool length compensation in the ngcgui scrips. With a fresh install of LinuxCNC and the .ini file set up as the instructions in the ngcgui section in the LinuxCNC documentation all ngcgui scripts use the preamble file "~/linuxcnc/nc_files/ngcgui_lib/utilitysubs/in_std.ngc". As default it includes a command to cancel tool length compensation. But that command is executed before a tool change command in the ngcgui script, and that in turn calls "loadtool.ngc" which executes "T#<toolno> M6 G43", where "G43" activates tool length compensation again.

The first time you fire up LinuxCNC, load a ngcgui script and run, tool length compensation will be active as LinuxCNC starts with no tool loaded, and initiates a tool change. Next time a ngcgui script is run using the same tool, no tool change is needed, and the "G49" in the preamble in_std.ngc file will cancel the tool length compensation. This results in an unexpected down shift of the Z axis by the length of the current tool - just by a repeated run of the same program.

I should probably have noticed this behaviour if I wasn't a coward rookie, that made "dry-runs" at safe level well above my work piece to test my programming, before I touch off and do the real cut. As long as I did 2 or more dry-runs all went fine. The tool length compensation stays cancelled as long as I don't change the tool. But as I got a little more cocky, and just mad one singe dry-run before I went for a real cut, it crashed as described above.

For now I have solved this issue in my mills by removing the "G43" command in the loadtool.ngc file, making the tool length compensation remain cancelled at all time using the ngcgui scripts.

The question is if the default configuration giving this behaviour, should be changed somehow to prevent crashes like mine?

Just bumping the topic as I accidentally submitted the initial post prematurely, long before it was ready.

Steps to reproduce my problem:

If tested on a real machine:
Do this at "safe" hight well above any real objects and the table.

1. Restart LinuxCNC if already running
2. Home the machine and jog to any suitable position
3. Touch off Z axis to zero at some level above a simulated material
4. Note machine Z position (G53)
5. Create and finalize any ngcgui program that uses tool change
6. Edit tool table and enter a reasonable length for the tool selected in the ngcgui program
7. Check DRO and verify TLO Z=0
8. Run the program once
9. Jog back to Z 0

Now the DRO should show a TLO Z equal to selected tool, and machine Z position should be elevated by the same amount compared to initial value. The preamble file "in_std.ngc" command to cancel tool length compensation has no effect after the initial tool change when the program is run for the first time.

If this was intended for a real cut, it would run far to high and perhaps never touch the work piece. But if like me, doing a dry-run with a touch off high up in free air to test and verify the program, it's hard to notice that elevated Z position.

In either case a new touch off is needed for the next "real" run so:

1. Touch off Z axis to zero at the top of a simulated material
2. Note machine Z position (G53)
3. Check DRO and verify TLO Z=tool length
4. Run the program again
5. Jog back to Z 0

This time the machine Z level is lowered by the distance of the tool length, causing the hole program to run the same lenth below the touch off level. The DRO TLO Z still remains but the compensation that occurred in the first run, now gets cancelled by the preamble file.

In my cases I didn't set a Z-safe greater than the tool length, and as the first move in the program is a rapid move to Z-safe, a crash comes at full speed within fractions of a second. With a Z-safe greater than the tool length there is a chance to notice the error and hit E-stop before things gets really bad. The part will be ruined though. Maybe to small Z-safe is just bad practice by an amateur rookie..?

I really suggest you file a bug at the sourceforge tracker so this isnt lost: sourceforge.net/p/emc/bugs/

also post to the developers mailing list

- Michael

Thanks for the detailed report and I'm sorry for the crash you experienced even with careful testing.

I think the problem is that the 'if' block around the tool change in loadtool.ngc is not needed:

So you can try removing this:
And substituting with:
You can always use your own files having the same names as the supplied files (loadtool.ngc for example) as long as you place them in the search path that linuxcnc uses so they precede the default routines. The first subroutine found in the search path is used.

For more information on search paths, see the [RS274NGC]Section in:
www.linuxcnc.org/docs/devel/html/config/ini_config.html

Thanks for your response. I kind of needed some confirmation that it wasn't just me that didn't understand how it's supposed to work. I'll be happy to file a bug, I just need some confidence...

I believe one question here is whether a tool changer with active tool length compensation should be considered as default configuration or not? I can't tell if my situation is common or rare, but I would guess that many cases are like mine, with no tool changer and no touch probe for tool touch off. In that case I'd prefer to have the tool length compensation always inactive as default. But this is just mine point of view...

dgarrett:
Your suggestion to remove the "if" block would keep the tool length compensation active every time, which for sure is consistent, but still not very useful as I have no practical means to set the correct tool length in the tool table. Removing the "if" block would also result in that the pop up message for tool change, will emerge every time a ngcgui script is run. Right..? Perhaps a bit annoying in situations when you do repeated runs. An alternative solution to keep active tool length compensation could be to remove the "G49" command that cancels tool length compensation in the preamble file "in_std.ngc".

One thing I have learned by now is that the use of modal commands can be very scary. Unexpected things can easily happen. And I realize I need to be extra careful when using codes from different sources successively.

i tried it with the if block removed and there was no popup when the tool is the same (tested on master) . Please try it, if it works for you I'll patch the loadtool.ngc file

I tried it - No popup when the requested tool is already loaded, just as you said.

But I happened to test it on my "Pure Simulator" installation and with the Axis/sim/ngcgui/ngcgui configuration, and that config includes a tool change position, to which it moves each time "loadtool.ngc" runs, even when the right tool is already loaded (it continues autocratically if no tool change is needed). For the moment it's not a problem to me as I don't use such a config - yet. But arranging a set-up with a touch probe for automatic tool length compensation is very high on my to-do-list. And I certainly don't want to have a touch sequence every time I start. So this solution might not be such a good idea after all.

And I still don't like the concept of having tool length compensation activated as default for ngcguis. With a basic set-up, as the one I have for present, you will have to load the requested tool manually, before you touch of at the work piece surface and run the ngcgui-code.

There is also an inconsistency problem having the tool length compensation cancelled in the "in_std.ngc" file and then reactivated by the "loadtool.ngc" file.
ex. If someone creates a new ngcgui script and don't include a tool change call to "loadtool.ngc", then the user can get an unexpected shift in the Z-level when the tool length compensation gets cancelled by "in_std.ngc".

Do you see any obvious drawbacks with the solution I did?
Just remove the "G43" from "loadtool.ngc". Changing from:To:
It would be nice if the use of tool length compensation instead could be controlled from "in_std.ngc". It's a file users are more likely to edit. But that is a bit over my programming skills for the moment...

OT...

While testing I went to the MDI-tab to load and unload tools manually.

Is there a reason why the tool length compensation don't get set to zero (watching the DRO) when I enter "T0 M6 G43" in a single command line?
The status line indicates that no tool is loaded, while the DRO shows that the previous toll compensation is still active.
I have to enter "g43" separately after "T0 M6" (or repeat the whole line twice) for the tool length compensation to take effect.

This is only the case when unloading the tool whit "T0". Entering "T1 M6 G43" in a single command works fine...

>I tried it - No popup when the requested tool is already loaded, just as you said.

OK -- I've made the change for both the v2.5_branch and master. The 'if' check
was a bug for sure.

>And I still don't like the concept of having tool length compensation activated ...

All the ngcgui examples are there to show a new user how to set up an ini file so that the ngcgui items and search paths are correct for a given usage. You can modify any of the examples or make your own and create your own [RS274NGC]SUBROUTINE_PATH

I don't think there is one setup that will work for everyone.

>There is also an inconsistency problem having the tool length compensation cancelled in the "in_std.ngc" file

It is pretty common to recommend cancelling compensation in a preamble:
gnipsel.com/linuxcnc/g-code/gen01.html
But you can use whatever preamble suits your needs.

>Do you see any obvious drawbacks with the solution I did?

No. You should use whatever preamble works for your purposes. Your preamble can be specified in the ini file with:And you can set it individually while testing "custom"subroutines specified with
You can also have different ini files for different usages of the same machine.