Calculation broken after klipper update

[RcTomcat1]

Hi, I just updated klipper to v0.11.0-89-gead81fbf and now my z-offset calculation seems broken. Where it gave me a perfect first layer before the update the nozzle is now scrapping across the bed. Z_calibration is v0.9.2-0-gf212b40

Z-Calibration gives back a value that i would deem logical yet my papersheet gets stuck quite early.

 12:22:36  // Z-CALIBRATION: ENDSTOP=0.470 NOZZLE=0.497 SWITCH=7.153 PROBE=7.132 --> OFFSET=-0.022500
12:22:36  // Docking Probe
12:22:42  $ GET_POSITION
12:22:43  // probe: TRIGGERED
12:22:43  // mcu: stepper_x:-10 stepper_y:-50 stepper_z:239 stepper_z1:239 stepper_z2:239 stepper_z3:239
// stepper: stepper_x:415.000000 stepper_y:-225.000000 stepper_z:23.520000 stepper_z1:23.520000 stepper_z2:23.520000 stepper_z3:23.520000
// kinematic: X:95.000000 Y:320.000000 Z:23.520000
// toolhead: X:95.000000 Y:320.000000 Z:23.520368 E:0.000000
// gcode: X:95.000000 Y:320.000000 Z:25.000000 E:0.000000
// gcode base: X:0.000000 Y:0.000000 Z:-0.022500 E:0.000000
// gcode homing: X:0.000000 Y:0.000000 Z:-0.022500
12:22:55  $ G90
G1 X175 F7800
12:22:58  $ G90
G1 Y175 F7800
12:23:02  $ G90
12:23:07  $ G0 Z3
12:23:33  $ G0 Z1
12:23:50  $ G0 Z1.5
12:24:17  $ G0 Z1.4
12:24:29  $ G0 Z1.3

Any advice on what I could check / do?

[coffeeandubuntu]

I’m having this same issue. On a recent print z-offset was calculated as 0.78. That caused my nozzle to drag across the bed. 1.44 was the setting I landed on.

[Adri-Donn]

I have the same issue too, while waiting for a resolution I defined a z-offset manually.

[Danielstc91]

Can confirm issue on same version of klipper. Was not an issue before

[RcTomcat1]

I replaced the omron switch twice, redid the endstop countless times. // Z-CALIBRATION: ENDSTOP=0.250 NOZZLE=0.257 SWITCH=7.217 PROBE=7.680 --> OFFSET=0.220000 Currently printing with 1.38 offset..... For me a formerly very helpful plugin has become a major issue. Three weeks and no reply or hint what to look at for troubleshooting. Currently I am better of without using it.

[Adri-Donn]

Okay on my side I realized that my klicky-macro file was not up to date because I was referring the one in printer_data instead of the one in the repository. Once this was corrected and updated everything works fine.

[RcTomcat1]

Okay on my side I realized that my klicky-macro file was not up to date because I was referring the one in printer_data instead of the one in the repository. Once this was corrected and updated everything works fine.

My macro file is current and identical to the one in the klicky repository

Edit: I just reverted to v0.9.1 54f9a2a by simply overwriting the z_calibration.py in klippy/extras. Redid the z-endstop calibration once more and had calibrate_z run. Calculated offset matched reality. So I restarted the printer, homed, QGL, Home and ran calibrate_z again. Calculated offset matches reality. G0 Z0 catches a piece of paper firmly. G0 Z0.1 makes for a slight grip. Seems to be back to working order.

Edit: Calculated offset seems to be correct when cold, while heated it still crashes....

Edit2: Looks like I have been quite stupid. I just ran my start macros and noticed that I am loading a mesh. Turns out my mesh was no longer there....loading an empty mesh seems to have been the root cause of my issue here.

[TitusLabs]

Good to hear it's working again!

I am not aware of or have encountered any problems with auto-calibration. Mesh is one thing though. I personally don't use it. But thanks for the feedback on this.

Is there any other need, or can I close the ticket?

[TitusLabs]

@Adri-Donn I would be interested in how the Klicky macros have influenced the auto calibration?

[Adri-Donn]

@TitusLabs : I'm not really sure, but it was like if the reference point was moving, but using klicky and auto-z at the last update works really well :)

I don't had the mesh problem, i make a new one on each print :)

So i modified my plugin to fix this and make a reference to the repository instead of blocking the file at a certain version. If you want, here is my plugin : https://gitlab.black-rider-studio.eu/Adri/voronbrds and here is my configuration : https://gitlab.black-rider-studio.eu/Adri/partagevoron/-/tree/master/Configurations/350/Adri/Blue%20(CanBUS)

Tell me if i can help you, i'm on discord too :)

You can get my discord on the readme of "partageVoron"

[TitusLabs]

Ok, great that you found it! A moving reference point could not be caused by the auto-z-calibration. But maybe an adaptive mesh macro did..