This branch only supports 1 sensor. The K1 series has 4 sensors. I’m actually shocked it worked and you didn’t crash the machine! I’d refrain from using this on the K1 series until we decide what to do about those 4 sensors.
But good to know it’s no longer crashing with a load of “timer too close” errors. Perhaps the mcu clock has been fixed?
I’m never seen messages about timer too close…
I’m solder all 4 sensors to one hx711.
And i’m did some tests - printer shutdown if i’m set 170 or more temp for extruder - if 160 - printer working 
- what this?)) And this only occur after bed mesh calibration and smart_park from KAMP. if heating nozzle without bed mesh and smart_park - all good - printer working… maybe problem in activate_gcode? or my config?
[load_cell_probe]
sensor_type: hx711
dout_pin: leveling_mcu:PA0
sclk_pin: leveling_mcu:PA2
z_offset: -0.1
counts_per_gram: 28.09438
reference_tare_counts: -32570
safety_limit: 5000
trigger_force: 160
trigger_count: 1
speed: 2
lift_speed: 5.0
pullback_dist: 0.5
pullback_speed: 0.2
pullback_extra_time: 0.3
settling_time: 0.5
activate_gcode:
{% set PROBE_TEMP = 150 %}
{% set MAX_TEMP = PROBE_TEMP + 5 %}
{% set ACTUAL_TEMP = printer.extruder.temperature %}
{% set TARGET_TEMP = printer.extruder.target %}
{% if TARGET_TEMP > PROBE_TEMP %}
{ action_respond_info('Extruder temperature target of %.1fC is too high, lowering to %.1fC' % (TARGET_TEMP, PROBE_TEMP)) }
M109 S{ PROBE_TEMP }
{% else %}
# Temperature target is already low enough, but nozzle may still be too hot.
{% if ACTUAL_TEMP > MAX_TEMP %}
{ action_respond_info('Extruder temperature %.1fC is still too high, waiting until below %.1fC' % (ACTUAL_TEMP, MAX_TEMP)) }
TEMPERATURE_WAIT SENSOR=extruder MAXIMUM={ MAX_TEMP }
{% endif %}
{% endif %}
Can you DM me the log file with the error? My guess is the crash about the JSON encoder is something to do with the Python version. I’m not sure about 170 degrees thing.
Looks like you override quite a bit of stuff in the config. The
pullback_speed has a direct impact on accuracy and is automatically set based on the sensor sample rate. You’ve made it faster which will hurt accuracy/repeatability.
You also made pullback_dist 5x the normal distance, I assume this is because the probe overshoots badly at 2mm/s and trigger_force of 160g.
To get equivalent speeds to Prusa’s machine you’d have to divide them by 4 because the sensor is 4x slower. E.g. probing at 2mm/s is the equivalent of probing at 8mm/s on the faster sensor. Pullback speed on the faster sensor is 0.32mm/s, but on this sensor it should be 0.08mm/s. If all that sounds really slow, blame Creality for the sensors.
Ideally you would also install SciPy and get the continuous tearing functionality to work. But I hear that on Creality’s “customized” linux distro this doesn’t install.
This is a Klipper bug. Needed on line 272 in the file klipper/klippy
/webhooks.py replace
jmsg = json.dumps(data, separators=(‘,’, ‘:’))
on
jmsg = json.dumps(data, separators=(‘,’, ‘:’), default=str)
very thanks man - im test this and reply.
That would mean that one of the data types being serialised isn’t a basic Python type. Sounds like a coding error on my part. I’ll have to investigate further.
I thought I saw this with Boolean values not being serialised by Python 2.7, but I can’t exactly remember.
yes - i’m think this is related to load cell code - beacuse with bl touch - no problems…
and - i’m not author for this config - i’m did copy past from k1 tenso_mod project from github.
But i’m can say that i’m have very good results without any problems - if nozzle clean - no problems with first layer - if I ever have problems with accuracy I will try to do what you advise thank you.
Strange but i’m cant edit with web interface z offset -
SAVE_CONFIG section ‘load_cell_probe’ option ‘z_offset’ conflicts with included value
YES this fix problems - very thanks!!
Thanks guys, I just built a version of klipper from pellcorp with your developments, and made it calibrate btt_eddy using load_cell_probe on my k1c
Hello.
My old Anycubic Vyper used to used board with a gauge sensor on the hotend’s mount.
People are struggling with these dying sensors a lot on this printer bsc of hardware problems.
Hi. I thought about this few months ago. Today, searching in the post if anyone had tried this idea, I have read this comment and it is just what I am testing.
In case it is usefull for anyone, I am using the load cell of anycubic vyper and a simple chip of hx711 and I can get data from the sensor correctly (I am using the adc-endstop branch from @garethky but I have just read that he changes to load-cell-probe-community-testing branch). The shape of this load cell allows to use v6 like hotends (in my case, one BMO hotend), decreasing the typical size of generic load cells. And I don’t have any problem reading and calibrating the load cell with the @garethky implementation.
I designed the support for the cell with a overhang that allows to support the hotend but also a little movement in the z axis when probe touches the heatbed.
BOM: Load cell and hx711 has been bought in aliexpress for 10€ approximately.
We don’t recommend that hx711 sensor for probing. It is a very slow sensor. The hx717 is basically the same chip at the same cost but clocked 4x faster. The trouble is availability of boards. If you are using the HX711 you should limit all probing and homing to a max speed of 2mm/s.
Thanks @garethky. I rode these recommendations previously in the post and in your documentation. I was designing a pcb like HX711 models but I found this design of @Celeste_e:
that I will test in the future.
Hi All around,
I can confirm that KIAUH is able to access the load-cell-probe-community-testing branch. I was able to install it and got updates since then.
How to do that:
put
garethky/klipper,load-cell-probe-community-testing
into
~/kiauh/klipper_repos.txt
and select it in the KIAUH Settings
You can Install and update from the branch then. You have to update the MCUs afterwards.
I’m forced to power cycle my machine after this procedure, to get everything up an running again, but that may affect me personally - it’s the same with the official branch.
Hi,
Recently, I designed a heated bed mount that includes four load cells mounted on the four corners of the bed. I plan to use a simple parallel connection of four full-bridge load cells and a single HX717 as an end-stop probe, similar to what @sekil did on K1 series. (Although, based on electrical principles, paralleling full-bridge sensors doesn’t seem very reasonable. It might work accurately under smaller loads, but I’m uncertain about the stability of this approach.)
Currently, I want to design a custom PCB to test four load cells using the HX717. This board will be installed underneath the heated bed. I have a few STM32F072 chips on hand, the design will include both CAN and USB connection options.
I also came across your ADS1220-Klipper-Board project on GitHub @garethky. I think that if using an ADS1220 to connect four load cells, adding a differential amplifier to each input channel might be a good solution. Since most commercially available load cells are full-bridge types, and the ADS1220 supports only two differential or four single-ended measurements, wouldn’t the ADS1256, which supports 8 single-ended or 4 differential measurements, be a better choice in this case?
You can hook up multiple full bridge load cells in parallel to one input. In the commercial weigh scale industry this is called a “Summing Box”. This is the wiring topology in the prototype board.
Multiple separate inputs don’t really help because the majority of these ADC chips can only read from 1 of the input at a time. This would divide the sample rate by 4 or increase the noise due to higher sample rate used to compensate. The summing box topology is better for this application than either of those options.
Another alternative is to use 4 separate ADC chips and write a driver that sums the result. I did this with the HX71x code as a test. Its not great because the 4 chips don’t share a clock, they drift apart in time. This has implications for precision because the summed signal is “smeared” out in time. (This is what Creality did)
Then there are chips like the ADS131A04 that have 4 internal ADCs and will do “Simultaneous Sampling”. If you really want 4 separate inputs this is The Right Thing. You still end up simply summing the 4 results.
I looked deeper into how load cells are used in industrial applications and found out there are actually two types of “Summing Boxes”: analog and digital.
The digital summing box is used in heavy-duty weighbridge systems. In this case, the load cell itself performs the analog-to-digital conversion and outputs an RS485 signal. The usage involves directly connecting multiple cells in parallel and addressing each sensor individually (similar to a CAN bus). Referring to the diagram below, this is clearly not what we need.
I know this doesn’t really address the issue here (having 4x full-bridge sensors), but I recently setup a high-SPS scale (unrelated to 3d printing) using an ADS1220 and 4x half-bridge sensors which each had a positive and negative gauge. The picture below is a diagram of how it is wired into a single wheatstone bridge to get the full 4x signal compared to a single half-bridge sensor. And since it’s a single wheatstone bridge, it samples with a single differential pair (I got ~300 Hz but I was bottlenecked by other processing. I know 1k-2k Hz is feasible with the ADS1220).
If you can isolate all the gauge wires and you don’t care about giving up half your resolution, you could simply omit half the wires and build a single mega-bridge like this:
I briefly considered switching to different sensors that each had full-bridges, and I spent some time with the ADS1256, which has 4 differential pairs for this purpose. The following document was very useful in understanding how to use it. It claims that you can do up to 30k SPS with a single differential, and that drops to 4.3k SPS using 4 pairs, which is still really fast (though I didn’t get far enough to evaluate SnR):
I found the ADS1220 so easy to use, and excessively accurate (and fast) for my application, it might be worth considering if you can access the wires for the individual strain gauges and do the half-bridge thing I mentioned. It would really simply things as long as you’re just looking for a total weight (and don’t need individual measurements from each sensor)
Thank you for your response. I have previously used the ADS1256 and STM32 to build a small photodetection device, but I don’t have the capability to write the necessary drivers for Klipper. Considering the issues mentioned by @garethky, I’ve decided to temporarily abandon the idea of simultaneously collecting data from 4 separate inputs.
I’ve noticed that there are two common types of load cells available on the market:
I will still attempt to use the analog “summing box” I mentioned earlier to connect four load cells. My heated bed mounting structure has already been designed and made, and modifying the load cells and wiring would be too painful for me. However, I still believe that using four half-bridge sensors is a great idea.
Hi @garethky can you help to check this issue when running your branch?
BatchBulkHelper batch callback error
Traceback (most recent call last):
File "/usr/data/klipper/klippy/mcu.py", line 71, in _do_send
return xh.get_response(cmds, self._cmd_queue, minclock, reqclock)
File "/usr/data/klipper/klippy/serialhdl.py", line 355, in get_response
raise error("Unable to obtain '%s' response" % (self.name,))
serialhdl.error: Unable to obtain 'sensor_bulk_status' response
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/data/klipper/klippy/extras/bulk_sensor.py", line 76, in _proc_batch
msg = self.batch_cb(eventtime)
File "/usr/data/klipper/klippy/extras/hx71x.py", line 129, in _process_batch
samples = self.ffreader.pull_samples()
File "/usr/data/klipper/klippy/extras/bulk_sensor.py", line 300, in pull_samples
self._update_clock()
File "/usr/data/klipper/klippy/extras/bulk_sensor.py", line 273, in _update_clock
params = self.query_status_cmd.send([self.oid])
File "/usr/data/klipper/klippy/mcu.py", line 75, in send
return self._do_send([self._cmd.encode(data)], minclock, reqclock)
File "/usr/data/klipper/klippy/mcu.py", line 73, in _do_send
raise self._error(str(e))
gcode.CommandError: Unable to obtain 'sensor_bulk_status' response
How can I solve this?