How to tune Stall Detection?
-
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.
-
That type of test code should suffice.
-
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. -
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 factor2) 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 2043These 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 R1The 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 readingsOn 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 endstopsThe 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. -
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.
-
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. -
Hi GaRv3,
This may be covered elsewhere, but have you tried increasing the travel speed in your test gcode?
ie, "G1 Z10 F50" to "G1 Z10 F300" or similar?
You could also try adding an H value to M915, such as "M915 P2:4 H10 S-10 F0 R1""Hnnn (optional) Minimum motor full steps per second for stall detection to be considered reliable, default 200"
I admit I am not certain of the exact relationship between mm/minute and steps per second, but I think you have
400 steps/mm;
10mm/minute;
=4000 steps/minute;
=66 steps/second.Personally I haven't had much luck tuning Z stall detect to where I would use it as a safeguard, however I am logging messages during a regular print.
On my machine I have both Z stepper motors on Drive 2 (option B on the "Duet Wifi/Duet Ethernet Connections" image) -
Well, I have updated information from my testings. I just upgraded my PSU to 24V and after re-tuning everything, I came back to test the stall on the Z-motors. The stallguard works well on all axis with the new 24V PSU. For the dual motor leadscrews axis I am using speeds above 400mm/second, and I am getting better results with higher speeds.
I re-calculated the speeds where my motors will start loosing torque using DC42 excel. the new value for the Z motors (2 in series) is 28.1min/sec (=1685 mm/min) for the low slip angle.
Working at 50% of this speed is roughly 800mm/min that is where I would expect to get the best results (middle of the dynamic margin). For the Z axis seems too fast and I am homing at 700mm/min which is working fine 90% of the time. However from time to time the stallguard triggers before hitting the limit and setting my Z-max at the wrong location. I need to investigate if there are other factors that I can correlate to the fails.A collateral effect of my migtation to 24V has been the radial fan. I am using my old 12V fans wit an LM7812. The problem is that it runs now at 100% speed all the time and I lost the capability to modulate the fan speed. The fan is cooling my hotend and is creating a temperature excursion exceeding 15.0°C and stopping my prints. But this is a different story that I have to solve buying a 24V fan ;).
-
A collateral effect of my migtation to 24V has been the radial fan. I am using my old 12V fans wit an LM7812. The problem is that it runs now at 100% speed all the time and I lost the capability to modulate the fan speed. The fan is cooling my hotend and is creating a temperature excursion exceeding 15.0°C and stopping my prints. But this is a different story that I have to solve buying a 24V fan ;).
I was in the same situation. I ended up using a buck converter to take 24v from the psu and pass 12v into the V_fan input of the Duet to feed 12v to the fan headers. That allowed me to use some 12v only Noctua fans with PWM intact.
-
Cool, I get to keep the Noctua. Thanks a lot for the tip!
-
Cool, I get to keep the Noctua. Thanks a lot for the tip!
Just be careful where you plug the 12v line in. You have to remove the jumper which bridges the Vfan in with either the Vin or 5v pins and connect to only the Vfan_in pin.
You will only need the + terminal from the buck converter, the - terminal can remain unconnected since the fans go to ground separately.
-
I followed your instructions and it is working perfectly fine. I used a three pin molex, one of the side pins is connected from the 24V pin to the buck converter VIN, the middle pin pin goes from the Vfan to the VCC output of the buck. Unfortunately this jumper is not protected against reverse polarity, so I will have to label it very carefully. Worst case (reversed polarity), I would power the buck converter with 5V and nothing serious will happen.
You saved my Noctua and my radial fan!. I love my Duet more and more, it has plenty of possibilities for any configuration. Very versatile.
Thanks again for you great help.
