extras: Add automatic z calibration extension

[TitusLabs]

With this pull request, I want to integrate my automatic z calibration into Klipper which is already widely used.
More on this can be found here: https://github.com/protoloft/klipper_z_calibration

[Tircown]

I guess it's ATTACH_PROBE there.

[TitusLabs]

Yes, changed it!

[Tircown]

typo: LIFT_SPEED

[TitusLabs]

Yes, changed it!

[Tircown]

I guess it's ATTACH_PROBE there too.

[TitusLabs]

Yes, changed it!

[KevinOConnor]

Interesting. Thanks.

Due to timing, however, this does not look like it will be something we can merge prior to the v0.10.0 release of Klipper ( https://klipper.discourse.group/t/upcoming-v0-10-0-release/791 ). Realistically, this means an October/November timeframe for this change.

At a high-level, is this module specific to Voron users that have the z endstop pin and have a "klicky" probe?

-Kevin

[zellneralex]

@KevinOConnor any printer running an z endstop (that is probed with the nozzle) and a mechanical probe can run it. I know Voron and Annex printers running it

[wlhlm]

Typo: ommit -> omit.

[TitusLabs]

I changed it, thanks!

[wlhlm]

Since nozzle_xy_position duplicates the homing position of the Z endstop, I can see a potential issue where the Z endstop position changes and the operator updates the position for homing, but forgets to also update the z_calibration configuration. At least when safe_z_home is defined, would it make sense to use home_xy_position in case nozzle_xy_position is undefined? In addition, switch_xy_position could be changed to be relative to nozzle_xy_position. What do you think?

[zellneralex]

@wlhlm the problem with using home_xy_position that than the order of the blocks is important, so that is not a good idea. I would like a relative definition but I fear many people will have problems to define a relative X,Y definition and you need both

[wlhlm]

@wlhlm the problem with using home_xy_position that than the order of the blocks is important, so that is not a good idea

Ahh, I see how that could be confusing. Then that would speak for a mechanism to allow using variables for regular config options other than gcode blocks

[Frix-x]

I see the discussion you are having here on the Z endstop position and I crashed my machine today because of that. The funny thing is that I already faced the same issue a couple of weeks ago but with the probing point on the bed : protoloft/klipper_z_calibration#20

The issue here could be easily generalized to allow setting almost all the value of the z calibration plugin at the runtime as arguments to the CALIBRATE_Z command.
This would not solve the problem perfectly but would at least allow to use a variable from a macro as a single input value for the [homing_overide] section and for CALIBRATE_Z call.

[KevinOConnor]

Thanks. I'm not sure what the state of this PR is.

FWIW, I don't really understand what this module does. I get the impression this is a tool for Voron printers to align the calibration between the "nozzle mouse switch probe" and the "toolhead z probe". I suspect a reviewer ( https://www.klipper3d.org/Contact.html ) will need to volunteer to review this PR.

FYI, a good place to discuss this PR, get testers, and engage a reviewer is on the Klipper Discourse server ( https://www.klipper3d.org/Contact.html ).

-Kevin

[zellneralex]

Hello Kevin, this is already heavily tested at least at Voron printers. Currently for testing it is linked as an extra module via https://github.com/protoloft/klipper_z_calibration.

Best regards Alex

[TitusLabs]

This PR is derived from my Klipper extension at https://github.com/protoloft/klipper_z_calibration (as zellneralex already said).
It uses two mechanical switches at the print head and next to the print bed to get the relative positions of the nozzle and the probe. With these values, the actual z-offset between the nozzle and the probe is determined automatically and set by GCODE_OFFSET. I run this setup since May 2021 in a daily basis without any issues - and, I have not tuned any z-offset since then manually!

So, any printer having this setup with a magnetic switch probe and a second switch as z-endstop, which is probed by the nozzle, will work (however, not all kinematics are supported so far).

Most of the code is for probing on these two switches and getting the standard parameters for doing this. Additionally, the probed positions need to be configured. And GCode hooks can be configured to attach/detach the probe in different stages. The calculation in the end is trivial. I tried to be compatible to this #4328 for such micro-switch-probes from @mental405

I can only speak for the Voron community, but it is already heavily used there. Currently, my github repo has 236 stars and on the Voron Discord the search for klipper_z_calibraton returns 446 result (and these are only the github links).

[github-actions]

Unfortunately a reviewer has not assigned themselves to this GitHub Pull Request and it is therefore being closed. It is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards,
~ Your friendly GitIssueBot

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

[zellneralex]

@KevinOConnor that is highly used at least in the Voron community and affects much more than 100 printers ...

The feature is tested insight the community more than 6 month now, that tests started well before the PR was done (and also your changes to the rules by modifying your Contribution guidelines) . See https://github.com/protoloft/klipper_z_calibration

It would be highly appreciated if some one of the reviewer team would volunteer and review it.