Current workflow for semi-automatic tool changes about core HOT 36 CLOSED

I want to use the functions in ATC.C, I should What is the most reasonable way to do it?

You should set the HAL function pointers to your functions and set the hal.driver_cap.atc capability flag to true. Then the tc_init function in tool_change.c will not overwrite your assignments.

Do I need to change the tool_change.c file?

No - and since your code is for you only you should name your init function that set the function pointers and capability flag void my_plugin_init (void). This way there is no need to modify any code from the repo.
You can find some plugin examples here that may be of help.

from core.

OK, looks like bCNC isn't following tool change protocol because it's tries to send commands from g-code file while grblHAL is in Tool state https://github.com/grblHAL/core/wiki/Manual-tool-change-protocol . That leaves us with the first question only.

from core.

From wiki I had impression that firstly tool is moved to home position for physical change then it moved to G59.3 offsets for automatic touch off but my tests revealed that there no move to home position just lift in Z direction, then after Cycle Start tool is moved to G59.3 offsets.

The behaviour depends on the $341 setting. The explanations for the different variants could be better though.

Maybe there was some discussions about semi-automatic changes in grblHAL?

There has been a few but at the old repo.

Also are tool changes in semi-automatic mode g-code sender dependent?

Yes - as explained in the Wiki the sender has to acknowledge the tool change and allow jogging and setting offsets (and allow the special $ -commands depending on the mode - possibly via MDI or macro input).

How could I understand that sender handles tool changes correctly?

It should be part of the sender specs? The tool change protocol is a grblHAL specific extension so it is unlikely any senders beside ioSender supports it? AFAIK some senders traps M6 and implements some kind of tool change protocol sender side, and some senders strips M6 altogether?

from core.

@terjeio

The explanations for the different variants could be better though.

Yep, that will help a lot. For some reason in $341=3 mode grblHAL firstly moves to G53 Z0 and then backoffs to G53 Z-1 while HOME position is G53 Z-2, and I don't understand why it's doing so.

Maybe it will benefit to have an explicitly specified physical tool change location in machine coordinates(something like G30 http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g30-g30.1 or maybe G59.2)?

There has been a few but at the old repo.

Nice, I'll explore them.

But right from the start I could confirm behaviour with soft limits alarm after tool change ( terjeio/grblHAL#225 ). My tests revealed it's connected to tool difference between probe tool and working tool, if probe is shorter, alarm is raised right after working tool returns to resume point in XY-direction and before Z-move. bCNC has the same behaviour because it makes return moves in working offsets and not via G53 or G28. So if it's not enough space in Z, soft limits alarm is raised.

AFAIK some senders traps M6 and implements some kind of tool change protocol sender side

Yes, bCNC has such implementation with WCS translation:

• Firstly calibration: bCNC finds Z-difference between workpiece and tool setter;
• Actual tool changes in g-code file are substituted on-fly with the macro;
• Tool moved to physical tool change location(set in G53 via sender settings);
• After tool change, placing tool setter clip on end mill if needed, operator presses Cycle start and tool moved to probe location(set in G53 via sender settings, same as G59.3 in grblHAL);
• Tool probed and returned to tool change location;
• If needed operator removes tool setter clip from end mill and presses Cycle start;
• WCS is translated via difference between new tool and probe used for calibration;
• Tool returned to resume point.

from core.

For some reason in $341=3 mode grblHAL firstly moves to G53 Z0 and then backoffs to G53 Z-1 while HOME position is G53 Z-2, and I don't understand why it's doing so.

It should make one move - either to Z home or Z home - 1 depending on a setting. What are the g-code commands prior to the M6 in your program?

Maybe it will benefit to have an explicitly specified physical tool change location in machine coordinates(something like G30 http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g30-g30.1 or maybe G59.2)?

G59.3 is used by linuxCNC for tool changes/tool probing so I selected that for grblHAL too. I do not want to claim an additional position/offset, IMO modify your post-processor to move to a specific position on tool changes if you want a different position from what is already supported by $341. I have considered adding a setting for the initial Z target (as an offset from Z home), this is hardcoded now. Perhaps one for the probe retract distance as well:

But right from the start I could confirm behaviour with soft limits alarm after tool change ( terjeio/grblHAL#225 ).

Is your g-code program moving to the Z home position before the M6? The tool change algorithm will move the controlled point (the tool tip) back to the position it had before the M6, if the new tool is longer that will be beyond Z home. Change the post-processor to move to a position with enough headroom or not move at all.

from core.

@terjeio

Sorry for my delay with answer :-(

It should make one move - either to Z home or Z home - 1 depending on a setting. What are the g-code commands prior to the M6 in your program?

Yep, it's my bad, configuration difference with previous setup on plain simple grbl and bCNC. It's has G28 move for clearing probe/end mill from workpiece before first tool change(G28 position was set higher than used to be):

N00001 G17
N00002 G21
N00003 G94
N00004 G28 G91 Z0
N00005 G90


N00006 T124 M6

But still, if home position shown as [HOME:-299.000,-353.000,-2.000:7] shouldn't the height for lift move be Z-2 or Z-3, why it's Z-1? Maybe define for LINEAR_AXIS_HOME_OFFSET should be positive number since minus operation is used here?

Anyway to which $-parameter settings.homing.flags.force_set_origin is connected to? I do not remember to setting something like this...

G59.3 is used by linuxCNC for tool changes/tool probing

LinuxCNC doesn't have hardcoded tool change routine, it's basically scripted so anyone could alter tool change behaviour to suit they needs, in LinuxCNC no need to modify post-processor for every setup out there. My fellow LinuxCNC user says that G59.3 offset in no shape or form is designated as tool change position in LinuxCNC.

Is your g-code program moving to the Z home position before the M6? The tool change algorithm will move the controlled point (the tool tip) back to the position it had before the M6, if the new tool is longer that will be beyond Z home.

For clearing probe/end mill off workpiece I've G28 move in header:

N00001 G17
N00002 G21
N00003 G94
N00004 G28 G91 Z0
N00005 G90


N00006 T222 M6
...
N00046 G0 X29.359 Y-.725 S12000 M3
N00047 Z15.000
N00048 Z2.400
N00049 G1 Z1.400 F390
N00050 X29.246 Y-.497 F760
N00051 G3 G17 X29.088 Y-.257 I-1.111 J-.556 F1250

Second tool change:

N03175 G3 X21.218 Y19.807 I3.349 J3.713 F760
N03176 G0 Z15.000
N03177 X9.533 Y-20.822

N03178 M5
N03179 T1 M6
...
N03221 G0 X9.533 Y-20.822 S4400 M3
N03222 Z15.000
N03223 Z4.500
N03224 G1 Z-2.085 F273
N03225 G0 Z15.000

I think standard grbl post-processor in Fusion360 has same behaviour with G28 in header.

Why in tool change routine move in work offsets is needed? Wouldn't TLO be applied in first moves after M6?

from core.

But still, if home position shown as [HOME:-299.000,-353.000,-2.000:7] shouldn't the height for lift move be Z-2 or Z-3, why it's Z-1?

Because I choose -1, currently it can only be changed by either editing tool_change.c or adding LINEAR_AXIS_HOME_OFFSET as a symbol on the compiler command line.

Maybe define for LINEAR_AXIS_HOME_OFFSET should be positive number since minus operation is used here?

Z-motion is negative in the down direction, to avoid confusion I used a negative value. If I move it to a setting a negative value will be the most obvious for users too?

Anyway to which $-parameter settings.homing.flags.force_set_origin is connected to? I do not remember to setting something like this...

$22, bit 3 (Set machine origin to 0), grblHAL has a lot more settings than vanilla Grbl, this to get rid of most compile time options. And I see now that I have not documented $22..

Issuing $$=22 in a terminal window returns this:

$22: Homing cycle as bitfield where setting bit 0 enables the rest:
    0 - Enable (1)
    1 - Enable single axis commands (2)
    2 - Homing on startup required (4)
    3 - Set machine origin to 0 (8)
    4 - Two switches shares one input pin (16)
    5 - Allow manual (32)
    6 - Override locks (64)
    7 - Keep homed status on reset (128)
ok

My fellow LinuxCNC user says that G59.3 offset in no shape or form is designated as tool change position in LinuxCNC.

Sloppy comment from me, IIRC it is commonly used as the location of the touch-off sensor often used in combination with tool changes. Sorry for that.

I think standard grbl post-processor in Fusion360 has same behaviour with G28 in header.

Yes I believe so. With grblHAL this causes problems with the tool change algorithm. Grbl does not support tool changes so I guess it was added as some kind of workaround?

Why in tool change routine move in work offsets is needed? Wouldn't TLO be applied in first moves after M6?

I am not sure what you mean by this. TLO is applied by the tool change algorithm after probing is completed, then a move to Z home followed by a move to the original XY position and finally to the original Z position (before the M6) is performed. Perhaps setting the TLO should be delayed until just before the final Z move?

from core.

@terjeio

I've done few test with Set machine origin to 0 option and now I completly lost :-)

Purpose of LINEAR_AXIS_HOME_OFFSET is to move axes away from home/limit switches during toolchanges, right? But if Set machine origin to 0 option is true, origin isn't set to point where limit switches were hit but that point is translated by value of $27 option. So during toolchanges axes are not even close to home/limit switches. In both values for Set machine origin to 0 option, tool change position is NOT home position(which is shown by $# command) as it described in the documentation( https://github.com/grblHAL/core/wiki/Manual,-semi-automatic-and-automatic-tool-change ), right?

Grbl does not support tool changes so I guess it was added as some kind of workaround?

Autodesk has strange policy about editing post-processors, it could be done without much discussion by anyone's request, so with G28 and M6 it was back-and-forth for a few times. I'm not sure what is background for that.

I am not sure what you mean by this. TLO is applied by the tool change algorithm after probing is completed, then a move to Z home followed by a move to the original XY position and finally to the original Z position (before the M6) is performed. Perhaps setting the TLO should be delayed until just before the final Z move?

I think I would like to try using tool change routine without that final Z move, I don't see why it's needed. Maybe it is possible to comment or alter few lines of code in tool_change.c file so I could check it?

from core.

if Set machine origin to 0 option is true, origin isn't set to point where limit switches were hit but that point is translated by value of $27

Correct, why it has been done like this I do not know. Should it be changed to the $27 pulloff distance (with sign determined by the homing direction) to be consistent with Set machine origin to 0 set to false?
If Set machine origin to 0 is false it is set to where the switch was hit or to max travel + the pulloff distance depending on the homing direction.
Note that grblHAL keeps track of the homing status and position, Grbl does not.

There is another related issue that bothers me a bit, it is currently not possible to know if G28 and G30 positions has been explicitly set, they both defaults to 0,0,0 - and should in principle default to unknown (NAN)? In addition G28 and G30 should error out if the machine is not homed or the positions has not been set? There is a warnining in the LinuxCNC about not using these commands if not homed or positions not set - but I do not know what will happen if issued regardless...

In both values for Set machine origin to 0 option, tool change position is NOT home position which is shown by $# command as it described in the documentation, right?

Yes it is offset the $27-value minus the LINEAR_AXIS_HOME_OFFSET in the tool change routine if Set machine origin to 0 is true. BTW LINEAR_AXIS_HOME_OFFSET should be removed - it is not needed. Setting the home position to where the switch was hit is not a good idea - a move there will likely trigger it again and cause an alarm if hard limits is enabled.

I think I would like to try using tool change routine without that final Z move, I don't see why it's needed. Maybe it is possible to comment or alter few lines of code in tool_change.c file so I could check it?

Yes, you may try that. The final move is required if not done in the gcode - impossible to know what a post-processor will output... IIRC this is where the move is performed:

from core.

@terjeio

I was checking LinuxCNC documentation for in depth explanations and I must say it has quite a different procedure for setting origin and home position. Should grblHAL use it as a reference?

Online http://linuxcnc.org/docs/html/config/ini-homing.html
PDF-file has bit more info in different sections http://linuxcnc.org/docs/2.8/pdf/LinuxCNC_Documentation.pdf (chapters 8.3 and 3.7.11)

Should it be changed to the $27 pulloff distance (with sign determined by the homing direction) to be consistent with Set machine origin to 0 set to false?

I think it should be at least consistent, if not then max travel distances($130,131,132) would be different between these two settings. Will it somehow affect rotary axes? Never had one, so no experience with them.

If Set machine origin to 0 is false it is set to where the switch was hit or to max travel + the pulloff distance depending on the homing direction.

LinuxCNC documentation states that explicit setting of machine origin from axes home switches is needed for lathes. Chapter 3.7.11:

The zero position is the location on the axis that is 0 in the machine coordinate system.
Usually the zero position will be within the soft limits. On lathes, constant surface speed
mode requires that machine X=0 correspond to the center of spindle rotation when no
tool offset is in effect.

So maybe in grblHAL origin offsets from home switches(HOME_OFFSET in LinuxCNC) should also be used?

BTW is HOME_OFFSET from LinuxCNC have something to do with LINEAR_AXIS_HOME_OFFSET in grblHAL???

There is another related issue that bothers me a bit, it is currently not possible to know if G28 and G30 positions has been explicitly set, they both defaults to 0,0,0 - and should in principle default to unknown (NAN)? In addition G28 and G30 should error out if the machine is not homed or the positions has not been set? There is a warnining in the LinuxCNC about not using these commands if not homed or positions not set - but I do not know what will happen if issued regardless...

I don't see why it would be a bad idea to post an alarm if the machine is not homed but G28/G30 commands are issued. Regarding checking if they were purposely set: if it's possible to do without much effort, it would be great to have such check, countless number of people had problems with G28 when it was enabled by default in Fusion360’s post-processor dialog and they didn't set that offset in grbl.

Setting the home position to where the switch was hit is not a good idea - a move there will likely trigger it again and cause an alarm if hard limits is enabled.

It's so many options(shared/separate limit and home switches, only home switches with soft limits, only limit switches) that it's tough to say what is a good idea and what is not :-)

Yes, you may try that. The final move is required if not done in the gcode - impossible to know what a post-processor will output... IIRC this is where the move is performed:

Thank you, I'll try that.

from core.

Hi.
I want to use ATC function of grblHAL, I see that grblHAL supports M6, I want to add ATC function to my CNC.
I've looked at the RAEDME file for grblHAL, and grblHAL doesn't support ATC yet and requires a plugin or driver. I want to write this driver. But I don't know how to start now, can you tell me the program flow.

Blessings from outer space. Thank you

from core.

@CHTUZKI You have to hook your code into two function pointers, see this incomplete example. The function pointers are hal.tool.select and hal.tool.change - some documentation here. The core manual tool change code may also be of some help.

from core.

HI.
I looked at the ATC.C file of the MSP432P401R example, there are atc_tool_change() and atc_tool_select() functions in this file, and I found that tool_change.c also has these two functions.
When I was debugging, I found that hal.tool.select and hal.tool.change will use the atc_tool_change() and atc_tool_select() functions in tool_change.c by default. I want to use the functions in ATC.C, I should What is the most reasonable way to do it? Do I need to change the tool_change.c file?
Greetings from Mars. thanks.

from core.

Hi terjeio,

I think i have a similar issue, and wanted to ask for your expertice.

When i do my first M6 Toolchange (not tool length offset is set) , and my starting position is at zMax (machine origin 0,0,0)

It will automatically move to g59.3, measure the first offset and return to zMax.

If i now insert a longer tool, do the m6 toolchange it will measure, but then drive to zmax+ measured offset and hit my z limitswitch.

So it seems for.me the m6 toolchange changes to machine coordinate system, and when going to zMax, it will trigger the limit switch.

If i do these tool length sensor measurements in IO Sender manually, it will change the WCS.

May i ask for your advice?

Thanks Christoph

from core.

Which build is this with? Help > About will tell you:

from core.

It is:

grblHAL ; 1.1f.20220325 ; [OPT:VNMZHS2,191,1024,3,0] ; [NEWOPT:ENUMS,RT+,HOME,ES,TC,SED,ETH] ; [FIRMWARE:grblHAL] ; [NVS STORAGE:*FLASH] ; [DRIVER:iMXRT1062] ; [DRIVER VERSION:220325] ; [DRIVER OPTIONS:USB.1] ; [BOARD:GRBLHAL2000 - PRINTNC] ; [AUX IO:4,1,0,0] ; [IP:192.168.5.1] ; [NETCON:Telnet] ; [PLUGIN:MODBUS v0.12] ; [PLUGIN:VFD SELECTOR v0.02] ; [PLUGIN:HUANYANG v1 v0.07] ; [PLUGIN:KEYPAD v1.3 INTERTEST] ; [PLUGIN:Macro plugin v0.02] ; [PLUGIN:RGB Indicator Lights v1.0

And my settings are:

$0=10.0 $1=255 $2=0 $3=5 $4=7 $5=7 $6=0 $7=0 $8=0 $10=511 $11=0.010 $12=0.002 $13=0 $14=0 $15=0 $16=0 $17=0 $18=0 $19=0 $20=0 $21=1 $22=175 $23=3 $24=25.0 $25=500.0 $26=250 $27=1.000 $28=0.100 $29=0.0 $30=24000.000 $31=6000.000 $32=0 $33=5000.0 $34=0.0 $35=0.0 $36=100.0 $37=0 $39=1 $40=1 $43=1 $44=4 $45=3 $46=0 $50=100.0 $51=600.0 $52=3000.0 $53=0.250 $54=500.0 $55=3000.0 $62=0 $63=2 $64=0 $65=0 $70=3 $100=200.000 $101=200.000 $102=500.000 $110=15000.000 $111=15000.000 $112=4000.000 $120=750.000 $121=750.000 $122=500.000 $130=1094.000 $131=771.000 $132=173.000 $160=0.000 $161=0.000 $162=0.000 $170=0.000 $171=0.000 $172=0.000 $300=GRBLHAL2000 $301=0 $302=192.168.5.1 $303=192.168.5.1 $304=255.255.255.0 $305=23 $307=80 $341=3 $342=50.0 $343=25.0 $344=400.0 $345=100.0 $347=5.0 $348=2.500 $349=25.000 $370=0 $372=0 $374=3 $375=50 $384=0 $395=0 $450= $451= $452= $453= $454=S200M03 $455= $456= $460=0 $461=60 $462=8192 $463=8193 $464=8451 $465=18 $466=34 $467=1 $468=50.0 $469=60.0 $470=60.0 $471=100.0 ok

from core.

Thanks, I have to recap a bit...
What are the commands immediately following the M6?

So it seems for.me the m6 toolchange changes to machine coordinate system, and when going to zMax, it will trigger the limit switch.

No, it changes the tool offset only. However if a G28 or G30 with axis parameter(s) follows the M6 this will move to the position specified including offsets before moving to the saved absolute position. E.g. a G28Z0 may trigger the Z limit switch.

from core.

I don't have any code loaded, i am just at machine 0,0,0. I type t1 m6 in the CLI, and it will do the first tool change with the short tool.

Than i change to a longer tool , type t2 m6, and it will measure the second tool, return to z max, and hit the limit switch.

And the MCS now shows 0, 0, 3.833

The Gcode i would use, would look like this:

from core.

But since i can't get even get the solo M6 command working, i didn't pursue the gcode generated by the grblhal PP

from core.

Ok, you start the initial probing from Z0 which is with the spindle fully retracted? This cannot work as there will be no headroom for a longer tool. Does it work with the spindle further down (negative Z)? It does for me.

from core.

Yes exactly, i start at z0, which is the spindle all the way up.

Yes when my i start the m6, with the spindle further down it works. Then it will travel to zmax, and go down to the position, where i started the m6 command, even if the new tool is longer than the previous one.

Is there a workarround arround this?
So it doesn't hit the z limitswitch when starting a M6 at ZMax/Z0?
Or do i have to modify the grblhal PP so it doesn't start the M6 at Zmax/Z0

from core.

Or do i have to modify the grblhal PP so it doesn't start the M6 at Zmax/Z0

Yes - since it is not possible to return the controlled point (the tool tip) to the previous position unless there is room for the movement. Raising an alarm is IMO the correct action.

from core.

Has this something to do with the hardcoded defines, mentioned earlier?

`// NOTE: only used when settings.homing.flags.force_set_origin is true
#ifndef LINEAR_AXIS_HOME_OFFSET
#define LINEAR_AXIS_HOME_OFFSET -1.0f
#endif

#ifndef TOOL_CHANGE_PROBE_RETRACT_DISTANCE
#define TOOL_CHANGE_PROBE_RETRACT_DISTANCE 2.0f
#endif`

Or does this something completely unrelated?

from core.

Has this something to do with the hardcoded defines, mentioned earlier?

No. But I believe you can add some headroom by increasing the homing pull-off distance ($27).

from core.

Ok thank you very much for the quick response!

i'll try the pull off distance first, but it will change the distance of all limitswitches, there is no explicit setting for z right?

from core.

there is no explicit setting for z right?

No.

from core.

But you can add a startup command to move Z down a bit.

from core.

Out of curiosity, why is return to previous even necessary? Doesn't the next operation after a toolchange move the toolhead to the start position? Seems like the redundancy is just a possible cause of error without a measurable benefit, unless there's something I'm unaware of?

from core.

Out of curiosity, why is return to previous even necessary?

From NIST RS274NGC v3 paragraph 3.6.3:

"The coordinate axes will be stopped in the same absolute position they were in before the tool change (but the spindle may be re-oriented)."

I read that as the absolute position of the controlled point (tool tip) in the real world.

Doesn't the next operation after a toolchange move the toolhead to the start position?

Via which path? IMO it is safer for the controller to return to the original position "known" by the gcode than having the CAM program add code (defined in the post) for movements from some arbritary position. It is simpler to just move the controlled point to safe Z (or Z clearance) before the the tool change and let the controller return to that position?

from core.

From NIST RS274NGC v3 paragraph 3.6.3:

"The coordinate axes will be stopped in the same absolute position they were in before the tool change (but the spindle may be re-oriented)."

i believe this is a clash between the common ATC usecase and our manual toolchange usecase.
What's written there is that the toolchange process, so switching out the toolholders, is not to change the axis location thus saying it should be in the same absolute xy position once the toolchange is completed. (which we even obey, because when we go to tool touchoff the toolchange is already complete)

I read that as the absolute position of the controlled point (tool tip) in the real world.

While it says that the spindle may be reoriented, trying to force the same position of the controlled point may, as seen above, result in problems when switching to longer tools

Via which path? IMO it is safer for the controller to return to the original position "known" by the gcode than having the CAM program add code (defined in the post) for movements from some arbritary position. It is simpler to just move the controlled point to safe Z (or Z clearance) before the the tool change and let the controller return to that position?

Isnt the toolchange position also an arbitrary position just the same as the TLS location?

And it could be argued that it is difficult to get the controlled point to a safe z since it's an arbitrary point below the spindle collet and defaulting to absolute z axis position at z-home is the 'safest' point there is regardless of the current TLO?

from core.

Comment out this line (or more motion commands in the restore() function) to get the behaviour you want:

I might either make it a compile time choice or a setting to change the behaviour, the default will be the same as now for backwards compatibility. I am a bit unsure if you want motion to the original XY at Z0 or if you want to leave the controlled point where it was after touch off is completed.

from core.

I would prefer move to G28 Z0 at the toolsetter and wait for next operation gcode to move to starting location. For example, if the first tool op ends at the opposite corner of the CNC from the toolsetter, and the second tool op starts next to the toolsetter, then there's a wasted move returning to the end of the first tool op location. Afaik a new operation will always start with an absolute XY in G5x to the next lead in starting point.

from core.

What LoganFraser is trying to say is the current mode of operation for Semiautomatic Toolchange at G59.3 is:

M6 Command received
go to G28 for toolchange, present TOOL status
tool changed, cyclestart received
go to G59 XY
go to G59 Z
start Probing cycle
successfull touchoff
raise Z to previous G28 Z + new Tooloffset
go to G28 XY location
continue loaded g-code file

this has the issue that it runs into problems when your G28 location is still at MCS 0 because the Z-Axis cant raise higher than the MCS without crashing or hitting limit switches. That is the issue that clehn8ok is encountering. (Proposed and confirmed workaround is setting your G28.1 to a lower z-height that accomodates your lagest tools so your last location is not at z-max)
During discussion most of us thought it would just raise to Z Home (MCS Z0 without the new tooloffset) and move from there and while we were at it we also contemplated that the return to the G28 XY location is an uneccessary move which could be omitted without any repercussions.

Result:

M6 command received
go to g28 for toolchange, present TOOL status
tool changed, cyclestart received
go to G59 XY
go to G59 Z
start probing cycle
sucessfull touchoff
raise Z to Z-Home 
continue loaded gcode file

In my mind this behaviour would also still be in compliance with the NIST standard your posted.
Hope, this clears it up a bit.

from core.

@Dietz0r The current sequence is:

M6 Command received
go to Z home (Z0) for toolchange, present TOOL status (LINEAR_AXIS_HOME_OFFSET is currently not used)
tool changed, cyclestart received
go to G59 XY
go to G59 Z
start Probing cycle
successfull touchoff
raise Z to Z home
go to original XY location
go to original Z location + tool offset (the controlled point is exactly as before the M6) // this is where hard Z limit is potentially triggered
restore spindle and coolant states
continue loaded g-code file

I would prefer move to G28 Z0 at the toolsetter

This can fail because the intermediate target Z includes the tool offset. If you want to go to Z home you have to use G53G0Z0 and is what the tool change code does.
Anyway I am adding a bool setting that when set moves to Z home above the toolsetter.
Or if you want, at the toolsetter so you can (or rather have to) move to whatever Z-position is deemed safe. You better be sure that the post used to generate the gcode does this...

In my mind this behaviour would also still be in compliance with the NIST standard your posted.

I do not agree - XY is not in the same position as before the M6 (and neither is Z).

from core.

@Dietz0r The current sequence is:

M6 Command received
go to Z home (Z0) for toolchange, present TOOL status (LINEAR_AXIS_HOME_OFFSET is currently not used)
tool changed, cyclestart received
go to G59 XY
go to G59 Z
start Probing cycle
successfull touchoff
raise Z to Z home
go to original XY location
go to original Z location + tool offset (the controlled point is exactly as before the M6) // this is where hard Z limit is potentially triggered
restore spindle and coolant states
continue loaded g-code file

hmm... i must have missunderstood a lot then. thanks for clarifying and thank you for your patience explaining it.

from core.

Setting $346 was added in build 20221018 to control return behaviour after tool changes.

from core.