Motor stall detection as Z probe

[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

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.

[dc42]

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

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