protoloft / klipper_z_calibration

Klipper plugin for self-calibrating z-offset

Automatic Z-Calibration

It's like automatically baby-stepping on your 3D printer before every print, and the first layer will always be perfect - no matter which nozzle or new flex-plate is being tested.

Documentation

Visit the Wiki to view the full documentation for this Klipper plugin.

The latest release notes are here.

📌 And remember: The smaller the switch-offset, the further the nozzle is away from the bed! 😉

Further Resources

A great how-to video by Kapman: https://youtu.be/oQYHFecsTto

And if you are looking for an RRF version of this automatic z-offset calibration

You can find one here from pRINTERnOODLE - This is really fantastic to see 🎉

Thanks for all your feedback and support!

And if you like my work and want to support me, you can do so here:

Disclaimer

You use it at your onw risk! I'm not responsible for any damage that might result. Although, this extension works rock solid for me and many others for years now. Always be careful and double check everything when configuring or working with your printer. And as always, never leave unattended while printing!

klipper_z_calibration's Issues

error with multi mcu homing

An error occurs when used with multi mcu homing branch.

pi@mainsailos:~/klipper $ git branch -a

• (HEAD detached at origin/work-homing-20210217)
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/work-flash-20210519
  remotes/origin/work-fopdt-20180405
  remotes/origin/work-homing-20210217
  remotes/origin/work-linux-irq-20200607
  remotes/origin/work-mechaduino-20181205
  remotes/origin/work-pins-20201222
  remotes/origin/work-python3-20200612
  remotes/origin/work-tuning-20200805

---

klippy.log

Internal error on command:"G28"
Internal Error on WebRequest: gcode/script
Traceback (most recent call last):
File "/home/pi/klipper/klippy/webhooks.py", line 225, in _process_request
func(web_request)
File "/home/pi/klipper/klippy/webhooks.py", line 366, in _handle_script
self.gcode.run_script(web_request.get_str('script'))
File "/home/pi/klipper/klippy/gcode.py", line 200, in run_script
self._process_commands(script.split('\n'), need_ack=False)
File "/home/pi/klipper/klippy/gcode.py", line 182, in _process_commands
handler(gcmd)
File "/home/pi/klipper/klippy/extras/homing_override.py", line 60, in cmd_G28
self.template.run_gcode_from_command(context)
File "/home/pi/klipper/klippy/extras/gcode_macro.py", line 68, in run_gcode_from_command
self.gcode.run_script_from_command(self.render(context))
File "/home/pi/klipper/klippy/gcode.py", line 197, in run_script_from_command
self._process_commands(script.split('\n'), need_ack=False)
File "/home/pi/klipper/klippy/gcode.py", line 182, in _process_commands
handler(gcmd)
File "/home/pi/klipper/klippy/extras/homing_override.py", line 23, in cmd_G28
self.prev_G28(gcmd)
File "/home/pi/klipper/klippy/extras/homing.py", line 252, in cmd_G28
kin.home(homing_state)
File "/home/pi/klipper/klippy/kinematics/corexy.py", line 65, in home
homing_state.home_rails([rail], forcepos, homepos)
File "/home/pi/klipper/klippy/extras/homing.py", line 209, in home_rails
self.printer.send_event("homing:home_rails_end", self, rails)
File "/home/pi/klipper/klippy/klippy.py", line 248, in send_event
return [cb(*params) for cb in self.event_handlers.get(event, [])]
File "/home/pi/klipper/klippy/extras/z_calibration.py", line 109, in handle_home_rails_end
kin_spos = homing_state.get_stepper_trigger_positions()
AttributeError: Homing instance has no attribute 'get_stepper_trigger_positions'
AttributeError: Homing instance has no attribute 'get_stepper_trigger_positions'
Transition to shutdown state: Internal error on command:"G28"
Dumping gcode input 0 blocks
gcode state: absolute_coord=True absolute_extrude=True base_position=[0.0, 0.0, 0.0, 0.0] last_position=[229.0, 355.0, 1.4304753823060659, 0.0] homing_position=[0.0, 0.0, 0.0, 0.0] speed_factor=0.0166666666667 extrude_factor=1.0 speed=200.0
Reactor garbage collection: (268.687623414, 181.198356706, 0.0)
MCU 'turbocan0' shutdown: Command request
clocksync state: mcu_freq=48000000 last_clock=13625396812 clock_est=(244.279 12248463101 48002638.387) min_half_rtt=0.000489 min_rtt_time=220.778 time_avg=244.278(875.719) clock_avg=12248463101.361(42036827636.792) pred_variance=1465532.097 clock_adj=(-0.860 48002166.750)
Dumping serial stats: bytes_write=9636 bytes_read=31806 bytes_retransmit=0 bytes_invalid=0 send_seq=924 receive_seq=924 retransmit_seq=0 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0
Dumping send queue 100 messages

configuration/homing.cfg G0 Z2 F1500 is in absolute not relative mode

Looking at configuration/homing.cfg:

Line 22 leaves the printer in absolute mode.
Line 38 the touches the nozzle to the z probe,
Line 39 then G0 Z2 F1500 which is intended to move the nozzle up, but if the z probe offset is more than 2mm it actually moves DOWN smashing into the Z probe.
I suggest adding a G91 just before line 39 as a fix.

Problems to install klipper_z_calibration on newest version klicky probe

hi i have been trying to install the klipper_z_calibration for days, read a lot on the repo and elsewhere, watched videos and talking to people about this.

but i cant get it to work. it seems like klicky probe has changed their files so when i install this (klipper_z_calibration i have new version files and old version files and cant use the auto z calibration? something is not connected it seems like.

is there some way i can read about how to fix this? or will there be an update?

thanks for your good work :) this seems like a must have plugin :)

Error: Unknown config object 'homing' after update

Hello,
I updated today both Klipper and Z_calibration plugin and get this new error :

I'll investigate further to find a fix and let you know.

removal?

Two weeks after installing I still can't print. Just went from this plugin calculating a -0.2 offset to a -36. How does one remove this and go back to manual method?

New update feedback

1. document which config values are used far which moves, or add them to be overwritten in the zcalibrate config section
2. allow user to overwrite probe sample's for z calibration independently of normal probe samples.

Will add more items as i find them :p

prints a little too close to the bed.

Hi,
what do I need to adjust in order for kzc to print a little further from the bed?

Dummy service not necessary?

I'm having trouble understanding the need for the dummy service. I'm no moonraker expert, but it would appear that it's not necessary to have a dummy service for update_manager to work?

Retry calibration if Deviation too high

Most times it doesnt work on the first try. However when i run it again its perfect. A retry calibration option would be nicewould be nice

z_tilt_adjust

I'm pretty new to macros, I had some working fine for magprobe that I lifted from someone's config and edited for mine - but I'm pretty sure it's causing the z height to be redefined somewhere and I can't seem to find it.

On my first nozzle probe during my start print routine I get the expected value of my position_endstop = -2.504
After z_tilt adjust, moving through to calibrate_z it seems to change to reading values of -7.xxxx, which is subsequently wildly out of the expected tolerance and errors out. Performing calibrate_z without the other macros behaves as expected.

I'm trying to swap to your macros, but they are obviously set up for QGL.
I am happy to have a tinker and see if I can get it working, but for the sake of sanity - is there any other "gotchya" code I need to look at than just swapping out QUAD_GANTRY_LEVEL references for "z_tilt_adjust" & rewriting/editing the QGL macro to perform z_tilt_adjust?

I'm slowly getting my head around it but there's plenty of things I don't know the benefit of or effects of that I'm taking at face value. Thought I'd post before I go to work so I can be well equipped when I come home to tackle it!

Neat program, love the idea.

Returning probe nozzle crash in the bed

Hi. I'm using Euclid with the plugin. If I do manual attach and detach of the probe it works fine. If I do a QGL it works fine but as soon I do Z calibration it will pickup the probe do the z offset and when it put it back it will be always hit the bed with the nozzle or the probe will not return properly into the dock. the question is why? if it can't pick it up and using the same coordinate in reverse mode it should bring it back as the dock location or position as it has not change. Any idea what I'm doing wrong? I'm using a V2.4 350

Fail gracefully

I think it'd be great if the z calibration could be retried if the resulting z offset is outside of the configured max_deviation. For me, this happens once in a while when the nozzle was not properly cleaned by my wipe procedure. Currently, I have to manually restart the print, waiting for QGL/bed mesh/heatup etc.
Ideally, when z calibration fails, i'd like to re-do my wipe procedure, followed by a new z calibration.
This is currently not possible, since z-calibration aborts the print in that case.

Could the macro somehow indicate that it failed, other than canceling the print?

[FR] Support for BLTouch

Hi, i tried your extra in knowledge of not tested with bltouch - all seems to work well but bltouch won't release pin to touch surface of endstop. Would it be possible to support the bltouch?

Homing instance has no attribute 'get_stepper_trigger_positions' (breaking change in Klipper?)

It looks like today's Klipper commit (65ed55a43be0b995fde2d620ea838352efa7afb8) might have a breaking change that is killing the z_calibrate logic. When I home all axes, it fails when homing the Z axis with:

In Klippy.log...

I rolled back my Klipper install to an earlier commit and the problem went away.

[FR] Be able to configure the plugin at runtime

Hi,

This is just a simple feature request to this plugin : I would love to be able to specify custom parameters at the call of the CALIBRATE_Z macro be able to do:
CALIBRATE_Z PROBE_BED_X={computed_value} PROBE_BED_Y={computed_value} [OTHER_PARAMETERS=...]

Use case : I'm doing a specific custom bed_mesh macro at every print start that is adapting the probing to the first layer size from the slicer. This system make the bed_mesh faster while still allowing for a very precise mesh: like 9x9 on the full plate but maybe 3x3 for a small part alone in the center or even around a small part in a corner if wanted. That mean the relative_reference_index change every time.
In fact today it's already working good for centered parts, but recently I got the center of my PEI sheet damaged and started to print off-centered. My custom bed mesh is already following the parts on the bed but the calibrate_z is still probing the center => This means that I got a deviation from the relative_reference_index that is not at the same position.

What do you think about this ?
I'll try to do a PR if I find time to do so :)

Not an issue, but an idea about autocalibrating switch_offset value

Hi,

I successfully use your code on my Voron2 equipped with a klicky probe.
Manual calibration of the switch_offset works fine, but is still a hassle.

I recently had to change my klicky probe to a spare one, and unfortunately, the switch_offset wasn't the same on the 2nd microswitch.

This gave me an idea on a possible way to try, and maybe achieve autocalibration of the swith offset:

On a voron we have to "endstops" being the z_endstop end the probe.
If we probe the magprobe two times, we could maybe get the relative distance travelled by the microswitch.

I'll try to explain my idea further with the description of a calibration sequence:

• probe nozzle on Z-endstop
• attach magprobe
• probe magprobe main microswitch body on Z-endstop
• probe magprobe microswitch actuator on Z-endstop and wait for having both Z_endstop and probe endstop triggered

We should now have the means to compute both relative distances between all required values.

Unofrtunately, I lack the base knowledge on klipper to implement this idea, and would appreciate your insights

Offset measurement goes bad every few prints

Hi - it might be more of a Userquestion than an issue - i use the plugin and it mostly works fine. But somehow (my pei sheet tells a few stories already) the offset changes so much, that it scars the sheet.

I do very simple startscripts:

`[gcode_macro G32]
gcode:
G28
G0 Y330 F3000
CLEAN_NOZZLE
G28
QUAD_GANTRY_LEVEL
CLEAN_NOZZLE
CALIBRATE_Z
## Uncomment for for your size printer:
#--------------------------------------------------------------------
## Uncomment for 250mm build
#G0 X125 Y125 Z30 F3600

##  Uncomment for 300 build
#G0 X150 Y150 Z30 F3600

##  Uncomment for 350mm build
G0 X175 Y175 Z30 F3600
#--------------------------------------------------------------------

[gcode_macro PRINT_START]

Use PRINT_START for the slicer starting script - please customise for your slicer of choice

gcode:
G32 ; home all axes
BED_MESH_CALIBRATE
G1 Z20 F3000 ; move nozzle away from bed`

Home, clean nozzle, home again, qgl (its a voron 2.4), clean nozzle again, calibrate Z.

Its fine - my values are consistent, no big spreads (single jumps but median is fine)

probe at 175.000,155.250 is z=7.608202 probe at 175.000,155.250 is z=7.610702 probe at 175.000,155.250 is z=7.610702 Switch body >> probe at 228.000,333.000 is z=8.104452 probe at 228.000,333.000 is z=8.104452 probe at 228.000,333.000 is z=8.104452 probe at 228.000,333.000 is z=8.104452 probe at 228.000,333.000 is z=8.105702 probe at 228.000,333.000 is z=8.105702 Nozzle >> probe at 231.000,350.000 is z=0.003202 probe at 231.000,350.000 is z=0.001952 probe at 231.000,350.000 is z=0.000702 probe at 231.000,350.000 is z=0.000702 probe at 231.000,350.000 is z=-0.000548 probe at 231.000,350.000 is z=-0.000548

But my overall offset changes from .55 to .8 from print to print, beeing to close from time to time.
Now i changed the nozzle and the measurement (i posted above) gave me an offset like OFFSET=-0.823048 what was .35 to big. i needed to adjust it to around .5 to start printing and stopping killing my pei sheet.

the plugin should calculate the offset even after changes of builplate or nozzle right? is there anything i can do to get consistent offsets? I adjusted my switch offset so it did a good job on the first sanity test and then said "fine, thats it" and hoped from now on it should do the trick. my sheet tells another story.
magnets are glued into place, no movement here so the klicky should be fine. should i do more probes?

thx!

Z_OFFSET_APPLY_CALIBRATOR

Idea for a gcode that works like Z_OFFSET_APPLY_PROBE/ENDSTOP that would apply the current offset to the switch offset for fast setup.

after last klipper update the plugin does not work anymore

Section 'z_calibration' is not a valid config section

Since update not working anymore

hello, I have updated z_calibration trough moonraker 4 or 5 days ago I it will not work anymore.
First without changing old configs, when printer was doing some calibration routines at start of a printer it would do like home but after when starting z_calbration looks like the two AB motors are working against each other with a rattling sound.

Try to use your new macros and configs but first it was heating my nozzle to 220 and bed to 100 without my gcode file need or want it. And also had crash issues the probe with z_endstop pin and had to increase clearance by a lot. but still not working.

When it starts to print imidiatly starts to loose steps. I gess it's it's because how your macros setc current to the motors.

Tryed to use Kliky examples and also could not make it work.

Now I have a very big paperweight.

regards

Probe samples exceed tolerance - Heaters remain on when error is raised

Hi,

Not sure if this is part of your macro or script or something that needs to be raised on the Klipper git.
Occasionally I get Probe samples exceed tolerance when calibrating the z offset and the print halts, but the heaters remain on.

Does your script use the standard probe commands from Klipper or should the script issue a shutdown if it errors out

Extract from the klippy.log

probe at 203.500,300.000 is z=0.753869
Probe samples exceed tolerance
Probe samples exceed tolerance
Probe samples exceed tolerance
Exiting SD card print (position 24234)
Stats 391442.8: gcodein=0 mcu: mcu_awake=0.002 mcu_task_avg=0.000007 mcu_task_stddev=0.000007 bytes_write=101248961 bytes_read=18515003 bytes_retransmit=9 bytes_invalid=0 send_seq=1853164 receive_seq=1853164 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=119996802 z: mcu_awake=0.012 mcu_task_avg=0.000011 mcu_task_stddev=0.000014 bytes_write=19438025 bytes_read=18749160 bytes_retransmit=9 bytes_invalid=0 send_seq=670802 receive_seq=670802 retransmit_seq=7 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=28 stalled_bytes=0 freq=119997356 adj=120000505 rpi: mcu_awake=0.001 mcu_task_avg=0.000013 mcu_task_stddev=0.000017 bytes_write=583278 bytes_read=1797527 bytes_retransmit=0 bytes_invalid=0 send_seq=97189 receive_seq=97189 retransmit_seq=0 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=49999811 adj=50001130  heater_bed: target=110 temp=110.4 pwm=0.467 enclosure: temp=29.4 sysload=0.94 cputime=8162.670 memavail=758140 print_time=180684.271 buffer_time=0.313 print_stall=12 extruder: target=160 temp=160.0 pwm=0.035
Heater extruder within range of 160.000
Stats 391443.8: gcodein=0 mcu: mcu_awake=0.002 mcu_task_avg=0.000007 mcu_task_stddev=0.000007 bytes_write=101249051 bytes_read=18515199 bytes_retransmit=9 bytes_invalid=0 send_seq=1853171 receive_seq=1853171 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=119996802 z: mcu_awake=0.012 mcu_task_avg=0.000011 mcu_task_stddev=0.000014 bytes_write=19438322 bytes_read=18749490 bytes_retransmit=9 bytes_invalid=0 send_seq=670816 receive_seq=670816 retransmit_seq=7 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=119997356 adj=120000494 rpi: mcu_awake=0.001 mcu_task_avg=0.000012 mcu_task_stddev=0.000016 bytes_write=583284 bytes_read=1797556 bytes_retransmit=0 bytes_invalid=0 send_seq=97190 receive_seq=97190 retransmit_seq=0 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=49999808 adj=50001106  heater_bed: target=110 temp=110.4 pwm=0.467 enclosure: temp=29.4 sysload=0.94 cputime=8162.770 memavail=758108 print_time=180684.271 buffer_time=0.000 print_stall=12 extruder: target=160 temp=161.6 pwm=0.035

Many Thanks

Edit Description in the z_calibration.cfg

Hi there,

I'm still fairly new to the Klippper and Voron world and in the last few days I tried to install or even set up the klicky with Auto Z calibration.

However, I was always too close to the bed until I noticed that my offset, which was 0.42 or 0.08, for example, was not taken into account!

Here I became skeptical and realized my mistake ..
I triggered the button of the Omron switch on the Z endstop and not the housing of the switch.

The reason for this was the assumption because of the text here ...

Could that be changed so that other users don't fall for it and the switch housing would will be used?

Kind Regards from Upper Austria

Tool head crash when probe detaches

I've just encountered a tool head crash when the plugin was attempting to touch the probe to the Z endstop pin. One of the magnets broke free from the probe, which must have occurred after the attachment procedure for it to have passed the attachment check. However, shortly thereafter the probe has fallen from the tool head and continued with the Z calibration procedure resulting in the nozzle crashing into the bed, because no probe was present to touch the Z endstop pin.

My assumption is that because klipper/the plugin is expecting to see a change in Z endstop state, it's not checking the probe state and is therefore unaware of the presence (or otherwise) of the probe. Since it must be attached to avoid a crash, is it possible to throw an error if the probe state is open during the Z calibration?

Calculated offset off by 0.9mm, possibly due to negative z endstop?

Hi there,

I have an issue where my Z Endstop pin on my Voron 2.4 is ~ 0.9mm below the PEI sheet on the bed, and the plugin does not seem to be correctly factoring in that negative offset, leaving the nozzle too low for a print, and scratching the bed.

I home the printer using G28, then run QUAD_GANTRY_LEVEL (which uses the klicky probe), and after that another G28. I then run Z_ENDSTOP_CALIBRATE, and moved the toolhead down until it rested with a little friction on a 0.2mm feeler gauge, and got the below

#*#
#*# [stepper_z]
#*# position_endstop = -0.900

Saving and restarting, I once again run G28, QGL, G28, and if I move the nozzle right down to the bed, it just touches the bed at z0

Running the CALIBRATE_Z macro, it calculates the following

Z-CALIBRATION: ENDSTOP=-0.900 NOZZLE=-0.898 SWITCH=8.956 PROBE=9.626 --> OFFSET=-0.702500

With this value set, I once again moved Z down until it rested with a little friction on a 0.2mm feeler gauge. I would expect that Z should equal 0.2mm, but it equalled 0.9mm (and says 0.197 in the brackets above the Z value in Mainsail), so it seems like it is not factoring in the z position_endstop value

Moving the z offset up by 0.9mm to 0.197 gets me to a position where the nozzle is just grabbing the 0.2mm feeler gauge, and the Z position is listed as 0.2

Am I doing something stupid here, or misunderstanding the plugin in some way? Is there a way to tell the plugin to raise the z offset by the value of the endstop, so that it's actually meeting the bed when z=0?

Install script not working

Hi I am not a linux pro.

But after running the new installer (updated from 0.8.1 to 0.9.1) the created link in klippy/extras points to //z_calibration.py. And Klipper fails when restarting the firmware.

I changed it manually to point to the right file, now it works.

The produced output of the install.sh (I have no idea on how to interpret this :) )

install.sh: 63: install.sh: Bad substitution
install.sh: 53: [: Illegal number:
Linking extension to Klipper...
Restarting Klipper...

Also wondering if there is some kind of Discord or some other way of discussing ( have some questions about accuracy)

how to access z_offset value that is stored in [SAVE_CONFIG] section of printer.cfg

Am considering adjusting calibrate_z.py a little, and would like to access z_offset from printer.cfg (the value prior to any SAVE_CONFIG). Please would you let me know how to do this from within calibrate_z.py - thanks!

This is a screenshot of the value's location

PrinterHoming instance has no attribute 'probing_move

I tried setting this up on my Voron 2.4 with klipper v0.9.1-299-gb0f94e50. At first I ran into issue #5, but I just removed the logging code that used that call and that got G28 running fine. I set up the following z_calibration config:

[z_calibration]                                                               
probe_nozzle_x: 232                                                           
probe_nozzle_y: 350                                                           
probe_switch_x: 227                                                           
probe_switch_y: 330.25                                                        
switch_offset: 0.46                                                           

and the following CALIBRATE_Z macro, using a klicky probe:

[gcode_macro CALIBRATE_Z]                                                     
rename_existing: BASE_CALIBRATE_Z                                             
gcode:                                                                        
    M117 Z-Calibration..                                                      
    Attach_Probe                                                              
    BASE_CALIBRATE_Z                                                          
    Dock_Probe                                                                
    M117                                                                      

When I tried running CALIBRATE_Z, however, I got the following error in the printer terminal:

Recv: !! Internal error on command:"BASE_CALIBRATE_Z"
Recv: !! Internal error on command:"CALIBRATE_Z"

This is the stack trace I got from klippy.log:

Internal error on command:"BASE_CALIBRATE_Z"
Traceback (most recent call last):
  File "/home/pi/klipper/klippy/gcode.py", line 182, in _process_commands
    handler(gcmd)
  File "/home/pi/klipper/klippy/gcode.py", line 120, in <lambda>
    func = lambda params: origfunc(self._get_extended_params(params))
  File "/home/pi/klipper/klippy/gcode.py", line 120, in <lambda>
    func = lambda params: origfunc(self._get_extended_params(params))
  File "/home/pi/klipper/klippy/extras/z_calibration.py", line 137, in cmd_CALIBRATE_Z
    state.calibrate_z()
  File "/home/pi/klipper/klippy/extras/z_calibration.py", line 312, in calibrate_z
    nozzle_zero = self._probe_on_z_endstop(self.helper.probe_nozzle_site)
  File "/home/pi/klipper/klippy/extras/z_calibration.py", line 266, in _probe_on_z_endstop
    self.helper.second_speed)
  File "/home/pi/klipper/klippy/extras/z_calibration.py", line 190, in _probe
    curpos = phoming.probing_move(mcu_endstop, pos, speed)
AttributeError: PrinterHoming instance has no attribute 'probing_move'
Transition to shutdown state: Internal error on command:"BASE_CALIBRATE_Z"

Any idea what may have caused this? My klipper install hasn't been updated since I first set up the printer, do I maybe need to update it?

Docking issue

I could use some ideas what look for on this. The v2.4 was printing fine and all worked. I updated all my file moonraker, klipper and z_calobration. So after that looks like now when tried to dock probe is drops down to far. Did something change I need to look for? https://share.icloud.com/photos/0c63r2jqQNJtYrYf1V1DQnlfg
iCloud.com

Add "Safety Probe check" to Calibrate_Z macro ?

I just had an issue during calibrate_z use and wonder if a probe "safety check" can be added to the macro...

Running the Klicky Probe on a Voron 2.4 w/ Z_Endstop switch and Nozzle Brush and bucket.
I issued a calibrate_z command/macro.

• It attached the probe successfully like normal, then moved to the Z endstop switch position.
• During the move the klicky probe got knocked off by the cleaning brush (did not lift high enough, my fault and fixed).
• It did not "sense" the probe was knocked off and probed the nozzle on the z endstop switch. Which was fine.
• Then tried to probe the switch body on the z endstop switch. Since the probe was knocked off it kept driving down until the nozzle buried itself in the bed.

The attach_probe and dock_probe has the checks built-in. But, if the probe gets knocked off during movement the calibrate_z function does not seem to check between it's steps for this. Is it possible to add a query_probe for an "open" state after movements to make sure it's still attached ?

CALIBRATE_Z - Docking probe before moving to press z-endstop.

This is for a Voron 2.4 with the jlas1/klicky-probe.

I've installed the probe and it's working great for QGL and Bed Mesh, but after installing klipper z calibration, when I run Calibrate_Z, the printhead attaches the probe, docks it, then moves over to the z endstop where the probe fails since there is no probe attached.

I've attached my config files as .txt below.

z_calibration.txt
printer.txt
Klicky_Probe.txt

How to use it

Hi, I don't understand what I'm supposed to be doing here
Should I replace BASE_CALIBRATE_Z with BED_MESH_CALIBRATE?
My code looks like this so far:

[gcode_macro CALIBRATE_Z]
rename_existing: BED_MESH_CALIBRATE
gcode:
    G28
    M117 Z-Calibration..
   # _SET_LOWER_STEPPER_CURRENT  # I lower the stepper current for homing and probing 
    Attach_Probe                # a macro for fetching the probe first
    BED_MESH_CALIBRATE
    Dock_Probe                # and parking it afterwards
    #_RESET_STEPPER_CURRENT      # resetting the stepper current
    M117

ERROR_NO_PROBE error message

The error message is the same for a missing [probe] section and a non attached probe because both use the same constant name.

klipper_z_calibration/z_calibration.py

Lines 8 to 9 in a814376

	ERROR_NO_PROBE = ("A configured probe is needed"
	" for calibrate_z module!")

klipper_z_calibration/z_calibration.py

Line 14 in a814376

ERROR_NO_PROBE = "Probe switch not closed - Probe not attached?"

klipper_z_calibration/z_calibration.py

Lines 83 to 84 in a814376

	if probe is None:
	raise self.printer.config_error(ERROR_NO_PROBE)

klipper_z_calibration/z_calibration.py

Lines 134 to 135 in a814376

	if probe.mcu_probe.query_endstop(time):
	raise self.printer.command_error(ERROR_NO_PROBE)

Attach & Detach Probe Documentation Macro has simple spelling mistake

Love your solution. Simple mistake under documentation for Attach & Detach Probe Macro on your main page.
You have CG28 instead of G28. Hope this helps and many many thanks for your tremendous work.

Hoping the macro should be like the following.

[gcode_macro CALIBRATE_Z]
rename_existing: BASE_CALIBRATE_Z
gcode:
{% set bed_position = params.BED_POSITION|default('None') %}
G28
M117 Z-Calibration..
ATTACH_PROBE # a macro for fetching the probe first
{% if bed_position != 'None' %}
BASE_CALIBRATE_Z BED_POSITION={bed_position}
{% else %}
BASE_CALIBRATE_Z
{% endif %}
DETACH_PROBE # and parking it afterwards (or DOCK_PROBE in klicky macros)
M117

Slow down the last probe action during z calibration

Hi,

I am currently successfully using your awesome plugin in and I am absolutely loving the function.
I have just one issue with the plugin and I can't seem to fix the issue myself.
The plugin has been setup in such a way that it probes the nozzle very slowly on the z switch 10x, the attached dock on the z switch 10x and then it moves to the middle and it probes 2x times at a much higher speed. (It looks like the same speed I use for the bed calibration)
I would like it to slow down and use the settings that are used for the other probes.

Is that something the plugin can do and I have incorrectly configured it or is that not an option?
I have attached my config

z_calibration(6).txt
Please let me know.

Auto Z calibration is not idempotent

Conjecture: All things being equal, running auto-Z calibration multiple times should produce the same result each time. That is, the operation should be idempotent.

The conjecture should hold true within the range of errors associated with the probe being used.

I have had a growing suspicion that performing multiple Z calibrations gives rise to a drift in the Z offset, so that it ends up incorrect, and the more you calibrate the more incorrect it becomes. That is, the operation is not idempotent. Leaving aside why you might want to do multiple Z calibrations, let's just say "it happens sometimes".

I measured a series of 14 calibrations, recording the various measurements after each operation. I performed these tests on my Voron 2.4 after a 40 minute heat-soak. My probe is "Klicky-NG". I homed the Z axis before measurements 1, 4, 7 and 14 only.

Measurements

Endstop	Nozzle	Switch	Probe	Offset	Reset Z
0.377	0.374	7	7.849	0.361167	Y
0.377	0.36	7.438	7.83	0.352833
0.377	0.349	7.424	7.814	0.340333
0.377	0.379	7.469	7.854	0.365333	Y
0.377	0.362	7.459	7.84	0.342833
0.377	0.352	7.451	7.828	0.328667
0.377	0.378	7.476	7.845	0.347	Y
0.377	0.369	7.463	7.833	0.338667
0.377	0.362	7.45	7.824	0.336167
0.377	0.354	7.441	7.82	0.332833
0.377	0.339	7.437	7.814	0.317
0.377	0.329	7.432	7.809	0.307
0.377	0.315	7.427	7.8	0.288667
0.377	0.376	7.487	7.857	0.346167	Y

Graph of Results - Switch and Probe Positions

Conclusions

My findings are that the offset does indeed drift downwards, resulting in the nozzle being too far from the bed. This is most easily seen in the graph. You can see that the measurements slowly drift downward until the Z axis is homed, where they jump back up. This is most noticable in measurements 7-14, where I took a series of 8 samples, homing the Z axis on the first and last sample. The downward trend continues for 7 samples before the large correction at the 8th sample.

Repeated applications of the auto-Z calibration are therefore not idempotent. It is imperative to home the Z axis before each operation in order to obtain correct results. Ideally, this should not be necessary and Z calibration should be idempotent, so this is probably a bug.

Reference Index from Session

Hi,

I'm using a macro to get generate the bed_mesh for the print area in each print session (https://gist.github.com/ChipCE/95fdbd3c2f3a064397f9610f915f7d02), so the point of the the reference index differs each print.

Unfortunately klipper_z_calibration s seems to retrieve the point from the saved config and not from the actual bed_mesh:

Relevant log entries:
bed_mesh: relative_reference_index 1 is (175.66, 142.83)
...
Bed Mesh state has been saved to profile [default]
for the current session. The SAVE_CONFIG command will
update the printer config file and restart the printer.
...
probe at 72.662,5.250 is z=7.275000

Any idea how to fix that?

Why is probing surface necessary for z calibration

Determine the height of the print surface by probing one point with the mag-probe.

Reading this part is not clear as it appears entirely superfluous. Z endstop probe followed by clicky body probe gives offset already. An additional surface probe doesn't add anything, unless it is intended to calibrate the offset of the Z endstop, which shouldn't be used for homing anyway...

CALIBRATE_Z command raised internal error

Hi,

When I executed CALIBRATE_Z, an error was raised as following:

16:12:09  $ CALIBRATE_Z
16:12:09  // Klipper state: Shutdown
16:12:09  !! Internal error on command:"BASE_CALIBRATE_Z"
16:12:09  !! Internal error on command:"CALIBRATE_Z"

And also a pop warning message float argument required, not NoneType.

This is what I found by looking at the traceback in the klippy.log:

Internal error on command:"BASE_CALIBRATE_Z"
Traceback (most recent call last):
  File "/home/pi/klipper/klippy/gcode.py", line 182, in _process_commands
    handler(gcmd)
  File "/home/pi/klipper/klippy/gcode.py", line 120, in <lambda>
    func = lambda params: origfunc(self._get_extended_params(params))
  File "/home/pi/klipper/klippy/gcode.py", line 120, in <lambda>
    func = lambda params: origfunc(self._get_extended_params(params))
  File "/home/pi/klipper/klippy/extras/z_calibration.py", line 140, in cmd_CALIBRATE_Z
    self._log_config()
  File "/home/pi/klipper/klippy/extras/z_calibration.py", line 233, in _log_config
    self.probe_bed_site[0], self.probe_bed_site[1]))
TypeError: float argument required, not NoneType
Transition to shutdown state: Internal error on command:"BASE_CALIBRATE_Z"

I commented out both probe_bed_x & probe_bed_y in z_calibration.cfg, but did have relative_reference_index configured in bed_mesh section in printer.cfg.

Is there anything else I might have missed?

Thanks for the help in advance.

Kaiyuan

Probe hits bed if retraction is smaller than new (negativ) offset

Hello

Example: Retract 0.2
After Probing on the bed the head move to the new offset.
If the Offset is bigger than the retract (i.e. -0.3) the probe will hit the bed and if the next move will
detect the probe as docked (as the probe triggered)

One way would be to increase the retract to a value which is save.
But best way the script should check and not move the head lower then the retract after probe

Thanks for considering

Self updating script

No idea if you want to implement this but i added this to my moonraker.conf to add tracking of new versions of this lib

[update_manager client z-calibrate]
type: git_repo
origin: https://github.com/protoloft/klipper_z_calibration.git
primary_branch: main
path: /home/pi/klipper_z_calibration

then ssh'd in and did
ln -s /home/pi/klipper_z_calibration/z_calibration.py /home/pi/klipper/klippy/extras/z_calibration.py

the only thing its lacking is a script to bounce the klipper service when it updates.

thought i'd share

Explain and/or rename the variable max_deviation

At first I assumed that deviation was referring the standard deviation, i.e. variability of measurements. Something akin to the "Probe samples exceed tolerance" that one always find in Klipper logs.

But after getting errors on that, it's as if max_deviation refers to the maximum offset. Is that correct? Shouldn't it be named something as max_offset?

(Initially I had a complete misunderstanding of the meaning of OFFSET too, because I thought it was related to difference between nozzle height and probe height. After a while I assume that that is not the case and it is related to difference between Z=0 prior to CALIBRATE_Z and after the procedure. My high offset came from doing CALIBRATE_Z after a QUAD_GANTRY_LEVEL without homing Z in-between. So really I have only myself to blame and RTFM for myself too! After I cleared my issues with OFFSET, I still have my doubts on max_deviation semantics and meaning).

Alternative way

Wanted to show an alternative way to do this with off the shelf hardware and only gcode commands.
I made the Knobprobe for probing Z offset between nozzle and Z-Probe.

https://youtu.be/fshmEMWxBHY

How should I go about converting this code base to probe the nozzle height like cnc routers do?

Hi, I have bed slingers so I can't really use this plugin without much pain or losing print volume.

But I seldom change nozzles or print sheet so it would not be a huge hassle to calibrate z height the way they do with cnc.

I would need to home z with the probe in toolhead but I can't figure out how to read external z height probe.

Can I read the switch value in python or gcode?
I was thinking the procedure would go something like this

1. home axises
2. go to predetermined location, lift nozzle like 50mm
3. wait for user to move external probe to position
4. move nozzle until height probe triggered. Nozzle would be exactly 20mm away from build plate once probe is triggered.
5. Now that I know where nozzle is relational to build bed, I could set z offset accordingly from there.

Or could I use probe_calibrate to set the height?

1. Start from 50.2mm nozzle offset
2. When hit nozzle probe, set z offset (current height (30.xx mm) - probe height (20mm))

suggest adding a note about GCODE_RESTORE_STATE

It appears that if a person has a print_start that saves the gcode state (SAVE_GCODE_STATE name=whatever), does a CALIBRATE_Z, and then follows the CALIBRATE_Z with a restoration of gcode state (RESTORE_GCODE_STATE name=whatever), that the offsets set by CALIBRATE_Z are lost.

I'd suggest adding a note in the documentation that calls to CALIBRATE_Z should be done outside of SAVE/RESTORE gcode state.

Auto-calibration issue with probe position in Z not being calculated properly

I have a weird issue with auto-z-calibration... shouldn't the actual probe height from the bed be considered every time the offset is calculated? I had to move the probe up on my printer and the whole first layer was messed up. Once the actual switch Z offset (in my case 0.44mm) is set into the configuration and the whole calibration works hitting the Z endstop with the nozzle, then the probe body etc., the script should just do the math, right? At least that is how it is working on my Voron. On my other printer, though, the (Quickdraw) probe is connected to the fan shroud, so when I adjusted the vertical position of the shroud, I realised that after a Z calibration the offset was wrong by the distance I moved the shroud/probe position by. I dit another test and I swapped the nozzle. The tip of the new nozzle was slightly lower than the old (luckily only 0.3mm or so). Again, after a calibration, the first layer was too low by the same amount.

Nozzle change alters docking height

This is more of a question than an issue. The euclid probe docking height relies on the Z-endstop offset from the nozzle being probed. If I switch nozzles and the nozzle has a different length, this will mess up the docking height (the Z position the probe gets slid into the dock) Is there a way to temporarily home off of the switch body (which would always be the same) and use that offset for the docking then once stowed, home again off the nozzle?

Reorder probe sequence to reduce ooze

Heating the nozzle at print temperature for extended period of time leads to unpredictable amount of ooze. The ooze can sometimes interfere with various probing operations. One way to reliably reduce ooze is to only heat the nozzle to slightly below the ooze temperature (let's call it warm nozzle) during most probing operations and do a final z-endstop touch at printing temperature.

With the current sequence of probing nozzle -> switch body -> bed, the nozzle has to be at printing temperature throughout the entire calibration process, and may ooze during bed calibration.

How about reordering the calibration:

• Initial homing, QGL / tilt adjust, re-home z (warm nozzle)
• Probe switch body (warm nozzle)
• Probe bed (warm nozzle)
• Dock probe
• Heat up nozzle
• Nozzle cleaning can be done here
• Probe nozzle
• Print

It may be necessary to do a final Z homing with the hot nozzle right before printing.

Understandig problems aka brain goes afk

I have a question and hope it's not stupid, the nozzle and the probe (wich is a endstop if I'm right) are fixed, the probe needs to be lower than the nozzle then. That means that the probe is constantly scratching over the print bed and printed parts (if not using z lift)

Where is the point where my mind goes lost there?

BTW I have a ratrig v-core3 with a bltouch and from time to time my z offset gets wrong without changing anything and now I am searching for a solution to automate this process as u did. I hope someone can answere my questions :)

For Load Cell/Nozzle probes, How to adjust for the probe's Z offset?

I am attempting to use this plugin with a machine that has a load-cell on the nozzle, using the nozzle itself as the probe for perfect 0.0 offsets. As well as a dedicated Optical Z endstop. This is similar, but different than #28.

The problem I'm having is that the load cell has a flex that equates to 0.2mm at the nozzle. This is a measurement that cannot be "measured" automatically via this script as this script attempts to use the klicky probe body to find the offset from the switch to the switches body.

Unfortunately, with a load cell there is no "switch body" to measure again - the nozzle itself is 0.0mm. However, with the load cell's flex, the nozzle is -0.2mm from the trigger.

I previously had probe -> z_offset -> -0.2 and this worked fine before this script was added.

Now, I am unable to set any firm offset what-so-ever, in switch_offset nor z_offset. Also, SET_GCODE_OFFSET Z_ADJUST=x doesn't seem to be working even setting it after a CALIBRATE_Z.

---

Ps, any way to remove the Nozzle and Switch probing? Those are always directly equal to my Z endstop, because there is nothing to probe on a load_cell setup: just touch the nozzle, and that's 0.0 immediately. For example, I get a lot of probing of the same Z:

$ calibrate_z
// my Z endstop is located at Z=8.775000
// hence all 10 are exactly the same.
// probe at 117.500,117.500 is z=8.775000
// probe at 117.500,117.500 is z=8.775000
// probe at 117.500,117.500 is z=8.775000
// probe at 117.500,117.500 is z=8.775000
// probe at 117.500,117.500 is z=8.775000
// probe at 117.500,117.500 is z=8.775000
// probe at 117.500,117.500 is z=8.775000
// probe at 117.500,117.500 is z=8.775000
// probe at 117.500,117.500 is z=8.775000
// probe at 117.500,117.500 is z=8.775000
// probe at 117.500,117.500 is z=-0.005000 // 5-samples nozzle probe starts here
// probe at 117.500,117.500 is z=-0.027500
// probe at 117.500,117.500 is z=-0.027500
// probe at 117.500,117.500 is z=-0.022500
// probe at 117.500,117.500 is z=-0.010000
// Z-CALIBRATION: ENDSTOP=8.775 NOZZLE=8.775 SWITCH=8.775 PROBE=-0.022 --> OFFSET=-0.032500

^- I might have been experimenting with switch_offset in the above, with everything else set to 0 for offsets. Which is odd as well, because the switch_offset only seemed to change this OFFSET reading above. G1 Z0 was always exactly the same, regardless of switch_offset.

Configuration is too complex

I was hoping this plugin would solve Z offset once and for all for my Voron Trident. I installed it but then I started to configure it and there a tons of parameters (around 17 values) that need to be set. I think this is a good project but it needs more work. It could extract the z_safe_home values for the position of the nozzle. It could use the Afterburner or Stealthburner distance between nozzle and probe as a default or as comments in the cfg. Perhaps, parse the bed mesh to determine the reference index. There must be ways of cutting down the sheer number of these parameters.

probe_nozzle_x:199.0
probe_nozzle_y:348.0
#   The X and Y coordinates (in mm) for clicking the nozzle on the
#   Z endstop.
probe_switch_x:199.0
probe_switch_y:325.0
#   The X and Y coordinates (in mm) for clicking the probe's switch
#   on the Z endstop.
probe_bed_x: default from relative_reference_index of bed_mesh
probe_bed_y: default from relative_reference_index of bed_mesh
#   The X and Y coordinates (in mm) for probing on the print surface
#   (e.g. the center point) These coordinates will be adapted by the
#   probe's X and Y offsets. The default is the relative_reference_index
#   of the configured bed_mesh. It will raise an error if there is no
#   probe_bed site and no bed_mesh with a relative_reference_index
#   configured.
switch_offset:
#   The trigger point offset of the used mag-probe switch.
#   This needs to be fined out manually. More on this later
#   in this section..
max_deviation: 1.0
#   The maximum allowed deviation of the calculated offset.
#   If the offset exceeds this value, it will stop!
#   The default is 1.0 mm.
samples: default from "probe:samples" section
#   The number of times to probe each point. The probed z-values
#   will be averaged. The default is from the probe's configuration.
samples_tolerance: default from "probe:samples_tolerance" section
#   The maximum Z distance (in mm) that a sample may differ from other
#   samples. The default is from the probe's configuration.
samples_tolerance_retries: default from "probe:samples_tolerance_retries" section
#   The number of times to retry if a sample is found that exceeds
#   samples_tolerance. The default is from the probe's configuration.
samples_result: default from "probe:samples_result" section
#   The calculation method when sampling more than once - either
#   "median" or "average". The default is from the probe's configuration.
clearance: 2 * z_offset from the "probe:z_offset" section
#   The distance in mm to move up before moving to the next
#   position. The default is two times the z_offset from the probe's
#   configuration.
position_min: default from "stepper_z:position_min" section.
#   Minimum valid distance (in mm) used for probing move. The
#   default is from the Z rail configuration.
speed: 50
#   The moving speed in X and Y. The default is 50 mm/s.
lift_speed: default from "probe:lift_speed" section
#   Speed (in mm/s) of the Z axis when lifting the probe between
#   samples and clearance moves. The default is from the probe's
#   configuration.
probing_speed: default from "stepper_z:homing_speed" section.
#   The fast probing speed (in mm/s) used, when probing_first_fast
#   is activated. The default is from the Z rail configuration.
probing_second_speed: default from "stepper_z:second_homing_speed" section.
#   The slower speed (in mm/s) for probing the recorded samples.
#   The default is second_homing_speed of the Z rail configuration.
probing_retract_dist: default from "stepper_z:homing_retract_dist" section.
#   Distance to backoff (in mm) before probing the next sample.
#   The default is homing_retract_dist from the Z rail configuration.```