stalling and destroying stepper drivers
-
-
Stalling motors does not damage constant current stepper drivers.
Please explain more clearly what the problem is. Are you referring to stall detection? If so, read the limitations at https://duet3d.dozuki.com/Wiki/Stall_detection_and_sensorless_homing.
-
You can physically stall the motors against a hard stop (like hit the carriage against the frame) all day and it won’t do anything to the electronics or motor. Might break some plastic or shake some screws loose in your printer though.
-
My XY stepper motors run at 24V 2.5A and I stall them frequently when experimenting with weight, acceleration, speed. No damage anywhere, as long as stuff stays cool.
-
@dc42 I'm not using stall detection I just have a linear rail system and every once in a while my motors will stall due to the linear rail system binding (because of dust I think) and after several time of my motors stalling I feel that it gets more and more frequent. I once swapped out the linear rail system for an openrail system and the duet still continued to stall my dual y axis motors...Then I swapped out the duet and I had no problems after that.
However, now with my new openrail system my system will work for about 200 hours and then start stalling the y axis motors. Once that happens I pop in a new duetwifi and everything starts working again. WHY IS THAT? It doesn't make a lot of sense unless the motor drivers have a lifespan of 200 hours.
This is my config file for reference:
; Configuration file for Duet WiFi (firmware version 1.20 or newer)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool on Fri Jun 08 2018 17:51:24 GMT-0700 (Pacific Daylight Time); General preferences
G90 ; Send absolute coordinates...
M83 ; ...but relative extruder moves
M555 P2 ; Marlin Compatibility; Network
M550 PCFB_03 ; Set machine name
M552 S1 ; Enable network
M586 P0 S1 ; Enable HTTP
M586 P1 S0 ; Disable FTP
M586 P2 S0 ; Disable Telnet; Motor Remapping
M584 X0 Y1:2 V3 U4 Z6;; Drives
M569 P0 S1 ; Drive 0 goes forwards (towards endstop)
M569 P1 S0 ; Drive 1 goes backwards (towards endstop)
M569 P2 S1 ; Drive 2 goes backwards (towards endstop, matches Drive 1, mapped above)
M350 X8 Y8 Z16 I0 ; Configure microstepping without interpolation
M92 X40 Y40 Z4000 ; Set steps per mm
M566 X300 Y300 Z12 ; Set maximum instantaneous speed changes (mm/min)
M203 X100000 Y100000 Z180 ; Set maximum speeds (mm/min)
M201 X2400 Y2400 Z250 ; Set accelerations (mm/s^2)
M906 X1600 Y2000 Z0 U0 ; Set motor currents (mA)
M84 S0 ; Disable motor idle current reduction; Axis Limits
M208 X0 Y0 Z0 U0 S1 ; Set axis minima
M208 X560 Y476 Z1 U1 S0 ; Set axis maxima; Endstops
; Helper Comments: X1 endstop at low end, Y2 endstop at high end
; Helper Comments: S0=active low endstop input,S1=active high endstop input
M574 X1 Y1 Z1 S1 ; See above for clarification.
M574 U0 V0 S0; Heaters
M140 H-1 ; Disable heated bed
M307 H0 A-1 C-1 D-1 ; this is what dc42 says to do; Fans
M106 P0 S0.0 I0 F500 H-1 ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off
M106 P1 S0.0 I0 F500 H-1 ; Set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned off
M106 P2 S0.0 I0 F500 H-1 ; Set fan 2 value, PWM signal inversion and frequency. Thermostatic control is turned off; Tools
; Extras
M305 P101 S"DriverTemp" -
How long have you been using 8 microsteps?
Have you tried using 16 interpolated all around?
-
@phaedrux I went to 8 microsteps only recently when I started to get the random stalling problem that I identified earlier. Is there a reason I should go to 16 over 8? I am using the duet as a controller for a pick and place machine for little boxes so I don't need much precision.
Could I have sized my motors incorrectly? I used this guide but I am not sure where any of the equations are derived from. @dc42 could you shed some light?
-
16 microsteps interpolated to 256 will give the smoothest and quietest operation. I'm not sure if using 8 would have any negative effects in your case but there have been times where full stepping can have issues.
If you move the carriages by hand with the power off and motors disconnected do they move smoothly? It sounds like you have some binding issues still.
-
@phaedrux Interesting. Everything moves beautifully now by hand with the belts and motors and without the belts and motors attached.
A good example is yesterday I had the problem I described and 45 minutes into my operation the y axis stalled. I swapped out the board and then I went problem free for 10 hours....I which I knew the source of this problem but currently I can only think that the drivers are the source. My rails have 3 rollers on them and I can test them at 80,000mm/min with no issues but going through long procedures I used to get stalling (until I swapped the board). I'm mostly just trying to find root cause for the problem.
-
@injoi9000 said in stalling and destroying stepper drivers:
M906 X1600 Y2000 Z0 U0 ; Set motor currents (mA)
You say in your first post you have 2A motors? and it looks like you are using the Y motor at max current? That may be your issue. Is the motor getting very hot? Do you have the board actively cooled with a fan blowing over both sides? Try reducing your Y motor current to 70-85% of max rated current.
-
@phaedrux Yup I have 2A motors. My motors only get warm to the touch and I have them mounted to an aluminum block for heat sinking. I have a 80mm 30cfm fan and I have position the duet as a blade in the middle of the fan so i get airflow on top and bottom.
What is the problem with having my motors at 100% max current? That is their rated current right?
-
-
@phaedrux So I have read that portion, however, I have several machines run perfectly fine at 100% of rated current and none of my motors get hot. That also doesn't explain how I can pop in a new duet and fix the stalling issues....seems odd.
-
Just throwing ideas out there. I would try running at 16 microsteps interpolated at 85% rated current and seeing how that goes. If it still occurs, send M122 to get a diagnostic report and post that here, perhaps that will give another clue.
-
@phaedrux Hmm ok I will try that. Thanks for the ideas....it is a tricky problem! Do you have any literature on the effects of running motors at rated current with proper heat sinking?
-
@injoi9000 yeah there was actually a discussion about doing exactly that recently.
Here you go.
https://forum.duet3d.com/topic/6797/setting-motor-current-higher-than-rated-current
Do you happen to have an IR thermometer to check the actual motor temps?
For my own 2.0A motors, I know they can get up to 80c if I run them at full current after several hours on a long high speed print. I don't think I was getting any missed steps and there was no stalling. I've added some heatsinking and run at 70% current and the temps are down to 42c. Same performance and a bit quieter.
I'm not exactly sure what your exact application is, or what your mechanics look like, so it's hard to know what else to try. The fact that the problem goes away when you swap the board leads me to wonder what a diagnostic report would say.
Also, which firmware version are you using exactly? Have you checked the recent upgrade notes to see if there have been any bug fixes or changes that might be relevant?
-
Ok so I have an update! I just transported my machine 400 miles to a friends house in a uhaul truck and in the first operation the motors stalled. This was after the machine was working continuously For 30 hours! I will run diagnostics on this board but I have a feeling once I swap out the duet everything will work again.....how sensitive is the duet to static electricity or shock/vibration similar to something that might occur during transport?
-
I looked at one of the old boards and took a diagnostic of it. Not sure what to look for but here it is.
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.01(RTOS) running on Duet WiFi 1.02 or later
Board ID: 08DGM-956GU-DJMSN-6J1FJ-3S06M-K9QRH
Used output buffers: 1 of 20 (1 max)
=== RTOS ===
Static ram: 28476
Dynamic ram: 95768 of which 0 recycled
Exception stack ram used: 204
Never used ram: 6624
Tasks: NETWORK(ready,1872) HEAT(blocked,1256) MAIN(running,4488)
Owned mutexes:
=== Platform ===
Last reset 00:01:40 ago, cause: power up
Last software reset at 2018-09-25 13:02, reason: User, spinning module GCodes, available RAM 6364 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
[ERROR] Error status: 0Free file entries: 10
SD card 0 not detected, interface speed: 30.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 40.9, current 43.6, max 43.6
Supply voltage: min 0.6, current 1.7, max 1.7, under voltage events: 0, over voltage events: 0
Driver 0: ok, SG min/max not available
Driver 1: ok, SG min/max not available
Driver 2: ok, SG min/max not available
Driver 3: ok, SG min/max not available
Driver 4: ok, SG min/max not available
Date/time: 1970-01-01 00:00:00
Slowest loop: 0.16ms; fastest: 0.07ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
Stack records: 0 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is ready with "M122" in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 0.16ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 0 of 8- WiFi -
Network state is disabled
WiFi module is disabled
Failed messages: pending 2779096485, notready 2779096485, noresp 2779096485
Socket states: 0 0 0 0 0 0 0 0
=== Expansion ===
- WiFi -
-
Was this after a failure?
-
@phaedrux This was many power cycles after a failure. Should I send the command immediately after a failure?