How to tune Stall Detection?

GaRv3

No additional suggestions?
This feature was one of the main reasons for buying the Duet

dc42

Is it just the Z motor that you can't get stall detection working on? Does it work on the X and Y motors? How about U?

GaRv3

It works on X and Y. I tuned the values until I got no more false detections. S22 seems to be the value to go on these axes.

I tried [c]M915 Z S-50 F0 R1[/c] and [c]M915 P2:4 S-50 F0 R1[/c] for Z but never got stall detections on drives other than 0 and 1 (X and Y).

dc42

I have added this to my list of pending investigations. I should get to it before the end of this coming week.

GaRv3

Great, thank you!

GaRv3

Any news on this already?

GaRv3

dc42

Do you have one Z motor or two? If you have two, how are they connected?

GaRv3

See this post: https://www.duet3d.com/forum/thread.php?pid=37997#p37997

dc42

If you run M915 without parameters, what stall detect configurations does it report for drivers 2 and 4?

GaRv3

The console does not show the whole response. Seems to be too long:

Driver 0: stall threshold 23, filter off, steps/sec 200, coolstep 0, action: log
Driver 1: stall threshold 23, filter off, steps/sec 200, coolstep 0, action: log
Driver 2: stall threshold -10, filter off, steps/sec 200, coolstep 0, action: log
Driver 3: s

dc42

You can send M915 D# where # is the drive number, to report the settings for a single drive.

GaRv3

Yeah, sure.
Drive 4 is the same as 2.
Tried this before with -50 instead of -10 for drives 2 and 4.

dc42

Please can you set up a config.g file and test script (based on your Z homing file) that I can use to test this. I don't mind whether you have 1 Z motor or 2, just so long as I can put those files on a bench test setup and replicate the fault.

GaRv3

I have not tried to implement the sensorless Z homing because the stall detection does not seem to work at all and I do not want to damage the printer.

My confi.g is pretty big already but I can send it to you along with a test gcode (which simply moves Z up and down slowly at low current so that blocking the axis should trigger stall detection) as soon as I am at home.

dc42

That type of test code should suffice.

GaRv3

You can download my config.g and the gcode here:
https://1drv.ms/u/s!Al1_ZNc7d8A1k_4Qr_b1D1yZMFp0LQ
At least the network section of the config.g has to be adjusted, of course.
I set the current for the Z motors in the first line of the gcode file so it can be adjusted for testing.

carlosspr

I also have tuned the stall detection for homing for X and Y, but for Z is getting very hard to tune. Also for an Anet A8 with dual Z motors and threaded rod. According to trinamic Apllication Note for Stall Guard, in order to find the stallGuard Threshold the challenge is to choose a range of speed for operation (https://www.trinamic.com/fileadmin/assets/Support/Appnotes/AN002-stallGuard2.pdf)

My steps for tuning have been the following:

1) Choose nominal phase current
My XYZ steppers are rated for 1A. I am working at 80% to keep them cold. The value on config.g is as follows:

[[language]]
M906 X800 Y800 Z800 E1200 I30 ; 30% idle factor

2) Choose velocity.
My starting point was DC42 Excel Sheet, that will calculate my maximum speeds. Inserting the specs for my motors I got the following results:
Axis: X Y Z E
Speed at which torque starts to drop (mm/sec), low slip angle: 106.8 106.8 13.2 34.0
Speed at which torque starts to drop (mm/min), low slip angle: 6411 6411 793 2043

These values will define my config.g speeds:```
[[language]]
M203 X6000 Y6000 Z700 E2000


**3) Search SGT within the range -10 … +10, starting with SGT = 0**

I testing started with a S0 for Home X and Y:```
[[language]]
M915 X S0 F0 R1

The homing worked fine for X and Y on the first attempt and the stall was detected, however during the print I received a stall notification on each high speed infill. I fine tuned the following homex.g to avoid the false reports on each print:

[[language]]
M400                       	; make sure everything has stopped before we make changes
M915 X S0 F0 R1	        ; increase stall sensitivity for endstop homing
M913 X50   		        ; reduce motor current to 50% to prevent belts slipping
G91				        ; relative mode
G1 Z4 F200 S1	        ; raise Z to avoid collisions and stop if endstop is switched (if already homed)
G1 X-240 F3000 S1	; Move towards origin and stop if endstop detected
G4 P500				; wait 500msec
G90				        ; absolute mode
M400                      	; make sure everything has stopped before we reset the motor currents
M913 X100    		; motor currents back to normal
M915 X S12 F1 R1	; Increase StallGuard thresold to prevent false readings

On homey.g the difference is the StallGuard thresold M915 Y S17 F1 R1 because Y stepper continued giving false readings. This might be because the Y motor moves the bed with the print and has a higher load than X motor moving a light bowden carriage. Probably I will have to tune it higher for big prints that might add extra load due to the print weight over the bed.

For the Z motor, however I have not found the settings after many tries. Starting with an speed of 350 the StallGuard will not trigger and will hit the maximum, increasing to >450 it will trigger at the current position regardless of the sensitivity. The following is my text macro that I have used:

[[language]]
M574 Z2 S3         	    	; set Z-max to use motor StallGuard
M400                     	; make sure everything has stopped before we make changes
M915 Z S0 F0 R1			; Set StallGuard sensitivity for endstop homing
G91				; relative mode
G1 Z200 F450 S1		        ; Move towards origin and stop if endstop detected
G4 P500				; wait 500msec
G90				; absolute mode
M915 Z S10 F1 R1		; reduce stall sensitivity to prevent false readings
M574 Z2 S0		        ; restore settigns Z-max active high switch NC endstops

The second problem that I have not solved is the precision: I tried to use M915 with R3 as opposed to R1 to home and resume printing. I have created a rehome.g file, but on this scenario my test prints stopped on each false report, the print paused executed rehome.g and resumed printing. after each homing I have an offset of 0.2mm.
I do not know how to bypass this offset.

dc42

1. On a Cartesian or CoreXY printer with a high steps/mm and a bed that moves in Z, I doubt that it is possible to use stall detection for Z axis homing. There is already quite a high Z motor loading due to the friction of the leadscrews, and it probably won't take very much more motor torque to drive the nozzle into the bed hard enough to cause damage.

2. If you read the notes on the wiki you will see that the homing position when using stall detection instead of endstops is only accurate to within 1 full step. If your X axis has 80 steps/mm at x16 microstepping then your 0.2mm offset is exactly one full step.

You may be able to improve the chances of getting it to home on the same full step by:

(a ) Make sure you use exactly the same X and Y homing code (including speeds) in rehome.g as you use in your initial homing (which you probably do using homeall.g). If you home X and Y simultaneously in homeall.g, do the same in rehome.g.

(b) Place the physical endstop that you home against at the end of the axis close to the corresponding motor, so that at the homing position the length of belt between the motor and the anchor point to the carriage or bed is small. This should make it more likely that thermal expansion will not change the homing position.

Home the printer when it is at operating temperature before printing - again to minimise the effect of thermal expansion

(d) Make the position of the physical endstops slightly adjustable. Moving them slightly by up to 1 full step in either direction may improve the chance of the stall being detected on the same full step each time.

GaRv3

Ok, so what about my problem? Z won't detect stalls at all.
Did you check my config? No matter what I do, the Z drives will not detect they are blocked.