# Load Cell Probing Algorithm Testing

**URL:** <https://klipper.discourse.group/t/load-cell-probing-algorithm-testing/9751>\
**Category:** Developers\
**Created:** [August 1, 2023, 5:37am UTC](https://klipper.discourse.group/t/load-cell-probing-algorithm-testing/9751 "2023-08-01T05:37:52Z")\
**Posts on this page:** 1\
**Showing post:** 35

<div class="post-metadata">

**Author:** ![koconnor](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@koconnor](https://klipper.discourse.group/u/koconnor)\
**Post date:** [August 9, 2023, 7:51pm UTC](https://klipper.discourse.group/t/load-cell-probing-algorithm-testing/9751/35 "2023-08-09T19:51:24Z")

</div>

> [@garethky](#):
>
> This should be leveraging all the goodness in `HomingMove.homing_move()` that works out exact stepper positions.

Okay - if you’re using the stepper position already then that is great. I know in another thread you asked about trapq\_extract\_old, so I wanted to make sure you were aware of the limitations of that mechanism.

> [@garethky](#):
>
> Since what I’m returning is a print time, any time skew would result in a z position skew

If the sensor and stepper are on the same MCU then I don’t think clock synchronization would alter the results - as the conversion from mcu\_clock to print\_time back to mcu\_clock should not be lossy. (That is, any clock skew should fallout.)

If the sensor is on a different MCU then clock synchronization can introduce a deviation. This is a known limitation of “multi-mcu homing”. Typically Klipper does a good job of synchronizing clocks, but you can graph the results of the logs ( [Advanced Trouble-Shooting / Graphing Klipper](https://klipper.discourse.group/t/advanced-trouble-shooting-graphing-klipper/6613#graphing-mcu-frequency-15) ) if you want to investigate that.

-Kevin

---

_[View the full topic](https://klipper.discourse.group/t/load-cell-probing-algorithm-testing/9751)._