Motor stall detection as Z probe

DjDemonD

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.

bartolomeus

Cool, thanks!

Francisco3D

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 S3

I have uploaded firmware 2.0 beta 2

dc42

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.

Francisco3D

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

dc42

If the servomotors have stepper motor style step/dir/enable inputs then you can connect them to the expansion connector.

carlosspr

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.csv

I 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.

bartolomeus

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?

dc42

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.

Bravojul

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.

Phaedrux

@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 testing

One 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

0_1528847598095_4ed95191-83d0-490a-a82e-0269728b607e-image.png

Versus the BLTouch results

0_1528847656139_75c440ce-1eb4-4662-a660-721d0cff98d9-image.png

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.

dc42

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.

Phaedrux

@dc42

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.

dc42

@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.

Phaedrux

@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.

Phaedrux

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.

Mugga

For me the probing is really inconsistent. Sometimes the hotend touches the bed and sometimes it stops before. Any tips to get it more reliable? I played with the stallguard sensitivity and motor current.

Phaedrux

@mugga I found that setting z jerk and acceleration really low helped reduce false triggers.

Lower the current as low as it will go without it skipping steps on normal travel And then just a little bit more.

Then experiment with trigger sensitivity and probing speed. Too low of a speed won't work well. I found that the sensitivity would change a bit based on motor temp.

I found the quickest way to test was to put your probing configuration values into deployprobe.g and then return to normal values with retractprobe.g

Mugga

Thx, for the tips.
I got it a little bit better, but 2 of 10 times its stopping right after the first move. The other 8 times it measures correctly, but still "crashes" a little bit into the bed so that the springs compress a little bit.

I got a cartesian printer. Maybe this is because I got 2 z-axis motors hooked up to the z-axis driver.

Phaedrux

@mugga Yeah I believe it will work best with only a single motor. I doubt you will be able to get it much better than you have with 2.