How to register and retrieve tool height data in tool table for the machine with ATC (using macro) and touch off probe at fixed location?

[karoria]

I have searched a lot over the internet but could not figure out the G-code syntax for touch off and saving that tool height in non-volatile memory just like work offsets. What are all queries related to tool table? I mean, sending $# populates work and tool offsets but are there any other commands specific to grblHAL for setting tool height manually in MDI? or retrieving tool height for say tool no. 6? Is there any standard Gcode syntax for this?

Asking this as new issue instead of ongoing discussion on macro support so that this can serve as quick wiki to many users.

[terjeio]

G10 L1, L10 and L11 is used for manipulating the tool table. $# for retrieving tool table data for all tools.

With expression and SD card (or littlefs) support enabled you can write a macro that does the touch off and writes the data to the tool table on success. The last probed position is stored in parameters 5061 - 5069, and probe result in 5070 - 1.0 on success, 0.0 on failure. Parameter bindings is defined here and here in the source code.

ioSender shows a tab for displaying/modifying the tool table when it is enabled in the controller. I have not yet written any code in the sender for performing touch-offs that updates the tool table directly.

[karoria]

Thanks. What is the need of all axis coordinates for T1, T2 etc? Isn't only Z axis data enough? I am planning something like a tool offset macro for all tools in the magazine. They just come one by oje and measure their length offsets and register in tool table. Then while in real production, each tool doesn't need to go to tool length sensor. Spindle just lifts the tool and start work. This is very useful for production jobs. Need your suggestions for this. Are the tool offsets in tool table persistant?

[terjeio]

What is the need of all axis coordinates for T1, T2 etc? Isn't only Z axis data enough?

For a mill/router then typically yes. For a lathe both X and Z is needed. And to be compatible with LinuxCNC all are included.

Then while in real production, each tool doesn't need to go to tool length sensor. Spindle just lifts the tool and start work. This is very useful for production jobs.

This is how it is supposed to work. But be aware that the offset has to be activated, a tool change will not do that by itself. And be aware that I have not extensively tested this functionality, the code has not been inherited from legacy Grbl.

Are the tool offsets in tool table persistant?

Yes.

[karoria]

Thanks for quick reply. Yes, the persistant nature of tool table makes it a huge feature. I had quick MDI "G10 L1 P1 Z15" to set tool 1 z coordinate. And it works. Rest of the work I will manage. If I can make some really good out of it, I will share my process and macros.

[karoria]

Probed coordinate query for Z in MDI like $#=5063 gives a value 1000 times of actual coordinate. Is it a bug?

[terjeio]

It is both a bug and an incomplete implementation. Will fix in the next commit.

[karoria]

Ok. I came across a new thing just for your consideration. While playing with tc.macro when I use "G10L1P1Z[#5063/1000]" (divided by 1000 due to above issue) or L10 or L11 (instead of L1) it makes X and Y wco Zero (work coordinates and machine coordinates same), though it is specifically written in LinuxCNC documentation that L10 is suitable for probing and it doesn't affect other axis coordinates. I assume here also it is incomplete implementation. Macro and expressions support is really proving awesome feature. Thanks a lot @terjeio for all your time and effort. Once I freeze my tc.macro, I will post it with comments at suitable place so that everybody can take benefit of it. This is because I have an ATC machine with me and it will be rigorously tested before posting. BTW, I have already broken 2 tools and almost damaged my touch off probe in the process, but will surely come to the result soon! Also eagerly waiting for your next commit regarding this.

[terjeio]

This is the LinuxCNC specification for the probing result:

"5061-5069 - Coordinates of a G38 probe result (X, Y, Z, A, B, C, U, V & W). Coordinates are in the coordinate system in which the G38 took place."

Prior to the latest commit I errouneosly returned the machine position in steps. This is now corrected to comply with the specification above (as I understand it). However, I am a bit unsure if I should record the offset on a succesful probe or just the coordinate system id, currently just the id is recorded. If the offset is changed then the returned values will change, but IMO this is ok as this allows one to always calculate the probe result as machine position (the probe result itself is stored as position in steps). Note that I do not add any G92 or tool length offsets to the probe result.

BTW, I have already broken 2 tools and almost damaged my touch off probe in the process, but will surely come to the result soon!

Thats too bad, but sadly it is part of debugging...

[karoria]

Thanks for prompt answer. I could not find a way to tell the machine its wco of x and y in G10L1 line so that it doesn't change its offset to 0.

[terjeio]

1. There is a bug that causes the current G5x offset to be reset to 0 when G10L1/10/11 is sent.
2. I am not able to interpret the LinuxCNC spec for G10L10 and L11 in a way that I can use for coding and verification - am getting closer to where I have to install LinuxCNC in order to check its actual behaviour in detail...

Anyway I believe I am getting a bit closer to relatively sane interpretation, at least for single axis tool offsets. If you compile locally you may try this grbl/gcode.c with the changes:

gcode.zip

Is this behaving in a way you expect?

[karoria]

Compiling error with above code.c file:

src/grbl/gcode.c: In function 'gc_execute_block': src/grbl/gcode.c:1719:22: error: 'io_stream_t {aka struct }' has no member named 'file' if(hal.stream.file) { ^ *** [.pio/build/teensy41/src/grbl/gcode.c.o] Error 1 =============== [FAILED] Took 12.31 seconds ===============

[terjeio]

Compiling error with above code.c file:

Update to the latest version.

[karoria]

Ok. Updated. But now error changes:

src/sdcard/macros.c: In function 'end_macro': src/sdcard/macros.c:76:12: error: 'system_t {aka struct system}' has no member named 'macro_file' sys.macro_file = stack_idx >= 0 ? macro[stack_idx].file : NULL; ^ src/sdcard/macros.c: In function 'macro_start': src/sdcard/macros.c:166:8: error: 'system_t {aka struct system}' has no member named 'macro_file' sys.macro_file = file; ^ *** [.pio/build/teensy41/src/sdcard/macros.c.o] Error 1 =============== [FAILED] Took 10.09 seconds ===============

[terjeio]

Your submodules are out of sync?

[karoria]

Replaced macros.c now it compiles. But I will be able to test it tomorrow.

[karoria]

G10 L10 works as expected. Probed coordinate decimal issue is gone now. Will post you further as I experiment. Thanks.

[terjeio]

The fix has been committed, thanks for testing.

[karoria]

Thanks a lot for quick support. Can we make a setting which can switch on and off "current tool" memorizing after power cycle? All industrial machines have memorizing behaviour, so that fully automatic tool change will be less interfering for operators. In most of the cases tool change will be done in auto mode due to pneumatics. So the last used tool will still be there after power cycle.

[terjeio]

Can we make a setting which can switch on and off "current tool" memorizing after power cycle?

I am a bit wary of adding this as grbl/grblHAL is not typically used for industrial class machines... Anyway is it only the tool number that should be kept and not any related offsets?

Note that adding settings for this will trigger a settings reset for all users unless I add it as a plugin.

[karoria]

1. Tool number needs to be memorized only. Offsets can be read from tool table which is already persistant.
2. Yes, plugin for simply ENABLE TOOL NUMBER PERSISTANCE as compile time option is also a good idea.

[terjeio]

I had to add a new core event for this to work, since the "standard" tool change functionality can be aborted asynchronously (after M6 returns "ok" to the sender. A plugin subscribing to the new event will be published when the next core build is committed.

[terjeio]

Needed core changes and plugin is now up. I'll add the plugin to the Web Builder soon.

[karoria]

Thanks a lot @terjeio I am currently lost at tc.macro where I am not getting tool height registered in tool table as I desire. This is with old update. Now I will start from new build. I know this has nothing to do with update. I have to experiment more.

[karoria]

Hi @terjeio Are there variables for tool table parameters? I need to get z offset of each tool for my tc.macro.

[terjeio]

Are there variables for tool table parameters?

No.

I need to get z offset of each tool for my tc.macro.

Why is that? One possible way to find it is to clear tool offsets, read the position, apply the offset and calculate the difference between the new position vs the previous?

[karoria]

Is there any command to clear all tool offsets?

[terjeio]

Is there any command to clear all tool offsets?

G49

[karoria]

Does it erase tool table data? I want to erase it.

[terjeio]

No, use $RST=# to erase parameters only (coordinate system offsets and tool table).

[karoria]

Hi @terjeio I have found that $#=#5063 doesn't give parameter value even though machine has successfully probed in Z. I have found other variables are also not displaying its value, instead it returns N/A.

[terjeio]

Did the probe update the coordinate system? From the LinuxCNC docs:

"Coordinates are in the coordinate system in which the G38 took place."

Do you have some examples of which values are returning N/A?

[karoria]

Coordinates are updated as expected. It just doesn't show up when I MDI above command. Otherwise it does the math as expected. I want their values to be seen at some poibt for debug purpose which it doesn't show. Does it show in your system? I am running grblHAL on Teensy4.1 board.

[terjeio]

It shows 0 or N/A? I am not able to retest now as I have a test platform wired up that is not capable of probing. Give me a bit of time...

[karoria]

It shows N/A. ok. Take your time.

[terjeio]

It shows N/A.

5063 should never return N/A. If probing has not taken place or failed 5070 is set to 0, 1 otherwise. If 5070 is 0 values for 5061-5069 are not valid.

When I test with probing in ioSender I get the results that I expect. E.g. a probe of Z in the Edge finder, external tab returns 0 if I set G54 with a thouch plate height of 0. Note that this will always be 0, the probe result will be the G54 Z offset in 5223 instead. If I clear G54 (and G54 is the current coordinate system) and set G92 I get the same position as reported by $# (in the PRB element).

Set G54:

[PRB:77.663,90.330,-18.190:1]
$#=5063
[PARAM:5063=0.000]
$#=5223
[PARAM:5223=-18.190]

Set G92, G54 active an G54 Z = 0:

[PRB:77.663,90.330,-18.224:1]
$#=5063
[PARAM:5063=-18.224]

How are you testing? E.g. if you do not set any offset post probing the result should be the PRB: reported value minus the offset in the coordinate system active when the probe took place.

It could be argued that the coordinate system values used in the calculation should be pre probing and disregard any subsequent changes. IMO that would leave the probe values meaningless.

[karoria]

So sorry @terjeio I was entering $#=#5063 instead of only 5063. Sorry to bother you for silly mistake. However, I got to know important clues from you regarding probing. Thanks.

[karoria]

Hi @terjeio I was wondering if I can make current tool number included in report and whenever tool number changes, it should update the report with new tool number. Is there a setting like this?

[terjeio]

In the real time report? It is already there, in the T:<n> element e.g:

<Idle|MPos:4.948,2.988,0.000|Bf:100,1023|FS:0,0|A:|T:3>

Note that it does not change until after the related M6 has been executed.

[karoria]

Thanks for quick reply. Can we update it on "$#=_current_tool" query or "M61Q3" kind of command?

[terjeio]

M61 updates it already, but only if the tool is changed:

M61Q3
<Idle|MPos:4.948,2.988,0.000|Bf:100,1023|FS:0,0|Ov:100,100,100|A:|T:3>

[karoria]

Ok. Thanks.