Did I kill my stepper driver (duet maestro)?

crpalmer

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

crpalmer

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.

Phaedrux

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?

crpalmer

@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

crpalmer

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.

Phaedrux

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

crpalmer

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

dc42

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

crpalmer

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