Introduce `PIN_PROBE` for Enhanced Multi-Probe Compatibility

[menelike]

Overview:

This PR introduces the PIN_PROBE, a new feature modeled after the existing PROBE functionality. The primary motivation is to support advanced calibration techniques by integrating tools like the klicky probe with the klipper_z_calibration and the eddy probe.

Rationale:

The eddy probe excels in fast and precise BED_MESH_CALIBRATE but falls short in homing precision and z_offset determination at critical points, such as the bed center, compared to the klicky probe. This discrepancy becomes significant on different PEI sheet coatings which affect scanning results. Furthermore, the eddy probe requires recalibration following nozzle changes and involves a cumbersome thermal drift compensation process.

This PR aims to leverage the klicky probe's high accuracy for critical measurements and the eddy probe's rapid scanning capabilities, thus offering an optimal calibration experience.

Technical Implementation:

Currently, this PR serves as a proof of concept (POC) and lacks documentation and tests. The implementation borrows heavily (e.g. copy/paste and therefore repetitive code) from probe.py, with modifications primarily in command registration and naming conventions, e.g., QUERY_PIN_PROBE PROBE=klicky.

Proposed Changes for Discussion:

1. Refactoring Shared Logic: Integrate probe_name as a parameter in relevant classes within probe.py to address the current limitation of configuring only one probe.

2. Command Registration: Replace register_command with register_mux_command in probe.py. For backward compatibility, a default parameter could mimic the behavior of the existing QUERY_PROBE command.

3. Enhancing Multi-Probe Support: We should consider architectural changes to make Klipper compatible with multiple probes simultaneously, which presents a challenge given the current design where the probe instance is singular and fixed.

Link to Counterpart Implementation: Counterpart on klipper_z_calibration

Conclusion:

This dual-probe approach promises to significantly enhance the calibration precision (makes thermal drift compensation obsolete) and operational flexibility of Klipper setups.

@KevinOConnor I'd love to get some guidance here, as this is the first time touching the code and surely I've missed a lot of details.

[JamesH1978]

Thank you for submitting a PR, please provide a signed off by line as outlined in https://github.com/Klipper3d/klipper/blob/master/docs/CONTRIBUTING.md

Thanks James

[menelike]

@JamesH1978 Thanks for the hint, I completely missed that, sorry. I updated the commit msg accordingly, hope it fits now.

[kitchung]

I'm looking forward to this capability!

[github-actions[bot]]

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then 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.

[TNTBA]

This would be amazing. Please implement this.

[BilkoNr1]

I also ask that they implement this!

[ItsReckliss]

I've unsuccessfully trying at this for a little while (new programmer) for the literal purpose of using a probe with eddy for better z homing. Thank you for finally implementing it. Would it be possible to also implement the use of eddy with a bltouch rather than a klicky?

[alewir]

Hello. Recently I've just stuck on that literal purpose of using a klicky probe homing with eddy coil rapid mesh scan and z offset autocalibration with sexbolt z endstop. I've just realized that it's not implemented yet and I'd really appreciate if anyone was able to add a support for it in Klipper.

Having something like a switchable pin_probe was also the first thing I actually thought about after hitting a wall with configuring the above - from what I can see there is not so much code there added within this PR. If there is anyone competent then please take a look at these changes...

[Haxiboy]

Please implement this, Eddy is perfect for meshing, but not for homing.

[zingo]

While waiting you can check out eddy-ng It's a replacement driver for the eddy with pin probe behavior, e.g. trying to touch the bed and check the height but as clever as possible.

[sl0m0ZA]

Please merge this as it is a very needed feature

[Shaische]

It would be awesome if this can be implemented as it can be used on pick and place machines that utilize Klipper so that each nozzle can act as an individual probe.