New probe_eddy_current "tap" logic

[KevinOConnor]

This changes the recent ldc1612 eddy current "tap" support to determine the bed/nozzle contact point by analyzing the post-contact lift movement (previously the code determined the point of contact by analyzing the descent).

There are some advantages to calculating the probe position by analyzing the lift movement:

• When the nozzle makes contact on the descent it can often induce an oscillation in the bed and/or toolhead. Similarly, an oscillation can also be induced when the Z motor are commanded to abruptly stop. These oscillations make it difficult to obtain reliable Z sensor measurements immediately following the bed/nozzle contact. This limits the amount of reliable data that can be used to determine a precise contact point. In particular, any measurement noise in the last measurement just prior to contact can have a notable impact on the final calculated contact position.
• In contrast, the lifting movement is less likely to have these types of oscillations which allows more data to be used. In particular, we can utilize measurements from both before and after the contact point.
• The code on this PR is less dependent on individual ldc1612 measurements and therefore less susceptible to sensor noise. The code is also capable of reliably calculating contact positions in between sensor measurements. That is, even if the sensor is only taking a measurement after every 20um of movement, the code on this PR can still reliably produce contact positions in the ~1um range.

The code on this PR implements a kind of "least squares" search of the measurement data to find the point of contact. Specifically, putting noise aside, the sensor readings around the point of contact are expected to follow:

• At the point of contact (z=contact_z): sensor_frequency(z) = k0
• At positions below the point of contact (z<=contact_z): sensor_frequency(z) = k0 + k1*(z - contact_z)
• At positions above the point of contact (z>=contact_z): sensor_frequency(z) = k0 + k2*(z - contact_z) + k3*(z - contact_z)*(z - contact_z)

Given the above formulas the code tries to find solutions for contact_z, k0, k1, k2, and k3 such that it minimizes the squares of the deviation from the actual sensor frequency measurements (ie, a "least squares solution").

This may best be seen with a picture:

In this example, the line shown was the "best fit" for the measurement data. (Note how the final "contact point" of z=1.054421 is actually between two measurements.)

Initial tests are indicating that this method of analyzing the tap position can produce more repeatable and more precise results. However, there are some known caveats:

• The analysis may have some dependency on how far the bed is depressed during the descent movement. If measurement noise or communications delays causes slightly earlier or slightly later toolhead halting, then there might be more jitter in the estimated contact position.
• The analysis code is sensitive to the "SAMPLE_RETRACT_DIST" and "LIFT_SPEED" settings.
• The host code to analyze the results does consume more host cpu. It's unclear if that could cause scheduling jitter on low-end host cpus.

This PR also includes some additional changes that were needed as prerequisites:

• Due to the change in analysis, the new code consistently finds contact points that are lower than the previous "tap" code. Users will likely need to recalibrate after this change. To facilitate this in the future, a new tap_z_offset config parameter has been provided. This is similar to the z_offset parameter found on other types of probes. It allows the user to specify a nominal Z offset between what the tap code provides and the actual desired Z value during prints. Even though the contact point would nominally occur at exactly Z=0, there can be cases where backlash, thermal expansion, and similar may make an offset desirable.
• The existing [probe_eddy_current] z_offset parameter has been renamed to descend_z. This is to avoid confusion with the z_offset found in other common probe configs and to avoid confusion with the new tap_z_offset.
• When utilizing "METHOD=tap" probing, the printer.cfg probe speed, lift_speed, etc. config options are no longer utilized. If a user wishes to change any of these settings from their defaults then they will need to provide the new values on the probe command-line (eg, PROBE_SPEED=9, LIFT_SPEED=3.0, etc.). This was implemented because the new code is sensitive to these types of probe settings and the defaults used for regular probing attempts would not be meaningful for "tap" probes.

-Kevin

Note, I also have a development branch at https://github.com/KevinOConnor/klipper-dev/tree/work-tap-20260224 . It has some debugging code. In particular it contains the scripts/tap_graph.py script that was used to generate the graph above.

[nefelim4ag]

JFYI: This does not make sense after adding the new interface, because they only make sense as the tap params, which now only apply from gcmd