stalling and destroying stepper drivers

  • preface: I am running dual y-axis motors into two different drivers on a duet wifi.

    I have been doing some experimentation on my machine and I have now stalled my Y-axis motors several times on the same drivers and I am wondering at this point are my drivers bad? I had stalled my motors several times on another duet wifi so many times that no matter what I did it stalled, so I swapped to a new duet. Now this duet is starting feel like it is doing the same things....

    my questions:
    How do I know if my drivers are blown out after stalling the motors so many times?
    How many times does it take for my drivers to get blown out?
    Why do my motors not stall with load but they will stall in free spin? (motors are 3.3mH, 2A, 0.81Nm, nema17)

  • @injoi9000 I also haven't found much information on the forums regarding repeated stall on the same Duet. @dc42 any information you can provide? I use an e-stop to cut power to the drivers if stall does happen, but can repeated stall even for a short time be detrimental to the board health?

  • Hi,

    We could use a little more information.

    When is this happening? Are you stalling them intentionally? What do you mean by "stall in free spin"?



  • Moderator

  • administrators

    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

  • 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"

  • Moderator

    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?

  • Moderator

    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.

  • Moderator

    @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?

  • Moderator

  • @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.

  • Moderator

    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 is a tricky problem! Do you have any literature on the effects of running motors at rated current with proper heat sinking?

  • Moderator

    @injoi9000 yeah there was actually a discussion about doing exactly that recently.

    Here you go.

    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 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: 0

    Free 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 ===

  • Moderator

    Was this after a failure?

  • @phaedrux This was many power cycles after a failure. Should I send the command immediately after a failure?

  • It could also be wiring problem. When you swap the board around the connectors and cables get moved around and they are working again. Have you tried to wiggle the connectors and cables when the gantry is moving to see if that has any effect?

    I've also had some random stalling problems after assembling my machine and they turned out to be my bad crimp connections.

  • Moderator

    @injoi9000 said in stalling and destroying stepper drivers:

    @phaedrux This was many power cycles after a failure. Should I send the command immediately after a failure?

    Yes. Any error message is reset at a power cycle.

Log in to reply