RRF can't "see" any of the stepper drivers, over night.

Exerqtor

@gloomyandy said in RRF can't "see" any of the stepper drivers, over night.:

@Exerqtor Might also be worth posting a high res picture of the board (when powered on so any leds can be checked).

Tried my best with the pics:
alt text

(Regarding the plug on IO_0 / PanelDue being a JST connector, it's just temporary until I get some 5pin molex connectors.)

I should add that I've tried to reinstal RFF 3.5b4 with no luck, roll back to 3.5b2 with no luck and now i'm back on 3.5b4 since it didn't help.

Could totally whiping the firmware of the board and doing a fresh install with bosa maybe be a way to go? 🤔

dc42

@Exerqtor as RRF has failed to find any of the stepper drivers, it looks as though UART communication with them has failed. Here are some possible reasons for that:

No power reaching the stepper drivers. Power is reaching the VIN measurement circuit, so the fuse should be OK.
Something has gone wrong with the circuitry that interfaces to the drivers via UART.
One of the drivers has failed and in doing so has shorted out the UART signal, thereby interrupting the comms with the other drivers too.

Does any of the TMC2209 stepper driver chips show signs of damage?

Exerqtor

@dc42 I've had a good look at them and i can't see any damage, misscoloring, cracks etc. That goes for the rest of the board too TBH. everything looks mint, can't smell any magic smoke residue either.

Exerqtor

@dc42 said in RRF can't "see" any of the stepper drivers, over night.

Does any of the TMC2209 stepper driver chips show signs of damage?

Here is some macro pictures of the drivers:
alt text

Exerqtor

Don't know if it's some kind of measurements or tests i should do, or if the next step should be a waranty return or something?

Phaedrux

Can you disconnect all wiring except for USB?
Does anything get hot to the touch shortly after connecting usb power?

Exerqtor

@Phaedrux said in RRF can't "see" any of the stepper drivers, over night.:

Can you disconnect all wiring except for USB?
Does anything get hot to the touch shortly after connecting usb power?

I'll try it this afternoon. Regarding heat i haven't noticed anything, either right after turning the printer on or while standing there idle. I haven't got a thermal camera so i can't say it ain't any "blips" with hot spots when it boots though.

Oook, that's fucking weird (pardon my french)... I just disconnected everything except the CAN connector, bed (out0), wifi antenna & power to the board. Fired it up, and the problem was still there.
So i pulled the whole board out of the machine and powered it by USB with only the wifi antenna connected, now all drivers show up again:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.5.0-beta.4 (2023-06-08 23:40:14) running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: DXGUZ-U196U-D65J0-40KMN-1Y03Z-RKST9
Used output buffers: 1 of 40 (18 max)
Error in macro line 56 while starting up: Response timeout: CAN addr 121, req type 6018, RID=0
=== RTOS ===
Static ram: 102996
Dynamic ram: 123720 of which 40 recycled
Never used RAM 12444, free system stack 146 words
Tasks: NETWORK(1,ready,6.3%,243) HEAT(3,nWait,0.0%,343) Move(4,nWait,0.0%,358) CanReceiv(6,nWait,0.0%,939) CanSender(5,nWait,0.0%,337) CanClock(7,delaying,0.0%,342) TMC(4,nWait,0.0%,124) MAIN(1,running,43.8%,704) IDLE(0,ready,49.1%,29) AIN(4,delaying,0.8%,274), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:00:48 ago, cause: power up
Last software reset at 2023-08-20 10:59, reason: User, Gcodes spinning, available RAM 9188, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU revision 3, ADC conversions started 48829, completed 48829, timed out 0, errs 0
MCU temperature: min 21.7, current 22.6, max 25.1
Supply voltage: min 0.5, current 0.9, max 0.9, under voltage events: 0, over voltage events: 0, power good: no
Heap OK, handles allocated/used 99/31, heap memory allocated/used/recyclable 2048/968/508, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 1: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 2: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 3: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 4: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 5: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 6: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Date/time: 2023-08-23 17:24:30
Cache data hit count 44358833
Slowest loop: 5.58ms; fastest: 0.17ms
=== Storage ===
Free file entries: 18
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 3.7ms, write time 4.4ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
=== 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, 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 doing "G4 S1                                                                        " in state(s) 0 0, running macro
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 0x0000803
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 409, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 18 (min 17), ts 245/0/0
Tx timeouts 0,0,244,19,0,143 last cancelled message type 30 dest 127
=== Network ===
Slowest loop: 7.01ms; fastest: 0.00ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 2 of 8
= WiFi =
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
Firmware version 2.1beta4
MAC address d8:bf:c0:14:e6:36
Module reset reason: Power up, Vcc 3.32, flash size 2097152, free heap 43128
WiFi IP address 192.168.10.50
Signal strength -51dBm, channel 1, mode 802.11n, reconnections 0
Clock register 00002001
Socket states: 0 0 0 0 0 0 0 0

I powered it down again and started inspecting the board, and it looks like it's some kind of ressidue (like possibly solder paste or something) in the general area around Driver0 and it's surrouding caps, resistors etc.

I'll ~~try to~~ take a picture of the above mentioned ressidue, and try to clean just that spot. Then put it back in the machine and see what happens.
alt text

Exerqtor

@Phaedrux Ok, so I cleaned the board and powered it by USB again and all still seemed good..

So i put it back in the printer, ONLY connecting power and the wifi antenna. Booted, and: no drivers.

Phaedrux

Can you connect it to VIN for power when outside the printer and see if it still happens? And power by USB inside the printer?

Is there something shorting on the back of the board when it's installed?

Is there some mounting pressure flex when installed?

Exerqtor

@Phaedrux Yeah i can, and it's the same exact behaviour.

So it can only see the drivers if not powered by VIN.

Regarding how it's mounted, it's mounted with the stock Voron board mounts and click-on DIN rail mounts. Both printed in ABS, with ABS washers between the PCB and screws on the front side.

Nothing shorting it while inside the printer either.

When i had the board out of the machine it was still screwed on to the mounts, so twisting/pressure ain't the issue.

Phaedrux

@Exerqtor said in RRF can't "see" any of the stepper drivers, over night.:

So it can only see the drivers if not powered by VIN.

Can it see (and move) the drivers if powered by vin and usb at the same time? Be careful with USB ground loops.

Exerqtor

@Phaedrux i haven't tried that since i thought that was a big no-no i can try it this afternoon. What precautions should i take in regard to USB ground loops?

gloomyandy

@Exerqtor See https://docs.duet3d.com/User_manual/Overview/USB_ground_loops

Exerqtor

@gloomyandy said in RRF can't "see" any of the stepper drivers, over night.:

@Exerqtor See https://docs.duet3d.com/User_manual/Overview/USB_ground_loops

Of course it's covered in the docs, the "one" place i didn't look 🤦‍♂️

Ok so running the usb to a laptop running on battery sounds like the safest and easiest way to go. I'll do that later and report how it turns out.

Exerqtor

@Phaedrux said in RRF can't "see" any of the stepper drivers, over night.:

@Exerqtor said in RRF can't "see" any of the stepper drivers, over night.:

So it can only see the drivers if not powered by VIN.

Can it see (and move) the drivers if powered by vin and usb at the same time? Be careful with USB ground loops.

I just hooked up both VIN & powered it from USB via a laptop running on the battery. No drivers visible.

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.5.0-beta.4 (2023-06-08 23:40:14) running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: DXGUZ-U196U-D65J0-40KMN-1Y03Z-RKST9
Used output buffers: 10 of 40 (24 max)
=== RTOS ===
Static ram: 102996
Dynamic ram: 124276 of which 16 recycled
Never used RAM 11912, free system stack 156 words
Tasks: NETWORK(2,nWait,17.1%,215) HEAT(3,nWait,0.0%,352) Move(4,nWait,0.0%,358) CanReceiv(6,nWait,0.0%,672) CanSender(5,nWait,0.0%,337) CanClock(7,delaying,0.0%,351) TMC(4,nWait,0.3%,110) MAIN(1,running,81.5%,704) IDLE(0,ready,0.2%,29) AIN(4,delaying,0.8%,266), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:02:32 ago, cause: software
Last software reset at 2023-08-24 17:31, reason: User, Gcodes spinning, available RAM 12404, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU revision 3, ADC conversions started 152189, completed 152189, timed out 0, errs 0
MCU temperature: min 24.4, current 27.0, max 27.0
Supply voltage: min 24.0, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/29, heap memory allocated/used/recyclable 2048/588/192, gc cycles 2
Events: 0 queued, 0 completed
Driver 0: not present
Driver 1: not present
Driver 2: not present
Driver 3: not present
Driver 4: not present
Driver 5: not present
Driver 6: not present
Date/time: 2023-08-24 17:34:05
Cache data hit count 252956637
Slowest loop: 11.79ms; fastest: 0.14ms
=== Storage ===
Free file entries: 18
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 4.5ms, write time 4.4ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
=== 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, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 1 is on, I-accum = 0.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 doing "G4 S1                                                                        " in state(s) 0 0, running macro
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 0x0000803
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== Filament sensors ===
Extruder 0 sensor: no filament
=== CAN ===
Messages queued 1145, received 2609, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 6, free buffers 18 (min 18), ts 636/636/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 25.23ms; fastest: 0.06ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
= WiFi =
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
Firmware version 2.1beta4
MAC address d8:bf:c0:14:e6:36
Module reset reason: Power up, Vcc 3.31, flash size 2097152, free heap 43132
WiFi IP address 192.168.10.50
Signal strength -49dBm, channel 1, mode 802.11n, reconnections 0
Clock register 00002001
Socket states: 0 0 0 0 0 0 0 0

Phaedrux

Quite strange. When and where was the board purchased?

Exerqtor

@Phaedrux Yeah it's pretty weird, especially since it worked perfectly one evening, then this just happens while standing idle over night.

I just bought the board second hand from a dude here in Norway. He purchased the board from E3D in november 2022 (i have a printout of the order confirmation mail he got, with order number).

Phaedrux

Please send an email to warranty@duet3d.com and CC your reseller. Include a link to this forum thread and the details of your original purchase. You'll receive a reply with a form to fill out.

Exerqtor

Thanks @Phaedrux, mail sent

jonasr75

@Exerqtor said in RRF can't "see" any of the stepper drivers, over night.:

G1: G0/G1: insufficient axes homed

I follow the topic.
I have a similar problem, but not quite this one. I also get the following error message: "G1: G0/G1: insufficient axes homed". Could this not be an endstop problem? I have a DueX5 extension board as I drive 3 pcs Z nema17 stepper motors. However, on the DueX5 board, I see a small "crater" on the first chip of the TMC2660 stepper. Could this chip be broken and cause the homing process to fail? I haven't run the M122 command yet.