I am writing to you because I am having some trouble with my load cell configuration. I am using a 1 kg load cell (HX711) module, and I have followed all of the steps that you mentioned in your previous message. However, I am still getting an error.
I have attached my config file for your reference. Can you please take a look at it and see if you can spot any problems?
The code output
As you saw on above image. l cannot take prope accuracy exactly. The heating bed go up but l cant take any value from loadcell when l press on it by hand. also l share image of system that l connect from outside to made sure from electronics.
Iām assuming you flashed the controller with the code in the banch. (klipper should throw an exception if the MCU isnt the same protocol version as the host)
I cant find the āCommunication timeout while idleā in the klipper codebase so that must be from your front end?
look in the klippy log and see if there are any message in there?
If you donāt see measurements from the load cell using READ_LOAD_CELL then its not reading data from the sensor.
The new version will stop a probe if the load cell is not calibrated. But if the sensor code sends back a stream of 0ās thatās not detected as an error case, yet.
[Update: I have managed to find their contact details and I have sent them a request for gerber files for a sample/development board]. If I hae any success I will report back. In the meantime I have ordered some strain gauges so I can make some custom load cells to experiment with.]
Unfortunately no. The PrinterProbe object doesnāt support multiple probes (i.e. there is no PROBE=ātool0ā parameter to its commands). If you try to make more than 1 it will throw an exception because the commands are already registered.
Iām dong all the ground work to support many load cells, but PrinterProbe needs to be re-worked to support named probes. That, or we have a complex probe that support switching which load cell its reading from.
Orange dot: the āelbow pointā. Likely first point of the collision dataset
Blue and green lines: least squares best fits of the pre and post collision lines
Red dot: the estimated time when the collision started which is reported to klipper
Yellow dot is the point where the endstop on the board triggered to stop the move
Magenta dot is when klipper said probing ended.
Taken me more than a year to get here but these PROBE_ACCURACY results are just nuts
// PROBE_ACCURACY at X:200.000 Y:125.000 Z:6.573 (samples=10 retract=5.000 speed=5.0 lift_speed=5.0)
// ...
// probe accuracy results: maximum 1.573681, minimum 1.570139, range 0.003542, average 1.572205, median 1.572205, standard deviation 0.001245
(sampled at 1200 SPS)
Thatās 1/2 the standard deviation of a switch probe at the same speed. Itās very close to a commercial CNC probe.
There is still room for improvement, especially on consistency between speeds and sample rates. I have at least 3 things left to try:
Well, if Iām honest, I get better results out of my Euclid probe on my Voron 2.4:
PROBE_ACCURACY PROBE_SPEED=5 SAMPLES=10 SAMPLE_RETRACT_DIST=5 RETRACT_SPEED=10
probe accuracy results: maximum 0.387469, minimum 0.385125,
range 0.002344, average 0.386234, median 0.386375, standard deviation 0.000714
I would have to say that the load cell probe is maybe at 0.0015 SD and the Euclid is down near 0.00075 SD on average.
I tried the 60Hz notch filter and it didnāt really change the results. I will try shortening all my wires to see if I can get the noise to be less.
The TrapQ idea did not pan out. The logged time of the stopping move is after I see noise in the plot. Just looking for where the force graph drops is easier and much less code.
The good news is I donāt see any difference in performance at 400 SPS vs 1200SPS. The estimation algorithm seems to be working well with less data.
Took a couple days to reflect on where Iām at and what to do next.
Clearly I need to ship a guided calibration tool and some documentation. A bunch of safety checks need to be added to stop people from accidentally crashing their machines. Iām going to focus on this first.
On the accuracy side, I think we need to look at the two core algorithms and find a way to measure the impact of any further code changes. Specifically:
Locating the elbow point
Estimating the contact time based on the elbow point
I think a good next step here would be setting up a simulation of a probe so we can control the exact timing, velocity, noise, elasticity etc. I cant run real probes in the 10ās of thousands that it would take to validate tweaks to this code. I think there is probably another order of magnitude improvement to be had with the right mathematical model. This might be something we can work on as a community.
Then there are other things beyond the current approach. Prusa captures both the down and up strokes of the probe and actually bases their z height on the up stroke. We could look into doing the same. Having 2 probe samples for the time cost of 1 is certainly attractive.
Iām also looking for ways to improve sensor read performance possibly using adaptive timing. This hasnāt been done exactly this way before in the klipper codebase but the general idea is not uncommon in other applications. It would be a win for low SPS devices like the HX71x chips.
Guided calibration has been implemented. This is very similar to how MANUAL_PROBE works with a set of shortcut commands getting registered when you start the calibration process.
READ_PROBE for shows grams and the % of the senorās range. This percentage idea is in all the commands now, it gives a much clearer idea of what going on, especially when the load cell isnāt calibrated.
LOAD_CELL_DIAGNOSTIC was added as a way to collect some data and try to see if your load cell is working as expected. It collects 10 seconds of data and then tries to tell you some useful statistics about that data, like how much of the sensors rage was used, any errors that occurred etc.
This was a lot of work/code and I cant swear its bug free. It has a lot of edge cases, some I cant easily exercise. Bug reports and feedback welcome.
If you have a bit of a data science, math or signal processing background you might want to check that out. I certainly donāt claim to be a mathematician and could use the help. Iām building up a model to test the algorithms so I donāt have to run probing cycles on my physical printer to validate what is a good change. Some folks that might be interested: @D4SK@etotheipi@mhier
I use the Deut3d Smart Effector on my monster 500 sized Delta. It works GREAT! You can program the sensitivity of the trigger point, thus making it very effective. Yes, you will see the little trigger LED flash once in a while while printing, but since you are not looking for a trigger, it has no effect on printing. What I watch that LED for is if I see it flickering a bit more than normal, i know I have over extrusion, or blobbing issues as the nozzle tip ātripsā over bumps or blobs!
I want to use this with a tool changer, but Iām not going to do the work to get multiple probes to work in klipper. It would add too much extra stuff to this PR. We need it though!
(andā¦ as if by magicā¦ my Prusa XL order is ready to ship today!)
Hey I been quite interested on this thread for a long time, I am trying to get a hx717 board asap for another project but quite in the same direction, I quickly made a desing based of the reference desing and another hx711 desing i found online. Still learning so idk if all is correct but i am trying to get it sent to manufacture before the end of the incoming week, here u can track the proccess so far. I hope it helps. HX717 PCB - EasyEDA open source hardware lab S0 and S1 are set HIGH for the 320sps. if anybody can help me point error that would be great. :s
I am not the best person to check a design like that. I really need to find time to learn ECAD.
Sparkfun has open source ecad for their HX711 board: https://cdn.sparkfun.com/assets/f/5/5/b/c/SparkFun_HX711_Load_Cell.pdf
They have added much larger capacitors on the power lines for noise suppression vs the cheap boards you see on amazon. It looks like you have the same 10uF caps in your design
They have a āshieldā pin thatās connected to ground which is nice to have. They had to split out the āBā connectors to do it (I donāt see a lot of use for the B connector, in most projects its not used). I think what you designed might be equivalent to theirs but their connections to ground are much clearer in the schematic.
A suggestion I read from another chip manufacturer (TI) was to put a large ground plane under the chip and keep all power lines clear of that area to reduce noise. I have no idea how easy that is to do.
