Solved Duet 3 fails to start print
-
I already warrantied my board, this is the new one that I just got
-
@michaelr123 said in Duet 3 fails to start print:
I already warrantied my board, this is the new one that I just got
Sorry, What was the original board warrantied for? Same problem or something else?
-
No worries, you’re tackling lots of different problems on here! It was replaced under warranty for the same issue Unfortunately. That’s what’s making me think it’s my setup somehow.
-
I ran another test where I just did a no extrusion run of the same Gcode with the X-axis belt de-tensioned. It ran the whole job for an hour and a half with no issues.
I tried re-running the file, this time with the belt tensioned, and it failed with the same error after a few minutes.
I have a thin wire screwed into one of the back screws on the stepper motor, which has something like 250-500 ohms of resistance to the pulley. Is this enough of a connection to rule out some sort of static build up on the belt? Is there a better way to ground the system in regards to the belt?
-
@michaelr123 said in Duet 3 fails to start print:
Is there a better way to ground the system in regards to the belt?
In industrial systems they use grounding brushes. Which is just as it sounds. Conductive bristles that brush against the belt. The brush is tied to ground.
Is the hotend metal work grounded?
-
@phaedrux Yes, the hotend and X-axis stepper motor case were both grounded through the same connection.
-
@michaelr123 Are you using RRF + DSF 3.4? If no, please upgrade and check if that helps. If you are already running v3.4, make sure the Pi is properly mounted and that no external or stepper motor cable is running right next to the ribbon cable. The symptoms suggest that the link between the Duet and Pi picks up noise at some point which causes the connection aborts.
You can also try to reduce
SpiFrequencyin/opt/dsf/conf/config.jsonto 4MHz (4000000) and check if that improves things.Duet software engineer
-
There's nothing near the SPI cable other than the 24v in cable. To satisfy my curiosity, what is "close" for communication data lines to interfere with one another?
it seems like its something to do with the SPI connection, but if I remember correctly I've already tried going to standalone mode (I'll double check that). I looked up some of the log errors I saw and they were CRC32 errors, which is an error checking function for parity.
I'll try reducing the SPI frequency and see where that takes me.
Also yes I upgraded to 3.4 before testing over the last two days, same issues, but now its reporting these CRC32 errors, which maybe is part of the improved error reporting?
-
Unfortunately that didn't work either.
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.0 (2022-03-15 18:57:24) running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-9P63L-DJ3T8-6J1D4-3SD6R-9U479
Used output buffers: 1 of 40 (12 max)
=== RTOS ===
Static ram: 151000
Dynamic ram: 65996 of which 0 recycled
Never used RAM 133676, free system stack 219 words
Tasks: SBC(resourceWait:,0.5%,484) HEAT(notifyWait,0.0%,321) Move(notifyWait,0.0%,352) CanReceiv(notifyWait,0.0%,944) CanSender(notifyWait,0.0%,374) CanClock(delaying,0.0%,333) TMC(notifyWait,7.8%,92) MAIN(running,91.6%,1219) IDLE(ready,0.1%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:06:37 ago, cause: software
Last software reset at 2022-03-26 09:08, reason: AssertionFailed, GCodes spinning, available RAM 133436, slot 2
Software reset code 0x4123 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00427000 BFAR 0x00000000 SP 0x2041b56c Task MAIN Freestk 1697 ok
Stack: 000004ee 0048fb8c 00408dfd 2042c2f8 20429f48 00000000 0a94f0af a5a5a5a5 a5a5a5a5 a5a5a5a5 0045c7fb 00000000 2042c2fc 00000001 2041b5ac 00000101 00000100 2042407c 00000000 00000000 ffffffed 00000000 00000000 00000000 00000000 00000000 00000000
Error status: 0x00
Step timer max interval 133
MCU temperature: min 47.2, current 48.4, max 48.5
Supply voltage: min 23.9, current 23.9, max 23.9, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.1, max 12.2, 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 0, mspos 8, reads 56975, writes 11 timeouts 0
Driver 1: standstill, SG min 0, mspos 184, reads 56972, writes 14 timeouts 0
Driver 2: standstill, SG min 0, mspos 8, reads 56972, writes 14 timeouts 0
Driver 3: standstill, SG min 0, mspos 8, reads 56972, writes 14 timeouts 0
Driver 4: standstill, SG min 0, mspos 1000, reads 56972, writes 14 timeouts 0
Driver 5: standstill, SG min 0, mspos 8, reads 56975, writes 11 timeouts 0
Date/time: 2022-03-26 09:14:38
Slowest loop: 1.09ms; fastest: 0.06ms
=== Storage ===
Free file entries: 10
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, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
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 ===
Segments left: 0
Movement lock held by 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
Code queue is empty
=== CAN ===
Messages queued 3575, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 1989/0/0
Tx timeouts 0,0,1988,0,0,1585 last cancelled message type 4514 dest 127
=== SBC interface ===
Transfer state: 4, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 24428/15428
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0, IAP RAM available 0x2b880
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server v3.4.0
Code buffer space: 4096
Configured SPI speed: 4000000Hz, TfrRdy pin glitches: 10
Full transfers per second: 38.82, max time between full transfers: 47.3ms, max pin wait times: 41.4ms/4.5ms
Codes per second: 0.98
Maximum length of RX/TX data transfers: 3408/1408The DCS log shows lost connection to duet (board is not available (no header))
connection established
SPI connection has been resetI saw a thread around the 5v pin to the sbc from duet, or the other way around, is there anything going on there?
-
I think I made a break through!!
I tried grounding a bunch more things:
-
I drove screws through the belt on both sides on threaded into the 20x40 extrusion
-
made a connector for the back of the X axis stepper shaft
*I pulled the wires out of the drag chain
None of this worked, What did work, or is working so far, was to tie a wire from ground to the screw post I put into the X-axis aluminum extrusion through the belt. It might not be anything to do with the stepper motors or belts, what I think it could be is this screw that mounts my extruder to the plastic plate scraping along the aluminum extrusion, or maybe some other source. I can see where the anodized coating is worn away long the X-axis. I'm not sure if a metal screw scraping along, or very nearly scraping along each other would cause static to build up, but this would mitigate that.
After making this change I ran the test Gcode I've been using for over an hour and it completed successfully. Adding in the hemera extruder was part of my most recent changes, and the mounting method I came up with could have created the static issue I was seeing. If I would have used a button head screw maybe I could have avoided all of this!!
I'll run some test prints tomorrow and report back!
-
-
well so far so good! I ran around 5 hours worth of prints yesterday and everything ran great!
I have no idea why grounding the floating X-axis fixes the problem but it seems to be looking pretty good.
-
undefined Phaedrux has marked this topic as solved
