Add Z-offset for load cell probe

[jaimbo]

Add factory-calibrated Z-offset for load cell probe

Description

This PR adds a default z_offset: -0.15 to the [load_cell_probe] of the included config. This value replicates the behaviour of the stock Elegoo firmware.

https://github.com/OpenCentauri/cc-firmware/blob/33e562eb1e973db5a4863037859351b48e4a8a2f/core/klippy/printer_para.cpp#L1912
https://github.com/OpenCentauri/cc-firmware/blob/33e562eb1e973db5a4863037859351b48e4a8a2f/core/klippy/extras/strain_gauge.cpp#L43
https://github.com/OpenCentauri/cc-firmware/blob/33e562eb1e973db5a4863037859351b48e4a8a2f/resources/e100/configs/unmodifiable.cfg#L4
https://github.com/OpenCentauri/cc-firmware/blob/33e562eb1e973db5a4863037859351b48e4a8a2f/core/klippy/extras/bed_mesh.cpp#L325

Why this change is needed

Because this printer uses the nozzle itself as the probe via the underbed strain gauges, the nozzle must physically press into the build plate to generate enough force to register a trigger. This creates a mechanical discrepancy where the true, un-flexed surface of the bed is actually higher than the coordinate at which Klipper registers the probe trigger.

This -0.15mm offset accounts for:

1. The physical deflection/flex of the bed and hotend required to reach the trigger threshold.
2. Probably some reaction time and processing delay of the HX711s and bed MCU

By applying this -0.15 offset natively in the standard Klipper config, users should need a far smaller gcode offset and should be less likely to damage their build plates.

This change is going to require any existing bed meshes to be re-done as they are going to bring the nozzle .15mm closer to the bed than intended.

Ideally this change would also be complimented by a mechanism to safely save a gcode offset in a way that remains visible to users in mainsail or fluidd between restarts. I think a safe, slightly high, default wouldn't go amiss here either!

[jamesturton]

I don't really know enough about klipper to give a good review here but my understanding was that this value should be used it there was an offset in the homing method? As we are homing the toolhead directly on the bed I would always think the offset should be zero for the cc (unlike if there was an offset between the toolhead and an external probe like bltouch for example). I didn't really understand the argument that's because elegeoo did this it's the right thing to do - it's obvious they did things that were fundamentally wrong....

The bed meshing driver which previously used a Kalman filter should account for any delay in sampling as it should look at the rate of change of force in the load cells and then back calculate the initial point of contact with the bed. I'm not sure how the implementation with the new SOS filter works

[jaimbo]

My understanding is that

[load_cell_probe]
z_offset: -0.15

Should represent the distance between the probe (in our case, the nozzle tip touching the bed surface). Per the Klipper docs https://www.klipper3d.org/Config_Reference.html#probe

z_offset:
#   The distance (in mm) between the bed and the nozzle when the probe
#   triggers. This parameter must be provided.

My observation is that without this probe offset, my gcode offset while printing had to be a rather high value of >0.15, compared to the stock firmware and oc patched value of 0.015.

We're saying that whenever the load cells trigger to a bed probe, the actual printable surface of the bed is really 0.15mm above that position. Due to the bed, build plate and hot end having some level of deflection before the load cells trigger.

This seems to be necessary in order to account for the fact that the load cells do not activate immediately when the tip of the nozzle makes contact with the bed, but instead after the nozzle deflects the bed enough for the load cells to trigger. With no offset to account for this, it creates a bed mesh that is below the real z position of the bed.

I think that 0.15mm is a rather large offset that many users, particularly those coming from stock/patched firmware, are not going to be expecting to need and will likely result in many cases of damanged build plates

[jamesturton]

Yeah of course people scraping their beds is bad and we should do the best we can to avoid this. This is fine as a "quick fix", but I was just skeptical that this was the "right" place to do it.

The load cells can indeed detect very small deflations but there are two things that I think causing this apparent offset, both come from the HX711 driver in klipper. I might well be wrong, and i would love to hear the opinions of anyone more knowledgeable about this, but here are my thoughts.

The load cell samples are noisy and we have to filter out this noise. If you were to do this the most simple way you could consider that you could set some threshold value which, if exceeded would indicate a probe event. The difference between this threshold value and the true load cell value (i.e. without the noise) directly correlates to the offset that you are trying to remove here. As it's the threshold value that steers this completely, any change to this value would effect the perceived offset. In out implementation (or at least the old Kalman filter implementation), we dont use a specific threshold "value" as the filter can compensate for the value drifting over time.

The second source of error is time at which the contact happens during the sampling cycle of the HX711. This time the error will be random but always seen as a delay as it can't sample before the probe event has occurred. This can be compensated quite easily know that the toolhead is moving at a constant velocity towards the bed - we just need to consider the delta in load cell value and back calculate for time. To think of this graphically, if you know the gradient of a line with a single point you can calculate it's intercept with the axis. The issue is that if the load cells have a great amount of variance, the assumption that we know the slope no longer holds. It could be possible to only trigger after two values have been sampled greater than the threshold value and calculate the gradient based on them in order to accurately calculate the intercept. Remember, it's not an issue that we "trigger" after 2 samples, because the trigger event is sent to the host as timestamp relative to the MCUs internal timer, so this should be back calculated time and not the moment we decide to stop the homing movement.

Maybe I didn't manage to explain that very well, but my hunch is that we could probably fix this in the hx711 driver, but if this value works for most people and it stops people from ruining their beds for now that's great!

And I'm sorry I don't mean to sound ungrateful of the effort you have gone to research elegoos approach to this problem. I really really appreciate all the testing and detailed feedback you have been giving, and the massive amount of support you have been giving others in the community on discord! It truly is heartwarming to see what an amazing community we have thanks to people like you investing so much time and effort into the project ❤️ Thank you!