You shouldn’t need an oscilloscope. I have a debugging tool that charts graph of the load cell data and the probes. Its one of the things I need to update for the weekend based on the changes to the config and data streams.
Maybe interesting for you, Peopoly will publish their Klipper version including their load cell code on GitHub:
We plan to open source the Peopoly Klipper firmware used on Magneto X to the public next week vit GitHub. We have been working with the Klipper team for quite some time now, and as discussed, we uphold the open-source software standard.
Source: Magneto X: Shipping Updates, sneak peeks, enclosures and more
That’s great, it would be nice to get source code vs what Creality did.
I haven’t talked to them, not that I’m anyone special. I don’t think they have a thread here, or an issue open, or have posted anything on the discord? If they are working with klipper I have missed it.
I was just trying to figure out if my issue was signal qaulity related.
I wasn’t aware of the tool to visuallize tht.
I need to take a closer look at that.
The branch, the docs and the debugging tool have been updated. It is ready to have people test it and file bug reports. I’d also like feedback on the documentation.
Proof of life:
There are now 2 documents, one about load cells and another about load cell probes. The config and commands have been integrated into the right places in the rest of the klipper docs:
- Load Cell
- Load Cell Probe
- [load_cell] Config Reference
- [load_cell_probe] Config Reference
- Load Cell G-Code commands
- Status Reference
If you had config from prior versions you will need to update. Everything has been merged under one object.
Here is the config for the Voron 2.4 test rig
There are two important new settings:
reference_tare_counts : this saves the tare value at the time the sensor is calibrated and is used as the default tare value when the machine starts up. The load cell is not considered calibrated without this value.
safety_limit_grams: this limits maximum force delta from reference_tare_counts while probing. This defaults to +/-1Kg. The idea here is if the filter or other settings fail this will limit potential for damage to your printer.
Other changes:
- Everything is using bulk_sensor. All the multiplex_adc stuff is deleted.
- The the hx71x implementation is now just 1 file that works for 1 to 4 sensors. If you use multiple sensors the output is the sum of all 4. This supports the 4x sensor Creality machines.
- Readings from all 4 sensors go back to the Host. Right now they are just summed together on the Host. I’m still thinking about how to expose the individual readings.
- The hx71x sensor can send a reset event back to the Host if it crashes. The Host will then try to re-start measurements. This is experimental and its not a fix for bad grounding.
7 Likes
I need to try this tomorrow.
The update looks very interesting.
1 Like
Hello,
I’m very interested in your work.
I am converting to klipper an old machine based on a Kossel architecture.
With 3 load-cells under the tray. they are all 3 connected in parallel on an analog input of the motherboard.
Wouldn’t using an analog input on the motherboard be a more economical solution? By logically defining the range of values that would be considered valid.
I found some issues with the documentation
From the load cell config reference:
[load_cell_probe]
sensor_type:
# This must be one of the supported bulk ADC sensor types and support
# load cell endstops on the mcu.
#counts_per_gram:
#reference_tare_counts:
# These parameters muct be configured before the probe will operate.
# See the [load_cell] section for further details.
#safety_limit_grams: 1000g
> #the underscore grams should be removed
# The safe limit for probing force relative to the reference_tare_counts on
# the load_cell. The default is +/-1Kg.
#trigger_force_grams: 50.0 **
> #the underscore grams should be removed
**
# The force that the probe will trigger at. 50g is the default.
#continuous_tear_highpass: 0.8
# Enable optional continuous tearing while homing & probing to reject drift.
# The value is a frequency, in Hz, below which drift will be ignored.This
# option requires the SciPy library. Default: None
#continuous_tear_lowpass: 100.0
# The value is a frequency, in Hz, above which high frequency noise in the
# load cell will be igfiltered outnored. If this option is set,
# continuous_tear_highpass must also be set. Default: None
#continuous_tear_notch: 50, 60
# 1 or 2 frequencies, in Hz, to filter out of the load cell data. This is
# intended to reject power line noise. If this option is set,
# continuous_tear_highpass must also be set. Default: None
#continuous_tear_notch_quality: 2.0
# Controls how narrow the range of frequencies are that the notch filter
# removes. Larger numbers produce a narrower filter. Minimum value is 0.5 and
# maximum is 3.0. Default: 2.0
#continuous_tear_trigger_force_grams: 40.0
> #the underscore_grams need to be removed
# The force that the probe will trigger at whe using the continuous tearing
# filter. 40g is the default.
In the config you have to define a first counts_per_gram: value
otherwise your printer will run into an error state.
After calibration you need to copy the counts_per_gram: value calculated by t he script and change the value within your config.
1 Like
I’ll check this today
Was it this?:
!! Internal error on command:"ACCEPT"
If so, fixed here. Along with that I did a scrubbing pass with the static analyzer, PEP checker and the whitespace tool.
If you see this:
!! Load Cell not calibrated
That’s on purpose. You cant probe with an un-calibrated load cell.
I made an update to [z_thermal_adjust] that allows you to specify multiple sections in the config and give each one a name. It also allows you to reference existing temp sensors as a data source. So now I can do this:
[z_thermal_adjust nozzle]
temp_coeff: -0.00055
sensor: extruder
max_z_adjustment: 0.1
and still be able to define a separate one for your frame:
[z_thermal_adjust frame]
temp_coeff: 0.0036
sensor_type: Generic 3950
sensor_pin: T1
min_temp: 0
max_temp: 80
We could even do a third for the heatbreak sensor in the MK4… 
Maybe I need to put this in an FAQ or something. We had a discussion about something similar earlier in this thread.
You cant “logically define” in software how the load cells output voltage maps onto the sensor’s bit range. That requires an amplifier, sometimes called a PGA, between the sensor and the load cell.
!! Internal error on command:“ACCEPT”
This was the message displayed after calibrating.
!! Load Cell not calibrated
Was one part of the message displayed directly after startup in my case.
The message halted the printer so I couldn’t even start the calibration process.
A workaround for me was to just uase a placeholder counts_per_gram value
It is a nice security meassure for shure!
That’s a good point, there is a lot of safety checks built in that you should know about. I added a section to the documentation that covers this Load Cell Probe Safety
Ive bent one very expensive printer’s X axis gantry while developing this and nearly destroyed the toolhead on another. So I don’t want that kind of problem to bite anyone else.
In the discord it was pointed out to me that the lack of clear hardware recommendations is a problem for testing. And unfortunately I don’t have a great list of recommendations. It would need to be base on the HX711 or HX717 sensor chip and be something that klipper can handle. Right now that’s:
- The Prusa MK4. If you wanted to klipperize an MK4, it should now be possible.
- The Creality K1 series. Currently @zarboz is doing some testing to prove this works.
- Mounting the MK4 nextruder to a Voron 2.4. I can provide STLs to do this, but you would need a complete MK4 Nextruder, which currently cant be assembled from spare parts. You have to buy the upgrade kit for $499. If you’re interested, let me know.
Anyone know of anything else? Realistically, to prove out the code and the PR, these are the options we have.
I’d love to offer a toolhead board with a better sensor and an option for a load cell that works with something like the Revo system. But doing that is going to take months of work.
1 Like
FWIW, Prusa has released the details of the MK4 including the Love Board: Open-source at Prusa Research | Original Prusa 3D printers directly from Josef Prusa
1 Like
You can buy the Love Board as spare parts for $19 and the load cell for $47. Everything else can be bought (thermistors, nozzles, heater etc.) But you cant buy the extruder motor and gears to make it work.
Maybe I should take a hacksaw to the load cell and see if a different extruder will work. That’s really the blocker right now.
I’d love with my simple version of a Toolhead using a simple load cell bought via Amazon. It uses pretty standard components.
So far I am having issues with my software config.
When I am able to use it properly, supported by test data, I could share the step file so others can use and improve my Idea.
Sadly I am not able to use the diagnostic tool due to a specific network environment I am working from right now.
If my proof of concept works I want to adapt it to also run on a core xy machine.
I’m not shure if it is possible or a good choice.
I was looking at the Huvud toolhead board.
The scematics are open source. If they are up to it it could be used as the base for a possible toolhead board.
Shouldn’t it be possible to expand the spi bus for the accelerometer to add an ADC chip? Or would that bus be to noisy?
Just wanted to let you know.
what about taking a different loadcell, for instance the one on the anycubic vyper.
That one looks generic, easier to integrate in various toolhead.
Edit: upload a picture of a spare, to show the shape, less than 20€
1 Like
I’ve posted the STEP files and details for the Nextruder Voron mod to Printables: Prusa Nextruder to Voron 2.4