impossible to get absolute machine coordinates from `G38.n` without erasing TLO

[wucke13]

I have a use-case where I want to get the touch-off from a G38 in absolute machine coordinates. The problem that I have is the following: G38 only stores the machine coordinates in the relative current working coordinate system. This might, or might not include the tool offset (TLO), depending i.e. on whether G43 was called after the last Tn M6.

The G38.2 example (https://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g38) cleverly avoids this pitfall by issuing a G49 before the G38.2, which however erases the current TLO. At first I tried to just incorporate the TLO in the formula found in that example, to this extent:

(                   G53+n Z  n             G92 Z   G92?    TLO Z)
#<z_work_offset> = [#[5203 + #5220 * 20] + #5213 * #5210 - #5403]

However, this formula is only correct half the times, depending on whether the TLO Z is also applied (via a G43) or not. For other optional coordinate system offsets, there is a status property (i.e. #5210 for G92/G52, https://linuxcnc.org/docs/html/gcode/overview.html#sub:numbered-parameters) that tell us whether this offset is actually applied.

Unfortunately, as far as I can see, none such parameter is available to announce whether TLO is applied.

[andypugh]

It's not impossible, but it is hacky and unsatisfying. (I figured this out a long time ago as a newbie and have forgotten that it's a terrible hack)

G30.1 - stores the current absolute position into parameters 5181-5186.

[wucke13]

And then you suggest comparing the current absolute parameters to 5420-5428 + work_offset to figure out whether TLO is applied?

If so, I agree, this most definitely is deserving of the attribution "unsatisfying". And it heats up fears around floating point arithmetic quirks on my end at least.

[andypugh]

No, if you run a G30.1 you can then read out the current absolute machine coordinates from #5181-5186. Which I think is what you said you wanted?

The hack is that this is not what G30 is for.

[wucke13]

I see. Do I get exactly the same coordinates from #5181-#5186 after the G38.n as I would get from #5061-#5069 (modulo the current work coordinate system offsets of course)?

I would assume that the G38.1 snapshots the coordinate in the servo thread tick in which the probe signal changes, but due to the maximum acceleration being less than infinity, the absolute coordinates (as reported by G30.1) likely are a bit further (due to a non-zero distance required to slow to a halt once the probe signal rise was registered).
So likely the best accuracy (independent of machine acceleration) would be achieved with something akin this?

G91
G38.2 Z-2
G90
G0 Z[#5063]
G30.1
#machine_actual_z_probed = #5183

[grandixximo]

I though I just fixed this a few weeks back, don't the parameters now reflect the actual loaded tool length?

Edit:

This should largely be solved now by #3996, which changed the semantics of parameters #5401-#5409.

Previously those parameters only refreshed on M6, G10 L1/L10/L11, and startup, reading from the loaded tool's stored offsets. G43Hn (with n different from the loaded tool), G43.1, and G43.2 never updated them, and G49 did not zero them. So reading #5401-#5409 did not tell you what offset was actually applied to motion, which is exactly the ambiguity described here.

After #3996, convert_tool_length_offset writes the applied tool length offset for every G43 variant and zeroes the parameters on G49. So:

• With a TLO active (G43/G43.1/G43.2), #5403 holds the Z offset actually applied to motion.
• With G49, #5403 is 0.

That gives you the status you were after: #5403 nonzero means a Z TLO is in effect, and the value is exactly the amount to back out. The formula is now reliable regardless of whether G43 or G49 is active, so you no longer need to issue G49 before probing just to get a known state.

One thing to keep in mind: G38.n stores the probe result in #5061-#5069 in the current coordinate system, which includes the active G54-style offset and any G92/G52 offset in addition to the TLO. #3996 makes the TLO portion reliably readable; to reach absolute machine coordinates you still subtract the active coordinate system origin (#5221+ for G54, etc.) and any G92/G52 offset (#5211+). The part that was "only correct half the time" was the TLO term, and that is what is fixed.

Note on versions: this landed on master. If you are on a 2.x stable release it is not there yet.

[grandixximo]

@andypugh Should I back-port this before the 2.9.9 release? It is pretty egregious to be needing G30.1 hacks for proper behavior.

[wucke13]

@grandixximo Thank you for the lengthy explanation; this sounds good. Just to confirm, after applying the patches:

(                   G53+n Z  n             G92 Z   G92?    TLO Z)
#<z_work_offset> = [#[5203 + #5220 * 20] + #5213 * #5210 - #5403]

Should be the correct Z offset between current work coordinate system (as reported by G38.n) and the machine actual coordinate system under all circumstances?

[rene-dev]

I had the exact same issue, my solution to this was to use an g53, and then do an incremental touchoff move. from a known position.

[grandixximo]

@wucke13

The formula is right except for the tool offset sign I believe, and yes it will work in all circumstances.

(                   G53+n Z  n             G92 Z   G92?    TLO Z)
#<z_work_offset> = [#[5203 + #5220 * 20] + #5213 * #5210 + #5403]
#<machine_z>     = [#5063 + #<z_work_offset>]

@rene-dev

That is the same class of workaround as Andy's G30.1 trick. And note you cannot put G38.n on a G53 line at all: G53 requires G0 or G1 to be active on the block, so the G53 has to be a separate move before or after the probe, then an incremental touch-off from a known machine position. It works, but it is exactly the kind of indirection #3996 removes: with the applied TLO now in #5403, the machine coordinate of a probe falls out of the parameters directly without any extra tricks.

[wucke13]

Just to confirm: I applied 267094a onto 2.9.8, and using this G-Code, no matter the sequence of G10 L1, G43 and what not, I do get a correct Z machine actual reading:

#<z_work_offset> = [#[5203 + #5220 * 20] + #5213 * #5210 + #5403]
#<z_probed_machine_actual> = [#<z_probed> + #<z_work_offset>]

Thanks @grandixximo !

Fixed via #3996

[grandixximo]

@andypugh worth porting to 2.9?

The g-code snippet might also be good for the docs, rather than being in a remote gh post?

[grandixximo]

@andypugh Prepared both, we can move conversation there...