Duet 3 fails to start print
-
Was the loop back test the same result with the new Pi?
The ribbon could be bad, but would be unusual. You could make a small jumper cable harness to test instead of the ribbon cable.
Can you post some photos of your setup? Are there cables running close together in a drag chain or bundle?
-
here are the results from the SPI test on the PI 4:
spi mode: 4
bits per word: 8
max speed: 500000 Hz (500 KHz)FF FF FF FF FF FF
40 00 00 00 00 95
FF FF FF FF FF FF
FF FF FF FF FF FF
FF FF FF FF FF FF
DE AD BE EF BA AD
F0 0DAll the cables are pretty tightly fitted in a drag chain, as they were before, but here are pictures of the setup:
-
I followed this a bit deeper and went to Danal's original SPI test tool and ran the full test with the two jumper cables. My results came back identical to his except for SPI mode being 0x4 instead of 0x0. I'm not sure if that's making a difference or not, but the test tool reports my PI is all good to go?
-
How long is your ribbon cable? Is that the one that came with the board? Do you have another to test with or are you able to make up a jumper set?
This shows which pins are actually required.
-
Its the original ribbon cable that came with the wire and connector kit.
I could make a short ribbon cable and give that a go. The little jumpers I have aren't the nicest, but they should work.
Do you have a pin map for the orientation and exactly which pin is which on the duet? I was able to find one for the pi's, but this is as much detail as I can find on the duet doc site :
-
The pin numbers are printed on the silkscreen under the board - but of course that's not possible to read after its mounted! I have updated the documentation to show the numbering:
-
Ah that makes sense, I've got the board mounted to an acrylic plate, so I could have climbed under the machine to see that, thank you though!!
-
Update:
I tried switching out the SPI cable: the printer ran fine with the somewhat sketchy ribbon cable I made. Still saw the same issue, SPI reset after a minute or so of running.
- I'm going back to the X-axis, here's where I'm at -
I left the X-axis motor plugged, wires in the wire loom, but I took the set screw out of the pulley and de-tensioned the belt, letting the motor shaft just spin freely inside the pulley:
This ran for 10 - minutes with no issues (This is my slow descent into madness, so humor me with this rabbit hole - we're going to call 10 min+ running a success, more testing will follow). This verifies that everything with the motion control to this specific electrical and mechanical system are sound, which is good.
I then reattached the pulley to the motor shaft with the pulley still de-tensioned: this also ran for 10 minutes plus. This is all with the same basic cylinder G-code I've been using for the last few weeks mind you. Again, this verifies this further verifies that its not a signal to the motor issues, cable issue, driver issue, etc.
So then I reinstalled the belt, not quite as tight as I had it before, and within 2 minutes of running, I had a partial failure, which I've never seen before [console output below]:
3/20/2022, 1:17:19 PM Connection to Duet established
3/20/2022, 1:17:19 PM Warning: Lost connection to Duet (Board is not available (no header))
3/20/2022, 1:15:50 PM M24 Printing resumedThe print kept running after this. Maybe I'm going crazy, but somehow it seems like my old belt attachment system grounded the belt, while the new one completely isolates it in plastic. 5 minutes after this weird half failure happened, the system totally reset:
3/20/2022, 1:22:42 PM Warning: SPI connection has been reset
3/20/2022, 1:22:42 PM Connection to Duet established
3/20/2022, 1:22:38 PM Warning: Lost connection to Duet (Board is not available (no header))here's a picture of the old system -right side of the picture at the end of the 20x40 extrusion (again, its not pretty, I'm not proud of it, but it worked):
basically I cut a slit in the GT2 belt, and sandwiched it around an M5 bolt that clamped 2 plastic pieces around it. This bit into the aluminum as there are spots where the anodized coating is rubbed off. My theory is this somehow connects the belt to the aluminum extrusion piece - am I wrong?
Here's a picture of the new belt tensioner:
There's a connection between the pulley on the X-axis and ground, so that doesn't seem to be helping with the discharge issue. But it does seem like the belt is somehow the issue. I'm probably going to try the old tensioning system and see where that takes me.
-
I just updated 3.4 hoping to get some better error reporting on this issue, M122 reports don't provide anything interesting, but the DCS report log did:
Mar 20 16:52:11 Duet3 DuetControlServer[2555]: [warn] Bad data CRC32 (expected 0xcd39fe63, got 0x4b271ab2)
Mar 20 16:52:11 Duet3 DuetControlServer[2555]: [warn] Bad data CRC32 (expected 0xcd39fe63, got 0x4b271ab2)
Mar 20 16:52:11 Duet3 DuetControlServer[2555]: [warn] Bad data CRC32 (expected 0xcd39fe63, got 0x4b271ab2)
Mar 20 16:52:11 Duet3 DuetControlServer[2555]: [warn] Restarting transfer because the number of maximum retries has been exceeded
Mar 20 16:52:11 Duet3 DuetControlServer[2555]: [warn] Lost connection to Duet (Board is not available (no header))
Mar 20 16:52:11 Duet3 DuetControlServer[2555]: [info] Connection to Duet established
Mar 20 16:53:20 Duet3 DuetControlServer[2555]: [warn] SPI connection has been reset
Mar 20 16:53:20 Duet3 DuetControlServer[2555]: [info] Aborted job fileDoes this provide any clues?
-
At this point we've tried many software solutions and swapped out the cable and Pi. I think we should swap the Duet3. When and where did you purchase the Duet3?
-
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!
-
