RRF can't "see" any of the stepper drivers, over night.
-
@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
