Motor stall detection as Z probe

Mysta

@djdemond said in Motor stall detection as Z probe:

It works fine for endstops, but because it is not very accurate, and I can confirm this having an endstop-less delta running, you need to auto-calibrate after each homing or you will not have an accurate enough calibration to print. Not a particularly big problem, but it highlights that it won't work for most deltas as a z-probe. My cylinder delta is 400steps/mm as it is leadscrew driven on XYZ but this is still only a 40-microns-accuracy z probe which is a good factor of 4-8 out on a smart effector or piezo probe.

Yeah I'm excited to try out the smart effector, my arms finally arriving today. 500mm from Haydn. Do you have your calibrate script for endstop less? I definitely don't mind probing each print.

dc42

@mysta said in Motor stall detection as Z probe:

Yeah I'm excited to try out the smart effector, my arms finally arriving today. 500mm from Haydn. Do you have your calibrate script for endstop less? I definitely don't mind probing each print.

For a script to home a delta without endstops, see the example macro file towards the end of https://duet3d.dozuki.com/Wiki/Stall_detection_and_sensorless_homing#Section_Configuring_sensorless_homing. This file is for testing homing without endstops. For actual use as a homing file you could simplify it. For example, you don't need the M574 commands to change the endstop type because you can just set stall detect endstops in config.g if that's the only type of endstop you ever use.

Mysta

Thanks, I'll start from there. I left the endstops on my frame just in case but I'm really interested in using some of the new functionality of the 2660

dc42

In firmware 2.0beta 1 you can now set Z probe type 10 in the M558 command, which selects a Z motor stall-detect probe. As I explained previously, this will only work if your Z steps/mm is high enough for 1 motor full step to provide sufficient resolution, and if you can find a combination of M915 stall detect settings and motor current that you can detect the stall before the Z motor drives the nozzle too hard into the bed.

DjDemonD

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 works

You just need to experiment with M915 R to get the threshold right.

bartolomeus

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

What would be the best choice?

DjDemonD

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.

bartolomeus

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?

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.