Short to ground on drivers 0123
-
@bearer
Is there not? OK, Every other stepper I've ever used (not that many) has always been B-G-R-B.In that case ignore me
-
@Touchthebitum said in Short to ground on drivers 0123:
I don't know whhat to do because I tried to swapped wires many times.
one wrong combination where you let one side of the h bridge drive against the other is enough to cause this issue.
-
@bearer said in Short to ground on drivers 0123:
@Touchthebitum said in Short to ground on drivers 0123:
I don't know whhat to do because I tried to swapped wires many times.
one wrong combination where you let one side of the h bridge drive against the other is enough to cause this issue.
On every drivers and without plugged motors ?
-
@Touchthebitum said in Short to ground on drivers 0123:
On every drivers and without plugged motors ?
driver 5 and 6 are okay arent they? and yes, the error will persist after unplugging the motor if you got the "correct" wrong combination.
-
@bearer said in Short to ground on drivers 0123:
@Touchthebitum said in Short to ground on drivers 0123:
On every drivers and without plugged motors ?
driver 5 and 6 are okay arent they? and yes, the error will persist after unplugging the motor if you got the "correct" wrong combination.
I didn't test the 5 and 6 drivers yet. I reflashed and erase everything to test again but always the same message.
With my Duet2 wifi, it worked before -
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) -
@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 -
@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.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@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. -
@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.01Here 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?
-
@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.
-
Were there any other error messages along with the short to ground errors?
-
@Phaedrux No, M122 had not error messages. Only those ground-short messages
-
When are where was the Duet 3 purchased?
-
-
Please send M122 and post the resulting output here.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
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
- Ethernet -
-
Thanks. Please try commanding the motors to move (without any motors connected) and repeat that. I am looking for the driver status to change.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
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
- Ethernet -
-
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?
