Error: short-to-ground reported by driver(s) 2
-
Hi,
Last night I managed to get to the point where everything was wired up and turned on for the first time. After updating the Duet 3 to the latest firmware, I tested the home function to test the config.g.
I immediately noticed that one of the steppers was incredibly loud (an electrical crunching sound) so I stopped everything and began looking into it. I was also provided with an error message on DWC that repeated every 10 seconds saying "Error: short-to-ground reported by driver(s) 2"
I've run a M122 and this is the answer:
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v1.01 or later (standalone mode)
Board ID: 08DJM-956L2-G43S8-6JTDJ-3S46J-9S2YD
Used output buffers: 4 of 40 (22 max)
=== RTOS ===
Static ram: 154604
Dynamic ram: 161848 of which 332 recycled
Exception stack ram used: 490
Never used ram: 75942
Tasks: NETWORK(ready,356) ETHERNET(blocked,436) HEAT(blocked,1188) CanReceiv(suspended,3820) CanSender(suspended,1488) CanClock(blocked,1424) TMC(blocked,68) MAIN(running,4784) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 00:06:33 ago, cause: software
Last software reset at 2020-07-05 10:18, reason: User, spinning module GCodes, available RAM 76120 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN
Error status: 0
MCU temperature: min 27.6, current 30.8, max 31.0
Supply voltage: min 23.9, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.0, max 12.1, under voltage events: 0
Driver 0: standstill, reads 13364, writes 5 timeouts 0, SG min/max 0/295
Driver 1: standstill, reads 13363, writes 5 timeouts 0, SG min/max 0/754
Driver 2: short-to-ground standstill, reads 13363, writes 5 timeouts 0, SG min/max 0/214
Driver 3: standstill, reads 13369, writes 0 timeouts 0, SG min/max not available
Driver 4: standstill, reads 13368, writes 0 timeouts 0, SG min/max not available
Driver 5: standstill, reads 13369, writes 0 timeouts 0, SG min/max not available
Date/time: 2020-07-05 10:24:56
Slowest loop: 4.08ms; fastest: 0.20ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 2.5ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 375, MinFreeDm: 373, MaxWait: 42519ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 4, completed moves: 4, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== 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
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 8.04ms; fastest: 0.03ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
HTTP sessions: 1 of 8- Ethernet -
State: active
Error counts: 0 0 0 0 0
Socket states: 5 5 2 2 2 0 0 0
=== CAN ===
Messages sent 1455, longest wait 0ms for type 0
=== Linux interface ===
State: 0, failed transfers: 0
Last transfer: 393574ms ago
RX/TX seq numbers: 0/1
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0
Following this, I did a bit of googling and found some info that it could be caused by a short in the stepper. I turned everything off disconnected the stepper and tested using a multi-meter. Everything looked fine with the motor and wiring as compared the the other steppers that were working normally.
I wanted to be sure it wasn't me or the stepper so I reconfigured the config to use Driver_4, reconnected the stepper and turned everything back on. I used the home function and everything worked fine. To be sure it was not a fluke, I turned it off, plugged the stepper back into Driver_2, turned everything on, reconfigured to use the suspect driver and sure enough, I got the same error message and the horrible sound.
I've since inspected the board and I can see no signs of anything burnt out or damaged or shorted.
Is this a damaged stepper driver or is there something else I can try to get Driver_2 working properley?
Cheers,
Angus. - Ethernet -
-
Well it sounds like you've already eliminated this by trying the motor on another driver with success, but you can check motor phases using this technique.
Can you post your full config.g?
Also a photo of the driver area may be helpful in case we can spot something.
-
Hi,
Yes, that is the guide I found on another post and I followed it to rule out a short in the stepper using a multimeter.
I've attached a decent close-up of the Driver_2 area as well as the original config.g
Cheers,
Angus. -
Where and when was your Duet 3 purchased? I believe you have a failed driver.
-
@Phaedrux
I purchased it from aurarum.com.au as they are the authorised distributor in Australia.Should I submit a warranty replacement form through them?
-
Yes if you're within 6 months of purchase please contact them to initiate a warranty return. You can use this thread as authorization.
-
@Phaedrux
Thanks very much for the help.
