Just a bit of an update:
Continuous Tearing
Over Christmas I did an investigation of Prusa’s use of the Butterworth filter. I was able to replicate what they are doing and, very long story short, an improved version is implemented and working on the test rig:
The filter requires the SciPy library. Its compatible with Prusa’s filter, so you could configure an MK4 or XL with the same filter frequencies they used. But I think we can do even better. The implementation has a number of improvements over Prusa’s specifically for klipper:
- Its in fixed point Q12 instead of floating point, aimed at the Cortex M0+ cores on most toolhead boards. So an FPU is not required.
- Its fully configurable, no filter coefficients in the source code. Printer designers will be able to measure drift frequency using an FFT and to find optimal filter frequencies. A Python notebook is included in scripts to help with this.
- The filter doesn’t have to be a bandstop filter. It can be just a highpass filter which reacts to taps faster than the bandstop filters that Prusa used.
- Up to 2 Notch filters can be configured to remove noise from your power supply. They might also be able to remove a particularly stubborn frame resonance frequency.
- The Host tears the
load_cell_endstop
to 0g at the start of homing moves. This is the one condition where the filter’s initialization state vector is all 0’s. This means there is no settling time for the filter. In the video above the 375ms settling time was set to 0 and it works just fine. - A “safety_limit” has been implemented that puts limits on the force to the toolhead based on the reference tear value that’s saved when the load cell is calibrated. If the filter is too aggressive you have this as a backup. Also, if you damage the load cell, this should cause it to stop working so you know something is wrong.
- The filter is completely optional and off by default. If your not using a toolhead load cell you probably won’t need the filter.
bulk_sensor
Refactor
This is underway right now, its going to be quite the change:
- The single and ‘multi’ implementations of the HX71x will be unified so there is just 1 thing to maintain.
- The config will see major changes. I have to go back to the
sensor_type: hx711
style config where the sensor options are inside either the[load_cell]
or[load_cell_probe]
sections (following the pattern of[temperature_sensor]
and[angle]
). This keeps the initialization logic for theload_cell_endstop
under the control of the containing module. - Aside from the
load_cell_endstop
support,hx71x.py
will be a genericbulk_sensor
that any other subsystem can adapt to be a data source. So you could use it as a PT100 sensor, filament width sensor, filament scale etc. - I want to get support for graceful resets in, so they don’t ruin a print. They will still result in a shutdown during probing. I think the Host has to be informed of the reset and request a restart of measurements.
Until I get done with all this the firmware wont build in the branch. It allocates too many message Ids. Post-refactor this isn’t a problem.