protoloft / klipper_z_calibration Goto Github PK
View Code? Open in Web Editor NEWKlipper plugin for self-calibrating z-offset
License: GNU General Public License v3.0
Klipper plugin for self-calibrating z-offset
License: GNU General Public License v3.0
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
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
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.
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 |
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.
An error occurs when used with multi mcu homing branch.
pi@mainsailos:~/klipper $ git branch -a
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
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?
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 :)
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.
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 ?
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.
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.
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.```
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
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
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).
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:
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
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?
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
Or could I use probe_calibrate to set the height?
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.
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
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?
Section 'z_calibration' is not a valid config section
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
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?
Hi,
what do I need to adjust in order for kzc to print a little further from the bed?
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.
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
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?
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?
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...
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?
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.
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
klipper_z_calibration/z_calibration.py
Line 14 in a814376
klipper_z_calibration/z_calibration.py
Lines 83 to 84 in a814376
klipper_z_calibration/z_calibration.py
Lines 134 to 135 in a814376
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.
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?
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
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]
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!
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.
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 :)
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
.
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
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?
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)
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
Will add more items as i find them :p
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 :)
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:
It may be necessary to do a final Z homing with the hot nozzle right before printing.
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
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.