PR: Load Cell Probe

[garethky]

• This is analogous to this PR to klipper: PR: Load Cell Probe Klipper3d/klipper#6871
• This PR requires work in Introduce Subsystem Component Registration #769 and Pr: Probe with Retries #756 to function correctly

The goal of this PR is to get from a gram scale all the way to being able to home a printer with a load cell.

An overview of whats in here:

• The SOS Filter is created as a new utility component on the MCU.
• The load_cell_probe is introduced on the MCU - this allows load cell sensors to act as data sources for an endstop that lives on the MCU. It can detect when a sudden force on the load cell indicates a collision. The SOS filter is used to do this.
• The Load Cell sensors are modified so they can send data to a load_cell_probe on the MCU.
• Finally the LoadCellProbe is introduced on the host that can combine a load cell sensor the load_cell_probe together to turn it into a probe.

---

SOS Filter

This is a general purpose fixed point SOS filter implementation. It supports a maximum of 4 filter sections.

The primary purpose it to reject drift and noise while homing. There is a post about this here.
This idea was originally introduced by Prusa Research code here. Their implementation uses an old code generator, mkfilter, and can't be easily changed without re-compilation.

This implementation uses the more modern Second Order Sections format and uploads each section to the MCU to initialize the filter. This has a number of advantages for kalico:

• This implementation uses fixed point math to get around limitations in kalico's communications protocol and potential issues using the FPU's on chip.
• The SOS algorithm avoids using a costly division instruction in the filter loop, saving hundreds of clock cycles.
• The only requirement for fast execution is single cycle SMULL which is a feature of every ARM Cortex M0+ core.
• The filter is entirely reusable by other analog probe types.

---

LoadCellProbe

Most of the code in this PR is about load_cell_probe MCU implementation. This is not the end of the code for the load_cell_probe.py. There are another ~1000 lines of code that will go into this file to do the post homing Tap Analysis. I see value in keeping these chunks of functionality separate and combining them with composition. People have reached out to me to do a Filament Scale that would have specific functionality for weighing filament, calculating filament used in a print and so on. Keeping load_cell relatively small and simple will let that development happen independently.

Kalico doesn't have the PrinterProbe interface as klipper. The commit that adds LoadCellProbe has been re-written to work with ProbeEndstopWrapper. Homing with loadcell probe works, but it will never do the high accuracy pullback move to refine the z=0 position because that would move the toohead while the machine is not homed. Probing after homing is required to get a high accuracy result. In #756, I added a PROBE HOME=z to simplify this process.

[dalegaard]

Why does the MCU need to work in grams? Can't it simply work in and report counts to the host instead? Then the host, with its oodles of cycles, can perform the conversion?

[dalegaard]

I don't like having a static list here, this should be dynamically loaded.

[garethky]

How can we do that?

[dalegaard]

One option could be to expose the sensors thing in a register_sensor_factory function, like it's done today for heaters with add_sensor_factory. A pattern that could work:

• User specifies sensor: hx71x.
• We lookup_object("hx71x")
• hx71x modules' load_config does a lookup_object("load_cell") and calls register_sensor_factory to register itself
• We call the registered hx71x sensor factory.

This way:

• we don't need to add any lookup/load object changes
• the sensor list isn't static
• all the dynamic loading stuff exists only within load_cell/__init__.py

[garethky]

looking at the existing pattern for heater sensors:

def load_config(config):
    # Register sensor
    pheaters = config.get_printer().load_object(config, "heaters")
    pheaters.add_sensor_factory("BME280", BME280)

This code is run because of a registry file, temperature_sensors.cfg. Heaters loads this file. So that's not a dynamic discovery system, that's a registry, so it wont work with plugins.

I'm on board for a fully dynamic system but it needs to solve a few things:

The senor file name is not the same as the sensor_type. Sensor modules can export multiple sensor types. (hx71x.py exports hx717 and hx711). But if all you have is a sensor_type you have no way to perform the reverse lookup to get to the module name to load. The registry 'hack' solves this issue for temperature sensors.

I don't think the individual sensors should be looking up an object. This runs into naming issues. e.g. load_cell cant be the name because it doesn't have to be registered. The user is free to name the load cells because they can have multiples. Heaters gets around this by registering heaters, by analogy I'd need to register load_cells to serve as the collection & registry. I'd rather not pollute the printer object registry with names that the user did not configure.

---

Proposal: Find all modules with a name that ends in a specific string: hx71x__load_cell_sensor.py. In that way you are exploiting the file system as a registry. Just give back the modules and don't run any load_config. Then the caller can decide how to treat them:

The in load_cell/__init__.py you can do something like this to build the registry once:

sensor_registry = {}
sensor_modules = printer.find_modules("__load_cell_sensor")
for sensor_module in sensor_modules:
    sensor_registry.update((sensor_module.register_load_cell_sensors())

This way:

• The sensor modules never get registered as objects, minimize clutter in the printer's object space which the user can see.
• Sensor modules can contribute multiple sensor_type entries
• Any plugin that copies the naming convention can be a sensor
• No central registry is needed, other than the file system

[garethky]

This is now implemented in #769 and this PR now depends on that one.

[dalegaard]

Would prefer name like complete or something, since this also has the side effect of setting is_started = False

[garethky]

changed to _complete()

[garethky]

Why does the MCU need to work in grams? Can't it simply work in and report counts to the host instead? Then the host, with its oodles of cycles, can perform the conversion?

Counts cant be used directly because they could overflow a FIXEDQ16. The sensors are 24 bit, 32 bit sensors exist. Its not defined how many count bits make up a gram. So the conversion to grams means that if the sensor has an excess of bits (has high resolution), the least significant bits are discarded. e.g. if 1 gram requires 18 bits to represent in sensor counts, it gets converted to grams on the MCU so it fits in FIXEDQ16 and requires only 1 bit of integer space. The math works the same for all sensor bit widths and physical/electrical setups.

Also, from painful experience, you want to use grams for debugging. When its a random value in counts you cant easily tell whats going on. With grams its easy enough to print out a value (just shift it right 15 bits) and be sure things are filtering correctly.

counts_to_grams() is optimized not to require a division instruction. It has 3 instructions that all run in a single clock cycle on an M0+. So the overhead is minimal.

[rcloran]

Shouldn't this have a cleanup of collector in case of probing move failure, along the lines of Klipper3d/klipper#7004 ?

[garethky]

Good point, I can bring that commit forward in the stack so its in this PR.