Duet 3 fails to start print
-
The other thing I would try is a fresh download and image of DuetPi.
-
So here's what I've done so far:
-Fresh install of duetPi on my raspberry PI 4, re-ran RRF configurator with the latest settings to get a clean config file set going.
-shielded cable install on X-axis stepper driver and for Z-probe
-moved x-axis stepper driver to output 0.4 to see if it was something up with the 0.0 driveHere's where I'm at:
I think I still am seeing the issue, but now I've seen it happen in an additional instance, I used the thermostatic cooler option for my coldside fan on my hemera which I kind of like, but then I accidently turned this on when I meant to turn on the part cooling fan, and this instantly gave me the same error that I've seen before, but for a different reason now. The M122 is listed below.
Other thought I had, is there any chance my ribbon cable is bad? Would that being faulty cause this type of issue?
M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.0rc2 (2022-02-22 17:04:17) 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 (14 max)
=== RTOS ===
Static ram: 150984
Dynamic ram: 65804 of which 0 recycled
Never used RAM 133884, free system stack 219 words
Tasks: SBC(resourceWait:,0.5%,506) HEAT(notifyWait,0.0%,353) Move(notifyWait,0.0%,352) CanReceiv(notifyWait,0.0%,944) CanSender(notifyWait,0.0%,374) CanClock(delaying,0.0%,343) TMC(notifyWait,7.3%,92) MAIN(running,91.2%,1245) IDLE(ready,0.9%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:00:18 ago, cause: software
Last software reset at 2022-03-14 16:06, reason: AssertionFailed, GCodes spinning, available RAM 133376, slot 0
Software reset code 0x4123 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x2041b504 Task MAIN Freestk 1675 ok
Stack: 00001014 004a3b10 00485807 00000000 2042ba18 20419a7c 2042d6e4 00000000 00000001 00000000 004844d7 2042d6e4 00000000 00000000 0048480f 00000000 00000000 20429860 2042d6e0 00000000 2042d6e4 20419a7c 00000000 55700d65 a5a5a5a5 a5a5a5a5 0048493b
Error status: 0x00
Step timer max interval 134
MCU temperature: min 50.6, current 50.9, max 50.9
Supply voltage: min 23.9, current 23.9, max 24.0, 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: pos 0, standstill, SG min 0, mspos 8, reads 39308, writes 11 timeouts 0
Driver 1: pos 0, standstill, SG min 0, mspos 40, reads 39305, writes 14 timeouts 0
Driver 2: pos 0, standstill, SG min 0, mspos 40, reads 39305, writes 14 timeouts 0
Driver 3: pos 0, standstill, SG min 0, mspos 888, reads 39305, writes 14 timeouts 0
Driver 4: pos 0, standstill, SG min 0, mspos 232, reads 39305, writes 14 timeouts 0
Driver 5: pos 0, standstill, SG min 0, mspos 8, reads 39308, writes 11 timeouts 0
Date/time: 2022-03-14 16:06:19
Slowest loop: 1.09ms; fastest: 0.05ms
=== 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 168, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 95/0/0
Tx timeouts 0,0,94,0,0,72 last cancelled message type 30 dest 127
=== SBC interface ===
Transfer state: 4, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 11267/750
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0, IAP RAM available 0x2b8b0
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server v3.4-rc2
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 45
Full transfers per second: 39.82, max time between full transfers: 131.9ms, max pin wait times: 57.0ms/3.3ms
Codes per second: 2.85
Maximum length of RX/TX data transfers: 3404/1664
3/14/2022, 4:06:02 PM Warning: M307: Heater 0 predicted maximum temperature at full power is 321°C
3/14/2022, 4:06:02 PM Warning: SPI connection has been reset -
And here's one after running for a few minutes on a print:
M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.0rc2 (2022-02-22 17:04:17) 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: 150984
Dynamic ram: 65804 of which 0 recycled
Never used RAM 133884, free system stack 219 words
Tasks: SBC(resourceWait:,0.6%,482) HEAT(notifyWait,0.0%,359) Move(notifyWait,0.0%,352) CanReceiv(notifyWait,0.0%,944) CanSender(notifyWait,0.0%,374) CanClock(delaying,0.0%,343) TMC(notifyWait,7.3%,92) MAIN(running,90.6%,1245) IDLE(ready,1.5%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:00:11 ago, cause: software
Last software reset at 2022-03-14 16:19, reason: MemoryProtectionFault mmarValid daccViol, GCodes spinning, available RAM 133668, slot 1
Software reset code 0x4163 HFSR 0x00000000 CFSR 0x00000082 ICSR 0x0044a804 BFAR 0xa5a5a5a6 SP 0x2041b520 Task MAIN Freestk 1682 ok
Stack: a5a5a5a5 2042b570 00000001 2042406c 00000002 0045c81b 00418cba 21000000 2042b400 00457c1b 2042b510 ffffff00 2042b570 20429f28 00000000 0045c6ef ffffffff 00000000 23d66c2b 00484b0f 2042b570 20429f28 00000000 23d66c2b a5a5a5a5 0045c81b 2042a980
Error status: 0x00
Step timer max interval 141
MCU temperature: min 50.7, current 50.9, max 51.0
Supply voltage: min 23.9, current 23.9, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.1, max 12.1, 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: pos 0, standstill, SG min 0, mspos 8, reads 313, writes 11 timeouts 0
Driver 1: pos 0, standstill, SG min 0, mspos 840, reads 310, writes 14 timeouts 0
Driver 2: pos 0, standstill, SG min 0, mspos 8, reads 310, writes 14 timeouts 0
Driver 3: pos 0, standstill, SG min 0, mspos 648, reads 310, writes 14 timeouts 0
Driver 4: pos 0, standstill, SG min 0, mspos 184, reads 311, writes 14 timeouts 0
Driver 5: pos 0, standstill, SG min 0, mspos 8, reads 314, writes 11 timeouts 0
Date/time: 2022-03-14 16:19:33
Slowest loop: 1.09ms; fastest: 0.05ms
=== 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 105, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 60/0/0
Tx timeouts 0,0,59,0,0,44 last cancelled message type 30 dest 127
=== SBC interface ===
Transfer state: 4, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 42465/476
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0, IAP RAM available 0x2b8b0
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server v3.4-rc2
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 71
Full transfers per second: 39.25, max time between full transfers: 66.1ms, max pin wait times: 59.8ms/7.0ms
Codes per second: 5.65
Maximum length of RX/TX data transfers: 3472/1664 -
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
