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? -
@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 0I 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 totake 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.
-
@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.
-
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?
-
@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.
-
@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.
-
@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 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.
-
@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 -
Quite strange. When and where was the board purchased?
-
@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).
-
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.
-
Thanks @Phaedrux, mail sent
-
@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. -
@jonasr75 Best to start a new thread. Provide all the details including your config.g and a photo of your driver.
-
@Phaedrux ok, i have started a new thread:
https://forum.duet3d.com/topic/33921/homing-error-in-x-y-axes -
undefined Exerqtor referenced this topic
