Load Cell Probe Calibration Tools

[garethky]

These are the 3 calibration tools that are mostly finished. This gives users a method for finding values for some of the trivky but essential settings for the load cell probe:

• CALIBRATION=DRIFT_FILTER - this calibrates the drift filter frequency setting used to eliminate load cell force drift caused by bowden tubes. It does this by tapping into the machnies bed mesh configuration. It visits each mesh point and moves the toolhead from the top of the machines build volume down to 10mm above the build plate. The force data is collected and the minimum filter frequency needed to eliminate the observed drift is calculated. This measurement is repeated for every mesh point and the peak value is reported as the optimal drift filter value.

• CALIBRATION=PULLBACK_DISTANCE - The pullback distance is the distance that the toolhead lifts when performing Tap Analysis. This distance needs to be tuned based on the observed machine characteristics. Less stiff machines, and machines with slower sensors have more overshoot at the maximum probing speed. Using too large of a value is slow, so we want to minimize this value while allowing probes with the highest amount of overshoot to succeed. This calibration performs a bed mesh with a very large pullback_distance value at the maximum configured probing or homing speed. It looks at the position of the elbow in all of the pullback moves and tries to optimize such that there is enough pullback distance in the worst case.

• CALIBRATION=DECOMPRESSION_ANGLE - This performs a standard bed mesh pattern at the standard probing speed and calculates the average of the decompression angle value. This setting is required to enable Tap Quality checking.

Checklist

• pr title makes sense
• added a test case if possible
• if new feature, added to the readme
• ci is happy and green

[EllaFoxo]

These tools are great. Noticed during the pullback distance calibration, the reading for force is in standard form/notation. Probably ought to output a decimal.

Decompression distance: 0.0359mm, force: 2e+02g

[garethky]

One critique that I can think of is CALIBRATION=DRIFT_FILTER may not require the Z axis to move at all. The Z axis moving is only useful if its going to impact the drift filter by somehow imparting a force on the load cell.

Where it matters:

• Gantry machines like the Voron 2.4 with a toolhead load cell
• Moving bed machines where the load cells are under the bed

Where it doesn't matter:

• Machines with a static bed with load cells under the bed (e.g. Voron 2.4)
• Machines with a toolhead that doesn't move in Z (e.g. Voron Trident)

In the case where it doesn't matter we still want to capture some data as the movement of the toolhead is going to cause forces on the bowden tube that show up as drift that needs canceling. In that case we would need to capture some amount of data (2 seconds?). But this would be a MUCH faster calibration run on those machines.

I don't know of a way to decide which case is which from the printer config. But I could provide an argument to the command to disable Z motion.

[rogerlz]

Reviewed this one. The CI failure is just a broken docs anchor, Load_Cell.md#tap-quality-calibration does not exist. But I found some real issues too:

• DriftFilterCalibration reads [printer] max_z_velocity and [stepper_z] at config time. That breaks startup for deltas and for configs without max_z_velocity. Better to resolve those at calibrate() time.
• The two gcmd.error(...) calls are built but never raised, so an unknown CALIBRATION value silently does nothing.
• TapQualityClassifier leaves _calibrating=True if probing fails, and min([]) crashes when no taps are valid.
• MAXIMUM_Z_POSITION is parsed but the moves use the config value, and the docs say MAX_ACCEPTABLE_SLOPE while the code reads MAX_DRIFT_RATE.
• The :.3 format specs print scientific notation, as Ella pointed out in May.

I can push fixes for these to your branch if that helps. Let me know.

[garethky]

Well spotted!

I'm going to push a fix for most of that and then look at the first issue:

• DriftFilterCalibration reads [printer] max_z_velocity and [stepper_z] at config time. That breaks startup for deltas and for configs without max_z_velocity. Better to resolve those at calibrate() time.

How do you propose we solve that?

I've never run a delta on klipper so I'm not familiar with the start up sequence.

If there is no [printer] max_z_velocity what should we use? Really we want to know: whats the fastest probing or homing move you are going to run. Quite often the homing move speed is higher than the probe speed, so the probe speed probably isn't it.