Duet 3 6HC with defect driver

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.