Duet 3 6HC with defect driver

[WillGIam]

Hi all together,

After a few days of troubleshooting I´m now trying to get some help here.

I have a duet 3 with defect (burned) driver 0.1. I desoldered it and now tried to configurate the other motors. I planned to use 0.5 for Y instead. After setting everything up Im getting not errors and can run the X motor, but non of the others. I tried different motors at different drivers and I´m clear now it has something to do with board. To make sure I didnt destroy something while desoldering the chip I was measuring the lanes that came from driver 1 to 2. everything fine. Is there a way to do some more troubleshooting? M122 is pretty useless in this case, because its saying even driver 1 (which is not existing...) is ok. I dont have a problem to solder, but I dont want to guess anymore.

i remember from my duet 2s, that I had some boards with defect drivers and could still use the others. Is there something of a daisy chained thing that the duet 3 now needs? Do I need to do something for the SDO Pin for example? I´m a bit unsure.

Hopefully its just a semicolon missing in my config...

I commented out the Z drivers, because I didnt connect them yet. Also some other things for troubleshooting.

; Configuration file for RepRapFirmware on Duet 3 Main Board 6HC
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v3.5.0-rc.2+6 on Fri Feb 02 2024 18:22:26 GMT+0100 (Mitteleuropäische Normalzeit)

; General
M550 P"WWBot" ; set hostname

; Accessories
;M575 P1 S0 B57600 ; configure PanelDue support

; Network
M552 P0.0.0.0 S1 ; configure Ethernet adapter
M586 P0 S1 ; configure HTTP

; Smart Drivers
M569 P0.0 S1 D2 ; driver 0.0 goes forwards (X axis)
M569 P0.1 R-1 ; defect driver 0.1
;M569 P0.2 S1 D2 ; driver 0.2 goes forwards (Z axis)
M569 P0.3 S1 D2 ; driver 0.3 goes forwards (extruder 0)
;M569 P0.4 S1 D2 ; driver 0.4 goes forwards (Z axis)
M569 P0.5 S1 D2 ; driver 0.5 goes forwards (Y axis)

; Motor Idle Current Reduction
M906 I30 ; set motor current idle factor
M84 S30 ; set motor current idle timeout

; Axes
M584 X0.0 Y0.5 Z0.2:0.4 ; set axis mapping
M350 X16 Y16 Z16 I1 ; configure microstepping with interpolation
M906 X800 Y800 Z800 ; set axis driver currents
M92 X80 Y80 Z400 ; configure steps per mm
M208 X0:300 Y0:300 Z0:200 ; set minimum and maximum axis limits
M566 X900 Y900 Z12 ; set maximum instantaneous speed changes (mm/min)
M203 X36000 Y36000 Z180 ; set maximum speeds (mm/min)
M201 X20000 Y20000 Z20 ; set accelerations (mm/s^2)

; Extruders
M584 E0.3 ; set extruder mapping
M350 E16 I1 ; configure microstepping with interpolation
M906 E1000 ; set extruder driver currents
M92 E420 ; configure steps per mm
M566 E120 ; set maximum instantaneous speed changes (mm/min)
M203 E3600 ; set maximum speeds (mm/min)
M201 E250 ; set accelerations (mm/s^2)

; Kinematics
M669 K0 ; configure CoreXY kinematics

; Probes
;M558 K0 P1 C"io2.in" H5 F120 T6000 ; configure analog probe via slot #0
;G31 P500 X0 Y0 Z0.7 ; set Z probe trigger value, offset and trigger height

; Endstops
;M574 X1 S3 ; configure X axis endstop
;M574 Y1 S3 ; configure Y axis endstop
;M574 Z1 S2 ; configure Z axis endstop

; Mesh Bed Compensation
;M557 X25:275 Y25:275 S40:40 ; define grid for mesh bed compensation

; Sensors
M308 S0 P"temp0" Y"thermistor" A"Heated Bed" T100000 B4725 C7.06e-8 ; configure sensor #0
M308 S1 P"temp1" Y"thermistor" A"Nozzle" T100000 B4725 C7.06e-8 ; configure sensor #1

; Heaters
M950 H0 C"out0" T0 ; create heater #0
M143 H0 P0 T0 C0 S140 A0 ; configure heater monitor #0 for heater #0
M307 H0 R2.43 D5.5 E1.35 K0.56 B1 ; configure model of heater #0
M950 H1 C"out1" T1 ; create heater #1
M143 H1 P0 T1 C0 S285 A0 ; configure heater monitor #0 for heater #1
M307 H1 R2.43 D5.5 E1.35 K0.56 B0 ; configure model of heater #1

; Heated beds
M140 P0 H0 ; configure heated bed #0

; Fans
M950 F0 C"out3" ; create fan #0
M106 P0 S0 L0 X1 B0.1 ; configure fan #0
M950 F1 C"out4" ; create fan #1
M106 P1 S0 B0.1 H1 T45 ; configure fan #1

; Tools
M563 P0 D0 H1 F0 ; create tool #0
M568 P0 R0 S0 ; set initial tool #0 active and standby temperatures to 0C

M122 gives:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5.0-rc.3 (2024-01-24 17:58:49) running on Duet 3 MB6HC v1.01 (standalone mode)
Board ID: 08DJM-956L2-G43S8-6J1D8-3SJ6P-9B0QG
Used output buffers: 3 of 40 (18 max)
=== RTOS ===
Static ram: 155184
Dynamic ram: 119528 of which 0 recycled
Never used RAM 71280, free system stack 208 words
Tasks: NETWORK(1,ready,39.9%,148) ETHERNET(5,nWait 7,0.2%,467) HEAT(3,nWait 1,0.0%,323) Move(4,nWait 6,0.0%,336) CanReceiv(6,nWait 1,0.0%,940) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,336) TMC(4,nWait 6,8.6%,56) MAIN(1,running,50.9%,103) IDLE(0,ready,0.3%,30), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:00:41 ago, cause: power up
Last software reset at 2024-02-07 14:06, reason: User, Gcodes spinning, available RAM 70744, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
MCU temperature: min 34.5, current 42.4, max 42.5
Supply voltage: min 23.9, current 23.9, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.2, max 12.3, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: ok, SG min 0, mspos 0, reads 32873, writes 16 timeouts 0
Driver 1: ok, SG min 0, mspos 0, reads 32878, writes 11 timeouts 0
Driver 2: ok, SG min 9, mspos 9, reads 32876, writes 14 timeouts 0
Driver 3: ok, SG min 9, mspos 9, reads 32874, writes 16 timeouts 0
Driver 4: ok, SG min 9, mspos 9, reads 32876, writes 14 timeouts 0
Driver 5: ok, SG min 9, mspos 9, reads 32874, writes 16 timeouts 0
Date/time: 2024-02-07 14:15:33
Slowest loop: 6.13ms; fastest: 0.07ms
=== Storage ===
Free file entries: 20
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 2.5ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, 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
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0000000
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 372, received 0, lost 0, errs 195522, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 208/0/0
Tx timeouts 0,0,207,0,0,163 last cancelled message type 4514 dest 127
=== Network ===
Slowest loop: 6.17ms; fastest: 0.03ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
= Ethernet =
Interface state: active
Error counts: 0 0 0 1 0 0
Socket states: 5 2 2 2 2 0 0 0
=== Multicast handler ===
Responder is inactive, messages received 0, responses 0

And M115 gives:

FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.5.0-rc.3 ELECTRONICS: Duet 3 MB6HC v1.01 FIRMWARE_DATE: 2024-01-24 17:58:49
7.2.2024, 14:15:51	

Have a nice day.
William

[jay_s_uk]

@WillGIam the SPI comms for the drivers are daisy chained. If you remove a driver you will have to account for that to get the remainder of the drivers working

[dc42]

@WillGIam it's as @jay_s_uk says. Desoldering the driver without messing up the traces is harder than soldering a new one, so I suggest you clean up the pads a little, add some no-clean flux and solder a new driver on. Where you have solder bridges between pads, check against the PCB layout extract that you posted whether those traces are connected together anyway.

BTW are you certain it was the driver chip that has failed and not the output mosfets?

A hint for next time you desolder or solder something using hot air: use thermal insulating tape (e.g. Cold Gold) to protect adjacent plastic parts and electrolytic capacitors.

[WillGIam]

@jay_s_uk Thanks a lot for your answer! I´m not sure if I´m getting this right: When looking into the Trinamic datasheet it seems like the SDO pin is the only SPI pin that is daisy chained? Chipselect, CLK, etc are not - right?

If so it should be possible to create a connection between Pin 15 and 16 of driver 1 to connect "driver_0_SDO" and "driver_1_SDO" right? Just for my understanding.

@dc42 Thanks for youre answer too!

@WillGIam it's as @jay_s_uk says. Desoldering the driver without messing up the traces is harder than soldering a new one

I´m not sure if I´m getting this right too You mean because I already desoldered it? I´ll give it a try.

BTW are you certain it was the driver chip that has failed and not the output mosfets?

Yes, I am. It burned and hat a whole in it haha. But it was´nt me.

A hint for next time you desolder or solder something using hot air: use thermal insulating tape (e.g. Cold Gold) to protect adjacent plastic parts and electrolytic capacitors.

Thanks for that advice, I actually did, but had to subsequently resolder a part - was not my best idea.

[jay_s_uk]

@WillGIam yes, that pretty much it. you should be able to connect those 2 pins and the rest of the drivers will work

[WillGIam]

@jay_s_uk Thanks a lot!

[dc42]

@WillGIam before you try soldering a new driver in, check the output mosfets for short circuits. It may be that one of them has a short circuit to the gate and that is what damaged the driver.

Connecting SDI to SDO on the pads of the removed driver isn't going to work unless you change the firmware to account for having 5 drivers in the chain instead of 6.

[WillGIam]

@dc42 Thanks for your hint with the Mosfets, I´ll check that, if I find them.

Can you help me understanding why I need to change that? Driver 0.0 is working, so it seems like he is not caring about the length of the chain? Only the drivers "behind" the 0.1 are not working, so I thought it would be a physical problem of the daisy chained SDO pins. After soldering DRIVER_0_SDO to DRIVER_1_SDO the problem is still the same - but why? I thought the firmware would only try to reach the drivers if they are configured. From this point the firmware shouldnt care if the SDO Pins are jumpered.

[dc42]

@WillGIam RRF sends 6 packets of data to SDI of the first driver in the chain and simultaneously reads 6 packets of data from SDO of the last driver. Without driver 1 it will be able to program driver 0 only and read the status of drivers 2 thru 5 only. If you bypass driver 1 then it will be able to program all 5 remaining drivers although drivers 2 thru 5 will be programmed as if they are drivers 1 thru 4. It will also read the status of all 5 remaining drivers, but the reported driver 0 status will be incorrect, the reported driver 2 status will be the actual driver 0 status, and the reported driver 3 thru 5 status will be the actual driver 2 thru 4 status. So the status reports will be incorrect.

[WillGIam]

@dc42 So I would not only need to set down the chain to 5, I also need to delete the pins for 0.1 as a driver?

Since the shipping to germany for this drivers is at about 20€, the best way would be to buy a breakout board and desolder the chip from it... But to be honest, I dont need 6 drivers, if editing the firmware is´nt that hard, I would go this way.

[WillGIam]

@dc42 Okay, I now desoldered another TMC5160 from one of my extension boards. The problem remains still the same. The Mosfets from what I was able to measure are looking just like the compared other drivers.

Is there a way to troubleshoot and get some more informations from the firmware? M122 is always saying everything is okay, even without the driver. I would like to make sure the new driver is soldered correctly.

[dc42]

@WillGIam what problems are there now that you have replaced the driver, and what driver status does M122 report?

btw either TMC5160 or TMC2160 (with or without letter A on the end) may be used.

[WillGIam]

@dc42 The problem stays the same. I can use driver 0.0 but no other drivers.

I tried measuring everything and cant find the error. But I checked driver 1 A+, A- B+ and B- and get about 8V to ground on every pin. With driver 0 I get 2V - There seems to be something wrong, but I dont really understand if these pins are directly used, or over a mosfet. Maybe you can help me here.

This is what I get with M122:

=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5.0-rc.3 (2024-01-24 17:58:49) running on Duet 3 MB6HC v1.01 (standalone mode)
Board ID: 08DJM-956L2-G43S8-6J1D8-3SJ6P-9B0QG
Used output buffers: 3 of 40 (18 max)
=== RTOS ===
Static ram: 155184
Dynamic ram: 119528 of which 0 recycled
Never used RAM 71280, free system stack 210 words
Tasks: NETWORK(1,ready,41.0%,162) ETHERNET(5,nWait 7,0.1%,317) HEAT(3,nWait 1,0.0%,323) Move(4,nWait 6,0.0%,336) CanReceiv(6,nWait 1,0.0%,940) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,336) TMC(4,nWait 6,8.8%,56) MAIN(1,running,50.0%,103) IDLE(0,ready,0.1%,30), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:02:49 ago, cause: power up
Last software reset at 2024-02-13 14:12, reason: User, Gcodes spinning, available RAM 70352, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
MCU temperature: min 24.4, current 37.7, max 37.8
Supply voltage: min 23.9, current 24.0, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.2, max 12.3, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min n/a, mspos 8, reads 18983, writes 17 timeouts 0
Driver 1: standstill, SG min n/a, mspos 8, reads 18987, writes 14 timeouts 0
Driver 2: standstill, SG min n/a, mspos 8, reads 18985, writes 16 timeouts 0
Driver 3: standstill, SG min n/a, mspos 8, reads 18985, writes 16 timeouts 0
Driver 4: standstill, SG min n/a, mspos 8, reads 18988, writes 13 timeouts 0
Driver 5: standstill, SG min n/a, mspos 8, reads 18988, writes 13 timeouts 0
Date/time: 2024-02-13 15:09:12
Slowest loop: 3.01ms; fastest: 0.07ms
=== Storage ===
Free file entries: 20
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 2.2ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, 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
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0000000
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 1520, received 0, lost 0, errs 795564, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 846/0/0
Tx timeouts 0,0,845,0,0,673 last cancelled message type 30 dest 127
=== Network ===
Slowest loop: 4.32ms; fastest: 0.03ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
= Ethernet =
Interface state: active
Error counts: 0 0 0 1 0 0
Socket states: 5 2 2 2 2 0 0 0
=== Multicast handler ===
Responder is inactive, messages received 0, responses 0

[WillGIam]

@dc42 Do you think. there is a way to fix this?

[T3P3Tony]

@WillGIam the issue is its difficult to diagnose remotely if the driver not fitted does not have a short or other issue, and if the MOSFETs are actually faulty or not.

@WillGIam said in Duet 3 6HC with defect driver:

driver 1 A+, A- B+ and B- and get about 8V to ground on every pin. With driver 0 I get 2V

the schematic is here:
https://github.com/Duet3D/Duet3-Mainboard-6HC/blob/master/Duet3_Mainboard_6HC_v1.02/Duet3_MB_6HC_Schematic_v1.02.pdf

Which may allow you to do some comparative probing to see whats going on. The output diodes and mosfets are in pretty small packages so not necessarily easy to remove using hot air, but possible.