Fix Z-probe default Z-offset for RRF2 and RRF3

[HaythamB]

In our default config files, we don't include a G31 command to account for the z-probe offsets, since we assume its the center of our tool coordinate offsets and its the center of our carriage.

However, due to legacy reasons, RRF defaults to a G31 Z0.7 hardcoded in RRF that must be addressed to get proper first layer behaviors, especially if using ZTATP for tool offset calculations in Z. (see forum post for details of why this occurs here

To test this out, unload your tools, rehome all your axes in RRF, and then issue a G30 S-1 command at the middle of your bed (or wherever your homez.g usually reads off of in your print space). You'll see that the trigger height consistently has an offset of 0.7mm applied to it!!

We should add a line to the config.g files to account for this oddity as follows: G31 Z0 (or alternatively more correctly: G31 K0 Z0), which will allow us to obtain a true reading of Z=0 when probing the bed.

This issue becomes even more apparent when aligning tools in Z using ZTATP, which will append this code to the endstop undefine/redefine steps it must take in order to use a touchplate. Without this code being in config.g, you must manually apply it every time you redefine your Z-probe code (M558 lines), which ZTATP does multiple times per tool.

[olby]

The duet3 config contains a G31, we should make them consistent.

https://github.com/machineagency/jubilee/blob/e3cbce06f40137bf855db0f54141e2761347d4b3/software/duet_config_files/duet3/sys/config.g#L124

[Poofjunior]

Oof; what a bug. Just tested this, and it looks like all of our tool offsets will need to be reduced by 0.7mm also. Not a big issue for people commissioning their machine for the first time, but it would be an adjustment for anyone blindly taking this setting. Thankfully, it defaults to making your tool 0.7mm too high, rather than too low.

[Poofjunior]

Ok, this is fixed on Duet2 configs. I'll need another few days to test this out on a (work-in-progress) Duet3 machine

[Poofjunior]

Ok; I got to thinking about this more recently. While it's a bummer that this is hardcoded into RRF, I think it's probably also saved countless Z limit switches on other machines running RRF.

Imagine if we set it to zero for a second. Then imagine we issue a G0 X0 Y0 Z0 followed by literally any move in X or Y (but not Z). Since All mechanical switches need to be depressed slightly to trigger, that means that any move without carrying tools with Z=0 will be scraping the limit switch along the bed. While this probably wont happen to too many people, it's super easy to do but also super easy to check for in ZTATP.

I actually propose that in your ZTATP code, you (1) read the state of the Z offset with G31 and (2) then apply it in your offset calculations. This is super easy to read from the machine state by simply issuing the gcode command, and it has the bonus that it prevents us from prematurely killing more Z limit switches on the off-chance someone goes to Z=0 and then issues an X or Y move. Let me know what you think!

[HaythamB]

I think this is a definitely win-win scenario. I'll add it to my ZTATP issues and handle it there. You're both correct that we should let the machine figure itself out without forcing the operator to think about Z crashes.

[HaythamB]

Handled this in HaythamB/TAMV#11