Closed alexbarcelo closed 1 year ago
Hey, just thought I'd chime in as someone who also struggled with the meaning of some of the terms/auto z calibration process in general and only relatively recently finally got it all squared in my brain.
The OFFSET value is just the same as the one that you would find if you were manually calibrating z. I don't know your current level of experience with all this, so just to elaborate on that,its the value you would find by doing first layer prints that you would then apply to your z endstop value after finding your preferred setting. It's essentially how far off your current z endstop value is from where it should be for an ideal first layer. When you're manually handling all this, everytime you make a change to your flex plate, nozzle, etc, you would then find the new offset value and apply it to your z endstop value.
For max_deviation
, max_offset
as you mentioned is a good alternative I think. Its value is the largest difference between that OFFSET value and your set z endstop value that you're willing to tolerate. So, for example if your max deviation was set to the default of 1.0, for the found offset to exceed that means auto z found the distance between where your nozzle triggered your z endstop and where your nozzle would come in contact with your build surface to be more than 1mm off from where it's currently set to. The main use of this value, as far as I'm aware, is to really just to avoid any obviously wrong auto z readings. The majority of the time, when you're doing things like changing out the flex plate, changing to a different nozzle, or even just differences due to temperature, the difference will very rarely exceed 1mm which is why that's the default I'm guessing.
What I did when first setting this up was to hone in on the ideal switch offset value by running first layer prints, and then running Calibrate_Z 10 or so times, choosing the median offset value, and applying that to my current z endstop value in order to have a good baseline.
Also, for your high offset value, the Calibrate_Z also homes Z so not homing z manually after your QUAD_GANTRY_LEVEL shouldn't have any impact on your offset. Not sure what happened there, could have just been an anomaly. I've found that the most common reason for the offset to exceed the max deviation is debris on the nozzle.
Anyway, hopefully this explanation was helfpul.
Yes, thanks for confirming my suspicions. I agree / I understand 99% of what you just said.
Let me nitpick / discuss on the 1%, sorry:
Also, for your high offset value, the Calibrate_Z also homes Z
Are you sure? I believe it does not. The macro probes the nozzle on the endstop, but that does not effectively home Z (right?). Did I miss something?
No worries, I don't blame you for being cautious. But yeah, the initial nozzle probe on the z endstop during calibrate_z is serving the same purpose as homing z. I came across a post by the creator at some point confirming as much that I tried to track down but no luck unfortunately. To provide some evidence though, there's the sample print start sequence in the readme:
Home all axes Heat up the bed and nozzle (and chamber) Get probe, make QGL or Z-Tilt, park probe Purge and clean the nozzle if available (Get probe), CALIBRATE_Z, (park probe) (Adjust Z offset if needed) Print intro line Start printing...
Anyways, if you're still concerned, while there's no need to run a second home z prior to running calibrate_z, it wouldn't cause any issues either as it just gets replaced by the value found during calibrate_z, so there's no problem doing that if it puts your mind at ease.
Well, I tried to replicate my issue and was successful (which makes me thing I'm right):
And, effectively, the behaviour I described happened:
Offset is larger as allowed: OFFSET=-2.194 MAX_DEVIATION=1.000
And the macro aborts.
If I Home Z after this and then proceed to CALIBRATE_Z, then everything works as expected:
Z-CALIBRATION: ENDSTOP=-1.049 NOZZLE=-1.044 SWITCH=4.311 PROBE=5.826 --> OFFSET=-0.029000
AFAIU, Z_CALIBRATION does not change/affect the Z home, only the gcode z offset, as seen by querying the GET_POSITION:
mcu: stepper_x:-15970 stepper_y:-15976 stepper_z:-42183 stepper_z1:-38961 stepper_z2:-39231 stepper_z3:-41878
stepper: stepper_x:260.000000 stepper_y:-180.000000 stepper_z:25.001000 stepper_z1:25.001000 stepper_z2:25.001000 stepper_z3:25.001000
kinematic: X:40.000000 Y:220.000000 Z:25.001000
toolhead: X:40.000000 Y:220.000000 Z:25.000000 E:0.000000
gcode: X:40.000000 Y:220.000000 Z:25.000000 E:0.000000
gcode base: X:0.000000 Y:0.000000 Z:-0.029000 E:0.000000
gcode homing: X:0.000000 Y:0.000000 Z:-0.029000
Note how gcode base Z matches the offset calculated by the CALIBRATE_Z macro.
The max_deviation was a wish from the community to be some kind of safe if something went wrong with the calibration. So, with 1mm you would destroy your PEI but hopefully not your entire gantry.
So, your first situation would work out perfectly as well. It just detects a higher offset and compensate it. Even with the higher offset, your print would be as fine as always. But, to prevent these cases, a second homing can be done before the calibration (and with a hot and cleaned nozzle - cold ooze with the first homing would be the main reason for a high offset). Some people say, that it is still good practice to home again after QGL/Z-Tilt. I think that this is not necessary - but could lead to a higher offset too. And a second homing is not harmful and can help in some situations if the dock is attached to the bed.
Back to the main question.. should I rename this property? I'm not sure.. I mean, it is the max offset it would take. But, the calculated offset of the calibration is again the current deviation of the original configured Z offset. Is deviation here not the correct word for this (max) difference, drift, error or whatever? :thinking:
More opinions on that?
I'm not sure that my issue releated to this or not. BTW. I facing issue after CALIBRATE_Z result in Offset is larger as allowed: OFFSET=-2.604 MAX_DEVIATION=1.000 and it consistently show this message every time CALIBRATE_Z executed. What Have I doing it wrong. I can do QGL with klicky proble and manual Z offset with Z_ENDSTOP_CALIBRATE and TESTZ. I think I'd install this plugin and forget about Z_ENDSTOP_CALIBRATE but I still get no luck using this plugin. Addition Info. After Z_ENDSTOP_CALIBRATE and TESTZ. I got response stepper_z: position_endstop: -2.950 The SAVE_CONFIG command will update the printer config file with the above and restart the printer. which mean the offset probably reported correct but not allow in the config somewhere. question: is it possible for offset that high and do I have something misconfigure either the printer it self or printer config.
@chaisaeng There is nothing wrong! You can increase the max_deviation property and go. But, it would be better/safer to adjust your endstop position to reduce the determined offset. So, yes.. a very quick manual Z endstop calibration would be good. Then, the auto calibration detects only the current offset needed for a accurate first layer at this moment...
Now, this property is deprecated and replaced by the offset_margins property which can also take a min and max value. Hope this is much better :+1:
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 asmax_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).