[2.0.x] Z correction on tool-change for all HAS_MESH

[thinkyhead]

Addressing #10130

Apply the same Z correction on tool-change for all mesh-based leveling (not just MBL).

[Bob-the-Kuhn]

The UBL equivalent of lines 458 & 459 need to be added.

458  planner.apply_leveling(current_position[X_AXIS], current_position[Y_AXIS], z1);
459  planner.apply_leveling(x2, y2, z2);

[thinkyhead]

Are you sure about that? Both planner.apply_leveling and unapply_leveling include code specific to UBL.

[Roxy-3D]

The root cause of all these problems is UBL has it's own motion routine. And that is only because the original mesh bed leveling had its own motion routine.

I suspect the 'right' answer is to merge UBL's motion routine with planner.cpp's motion calculations. And seriously... UBL's code is optimized for CPU cycles....

We should share common code just because it simplifies the maintenance of the code...

[thinkyhead]

the original mesh bed leveling had its own motion routine

I believe that we're calling functions here that will result in calling the appropriate motion routines, since those are at a lower level. But, yes, it would be good if everything was more integrated so that all internal moves do the right thing.

Anyway, this code should be obviated by my proposed change to tool_change where it disables leveling before the Z raise and then re-enables leveling for the "move back."

But this means we have to fix all cases where there's a Z raise followed by a Z lower, especially where this is done by "spoofing" the current Z position. This is because the spoofing approach is incompatible with Z Fade. So this includes the Z hop done as part of G10/G11, and perhaps some other cases.

The reason for this is easy to understand. Z fade changes the amount of leveling compensation depending on both the starting and ending Z position of a move. If a move is done by "spoofing" the Z position then the amount of fade will be incorrect for both the start and end of the Z move (and the Z will be slightly off for any moves done in-between the Z raise and Z lower).

These Z moves are only complicated by the fact that we need to keep the same Z position (i.e., spoof Z) as part of the raise and lower behavior. There are a couple of approaches that could fix this:

1. Leverage the Z babystepping code and include it whenever there are (a) multiple tools requiring raise/lower, or (b) firmware retraction. Then we could set the Z babystepping distance as needed.
2. Temporarily set the Z fade to 0 (or just disable leveling) temporarily in-between G10 and G11. This would cause noticeably incorrect movement on a very tilted bed.
3. Continue to use "spoofing" but make sure it's symmetric: If the Z position is spoofed before the raise, then don't spoof it before the lower, but make sure to only spoof it after the lower. This may not work because the amount of Z correction at the XY where the G10 is done will differ from the Z correction where the G11 is done.

I'm going to have users test and see whether any of these approaches works as part of debugging the current open Z hop and tool change issues.