@droftarts I have everything disconnected from the board and powered it up with 48V in. No change in behavior from the response that was described above unfortunately. I have removed the board from the printer, a quick visual inspection doesn't indicate anything that is obviously crispy / failed.
The overcurrent situation you described seems like a likely candidate, mainly given that I was playing with stealthchop during this event.
Hello,
I fear my Duet 3 6HC is toast: the smoke has come out of it. I figure I will report it here just in case there is some recourse and hopefully get a sense of what the root cause is.
Here is a photo of where I think the issue appears to be on driver 1. See the dots on the TMC2160 drivers. Visual inspection of the board seems to look normal otherwise.
I have running a Duet 3 MB6HC on RRF 3.5.4 SBC mode with 2x 3HC Expansion Boards. It has been working pretty solidly for the better part of a year now. The motor current was set to 800-1000mA (I forget exactly what I set it to, but definitely somewhere in this range)
Here is the sequence of events that got me here:
0.) Initial setup was working fine with 2x NEMA 23 Y-axis motors, running without issue for months. I decided to swap in NEMA 17 to see if I could get it to run quieter.
1.) Initial setup working fine with NEMA 17 Y-axis motors, but I missed the accelerations and speeds I could achieve with the NEMA 23.
2.) I reverted the NEMA 17s back to the NEMA 23s motors (wiring verified; proper coil pairs, no shorts).
3.) On first power-up after swap, heard an audible electrical snap and saw smoke. This was maybe a second after I powered it on, I don't think it had got to the point of running the config file yet. I yelped in surprise and powered off immediately.
4.) Disconnected all motors, outputs, and sensors. Powered up again. Board booted successfully. M122 reported all drivers as "ok". Web interface and MCU appeared functional.
5.) Gradually reconnected components: a) Plugged in all I/O except drivers b) Then connected X motor alone into driver 0.
6.) On powering up: sparks emitted from area near driver 1 (not driver 0).
7.) Powered off, unplugged X motor from driver 0, powered on again — sparks reappeared at same location.
8.) Board now fully powered off and removed from printer.
I checked the NEMA 23 motor associated with driver 1 and the NEMA 17 motor associated with driver 0. The wires show continuity, the coils for each motor measure as expected, and no shorts to the motor housing are found.
Here is the M122 response
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5.4 (2024-11-24 10:47:10) running on Duet 3 MB6HC v1.02 or 1.02a (SBC mode)
Board ID: 0JD2M-9P9DA-F0PSD-6JTD0-3S86S-TNT72
Used output buffers: 1 of 40 (23 max)
=== RTOS ===
Static ram: 155464
Dynamic ram: 97720 of which 0 recycled
Never used RAM 92808, free system stack 202 words
Tasks: ACCEL(6,nWait 6,0.0%,343) SBC(2,rWait:,0.9%,801) HEAT(3,nWait 6,0.0%,321) Move(4,nWait 6,0.0%,335) CanReceiv(6,nWait 1,0.0%,796) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,348) TMC(4,nWait 6,9.1%,55) MAIN(2,running,89.7%,101) IDLE(0,ready,0.2%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:03:01 ago, cause: power up
Last software reset at 2025-04-02 10:15, reason: User, Platform spinning, available RAM 92096, slot 2
Software reset code 0x6000 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
MCU temperature: min 20.4, current 33.0, max 33.1
Supply voltage: min 47.7, current 47.8, max 47.9, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.3, max 12.5, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 7 queued, 7 completed
Driver 0: ok, SG min 0, mspos 0, reads 23706, writes 16 timeouts 0
Driver 1: ok, SG min 0, mspos 0, reads 23705, writes 17 timeouts 0
Driver 2: ok, SG min 9, mspos 9, reads 23707, writes 16 timeouts 0
Driver 3: ok, SG min 9, mspos 9, reads 23707, writes 16 timeouts 0
Driver 4: ok, SG min 9, mspos 9, reads 23707, writes 16 timeouts 0
Driver 5: ok, SG min 9, mspos 9, reads 23707, writes 16 timeouts 0
Date/time: 2025-04-02 10:28:36
Slowest loop: 26.76ms; fastest: 0.06ms
=== Storage ===
Free file entries: 20
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 ===
DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 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 2 3 4 5 6 7 -1 -1 -1 -1 -1 -1, chamber heaters 8 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, null
HTTP* is doing "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
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x80000003
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== Filament sensors ===
check 0 clear 0
Extruder 2 sensor: no data received
=== CAN ===
Messages queued 1618, received 4997, lost 0, errs 0, boc 0
Longest wait 2ms for reply type 6060, peak Tx sync delay 5, free buffers 50 (min 49), ts 909/908/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 6424/6424
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x24cfc
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.5.4 (2024-11-25 17:29:06, 32-bit)
HTTP+Executed:
Executing M122
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 8.44, max time between full transfers: 37.7ms, max pin wait times: 33.7ms/2.0ms
Codes per second: 0.21
Maximum length of RX/TX data transfers: 5725/1176
Anyways, I am hoping to see if there is any way to repair (seems unlikely) or other recourse, and if anyone has ideas on what the root cause could be.
@droftarts it is definitely the 12V LED, I think I mischaracterized it above since the blinking was so fast and dim that I mistook it for red rather than amber. Looking at the actual LED label, it is the 12V LED.
Here is a photo with an arrow indicating which LED was flickering ever so dimly. FYI the photo is taken immediately after shutdown since the V_FUSED LED was too bright to see anything around it in the photo when powered on. 
Also, perhaps notably, I have been driving the motor current set at M906 Y4400 for this motor which drives a NEMA 34 moving a fairly hefty gantry.
Hello,
I have been running a 1HCL for about 6 months without issue.
Today, I made a change to the driver setup going from M569 P50.0 S1 D2 V5 to M569 P50.0 S1 D3 V1000. I also increased the microstepping to x64 for this motor.
Upon the first test print I noticed that it sounded "clunky" when it went to travel moves, and then I noticed the motor associated with this board was no longer moving. Paused print and saw that the indication on the board LEDs was the fast flashing as if the CAN connection failed.
I then power cycled and got "CAN Response Timeout". Then I tried jumping the CAN_RST, power on, wait 5 min, power down, remove jumper, and power up. Same issue: with timeout on communication. The blue "Fused" LED is on, but I have no red Status nor green LED. The red 12V LED is blinking very fast and dimly.
Any ideas on what else I can do? I am worried I am toast now, and also don't want to fry a replacement board if this config change caused the board to go bad somehow.
I have also replicated this issue with firmware version 3.5.4 using Orcaslicer GCODE. I was able to recover operation by toggling off "Exclude Objects"
Oddly, this was working fine for slicing normal STL files but occurred when I was running Orcaslicer's built-in pressure advance calibration tests.
@dc42 I hadn't taken a measurement from the bed previously. I just tried that out and you are correct, the EI3 shaper was able to cover the relevant frequencies for me on both the X/Y axes in addition to the Z resonance. There is some trade-off, but I will run some test prints next to see if the magnitude of the remaining vibration is worth worrying about.
Just adding for the record that this would be helpful for printers with large area beds. On my printer which is roughly 1x1x1m, I get a Z resonance that is similar to how a drum vibrates.
My solution now is go slow with Z motions, stiffen it up, etc.... But it would be nice to have a software firmware solution to help address this from the input side.
Hello,
I just experienced a mid-print failure associated with the message:
"Connection interrupted, attempting to reconnect...
DCS has been stopped"
My print was ~30% complete when this occurred, but the printer state was as if the print completed successfully: on the Job > Status page it had the option for Print Again, and the heaters were turned off. I checked the GCODE file and it looks fine, i.e. there is a full file worth of GCODE.
For context, I am running:
There is another thread from 4 years ago with the same issue but it seems it was marked as resolved with a new firmware revision.
I am now trying the print again now to see if I can replicate the behavior.