Fix rotation point for transformation matrix for auto bed leveling

[roginvs]

There is a bug in auto bed leveling logic. After measurement bed plane we have to adjust current z position from bed plane at zero point, not at current position point because transformation matrix performs rotation through zero point.

For example, old behavior of G32:

10:17:37.527: Z-probe:20.00 X:20.00 Y:20.00
10:17:55.232: Z-probe:18.95 X:160.00 Y:20.00
10:18:12.466: Z-probe:19.05 X:100.00 Y:145.00 ; This is measured point. We can be sure that bed is 19.05mm far away at this position.
10:18:17.583: plane: a = -0.0075 b = -0.0025 c = 20.1978
10:18:17.592: Transformation matrix: 0.999972 0.000000 0.007471 -0.000019 0.999997 0.002504 -0.007471 -0.002504 0.999969
10:18:17.595: CurrentZ:18.88 atZ:23.00
10:18:18.047: Info:Autoleveling enabled
10:18:18.049: X:100.14 Y:145.04 Z:17.764 E:0.0000 ; Wow, we measured this point few lines before, and we got 19.05 as z-level, so after all transformations here should be 19.05 at Z

New behavior:

10:33:46.499: Z-probe:25.97 X:20.00 Y:20.00
10:34:10.184: Z-probe:24.93 X:160.00 Y:20.00
10:34:33.396: Z-probe:25.05 X:100.00 Y:145.00 ; Same place, measured Z here is true distance (regardless that is 5 mm greater than in previous example)
10:34:41.512: plane: a = -0.0074 b = -0.0023 c = 26.1634
10:34:41.520: Transformation matrix: 0.999973 0.000000 0.007410 -0.000017 0.999997 0.002342 -0.007410 -0.002342 0.999970
10:34:41.522: CurrentZ:26.16 atZ:28.95 ; Actually it is CurrentZ before transformation matrix applied
10:34:41.978: Info:Autoleveling enabled
10:35:03.686: X:100.19 Y:145.06 Z:25.081 E:0.0000 Now here after applying transformation we have same Z as measured before

[repetier]

I think you are right in using origin height here (took me 1h to understand though).

I'm wondering if you have z max homing as I think that the patch will now break the z length correction a few lines later. I think that should with your patch looks like this

#if MAX_HARDWARE_ENDSTOP_Z
float xRot,yRot,zRot;
Printer::transformFromPrinter(Printer::currentPosition[X_AXIS],Printer::currentPosition[Y_AXIS],Printer::currentPosition[Z_AXIS],xRot,yRot,zRot);
Com::printFLN(PSTR("Z after rotation:"),zRot);
// With max z endstop we adjust zlength so after next homing we have also a calibrated printer
if(s != 0) {
Printer::zLength += /currentZ/ plane.z((float)Printer::currentPositionSteps[X_AXIS] * Printer::invAxisStepsPerMM[X_AXIS],(float)Printer::currentPositionSteps[Y_AXIS] * Printer::invAxisStepsPerMM[Y_AXIS]) - zRot;
Com::printFLN(Com::tZProbePrinterHeight, Printer::zLength);
}
#endif
where I used the old currentZ computation. Otherwise each calibration would increase the zLength which can't be right. Can you verify that? I will test this on a delta as well.

[roginvs]

I updated branch as you proposed. Honestly, I do not understand what magic happens inside '#if MAX_HARDWARE_ENDSTOP_Z' block, but I have a clue that probably to add a new currentZ to Printer::zLength (without zRot) is better way (one of the reason is that we are interested in z-distance between calculated plane and rotation plane, not in Z change on rotation [nevertheless, these values will be almost the same, but not strictly equal]).
Anyway, current branch version is not changing magic block behavior.

[repetier]

I will test it with delta and then see what complains come up. But I guess the bug you found is the reason for many users getting in trouble. It works great if you do not use position as start height and do z max homing afterwards. Therefore I think I never had that problem or noticed.

[flenger1]

Hello,
Thanks for the fix, it works fine.
But in my case it is necessary before each printing after home xyz doing G32.
Length axis z is not correctly defined...

[roginvs]

This fix is included into development branch, no need to have this pull request here anymore.