Autocalibration probe radius and endstop signal duration
-
I have some under-bed piezo sensors, connected via logic running on a Teensy, serving as my E0 endstop. This seems to work very reliably. If I tap the bed, the web interface shows that the endstop is activated, 100% of the time. False negatives never seem to be an issue, though the motors can cause a false positive when they first turn on, but are ok after that I think, though perhaps direction changes cause more EMI?
Anyway, when I go to run the autocalibration routine two problems occur:
-
It is probing too far from the center and can slip off the bed. Even if I reduce my printable radius in config.g, that doesn't seem to affect the probing points in bed.g. It seems like the desired behavior would be not to probe outside of the printable radius. Am I doing something wrong?
-
It repeatedly says: "Error: Z probe already triggered at start of probing move".
Perhaps this has to do with how long I am sending the endstop signal for? I currently have the Teensy sampling 20 times over 20ms to make sure the signal isn't noise, and then if the signal is legitimate, it sends a digital HIGH for 50ms (arbitrary – I have tried various values, and will try shorter ones now, but I started with longer ones to make sure I could see the activation on the web interface). 50ms seems like a short time to me, but perhaps the Duet expects the signal to disappear faster than that?
If the 50ms signal shouldn't be a problem, then I am wondering if the motors changing direction are making burst of EMI that are triggering false positives. I can raise the threshold for a real signal, but that could be harder to deal with so I'd like to find out first if it's just a timing issue.
-
-
I've played with this some more, physically damping the system with sorbothane to make sure there aren't actual oscillations causing false positives. That doesn't appear to be the problem. It's something about the nozzle movement that I don't understand. Despite there being 9 points in bed.g, it strikes the bed a lot more than 9 times (does it sample each spot multiple times?), sort of wood-peckering a spot, moving on, doing the same thing, and then getting those errors and starting to waive around in the air maybe an inch above the bed.
I'm stumped. I've tried signal times from the Teensy ranging from 2ms to 100ms+, I've tried adding debounce logic and delays (even though with the sorbothane it is largely necessary), and I've tried adjusting the number of points collected from the sensors, and the average and max values that cause endstop activation. Of course I could just raise the thresholds even higher, but the way the nozzle is moving and the generation of false positives during the process doesn't make sense – essentially turning down the sensitivity doesn't seem like the answer.
-
Here is a video of the entire autocalibration run, until it gives up. The behavior is the same no matter what parameters I choose.
https://www.youtube.com/watch?v=L1L3FlEsBXE&feature=youtu.be
-
Is there any way to make the nozzle not slow down as it probes? Hitting too slowly is a problem for piezos.
-
The points it probes in order to auto calibrate a delta are whatever you put in bed.g. You can put whatever points you any in there, but they should cover all areas of the bed especially near the periphery. You can use either the configuration tool at reprapfirmware.org or the wizard at Escher3D.com to generate the bed.g file if you want.
Each point is only probed once.
The probe output is sampled every 2ms in firmware prior to 1.18 and every 1ms in firmware 1.18 (except probe type 2 is still in effect every 2ms). With a digital output probe, each reading contributes a value of 125 towards the sum which has to exceed the G31 P parameter. So with P100, a single sample will be sufficient to count as triggered. With P900, there will need to be 8 samples to register as triggered. So even in this case, a trigger pulse just over 8ms long would be sufficient with firmware 1.18.
Probing slows down when the accumulator reaches 90% of the threshold set in G31. So it will not normally slow down when using a digital probe.
HTH David
-
Thanks for the information. What do you mean that probing will not normally slow down with a digital probe? I thought it went slowly starting at the M558 H value. When I set it to H30, even with a digital probe, it moved really slowly for a long time (presumably 3cm).
Can you explain how the M558 H parameter works exactly? For example, using the default of H3, that means "probing" starts 3mm above where it thinks the bed is. But, what exactly is "probing"? Does that just mean that the nozzle moves slowly (at least for some probe types)? Or is it a logical state that says "OK, now I'm looking for the bed (whereas beyond 3mm I was not)."
I ask because, in the second case, if you use H3, but the bed is 4mm higher than expected, the nozzle hits the bed before it is "probing." If that hit doesn't count because "probing" wasn't active yet, that's a problem. I don't care how fast the nozzle hits the bed – I can control that via M203, I just want to be sure I understand what counts as a hit.
Also, if the probe slowing down once it is within the H value is part of the routine (although perhaps it is not for a digital probe, as implied above), is it possible to avoid this behavior with, e.g., H0 or some other trick?
If slow nozzle speed in Z is intrinsically tied to probing and there is no work around, I would ask that a feature be added to give control over the probing speed.
-
With a digital output probe, each reading contributes a value of 125 towards the sum which has to exceed the G31 P parameter.
David
What happens if the reading indicates the probe is no longer "active" - do you subtract 125 or reset the sum to zero?
Thanks.
Frederick
-
I second Frederick's question lol. But either way if it's happening every 1-2ms, it's probably not the issue since it would quickly be 0.
-
Probing starts by moving the nozzle to the dive height (M558 H parameter) plus trigger height unless it is negative. Then there is a pause as specified by the M558 R parameter to allow the probe to settle. The nozzle is then moved down at the speed given by the M558 F parameter. The probe output is sampled every 1ms and a running average of the last 8 output values is maintained. For a digital-output probe, the output value is taken as 1000 when triggered and 0 when not triggered.
When average reaches or exceeds 90% of the threshold given in the G31 P parameter, the probing speed is reduced by two thirds. When it reaches or exceeds 100%, probing stops and a hit is recorded.
If the probe is already triggered at the start of a probing move when the pause ends, this counts as a failure. If the probe has not been triggered after moving the probe down by twice the dive height, that also counts as a failure.
HTH David
-
Awesome, thanks. Sounds like I can increase dive speed with M558 F, and inscrease the pause with M558 R. That should allow me to figure out what is going on.
-
This seems to work better now, with increased dive speed and a 1 second delay between probe attempts.
However, at the very beginning, the nozzle comes straight down to the center of the plate (which is not the first point specified), hits the plate, and grinds across it towards the edge. The hit sensors are triggering during this time (between 30 and 35 times as the nozzle scrapes/skips across the plate), but the nozzle essentially never leaves the plate (it might come up slightly – hard to see and hard to tell what is vibration versus planned movement -- but certainly doesn't come up to my setting of H20 between strikes). Only after that does it seem like the "real" autocalibration begins (but by this time I don't think it actually knows where the nozzle is -- perhaps grinding it into the plate causes the motors to skip steps).
Any idea what this first odd phase is?
====== bed.g ======
; Auto calibration routine for delta printers
; Before running this, you should have set up your zprobe Z offset to suit your build, in the G31 command in config.g.M561 ; clear any bed transform, otherwise homing may be at the wrong height
G31 X0 Y0 P100 ; don't want any probe offset for this, P is probe activation threshold, should not matter for digital, which should always count as 1000 when "on" but this lowering because web control panel does not always show 1000
G28 ; home the printer; Reduce the motor current for bed leveling in case the tip crashes into the bed
; Normally current is 1000, presumably will revert to main config.g value when done
M906 X600 Y600 Z600 I60 ; Set motor currents (mA, 1000 is default), Idle = I60 is default; Change the default M558 dive height (H, mm), dive speed (F, mm/min),
; pause between probes (R in secs, default 0), and T, travel speed between points (mm/min)
M558 H20 F1200 R1 T1200; Probe the bed
; Changed from original, just using a square for testing
; To generate circular parameters see http://escher3d.com/pages/wizards/wizardbed.php
; setting H to small negative value since in theory a piezo needs to move to signal
G30 P0 X-50 Y-50 H-0.2 Z-9999 ; upper left
G30 P1 X0 Y-50 H-0.2 Z-9999 ; upper middle
G30 P2 X50 Y-50 H-0.2 Z-9999 ; upper right
G30 P3 X-50 Y0 H-0.2 Z-9999 ; middle left
G30 P4 X0 Y0 H-0.2 Z-9999 ; middle middle
G30 P5 X50 Y0 H-0.2 Z-9999 ; middle right
G30 P6 X-50 Y50 H-0.2 Z-9999 ; bottom left
G30 P7 X0 Y50 H-0.2 Z-9999 ; bottom middle
G30 P8 X50 Y50 H-0.2 Z-9999 ; bottom right; Note S7 includes diagonal rod length but requires oversize bed. See:
; https://duet3d.com/wiki/Configuring_RepRapFirmware_for_a_Delta_printer
G30 P9 X0 Y0 Z-99999 S6 ; center, and auto-calibrate 6 factorsG1 X0 Y0 Z150 F15000 ; get the head out of the way of the bed
-
It sounds to me that some of the M665 or M666 parameters in config.g are a very long way off the correct value. It's probably the M665 H parameter. With the carriages up against the endstops, measure how high the nozzle tip is from the bed, and compare that with what you have H set to.
-
M665 H is within a millimeter of exact. I think I have M92 set incorrectly so that it is not moving the distance it thinks. Using 0.9 degree motors = 400 steps per revolution x 16X microstepping / 36mm per revolution (for 18 teeth) = 177.78 steps/rev, meaning that M92 should be:
M92 X177.78 Y177.78 Z177.78
Is that correct? I assume you have to account for microstepping per the sample calculations I see, although it seems like it would be simpler to always enter M92 by whole step and allow microstepping to be calculated from that.
-
That fixed it– I had use the wrong number of teeth in my calculation for M92. Uggghhh.
Anyway, this is what I get now:
"Calibrated 6 factors using 10 points, deviation before 7.591 after 1.077"
Running again, I got:
"Calibrated 6 factors using 10 points, deviation before 2.104 after 0.941"
Is that flat enough? If that's mm, seems like it might be too much error.
-
16 tooth pulleys with GT2 belts and 0.9deg motors works out as 200 steps/mm, so your figure of 177.78 looks about right for 18 tooth.
I agree, it would be more logical to enter mm per whole step or vice versa, but 3D printing has used microsteps/mm for too long to change it now. At least RRF adjusts the steps/mm automatically when you change microstepping.
-
How high a deviation after calibration is acceptable? Can you also then use bed mapping (I assume that autocalibration figures out the geometry, while bed mapping assumes the geometry is correct and corrects for bed deviations)?
-
High deviation errors are caused by geometrical errors in your build, which will cause print distortions. So the deviation you can accept depends on how accurate you need your prints to be. I used to have around 100um deviation, but after the rebuild it is down to 20um.
You can use mesh bed compensation after auto calibration.
-
20um?!? Sh*t. Well, I just ordered a larger caliper and a digital protractor. I'm guessing that play in the rod ends is important too at this level. I need to change those. Hopefully in a few days I'll get the error down. Thanks!
