Problem with bltouch bed level compensation calculation?

[urish]

There seems to be some discrepancy I can't figure out between the bltouch calibration values and the actual compensated z-values.

When I send a BED_MESH_CALIBRATE command, it prints out:

Send: BED_MESH_CALIBRATE
Recv: // probe at 45.000,27.000 is z=1.980000
Recv: // probe at 135.000,27.000 is z=2.162500
Recv: // probe at 225.000,27.000 is z=2.292500
Recv: // probe at 225.000,126.000 is z=2.322500
Recv: // probe at 135.000,126.000 is z=2.105000
Recv: // probe at 45.000,126.000 is z=1.942500
Recv: // probe at 45.000,225.000 is z=1.662500
Recv: // probe at 135.000,225.000 is z=1.950000
Recv: // probe at 225.000,225.000 is z=2.102500
Recv: // Mesh Bed Leveling Complete

You can see that the Z difference between (X=45,Y=225) and (X=225,Y=225) should be 0.44mm

However, when I tell the printer to go to these corners and observe the difference in the Z offsets, it is smaller:

Send: G0 X45 Y225 Z2
Recv: ok
[...]
Send: get_position
Recv: // mcu: stepper_x:3604 stepper_y:18000 stepper_z:-2525
Recv: // stepper: stepper_x:45.000000 stepper_y:225.000000 stepper_z:2.475000
Recv: // kinematic: X:45.000000 Y:225.000000 Z:2.475000
Recv: // toolhead: X:45.000000 Y:225.000000 Z:2.476067 E:0.000000
Recv: // gcode: X:45.000000 Y:225.000000 Z:2.000000 E:0.000000
Recv: // gcode base: X:0.000000 Y:0.000000 Z:0.000000 E:0.000000
Recv: // gcode homing: X:0.000000 Y:0.000000 Z:0.000000
[...]
Send: G0 X225 Y225 Z2
Recv: ok
[...]
Send: get_position
Recv: // mcu: stepper_x:18004 stepper_y:18000 stepper_z:-2436
Recv: // stepper: stepper_x:225.000000 stepper_y:225.000000 stepper_z:2.697500
Recv: // kinematic: X:225.000000 Y:225.000000 Z:2.697500
Recv: // toolhead: X:225.000000 Y:225.000000 Z:2.696875 E:0.000000
Recv: // gcode: X:225.000000 Y:225.000000 Z:2.000000 E:0.000000
Recv: // gcode base: X:0.000000 Y:0.000000 Z:0.000000 E:0.000000
Recv: // gcode homing: X:0.000000 Y:0.000000 Z:0.000000
Recv: ok
[...]

As you can see, the difference between the stepper_z in these two offsets is only 0.22mm, which is just half of the expected difference (0.44mm). So either I am missing something, or is there some kind of bug in the calculation?

I'd love to take a look at the code if you could point me out at the right direction. Also, here is my configuration (I also attached a recent log in #1804, would be happy to attach another one here if it would be helpful in any way).
printer.cfg.txt

And thanks again for Klipper!

[urish]

Also, this might be helpful as well:

Send: BED_MESH_OUTPUT
Recv: // Mesh Leveling Probed Z positions:
Recv: // 0.580000 0.762500 0.892500
Recv: // 0.542500 0.705000 0.922500
Recv: // 0.262500 0.550000 0.702500
Recv: Mesh X,Y: 7,7
Recv: Search Height: 5
Recv: Mesh Average: 0.68
Recv: Mesh Range: min=-0.4175 max=0.2603
Recv: Interpolation Algorithm: lagrange
Recv: Measured points:
Recv:   0.262500  0.373333  0.469167  0.550000  0.615833  0.666667  0.702500
Recv:   0.382778  0.463642  0.540216  0.612500  0.680494  0.744198  0.803611
Recv:   0.476111  0.536049  0.598735  0.664167  0.732346  0.803272  0.876944
Recv:   0.542500  0.590556  0.644722  0.705000  0.771389  0.843889  0.922500
Recv:   0.581944  0.627160  0.678179  0.735000  0.797623  0.866049  0.940278
Recv:   0.594444  0.645864  0.699105  0.754167  0.811049  0.869753  0.930278
Recv:   0.580000  0.646667  0.707500  0.762500  0.811667  0.855000  0.892500
Recv: 
Recv: ok

[klipper-gitissuebot]

Hi @urish,

It did not look like there was a Klipper log file attached to this ticket. The log file has been engineered to answer common questions the Klipper developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions).

Unfortunately, too many people have opened tickets without providing the log. That consumes developer time; time that would be better spent enhancing the software. If this ticket references an event that has occurred while running the software then the Klipper log must be attached to this ticket. Otherwise, this ticket will be automatically closed in a few days.

For information on obtaining the Klipper log file see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

The log can still be attached to this ticket - just add a comment and attach the log to that comment.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[urish]

Adding the log again, to make the bot happy :-)

klippy.log

[KevinOConnor]

Given you were impacted by #1804, I'd recheck with the latest version of the software.

-Kevin

[urish]

Sure, I just redid the test - and it seems like the issue is still happening. Basically, the calculated difference in the Z height between two points is only about half of the measured difference according to the bed mesh:

Send: BED_MESH_CALIBRATE
Recv: // probe at 45.000,27.000 is z=1.937500
Recv: // probe at 135.000,27.000 is z=2.107500
Recv: // probe at 225.000,27.000 is z=2.240000
Recv: // probe at 225.000,126.000 is z=2.287500
Recv: // probe at 135.000,126.000 is z=2.155000
Recv: // probe at 45.000,126.000 is z=1.850000
Recv: // probe at 45.000,225.000 is z=1.632500
Recv: // probe at 135.000,225.000 is z=1.907500
Recv: // probe at 225.000,225.000 is z=2.025000
Recv: // Mesh Bed Leveling Complete
Recv: // Bed Mesh state has been saved to profile [default]
Recv: // for the current session.  The SAVE_CONFIG command will
Recv: // update the printer config file and restart the printer.
Recv: ok
[...]
Send: BED_MESH_OUTPUT
Recv: // Mesh Leveling Probed Z positions:
Recv: // 0.537500 0.707500 0.840000
Recv: // 0.450000 0.755000 0.887500
Recv: // 0.232500 0.507500 0.625000
Recv: Mesh X,Y: 7,7
Recv: Search Height: 5
Recv: Mesh Average: 0.66
Recv: Mesh Range: min=-0.4275 max=0.2461
Recv: Interpolation Algorithm: lagrange
Recv: Measured points:
Recv:   0.232500  0.341667  0.433333  0.507500  0.564167  0.603333  0.625000
Recv:   0.319444  0.440463  0.541574  0.622778  0.684074  0.725463  0.746944
Recv:   0.391944  0.516852  0.621296  0.705278  0.768796  0.811852  0.834444
Recv:   0.450000  0.570833  0.672500  0.755000  0.818333  0.862500  0.887500
Recv:   0.493611  0.602407  0.695185  0.771944  0.832685  0.877407  0.906111
Recv:   0.522778  0.611574  0.689352  0.756111  0.811852  0.856574  0.890278
Recv:   0.537500  0.598333  0.655000  0.707500  0.755833  0.800000  0.840000
Recv: 
Recv: ok
Recv:   0.537500  0.598333  0.655000  0.707500  0.755833  0.800000  0.840000
Recv: 
Recv: ok
[...]
Send: G0 X45 Y225 Z2
Recv: ok
[...]
Send: get_position
Recv: // mcu: stepper_x:3598 stepper_y:18000 stepper_z:777
Recv: // stepper: stepper_x:45.000000 stepper_y:225.000000 stepper_z:2.445000
Recv: // kinematic: X:45.000000 Y:225.000000 Z:2.445000
Recv: // toolhead: X:45.000000 Y:225.000000 Z:2.446183 E:0.000000
Recv: // gcode: X:45.000000 Y:225.000000 Z:2.000000 E:0.000000
Recv: // gcode base: X:0.000000 Y:0.000000 Z:0.000000 E:0.000000
Recv: // gcode homing: X:0.000000 Y:0.000000 Z:0.000000
Recv: ok
Recv: // toolhead: X:45.000000 Y:225.000000 Z:2.446183 E:0.000000
Recv: // gcode: X:45.000000 Y:225.000000 Z:2.000000 E:0.000000
Recv: // gcode base: X:0.000000 Y:0.000000 Z:0.000000 E:0.000000
Recv: // gcode homing: X:0.000000 Y:0.000000 Z:0.000000
Recv: ok
[...]
Send: G0 X225 Y225 Z2
Recv: ok
[...]
Send: get_position
Recv: // mcu: stepper_x:17998 stepper_y:18000 stepper_z:852
Recv: // stepper: stepper_x:225.000000 stepper_y:225.000000 stepper_z:2.632500
Recv: // kinematic: X:225.000000 Y:225.000000 Z:2.632500
Recv: // toolhead: X:225.000000 Y:225.000000 Z:2.633750 E:0.000000
Recv: // gcode: X:225.000000 Y:225.000000 Z:2.000000 E:0.000000
Recv: // gcode base: X:0.000000 Y:0.000000 Z:0.000000 E:0.000000
Recv: // gcode homing: X:0.000000 Y:0.000000 Z:0.000000
Recv: ok
[...]

The Z-difference between (45, 225) and (225, 255) in mesh in 0.3925, while the stepper_Z difference is only 0.1875.

Also, here is a recent klippy.log, if that's helpful in any way:

klippy.log

[urish]

Update: I started looking into this myself, and created a script that initializes a BedMesh object so I can test it in isolation. It seems to reproduce the issue:

('move', [45, 225, 2.4461833333333334, 0], 400)
...
('move', [225, 225, 2.63375, 0], 400)

The Z-difference between the transformed moves is 0.1875, just as I got with the real printer. I'm going to keep investigating...

[urish]

Update:

After experimenting with the code, this seems to do with the probe's x_offset and y_offset being taken into account. When I set both to zero, I get the expected values, though, I suspect that this means I have done the test wrong, and that I have to move the bltouch probe to the relevant points ([45, 225] and [225, 255]) instead of moving the printer head there as I did. I will update as I keep experimenting

[Arksine]

The z adjustment is smaller because you have fade enabled. According to your configuration z adjustment starts fading out at gcode Z=1, and adjustment completely fades out by gcode Z=5.

[urish]

Thank for the input @Arksine! Where can I read more about the rationale behind Z-fading and how it affects the print quality?

[Arksine]

I don't know if there is any specific literature for it, I do know that it was introduced by Marlin a couple of years ago. The rationale is that small adjustments in Z should have a negative impact on print quality, so we can gradually fade out adjustment between fade_start and fade_end. Whether or not the Z adjustment is noticeable likely depends on the the shape of your bed. If nothing else, enabling fade should result in a flat surface at the top of the print, rather than a surface that matches the shape of your bed.

[urish]

Well, that makes sense! Anyway, seems like I better understand the numbers I'm getting so I will close this issue and move-on