Short to ground on drivers 0123

A Former User

I think we can leave it at drivers 0-3 are damaged, and Duet people will determine the cause and potential remedy.

(edit: shop will tell you to get Duet people to determine the cause, on this fourm)

Touchthebitum

@bearer said in Short to ground on drivers 0123:

I think we can leave it at drivers 0-3 are damaged, and Duet people will determine the cause and potential remedy.

Ok I contacted the shop and see what we can do .
Thanks for your help

dc42

@Touchthebitum said in Short to ground on drivers 0123:

I don't know whhat to do because I tried to swapped wires many times.

Unfortunately, swapping stepper motor wires over so that they are no longer wired with one phase to each end of the connector is a recipe for blowing drivers. This is because the driver cannot control the output current when they are mis-wired in this way. Sometimes they survive, sometimes they don't - it depends on the VIN voltage and the type of motor.

Touchthebitum

@dc42 ok I understand but the problem was present at the first plug and I used the same working wiring than my working Duet2. And the message was telling that the driver 1 was short - ground and I had never plugged anything on the socket.
I repeat, I swapped the wires because it didn't work with the same wiring as my Duet2.

Phaedrux

@Touchthebitum said in Short to ground on drivers 0123:

I forgot to mention that the error message is present without the motors plugged ...
It is the Duet3 V1.01

Here is a photo of the plug. I tested the phase before plugging it.

Tape is provisory.

What role does the tape play there? Is it possible the crimp was bad from the start and making a bad connection?

Were you getting the error before plugging anything in or only after?

Touchthebitum

@Phaedrux Tape is only a protection to avoid shorts contact. Contacts were good since I made continuity tests and resistance tests and I always had signal.

Phaedrux

Were there any other error messages along with the short to ground errors?

Touchthebitum

@Phaedrux No, M122 had not error messages. Only those ground-short messages

Phaedrux

When are where was the Duet 3 purchased?

Touchthebitum

@Phaedrux www.3dware.ch

dc42

Please send M122 and post the resulting output here.

Touchthebitum

@dc42

m122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956L2-G43S8-6J9F4-3S46N-TU2QD
Used output buffers: 1 of 40 (10 max)
=== RTOS ===
Static ram: 154604
Dynamic ram: 162592 of which 44 recycled
Exception stack ram used: 224
Never used ram: 75752
Tasks: NETWORK(ready,1968) HEAT(blocked,1200) CanReceiv(suspended,3820) CanSender(suspended,1488) CanClock(blocked,1436) TMC(blocked,204) MAIN(running,4952) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 00:00:44 ago, cause: power up
Last software reset at 2020-07-27 15:14, reason: User, spinning module LinuxInterface, available RAM 75704 bytes (slot 0)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0443c000 BFAR 0x00000000 SP 0xffffffff Task MAIN
Error status: 0
MCU temperature: min 19.4, current 27.7, max 27.8
Supply voltage: min 24.0, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.1, max 12.2, under voltage events: 0
Driver 0: standstill, reads 22474, writes 14 timeouts 0, SG min/max 0/0
Driver 1: standstill, reads 22474, writes 14 timeouts 0, SG min/max 0/0
Driver 2: standstill, reads 22475, writes 14 timeouts 0, SG min/max 0/0
Driver 3: standstill, reads 22475, writes 14 timeouts 0, SG min/max 0/0
Driver 4: standstill, reads 22478, writes 11 timeouts 0, SG min/max 0/0
Driver 5: standstill, reads 22479, writes 11 timeouts 0, SG min/max 0/0
Date/time: 2020-07-27 15:15:01
Slowest loop: 3.63ms; fastest: 0.14ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 375, MinFreeDm: 375, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 0, completed moves: 0, 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 ready with "M122" 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: 1.02ms; fastest: 0.01ms
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: 0 of 8

Ethernet -
State: disabled
Error counts: 0 0 0 0 0
Socket states: 0 0 0 0 0 0 0 0
=== CAN ===
Messages sent 72, longest wait 0ms for type 0
=== Linux interface ===
State: 0, failed transfers: 0
Last transfer: 18ms ago
RX/TX seq numbers: 583/584
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.1.1
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 30.27

dc42

Thanks. Please try commanding the motors to move (without any motors connected) and repeat that. I am looking for the driver status to change.

Touchthebitum

@dc42

Error: short-to-ground reported by driver(s) 0 1
27/07/2020 à 21:40:14 m122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956L2-G43S8-6J9F4-3S46N-TU2QD
Used output buffers: 1 of 40 (10 max)
=== RTOS ===
Static ram: 154604
Dynamic ram: 162592 of which 44 recycled
Exception stack ram used: 280
Never used ram: 75696
Tasks: NETWORK(ready,1968) HEAT(blocked,1200) CanReceiv(suspended,3820) CanSender(suspended,1488) CanClock(blocked,1452) TMC(blocked,68) MAIN(running,4952) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 00:00:47 ago, cause: power up
Last software reset at 2020-07-27 15:14, reason: User, spinning module LinuxInterface, available RAM 75704 bytes (slot 0)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0443c000 BFAR 0x00000000 SP 0xffffffff Task MAIN
Error status: 0
MCU temperature: min 20.8, current 29.0, max 29.1
Supply voltage: min 24.0, current 24.1, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.1, max 12.1, under voltage events: 0
Driver 0: short-to-ground standstill, reads 39652, writes 17 timeouts 0, SG min/max 0/0
Driver 1: short-to-ground standstill, reads 39652, writes 17 timeouts 0, SG min/max 0/63
Driver 2: standstill, reads 39656, writes 14 timeouts 0, SG min/max 0/0
Driver 3: standstill, reads 39656, writes 14 timeouts 0, SG min/max 0/0
Driver 4: standstill, reads 39660, writes 11 timeouts 0, SG min/max 0/0
Driver 5: standstill, reads 39660, writes 11 timeouts 0, SG min/max 0/0
Date/time: 2020-07-27 20:36:50
Slowest loop: 3.82ms; fastest: 0.14ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 375, MinFreeDm: 373, MaxWait: 34018ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 1, completed moves: 1, 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 ready with "M122" 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: 0.88ms; fastest: 0.01ms
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: 0 of 8

Ethernet -
State: disabled
Error counts: 0 0 0 0 0
Socket states: 0 0 0 0 0 0 0 0
=== CAN ===
Messages sent 100, longest wait 0ms for type 0
=== Linux interface ===
State: 0, failed transfers: 0
Last transfer: 17ms ago
RX/TX seq numbers: 808/809
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.1.1
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 3.50

percyb

I have a similar issue, getting "Warning: motor phase A may be disconnected reported by driver(s)" on all drive ports with what were working stepper motors. Only possible mistake i made is connect one stepper motor to 3 pins instead of 4 ie offset one pin. Would this cause all drivers to die?

Touchthebitum

@percyb said in Short to ground on drivers 0123:

I have a similar issue, getting "Warning: motor phase A may be disconnected reported by driver(s)" on all drive ports with what were working stepper motors. Only possible mistake i made is connect one stepper motor to 3 pins instead of 4 ie offset one pin. Would this cause all drivers to die?

Impossible because I tested all phases before plugging motor and I checked if these big crimps went on the right place when connectind them on the Duet,

A Former User

@percyb said in Short to ground on drivers 0123:

I have a similar issue, getting "Warning: motor phase A may be disconnected reported by driver(s)"

ref https://forum.duet3d.com/post/100507 and you should probably start your own topic if the error persist after disconnecting your motors (when powered down ofc)

Touchthebitum

@bearer said in Short to ground on drivers 0123:

@percyb said in Short to ground on drivers 0123:

I have a similar issue, getting "Warning: motor phase A may be disconnected reported by driver(s)"

ref https://forum.duet3d.com/post/100507 and you should probably start your own topic if the error persist after disconnecting your motors (when powered down ofc)

I think we should think about a warranty process. I don't know what to add to the discussion. I repeat, it is not the first printer I build and I'm aware of risks. Before this Duet3 I used a Duet2 and was perfect (no errors messages) with the same motors. This board never worked and I directly plugged the SAME motors that I plugged to my Duet2. So there is a problem.
My shop told me to see with this forum, what I did.
Now, I choosed a Genuine board because I believe in the right intelectual properties and know-how.
Please, give me a clear answer and we can go on.
Thanks

A Former User

@Touchthebitum said in Short to ground on drivers 0123:

@bearer said in Short to ground on drivers 0123:

@percyb said in Short to ground on drivers 0123:

I have a similar issue, getting "Warning: motor phase A may be disconnected reported by driver(s)"

ref https://forum.duet3d.com/post/100507 and you should probably start your own topic if the error persist after disconnecting your motors (when powered down ofc)

I think we should think about a warranty process.

that was not directed at you; I'm sure dc42 is trying to evaluate the information you've provided already

Touchthebitum

@bearer said in Short to ground on drivers 0123:

@Touchthebitum said in Short to ground on drivers 0123:

@bearer said in Short to ground on drivers 0123:

@percyb said in Short to ground on drivers 0123:

I have a similar issue, getting "Warning: motor phase A may be disconnected reported by driver(s)"

ref https://forum.duet3d.com/post/100507 and you should probably start your own topic if the error persist after disconnecting your motors (when powered down ofc)

I think we should think about a warranty process.

that was not directed at you; I'm sure dc42 is trying to evaluate the information you've provided already

Thanks