Did I kill my stepper driver (duet maestro)?
-
While working on my printer (with the power off), I accidentally partially unplugged the cable from a stepper. It was about 50% plugged in and 50% unplugged.
I homed my printer with no problems and then started a print. After waiting for the bed and hotend to reach temperature, the job tries to home the printer causing that motor to stutter and I see "short-to-ground" errors on a bunch of drivers. If I power the printer off for a while (not just a few seconds), I can home that axis and drive it just fine. If I then let the printer sit for several minutes then homing that axis now causes the stuttering and a flurry of short-to-ground errors. Between the time that homing succeeded and the time that it failed, the printer didn't move and nothing was touched. In concrete steps, I did:
- Power on
- Home X
- G1 X200
- Home X
- G1 X200
- wait for a bit
- Home X
- bad things happen!
These steps seem to be reproducible. I've repeated the procedure three times in a row now and the couple of times when I homed and then started the print.
I'm guessing that this is a sign that I should upgrade to a Duet 3 board, but I wanted to check that there isn't any obvious reason why I would be seeing this behaviour?
Thanks!
Chris -
Sounds like I've probably killed something related to the stepper drivers. It just occurred to me to try using only the y axis to see if the problem was specific to the x axis or just a general problem with the board. I homed the printer and then periodically kept moving just the y axis and had something similar happen after a few minutes.
-
If the connection to the stepper was intermittent while trying to move an axis, then yes, chances are that a driver was damaged. Do you see any damage on the board?
After trying to move all axis can you send M122 to get a diagnostic report and copy and paste that here?
-
@phaedrux I don't see any obvious damage to the drivers (or anything else) on the board. To rule out somehow having damaged the stepper that was partially unplugged, I connected a different stepper in its place. That didn't change anything. Here's the M122 output after successfully moving an axis:
=== Diagnostics === RepRapFirmware for Duet 2 Maestro version 3.3 (2021-06-15 21:47:01) running on Duet Maestro 1.0 Board ID: 08DGM-95762-FD3TD-6J1F8-3S86S-KS8MF Used output buffers: 3 of 24 (22 max) === RTOS === Static ram: 23556 Dynamic ram: 67012 of which 144 recycled Never used RAM 21928, free system stack 178 words Tasks: NETWORK(ready,28.1%,270) HEAT(delaying,0.1%,345) Move(notifyWait,0.1%,343) TMC(notifyWait,2.2%,117) MAIN(running,69.5%,493) IDLE(ready,0.0%,30), total 100.0% Owned mutexes: === Platform === Last reset 00:00:31 ago, cause: power up Last software reset at 2021-12-06 19:06, reason: User, GCodes spinning, available RAM 21752, slot 2 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x00 Step timer max interval 484 MCU temperature: min 21.0, current 22.0, max 22.3 Supply voltage: min 24.2, current 24.3, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/4/4, gc cycles 0 Driver 0: position 16000, standstill, read errors 0, write errors 0, ifcnt 9, reads 5227, writes 2, timeouts 0, DMA errors 0 Driver 1: position 0, standstill, read errors 0, write errors 0, ifcnt 7, reads 5229, writes 0, timeouts 0, DMA errors 0 Driver 2: position 0, standstill, read errors 0, write errors 0, ifcnt 9, reads 5226, writes 2, timeouts 0, DMA errors 0 Driver 3: position 0, standstill, read errors 0, write errors 0, ifcnt 7, reads 5228, writes 0, timeouts 0, DMA errors 0 Driver 4: position 0, standstill, read errors 0, write errors 0, ifcnt 9, reads 5226, writes 2, timeouts 0, DMA errors 0 Driver 5: position 0, standstill, read errors 0, write errors 0, ifcnt 9, reads 5226, writes 2, timeouts 0, DMA errors 0 Driver 6: position 0, standstill, read errors 0, write errors 0, ifcnt 7, reads 5228, writes 0, timeouts 0, DMA errors 0 Date/time: 2021-12-07 05:03:34 Slowest loop: 3.89ms; fastest: 0.13ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 10 SD card 0 detected, interface speed: 15.0MBytes/sec SD card longest read time 0.5ms, write time 0.0ms, max retries 0 === Move === DMs created 83, maxWait 20325ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 6, completed moves 6, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 1], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = 0 -1, chamberHeaters = -1 -1 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 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 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 7.39ms; fastest: 0.04ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions HTTP sessions: 1 of 8 Interface state active, link 100Mbps full duplex
And after letting it sit and then moving the axis 0.1mm with stepper errors:
Error: short-to-ground reported by driver(s) 0 12/7/2021, 5:06:45 AM m122 === Diagnostics === RepRapFirmware for Duet 2 Maestro version 3.3 (2021-06-15 21:47:01) running on Duet Maestro 1.0 Board ID: 08DGM-95762-FD3TD-6J1F8-3S86S-KS8MF Used output buffers: 3 of 24 (23 max) === RTOS === Static ram: 23556 Dynamic ram: 67012 of which 144 recycled Never used RAM 21928, free system stack 178 words Tasks: NETWORK(ready,27.8%,270) HEAT(delaying,0.1%,345) Move(notifyWait,0.1%,343) TMC(notifyWait,2.2%,117) MAIN(running,69.9%,493) IDLE(ready,0.0%,30), total 100.0% Owned mutexes: === Platform === Last reset 00:03:41 ago, cause: power up Last software reset at 2021-12-06 19:06, reason: User, GCodes spinning, available RAM 21752, slot 2 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x00 Step timer max interval 548 MCU temperature: min 21.8, current 24.0, max 24.4 Supply voltage: min 23.9, current 24.3, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/4/4, gc cycles 0 Driver 0: position 15984, short-to-ground, standstill, read errors 0, write errors 0, ifcnt 11, reads 51996, writes 2, timeouts 0, DMA errors 0 Driver 1: position 0, standstill, read errors 0, write errors 0, ifcnt 7, reads 51998, writes 0, timeouts 0, DMA errors 0 Driver 2: position 0, standstill, read errors 0, write errors 0, ifcnt 10, reads 51998, writes 1, timeouts 0, DMA errors 0 Driver 3: position 0, standstill, read errors 0, write errors 0, ifcnt 7, reads 51999, writes 0, timeouts 0, DMA errors 0 Driver 4: position 0, standstill, read errors 0, write errors 0, ifcnt 10, reads 51998, writes 1, timeouts 0, DMA errors 0 Driver 5: position 0, standstill, read errors 0, write errors 0, ifcnt 10, reads 51998, writes 1, timeouts 0, DMA errors 0 Driver 6: position 0, standstill, read errors 0, write errors 0, ifcnt 7, reads 51998, writes 0, timeouts 0, DMA errors 0 Date/time: 2021-12-07 05:06:45 Slowest loop: 7.99ms; fastest: 0.16ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 10 SD card 0 detected, interface speed: 15.0MBytes/sec SD card longest read time 4.8ms, write time 0.0ms, max retries 0 === Move === DMs created 83, maxWait 186941ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 7, completed moves 7, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 1], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = 0 -1, chamberHeaters = -1 -1 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 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 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 6.02ms; fastest: 0.04ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions HTTP sessions: 1 of 8 Interface state active, link 100Mbps full duplex
-
I do find it strange that this is affecting all stepper drivers, not just the one that was partially unplugged. Originally, I was trying the x axis but this is also the case:
- G92 Y100
- Y +0.1 from the dashboard
- wait 30 seconds
- Y +0.1
causes it to start reporting short-to-ground for both of my y steppers.
-
@crpalmer said in Did I kill my stepper driver (duet maestro)?:
I do find it strange that this is affecting all stepper drivers
How do you mean? Do you get short to ground errors for each driver or just driver0?
-
@phaedrux When I said "all stepper drivers", I meant that I will get short-to-ground for whatever motor I have just driven. For example:
- G92 X100 Y100
- X +10
- wait a minute
- Y + 0.1
- short-to-ground: y drivers
- X + 0.1
- short-to-ground: x driver, y drivers
I just added this on to the end of it:
- G92 Z100
- Z +0.05 (a bunch of times to see if I really had to wait any appreciable amount of time)
- wait a minute (I did have to wait)
- Z +0.05
- short-to-ground: x driver, y drivers, z drivers
This made me think it was related to idle hold, so I commented out the M84 line of my config.g but that didn't seem to change the behaviour. With that line removed, I can still replicate the same behaviour.
-
@crpalmer if you home the printer and then let it sit there with motors still enabled, do any of the drivers get hotter than normal?
-
@dc42 FWIW, I don't even need to home the printer, just move any axis, wait and then move any other axis. Doing this now, my MCU Temperature was around 25C and, as best I can measure with an infrared thermometer, the drivers themselves never went above around 23C. When I'm not trying to measure temperature, the board has a 120mm fan blowing on it with exhaust holes out the side which seems to very effectively cool the drivers (as reported by the MCU as a proxy).