The question is, how to you characterise the sensor? You need a known, controlled input signal to do so. How do you apply this? You could maybe use the bed as an actuator applying a force to the nozzle (and hence the sensor) by moving the z axis. This will include some effects caused by the actuator chain though (e.g. delay between motor movement command and actual movement). I am not sure, but maybe that can even be a wanted effect, since these effects will play a role in the actual homing movement as wellā¦
1 Like
Yep. In short we need a way to:
- Collect data: force graphs from real probing collisions.
- Compute the sensors characteristics from those graphs
- Load the computed values into the sensor
- Test that the computed characteristics work using the same data collection routine
- That they result in 100% endstop success
- That they result in accuracy/repeatability
For #1 and #3 we could run a routine that just moves the tool head a set distance repeatedly into the bed. Maybe we ask the user to start this by positioning the nozzle 1 sheet of paper above the bed. This is āBed as Actuatorā as you imagined it.
In phase #3 we load up our computed values for the filter, hysteresis etc. I can have the C code report back if and when it would have triggered the endstop as a special ātest resultā signal. Then we check that it always triggers the endstop when we think it should have based on the analysis of the force graphs.
Jumping straight to āmake the endstop workā was my first mistake. It should have been ābuild a safe and effective data collection processā.
I wonder if one could use a simple āexponential moving averageā filter in the mcu. On a trigger, start the āslow pathā force analysis in the host code. If it turns out the trigger was due to noise, the code can restart the fast homing process.
Said another way, Iām not sure the initial homing has to be super accurate or super fast - it just canāt ābreak the printerā.
Good point.
-Kevin
I have been working with piezoelectric detectors for 3D printing for some time and may be able to put some useful input into this discussion. While there are differences between strain gauges and piezoelectric sensors, there are also similarities.
The first point is in regard to an observation made by Sineos in this thread back in Feb '22 regarding plastic on the nozzle. I have found that a piezoelectric sensor can in fact detect plastic on the nozzle and this is sensitive enough that the contact of a brass nozzle with a clean glass bed can be distinguished from the same contact on a glass bed with a visible fingerprint. I would think that strain gauges would be equally sensitive.
Any method using sensors under the bed is potentially problematic for a number of reasons: A transverse wave (up and down in the case of a 3D printer bed) moves quite slowly and the signal reaching a more distant sensor will indicate a later contact than if the sensor is near the nozzle contact. Additionally, any combination of sensors can have local cancellation at some points on the bed. Further problems arise if there are even relatively small differences in the sensitivity of multiple sensors, particularly outside the triangle - assuming three sensors.
I have not yet settled on a method of leveling and mesh compensation, but am leaning towards a single underbed sensor with a nozzle probing directly above the sensor to set height, with a separate touch sensor for mesh probing the bed surface.
Regarding the signal treatment, I use the exponential moving average as suggested by koconnor and this is reliable and uses few mcu cycles Two probes, Underbed for Z height and Z carriage mounted probe for leveling
Mike
1 Like
The implementation that I was working on uses an Exponential Moving Average filter in the MCU: klipper/load_cell_endstop.c at adc-endstop Ā· garethky/klipper Ā· GitHub
So we are all in violent agreement there. This was mainly focused on attenuating high frequency noise at a very high sample rate.
The Butterworth filter in the Prusa implementation is interesting because it is set up as a High Pass filter at 5Hz, meaning it blocks low frequency noise below that. Their lower sample rate is, in effect, a high frequency filter. So I think they didnāt want to loose any of the high frequency components of the signal. I guess (guess!) they ran an FFT over the samples and identified low frequency noise as the main source of false readings. The Butterworth filter leaves the high frequency signals intact. It has similar delay characteristics to the EMA filter and doesnāt look any worse in terms of runtime cost.
I think we should implement them both and have a bake off. Maybe its best to do them in Python first and perform the data analysis there before we commit to a C implementation.
1 Like
My project has been glacially slow lately so I have been going through my notes to try to remember some details.
The following is for my piezo sensors, but I believe would also apply to strain gauge sensors.
The first part of the program simply detected the point at which the sensor output rose above a trigger level to declare that the nozzle had made contact with the bed. The program would then process a batch of samples after the contact point to determine if the standard for a good contact had been met: A good contact being one with a sharp knee and a linear rise.
A rounded knee likely indicated gunk on the nozzle while mechanical or electrical noise would affect the linearity of the post-contact data. A rate of rise that is outside of the expected value would typically indicate a dynamic effect such as reflections of the initial nozzle contact from other parts of the bed.
Mike
1 Like
Iāve been thinking about tackling this Z-strain-gauge thing as my first Klipper hacking project. Glad to see people already working on it. Having a DSP & statistics background, I had a different idea for doing the detection I wanted to throw out there, based on statistics.
For the strain gauge, youāre trying to measure when the force jumps suddenly as you move the bed towards the nozzle, but you donāt know the initial conditions or noise. What you can do is sample the measured force during the initial rise before it could possibly touch the plate, use those samples to produce a mean and standard deviation. Then as the bed keeps moving, you stop the with the first measurement (or when two sequential measurements) exceed 5+ standard deviations above the mean (the specific values can be tweaked).
The advantage to this idea is that you can make the detection on a single sample (or two), whereas an EMA or any other MA will have a lag. Also, I think this is just overall simpler. Thereās a few tweaks that could be made to the idea to address corner cases.
BUT, I havenāt tried it (I havenāt even bought the strain gauge yet). So I could be oversimplifying the problem. Also, you guys might already feel like you have a solution. I just wanted to throw it out there in case it was useful, and I might try it myself at some point.
1 Like
Can I ask in a genuine sense of inquiry: Why load cell/strain gauges? What advantages do these have over other methods of detecting nozzle position or acquiring data for bed meshing?
Mike
Direct nozzle contact probing has the potential to be more accurate than all forms of non-contact probing. It should also outperform direct contact probing that requires post contact travel or have an x/y offset to the contact point (Voron Tap, Switch bases probes). It should end up being easier to use because no z-offset calibration is required, there is nothing to ādial inā. Indeed this is what we are seeing with the MK4 printers now in the wild. The system is robust to imperfect printer motion systems:
(yes thatās a print on cardboard, not mine, see link)
Beyond that, strain gauges have the potential to do more than z-probing. We should also be able to probe the x/y location of the nozzle for multi-tool printer alignment. And we should be able to do jam detection, detect if the nozzle collides with the print and sense if the print has moved and we are printing a spaghetti monster.
There might be faster or less complex probes, but there wont be a more accurate, versatile and easy to use probe.
Thank you garethky, perhaps I should clarify why I am asking. I have been investigating a number of different and unusual ways of bed leveling since I built my first RepRap printer back in 2011. I have found that most can be made to work in an acceptable way, but few without any disadvantages.
The only ones I have found no good reason for are accelerometer sensors and FSRs (force-sensitive resistors) and I may change my mind about these - I am not religious about them.
We would love to work with someone with a DSP backgound on this!
I think what we are all struck by is that we need to come up with those values for some arbitrary sensor+printer combo with zero prior knowledge about that system. Maybe we can ask for the conversion from sensor counts to grams but thatās probably it. Specifically I think we need:
- A trigger threshold that doesnāt break the printers motion system or toolhead, we want to aim low.
- Some number of samples to perform continuous tearing over
Maybe we take samples while the system is motionless. Then take samples with the toolhead (or bed) moving up and down so we can see how much drift occurs. From that we work out what a tear value should be. Perhaps thatās also where we work out the low frequency noise filter.
Then we tap the build plate with progressively longer Z movements until we exceed the threshold (or hit some safety cutoff). Then we can use the data from the collisions to fine-tune the threshold.
Agreed. EMA is doing double duty as both a continuous tearing function and a noise filter. Pruse split those functions up which I think is a good insight into the problem.
My proposal has excellent generalizability, because it assumes nothing about the sensor sensitivity, noise, machine vibrations etc. If you lower the bed a few mm before starting, then you have a few mm to collect sensor samples and approximate the distribution of sensor values for z-bed-is-moving-with-no-collision. This should be extremely reliable because whatever noise we will have during the bed collision (z-motor vibrations, aggressive hotend fan, etc), will also be present during the sampling period.
From that you can compute, say a 6-sigma detection threshold for which thereās only a 0.000000002% chance of a false positive (in theory). It might still be best to use two consecutive samples to cram more zeros in there and accommodate the difference between theory and practice. If we do have any reference for absolute force from the sensor, we could use it to set some kind of backup value.
Two questions:
-
Do we have any data from load-sensor detection cycles? Iād love to get some data into python environment to play with it.
-
It would be fun to get a couple strain gauges and modify one of my printers to start experimenting. Is there an existing strain-gauge-printhead model somewhere I could use or at least reference for creating my own? I would guess that 5kg is probably the correct load rating for the sensor. I have a RatRig V-Core-3 with an EVA3 printhead, if that helps.
How are you considering mounting the strain gauge or gauges? Specifically, what is the path of the force from the nozzle to the sensor?
I ask this because I have been looking at the dynamics of underbed sensors and I have found that there are many unexpected behaviors from multiple causes.
Mike
I was asking about existing printhead models because I actually have no idea. I can theorize a few ideas, but Iād like to see what has already been done and probably follow that.
What did you find out about using underbed sensors? I was also considering that idea especially at first, because it is far less disruptive than replacing my printhead. Especially because my RatRig printer has a bed that simply sits on the bed arms, it would be easy to modify.
I donāt have any data stored anywhere. Iām going to update my branch of klipper to remove the EMA stuff and implement a basic tare and threshold system. So you could tare the sensor from Python and then run a probe with a fixed threshold that you also compute in Python. If the raw sensor value deviates +/- the threshold from the tare value it will trigger. I also need to attach my code for data collection and visualization. Then I can collect some data for you, probably using a macro and MANUAL_PROBE.
I donāt think I can even get started on this for another couple of weeks. But I recognize that with the MK4 out people are getting excited about this topic and want to make progress.
Not that I know of 
. I started a separate thread to try and get something going but its gone nowhere. For testing I just put a 5Kg beam load cell on a mount on my bed and hit the nozzle with it.
This is a chicken and egg problem. Someone is going to take the Nextruder and try to graft it onto a Voron (I saw Nero suggest this on a live stream). I assume that will be the first thing that people want fully supported.
I am not saying that underbed sensors can not be used, but that there are a number of pitfalls that are not at all intuitive.
Taking a simple case of three microswitches under the bed of the printer. For the sake of argument we will say that each of these switches operates consistently with a force of 10 grams and 100 microns of movement.
Probing with the nozzle directly above any of the switches will result in a force of 10 grams, but probing the center of the bed will result in 30 grams of force. Not only is there the flexing of the bed itself which did not occur when probing directly above the microswitch, but the upward forces from the nozzle are now three times as great and this will be transmitted through to the stepper motors, drive belts and frame itself.
A second case is piezoelectric sensors which give an output that is linearly proportional to the force but can also be negative as well as positive. If three sensors are connected in parallel then the voltage should be the same for any point on the bed. Note that I said āshouldā there. In the case of probing a corner furthest away from any sensor then one of the three will be in tension rather than compression and, if that sensor is more sensitive than the two acting as a fulcrum then the outputs could cancel out.
In a third case, transverse waves - perpendicular to the plane of the bed, are much slower than longitudinal waves. The wave generated by a nozzle strike can be reflected from the edge and create nodes of cancellation. This can be most clearly seen in the case of Chladni plates. where sand gathers at null points where there is no surface movement. Example at Weekend Projects: Visualizing Sound with a Chladni Plate - YouTube
It is this last case that bit me. A bit of history at Report on under bed sensor problems
Mike
1 Like
Very interesting read, thanks for that. You say above they are āmicroswitchesā but in the post you show 1D data which I guess is pressure in the piezo sensor (Iām actually not familiar with piezo sensors at all, so excuse my ignorance of how they work). Based on your post it seems like three things are working against you.
- The piezo sensors are kind of acting like microswitches instead of a continuous variable that can be processed more intelligently. And worse, they are potentially too sensitive and noisy.
- By being in the bed, you require more impactful contact than if you had it in the light printhead.
- One sensor in the printhead would have measurements mostly independent of XY probe position, vs the 3 sensor layout you have.
I would love to do the bed sensors, because itās just so much less disruptive to the overall design of the printer. But I feel like thereās more opportunity with a single printhead sensor, both in terms of getting reliable measurements, and the fact that it can double as a filament pushing sensor (though that will be a much-more-difficult signal to isolate).
I have some ideas for designing a simple bar-load-cell based printhead that achieves the goals. I donāt know when Iām going to find time to try itā¦ but I have a spare printer waiting to be used as a guinea pig.
Piezoelectric detectors have no similarity to microswitches; what I was trying to show in my last posting is that underbed sensing is potentially problematic.
Taking your three points in order.
-
Piezo sensors are inherently linear devices as long as the part you are measuring changes fairly quickly. The practical lower frequency of the piezo/conditioner circuit that I have been working with is 0.5 to 1 Hz. I cannot disagree with your point about them being too mechanicaly noisy.
-
No great impact is necessary or desirable. My typical values are 2mm per second nozzle contact speed and reliable detection at less than 3 grams of pressure and within 3 to 5 microns.
-
One sensor in the print head/effector is definitely preferable.
All of the above are eminently solvable except the last where I havenāt found a way to use piezo sensors reliably in the print head. At the moment I use a single underbed sensor for getting the Z reference position and a touch sensor for bed mapping.
Since I first saw this thread I have been buying several different types of foil strain gauges and downloading datasheets. It is not at this moment apparent how I can mount the sensors and it is possible that I will find the same problems as in mounting a piezo sensor.
Mike
btw, to explain piezo sensors, you could look at the first oscilloscope trace in this Piezoelectric disks for Z contact detect and bed levelling
I am happy to have a shot at modelling a strain gauge into a print head for a Rat Rig printer. I have done a bit of other design work on the EVA carriages used on the Rat Rigs including the Superlight print head.
I am keen to see some pics of where and how Prusa have mounted their strain gauge to start from a concept that we know works.
I am waiting for someone to post some pics somewhere. I havenāt looked but perhaps Prusa have already released the STL files?
best I can do is this render on the Prusa XL blog post:
You can see the ābarbellā shape cut into the aluminum frame below the gear? Thatās a beam load cell element.
Iāve tried to model something myself last night and Iām not happy about the āDesign for Manufactureā aspects of this solution:
Its in 2 parts to make accessing the screws in the hot end and the extruder possible. It requires machining from 3 sides of the load cell part which is expensive. The support bar on top has 2 threaded features. Itās width is controlled by the hot end, so I cant easily control the bending modulus that way. Iād like to see a single part solution with fewer machining steps/setups.
But maybe this is enough to get the creative juices flowing? OnShape Link
1 Like