Sorry I’m so late to the party.
I read this entire thread, fantastic work guys!
Has anyone seen the toolhead Sovol is putting on their Ace models? They have mounted their heatbreak on a force plate. They use a HV711 to read it, a python module to convert it to a switch and pass it to [smart_effector].
My question is if I copy their HX711.py to the extras folder will mainline Klipper work? How do they assign it to Pin PB6? My python skills are weak, if only it was written in Fortran.
Klipper does support the HX711.
Klipper does not yet support probing/homing by the load cell.
If it is a question.
Module from the sovol repo will not work with the mainline Klipper.
Hope that helps.
Yes it helps… Not the answer I hoped for but defines the scope of putting that toolhead on my old printer. Sovol’s “fork” of klipper is a compete mess.
Why not try it with the community testing branch? That will work.
Edit: the branch will give you better accuracy than the switch pin method. It’s still probably a few months of work away from merging into Klipper fully but it’s on the way. I can use all the eyeballs and QA I can get.
Where is the best place to learn about using the testing branch?
For what it’s worth I wasn’t expecting probe functionality I simply NEED automated Z offset. I have ALS and my printers are located such that running a “paper test” is difficult.
I would be thrilled to test your probing function and as fate would have it my pre ALS day job was test engineer.
Awesome! The community testing branch has some edits in the main readme file to link to all of the documentation files, configuration references and so on.
If you are using Kiauh there is a way to designate an alternate klipper repo and branch to pull from. You’ll have to manually install numpy and scipy in the klippy virtual env.
Easy enough! I don’t have the toolhead yet and haven’t completely worked out how to mount it.
Anyone with a functional Sovol “Ace” should be able to be an alpha tester without needing any hardware work. Would you like me to try and recruit a couple? The test fleet gets too large and you spend all your time on maintenance and none on development.
Just starting to get up to speed but I have to flag this from https://github.com/garethky/klipper/blob/load-cell-probe-community-testing/docs/Load_Cell.md
A good calibration force would ideally be a large percentage of the load cell’s rated capacity. E.g. if you have a 5Kg load cell you would ideally calibrate it with a 5kg mass. This might work well with under-bed sensors that have to support a lot of weight. For toolhead probes this may not be a load that your printer bed or toolhead can tolerate without damage. Do try to use at least 1Kg of force, most printers should tolerate this without issue.
This is not “best practice”. If you know your test endpoints and have the opportunity to calibrate pre test you should calibrate over the expected test range and no more. All transducers have some non-linearity. I would expect that most sensors built into printheads to be especially nonlinear. Case in point, the Sovol force plate I intend to use is going to transition from bending beam to sheer at some unknown force. That will result in a strong knee in the force to counts curve. A 2 point calibration done across that knee will be wildly inaccurate at low forces.
TLDR - Calibration load should be 110% of expected* load
Your comment on gain is spot on (unlike my early days with 8 bit equipment).
Final note, I’d recommend a piece of foam tape and a coin stuck to the digital scale. Lowering the force/position slope will allow hitting the goal input load much easier.
Edit: *maximum load
As long as I’m running roughshod over all your hard work consider this:
From a “probe” perspective we care NOT what the force is. There is no need calibrate in any units at all (filament force if/when it comes online will need the force calibration back).
Calibration routine:
Replace the nozzle with a smooth head bolt to protect the bed.
Generate a force/deflection curve by intentionally crashing the bed. X axis is Z microsteps, Y axis is raw AD counts. Do the regression and once the nozzle is reinstalled for any AD count we either know nozzle is in free air OR (C) microsteps below zero.
All the end user needs is a M6 bolt filed smooth.
TODO: determine if the compliance of the bed at the corners and edges is great enough to require multiple force/deflection curves.
If you calibrate with 1Kg for probing that would be over 100% of the expected load, for a probe.
The toolhead sensors have to be designed to survive more than the extrusion force. This has been measured at around 12Kg.
They should, ideally, also survive a head crash, both horizontally and vertically. So odds are good that the sensor can physically survive 25Kg of load. I think the Prusa one is more like 50Kg. But I kinda doubt if these “flat bar” style flexures are going to survive that.
But I would but NOT put a 50Kg force on the load cell mounted inside the printer. I do not think that anyone’s X axis or toolhead printed parts would survive that load without permanent deformation. Even the lower value of the extrusion force is only between the extruder motor and the nozzle. So its internal to the toolhead. The frame of the printer never sees that force.
So the 1Kg number was picked because its something that you can do on most printer frames. Its also well over the ~200g force we expect to see in a probe. You should get good linearity in the probing region.
For extrusion force it would be better to calibrate over that ~12Kg range. In a perfect world you would mount and qualify the sensor in a test rig. Then the customer would get the sensor along with a counts_per_gram value from the manufacturer for some common ADC + gain combos. I think we will start to see this as products developed for this code hit the market.
There is a real risk that you can bend or break parts of your printer. I have personally bent 1 printers X axis while developing this (and I’ve only had 2 test machines). That event caused me to add a number of safety systems to this code. The conversion to grams is one of them. All of the units are in grams because that’s how we can have a common understanding of safety. As the saying goes; “the regulations are written in blood”.
You can defeat this by putting in some random value for counts_per_gram, perhaps its aspirational. e.g. if you put in 1000 and it turns out that the real calibration value is 10. Then you probe to ‘75g’ but in reality, 7.5 Kilograms of force goes through your toolhead before it to triggers. That might break things. All of this will happen too fast to even hit an estop button. Like 50ms fast.
The math doesn’t care about units, but your hardware surely does.
7 posts were split to a new topic: Z-Forces (philosophical)
I’d recommend this process becomes a dead weight test in the same direction as the applied force. Hang known weights from eyebolt in place of the nozzle. YIKES My oldest printer uses a single grub screw (M3) to secure the heat break… 12kg might rip it out… let me think on it.
Let me try again to explain my perceived issues with your preposed calibration method with the understanding that to measure filament push my method won’t work.
First off, many of the load cells integrated into OEM tool heads (80% of the user base when this goes mainline) can never be used for filament force as they are either mounted such that they are not acted upon by the separation force between the extruder and nozzle or hit an overload stop at some small fraction of 12 kg. Requiring users of these machines to do a force calibration will lead to many “Issue” entries at git.
Instead consider the following procedure:
This method doesn’t encourage users to lie and estimate “yah that’s about a kilo”.
it also linearizes a (in most oem units) poorly designed load cell over the exact range it will be used in this function.
Question - The load cell output is available to other functions when modules when the hardware is not being used by these endstop functions? Another branch of code could read and process load cell counts to generate force measurements using a different scale factor?
This seems like a hugely elaborate scheme to avoid using a kitchen scale. I don’t find that repeatable or compelling. There is nothing “exact” about it.
If you have some specific problem, like your ALS means it’s hard to get the scale into the printer and read it, I have some sympathy for that. We could come up with something different for you.
But I don’t think that’s going to make me direct all users towards some procedure that doesn’t result in at least a somewhat calibrated load cell. Not least of all, people post their issues here and if we have no common measurement to compare, I can’t tell if what they are doing is a problem or not.
Just try the procedure with the kitchen scale. It’s simple, works in an assembled printer and it is just 2 steps.
—-
Yes, the load cell module does expose the load data as both raw counts and grams to any other code that wants to subscribe. The module can already function as a basic filament scale. We might get a filament scale specific module at some point that does other stuff, like trigger gcode and integrate with spoolman.
I need no special code. I am ready and willing to calibrate the load cell in that Sovol toolhead (shipped today) when I eventually get it mounted. Perhaps real data will confirm my fears of nonlinearity in OEM loadcells. Perhaps it will show I’m too pessimistic. Your code allows me to choose a calibration point less than your recommendation. I’ll experiment and and see what I can learn.
Maybe someday someone to rework the $6 USB accelerometer board with a decent AD
converter. Spool scales, real time belt tension, and ?
We’ll see about more advanced calibration types. I could see multi-point and thermally compensated zero being a thing. Maybe if someone puts a filament scale inside a heated dry box. But we need the application to show up that actually has that need.
For the toolhead stuff, I think you will be disappointed with how much noise there is. Also just how much force the Bowden tube imparts to the toolhead based on x/y position. It’s never going to be a very precise scale. But it is “good enough” to do probing and probably good enough to do things like jam detection. (Although no one has actually done this publicly yet)
I know I’m getting a reputation as a troll so I tried to let it go… but them’s fightin words.
First off the word “exact” should never appear in a discussion of metrology. The only measurement that is ever exact is a count of objects (4 apples or 23,456,321 electrons). Distance, force, mass cannot ever be exact.
Examining the goal implied by the title of this thread the goal is to measure the POSITION at witch a nozzle contacts a bed utilizing a strain gage (or 2 or 4) bonded to the surface of an object positioned such that it deflects at POSITIONS beyond contact.
What does a strain gage measure? It measures a change in length. It does not measure force. A transfer function is used to convert change in length of an object to estimate (but NOT EXACTLY) force.
Hold on that transfer function has a couple coefficients that are estimates. Also the specimen to which the strain gage is bonded is effected by temperature, work hardening, prior excursions that resulted in plastic deformation. Oh well we need to know the force so we’ll use the inexact output from the strain → force transfer function.
Wait, the goal is to find a POSITION why do we give a damn about force.
How about we focus on the first detectable change in length of the strain gage and UNDERSTAND that is the closest point to our target as the hardware will allow.
Still not exact.
Most engineering tasks, including setting up and running a 3D printer, operate on the principle of achieving sufficient precision and repeatability for the task at hand, rather than absolute theoretical exactness.
Dwelling on the philosophical distinction between measurement and counting, or the precise nature of the transfer function, doesn’t seem to add anything useful. Your theoretical insights into the impossibility of “exactness” and similar wisdom may become counterproductive in this practical application context.
I didn’t bring up exactneess
Another engineering principle is take the simplest route that achieves
Strain > Force > position VS strain > position. Which is most accurate repeatable?
To be clear I’m not against attempts to automate finding good values for things like the low filter cutoff frequency and the pullback distance. But so far they would seem to need to be tests at several points over the bed surface. That would have to be user input, or it would have to be the result of a detailed “scan” of the bed to look for squishy spots and extreme bowden tube forces.
Kevin asked if we could remove support for this being a true “endstop” and limit it to being a probe to make future homing changes easier to do. There is a long discussion about whats going to happen in the PR. Part of that will be the loss of support for QUERY_ENDSTOPS and QUERY_PROBE. This would be replaced with an interactive tool where you apply a force to the nozzle and it would log “tap” detection to the console. Prusa has something similar as a commissioning check when you first set up one of their toolheads. It’s something that users have complained about because “tap the nozzle” is a vague enough instruction that people will do all kinds of different things (E.g. this reddit thread). At least the test is low stakes because the toolhead wont be moving and you can try as many times as you like with different force & speed. You try until it triggers or you satisfy yourself that it wont.
But this is where my intuition comes from that getting the user to tap the nozzle is not a repeatable input. I’ve experienced this with my XL. Humans are squishy, at least I am. The pads of my fingers as squishy. Its hard to simulate the collision between two rigid objects when you replace one of them with a gel. You can do it, it just might be faster / more forceful that you might expect. Using that as the basis for a calibration seems very iffy. Using it as a coarse gut check is much better than no check at all.
