Motor stall detection as Z probe
-
M80 ;PSU ON
; Homing file for RepRapFirmware on Large Kossel
; Sensorless Homing test file for RepRapFirmware on Kossel
M915 X Y Z S2 F1 R0 ;set stall detect drives, S-threshold (-64 to 63), F1 filtered, R-log only
M400 ; make sure everything has stopped before we make changes
M574 X2 Y2 Z2 S3 ; set endstops to use motor stall
M913 X30 Y30 Z30 ; reduce motor current to 50% to prevent belts slipping
G91 ; use relative positioning
G1 S1 X700 Y700 Z700 F2000 ; move all carriages up 700mm, stopping at the endstops
G1 Z-5 F2000 ; down a few mm so that we can centre the head
G90 ; back to absolute positioning
M400 ; make sure everything has stopped before we reset the motor currents
M913 X100 Y100 Z100 ; motor currents back to normal
G1 X0 Y0 F2000 ; centre the head and set a reasonable feed rate
M574 X2 Y2 Z2 S1 ; set endstops back to normal so that homedelta.g worksYou just need to experiment with M915 R to get the threshold right.
-
I like experimenting and would like to give this a go. I am building a corexy, with 3200steps/mm on Z with1/16th microstepping. I could also go for a 0.9 stepper motor and get 6400 steps/mm at 1/16th or 3200 at 1/8th, or 1600 at 1/4 and so on.
With a 1.8 stepper, accuracy would be 0.005
With a 0.9 stepper, accuracy would be 0.0025What would be the best choice?
-
Well for Z positional accuracy at 10 microns would be fairly good, 5 microns even better, 2.5 microns is probably excessive, but then I cannot see a reason to choose 1.8 deg motor for Z, it never has to move fast.
-
How about steps/mm with a 0.9degree. Is 6400 doable for the duet or should I then use 1/8th microstepping, or does this have no effect at all? And then, are there any downsides to 1/8th microstepping?
-
6400 steps/mm is doable and given the very small amount of movement required in z it won't overly tax the processor. However in terms of stall detect only full steps count so 0.9 degree is preferable.
1/8th is noisier. But try it, its very interesting to see the differences in noise, speed and (if you look really hard) print quality between different microstepping modes.
-
Cool, thanks!
-
Hi @dc42!
I have been able to successfully autohome X, Y and Z using sensorless homing (I am working with a coreXY).
Currently I am experimenting with manual bed levelling assistant using StallGuard but I don't know how to correctly input StallGuard parameters into probing. My code is as shown below. Am I missing something?
config.g file
...
M671 X111:11:211 Y14.2:194:193 P0.7
...
M558 P10 X0 Y0 Z0
...bed.g file
G28
M915 Z H200 S3 F0 R1
G30 P0 X111 Y14.2 Z-99999
G30 P1 X11 Y194 Z-99999
G30 P2 X211 Y193 Z-99999 S3I have uploaded firmware 2.0 beta 2
-
That looks correct to me, although you may need to adjust the probing speed (F parameter in M558) and you may also wish to adjust the travel speed between probe points (T parameter).
Getting the Z motors to stall without applying excessive force to the nozzle will be a delicate balance. You will probably need to use M913 to reduce the Z motor current temporarily.
-
Thank you @dc42
The manual bed levelling assistant is working smoothly now! Great stuff!
We are looking onto the possibility of implementing fully automated bed levelling using 5V servomotors. Is it possible to connect them to the original duet wifi board. If so, where should we connect them?
Thanks, good job
-
If the servomotors have stepper motor style step/dir/enable inputs then you can connect them to the expansion connector.
-
I have tested the feature on 2.0(RTOS)beta2 and it works.
I have a Cartesian printer with dual Z axis connected in Serial. The problem is that the Force of the nozzle when it hits the bed overshoots a little bit the bed due to the springs and that makes unfeasible for mesh bed leveling.However, an excellent finding is that G30 executed on the same X,Y coordinates gives exactly the same result. As a test I run G30 S-1 20 times and I got the same result all 20 times on the same spot with 0 standard deviation!. I think that the overshoot is to the next "full step" and this is allowing a very good accuracy.
Basically is an excellent Z-min switch that does not require calibration and takes into account thermal expansions.
I have made a small script to use Z stall before G30 and change back to NPN capacitive probe for bed leveling. The results are excellent, I do not have to worry about the Z offset of the probe because it is only used to level a plane and the repeat ability of the Stall always on the same spot is extremely repetitive. First layer always perfect.
My script in case that someone is interested.
;find_zero_and_level.g G90 ;absolute positioning G1 X110 Y105 Z10 F4000 ; Always probe on the same spot M558 P10 X0 Y0 Z0 H2 F600 T5000 ; Enable Stall Z probe G31 X0 Y0 Z-0.77 P200 ; Set Z probe trigger value, offset and trigger offset (overshoot due to springs) M574 Z1 S3 ; set Z-min to use motor StallGuard M913 Z20 ; reduce motor current to 20% M201 Z30 ; Reduce acceleration mm/s2 M915 Z S-2.9 F0 R0 ; Set StallGuard sensitivity for endstop homing G30; Find the bed Z=0 reference G1 Z2 G30 S-1 ; do a couple of repeteability tests G1 Z2 G30 S-1 ; G1 Z2 G30 S-1 ; G1 Z2 G30 S-1 ; M913 X100 ; restore current to 100% M201 Z300 ; Restore acceleration ; Revert back to Capacitive Z probe NPN M558 P4 X0 Y0 Z0 H3 I1 F300 T5000 G31 X23.5 Y5 Z1.04 P200 ; Set Z probe trigger value, offset and trigger height. G29 S2 ; Clear any bed leveling compensation G29 S0 ; Run probing sequence defined by M557 on the config.g M374 ; Save calibration data in sys/heightmap.csvI have added M98 P/sys/find_zero_and_level.g on the start G-Code script on the slicer and the results are more than satisfactory for me.
-
So, I had motor stall configured beautifully as z probe with 30% motor current. I tested with a macro, and when it was working nicely I put the parameters in config.g and homez.g.
After that, I couldn't get it working as beautifully again. My best guess is the motor was getting warm and that was affecting sensitivity. Is that possible?
Another thing. I read higher homing speeds work better. I am now at 380mm/min. If I go faster the motor really starts screeching/whining (3200 steps/mm). Is that a bad thing? Should I try 1/8th microstepping and 1600 steps/mm and then increase homing speed?
-
I never expected it to be possible to use motor stall for Z homing on a Cartesian or CoreXY printer, and I am surprised that several Duet users have got it working. If you have a Z probe (as most 3D printers do), that is the obvious device to use for Z homing.
If you do want to use stall detect Z homing, here are some tips:
-
Stall detection gives false reports at low speeds, so there is a cut-off speed below which stall detection is disabled. The default is 200 full steps per revolution although you can change it. So your homing speed needs to correspond to at least this value. Changing microstepping won't help.
-
The stall must occur without applying excessive force between the nozzle and the bed. That is why reducing motor current during homing is recommended.
-
When the motors are hot, the voltage drop due to resistance increases. This voltage drop is in phase with the motor current, making it indistinguishable from the back emf when approaching the motor stall. So the stall detection threshold will need to be higher when the motors are hot.
-
-
I was thinking of stall detection to calibrate z probe offset (G31 Z value). Is it possible to do that. I would continue to probe using my inductive sensor.
-
@dc42 I've just been trying to configure stall detection Z probing and I'm having a bit of an issue getting it to behave along side the BLTouch.
Even after defining the probe type to 10 in the macro to test zstall, the BLTouch pin still gets deployed and retracted on every G30. It doesn't seem to be effecting the probe because the nozzle still goes down to touch the bed.
Here's a video to show what I mean.
And here is the macro I'm using to test with. It's slightly modified from the one @carlosspr posted above.
; 2_ZStallProbe.g ; ; Uses the Z axis StallGuard detection as a Z-Probe ; M291 P"Are you sure you want to proceed?" R"StallGuard Z-Probe" S3 G28 G90 ; absolute positioning G1 X150 Y150 Z3 F4000 ; Always probe on the same spot M558 P10 X0 Y0 Z1 H3 F200 T6000 A10 R0.1 S0.005 ; Enable Stall Z probe G31 X0 Y0 Z0 P200 ; Set Z probe trigger value, offset and trigger offset (overshoot due to springs) M574 Z1 S3 ; set Z-min to use motor StallGuard M913 Z40 ; reduce motor current to 20% M201 Z30 ; Reduce acceleration mm/s2 M915 Z S5 F0 R0 ; Set StallGuard sensitivity for endstop homing M291 P"StallGuard Z-Probe Settings Loaded. Proceed with Probe?" R"Yes or No?" S3 G30 S-1 ; Find the bed Z=0 reference G1 Z3 G30 S-1 ; do a couple of repeatability tests G1 Z3 G30 S-1 G1 Z3 G30 S-1 G1 Z3 G30 S-1 G1 Z3 G30 S-1 ; Find the bed Z=0 reference G1 Z3 G30 S-1 ; do a couple of repeatability tests G1 Z3 G30 S-1 G1 Z3 G30 S-1 G1 Z3 G30 S-1 G1 Z3 M291 P"Probing complete. Restoring settings." S3 M913 X100 ; restore current to 100% M201 Z300 ; Restore acceleration M915 Z S64 F1 R0 ; Set StallGuard sensitivity for normal movement M574 Z1 S2 ; Use zprobe and home to Z Min. M558 P9 X0 Y0 Z1 H3 F100 T6000 A10 R0.5 S0.005 ; P9 for BLTouch, dive height 3mm, probe at 100mm/s, travel 6000mm/s, up to 10 probes, pause 0.5s G31 X-41.8 Y32.2 Z2.3 P25 ; probe offset from nozzle, p is trigger value, set low for bltouch, set Z=0 for testingOne other issue I'm having is that I don't use stall detection during normal operation. Is there a way to completely disable stall detection again at the end of the macro? I've tried to set it to the highest detection threshold but it still sometimes seems to stall even after reseting all the values. At least I think I am.
Even so, this method of z probing seems to provide good repeatability. The results of running the macro above give me
Versus the BLTouch results
I think with further tuning it could become more accurate. I am also going to try switching from a 1.8 degree motor to a 0.9 which will double my steps per mm from 3200 to 6400.
Thanks in advance.
-
-
Currently the firmwas only supports a single pair of deployprobe.g and retractprobe.g macros, which are used whatever type of Z probe is used. I could make type 10 a special case that doesn't run those macros, but perhaps it would be better to provide an option to specialise the macros according to Z probe type. For example, deployprobe9.g and retractprobe9.g would be used only when the Z probe type is 9.
-
You shouldn't need to disable stall detection, just use parameter R0 in your M915 command.
-
-
I figured that was the case. I had assumed that it would be a little easier to use multiple probe types at the same time. I thought that maybe using M558 P9 Z0 might disable the BLTouch completely, but then realized that it was just calling the deploy and retract macros.
Is there a reason for stall detection probing to use those macros at all, other than consistency with the other probe types? Having the option to use dedicated deploy and retract macros for each type would add flexibility but also complexity.
Further to this, would it be possible to use a G1 S1 move in the homing file to trigger the stall detection endstop rather than a G30 probe command? Would that prevent the deploy retract macros from being called? I suppose that wouldn't actually help during a mesh bed compensation run.
At any rate, my test was successful enough that I went ahead and tested stall detection as the sole Z endstop and commented out the servo commands for the BLTouch from the deploy and retract and that worked fine.
I just realized going over my macro with fresh eyes that I made an error in the settings restore section. I restored the current of the X axis instead of the Z axis. So it wasn't stall detection causing the stalls at all.
If the 0.9 motor can get me better accuracy and repeatability I think I may adandon the BLTouch entirely as getting rid of the XY offset between nozzle and probe will let me probe my entire bed for mesh compensation.
-
@phaedrux said in Motor stall detection as Z probe:
Is there a reason for stall detection probing to use those macros at all, other than consistency with the other probe types? Having the option to use dedicated deploy and retract macros for each type would add flexibility but also complexity.
If I make Z probe type 10 a special case, sooner or later someone will find a good reason why they need to run deploy/retract macros, for example to change motor currents or stall detect parameters. Also it wouldn't address the general case of wanting to use two different types of Z probe.
Further to this, would it be possible to use a G1 S1 move in the homing file to trigger the stall detection endstop rather than a G30 probe command? Would that prevent the deploy retract macros from being called? I suppose that wouldn't actually help during a mesh bed compensation run.
You can home Z that way, but not perform mesh bed compensation or bed levelling using independently-driven leadscrews.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 Yes of course. I realize now that having the motor current and acceleration changes in the deploy and retract macros makes a lot of sense and is the only way to automatically configure the stall detection probing for all G30 calls.
-
After some more tuning I have stall detection z probing working rather well. Probing was nearly as consistent as the BLTouch.
The only thing keeping me from using it full time is that due to the springs of my bed the edge of the bed will deflect more the farther away it is from a spring.
I think I will need to use a 0.9 degree motor to make it more sensitive. I'm waiting for some new pulleys but when they arrive I will install them along with the 0.9 motor and report back.
