It was indeed a loose grub screw on one of the xy plane motors. Machine is printing well again.

Thanks all.

Hello, I need help troubleshooting this issue;

A few months ago, I converted one of my machines to use an SBC mode Duet3 6HC. The machine now randomly halts. DWC will report status=disconnected. And this warning will be in the console;

"Warning: Lost connection to Duet (Timeout while waiting for transfer ready pin"

At this point the duet itself seems to be in a sailfafe mode, all the fans on max, all the heaters off. And requires a power cycle to restore communication.

Here are some details about my setup;

• Duet3 6HC 1.02a
• Pi4 /w duet ISO for the Pi with DSF.
• Pi PSU Meanwell LRS-75-5. Adjusted the output trim pot to 5.1v.
• Duet 5v Select to 5V_EXT
• 24v System PSU.
• Commoned ground between 24v PSU and 5v PSU.
• Included GPIO ribbon used. Currently ran straight with pi in temporary position.
• Cables running power and control signals to tool CAN boards pinned aside and clear of this cable.
• I've updated DSF and all the cand devices firmware at least once since experiencing the issue.
• (M115) FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.5.3 ELECTRONICS: Duet 3 MB6HC v1.02 or 1.02a FIRMWARE_DATE: 2024-09-18 11:27:36

The problem itself is intermittent, as far as I can tell random. If it's a short enough print, it may finish or may fail on like the third layer. Some of the above are as a result of troubleshooting steps I've already tried. e.g. Updating firmware, managing interference around the ribbon cable, ensuring a common ground, 5.1v is as a result of that's what the Pi PSU does for instance. But I am just taking wild guesses, and am basically at the end of what I can think to try.

Here are some pictures of the electionics bay if it helps, and I'll include M122 dumps before an issue has occured, and immediately after a restart post issue.

No Issue M122

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5.3 (2024-09-18 11:27:36) running on Duet 3 MB6HC v1.02 or 1.02a (SBC mode)
Board ID: 0JD4M-958L1-M24TD-6J9F2-3S46J-K0TFX
Used output buffers: 1 of 40 (18 max)
=== RTOS ===
Static ram: 155352
Dynamic ram: 92292 of which 2744 recycled
Never used RAM 95604, free system stack 202 words
Tasks: SBC(2,ready,0.9%,820) HEAT(3,nWait 6,0.0%,323) Move(4,nWait 6,0.0%,335) CanReceiv(6,nWait 1,0.1%,796) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,348) TMC(4,nWait 6,9.4%,55) MAIN(2,running,89.3%,101) IDLE(0,ready,0.3%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:04:43 ago, cause: power up
Last software reset at 2024-10-27 12:20, reason: User, PrintMonitor spinning, available RAM 127816, slot 2
Software reset code 0x0009 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
MCU temperature: min 17.1, current 31.9, max 32.0
Supply voltage: min 24.2, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.2, current 12.3, max 12.4, 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 n/a, mspos 8, reads 45138, writes 17 timeouts 0
Driver 1: standstill, SG min n/a, mspos 8, reads 45136, writes 19 timeouts 0
Driver 2: standstill, SG min n/a, mspos 8, reads 45137, writes 18 timeouts 0
Driver 3: standstill, SG min n/a, mspos 8, reads 45139, writes 16 timeouts 0
Driver 4: standstill, SG min n/a, mspos 8, reads 45144, writes 11 timeouts 0
Driver 5: standstill, SG min n/a, mspos 8, reads 45145, writes 11 timeouts 0
Date/time: 2024-11-08 14:14:19
Slowest loop: 2.72ms; fastest: 0.06ms
=== Storage ===
Free file entries: 20
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, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== 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 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, 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
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0000000
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 2521, received 21516, lost 0, errs 0, boc 0
Longest wait 2ms for reply type 6031, peak Tx sync delay 6, free buffers 50 (min 49), ts 1417/1416/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 10023/10023
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x24d04
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.5.3 (2024-09-21 10:23:58, 64-bit)
HTTP+Executed:
> Executing M122
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 0.03, max time between full transfers: 60.6ms, max pin wait times: 60.0ms/3.9ms
Codes per second: 0.00
Maximum length of RX/TX data transfers: 4568/1176

Post Restart after Issue M122

Warning: Lost connection to Duet (Timeout while waiting for transfer ready pin)

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5.3 (2024-09-18 11:27:36) running on Duet 3 MB6HC v1.02 or 1.02a (SBC mode)
Board ID: 0JD4M-958L1-M24TD-6J9F2-3S46J-K0TFX
Used output buffers: 1 of 40 (18 max)
=== RTOS ===
Static ram: 155352
Dynamic ram: 92292 of which 2744 recycled
Never used RAM 95604, free system stack 202 words
Tasks: SBC(2,ready,1.0%,789) HEAT(3,nWait 6,0.0%,329) Move(4,nWait 6,0.0%,335) CanReceiv(6,nWait 1,0.1%,796) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,348) TMC(4,nWait 6,9.4%,55) MAIN(2,running,89.2%,101) IDLE(0,ready,0.3%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:01:30 ago, cause: power up
Last software reset at 2024-10-27 12:20, reason: User, PrintMonitor spinning, available RAM 127816, slot 2
Software reset code 0x0009 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
MCU temperature: min 38.3, current 41.1, max 41.3
Supply voltage: min 24.2, current 24.3, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.2, current 12.3, max 12.4, 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 n/a, mspos 8, reads 35486, writes 17 timeouts 0
Driver 1: standstill, SG min n/a, mspos 8, reads 35484, writes 19 timeouts 0
Driver 2: standstill, SG min n/a, mspos 8, reads 35485, writes 18 timeouts 0
Driver 3: standstill, SG min n/a, mspos 8, reads 35488, writes 16 timeouts 0
Driver 4: standstill, SG min n/a, mspos 8, reads 35493, writes 11 timeouts 0
Driver 5: standstill, SG min n/a, mspos 8, reads 35493, writes 11 timeouts 0
Date/time: 2024-11-24 15:53:17
Slowest loop: 2.71ms; fastest: 0.06ms
=== Storage ===
Free file entries: 20
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, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== 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 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, 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
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0000000
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 873, received 7144, lost 0, errs 0, boc 0
Longest wait 2ms for reply type 6031, peak Tx sync delay 5, free buffers 50 (min 49), ts 452/451/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 1, checksum errors: 0
RX/TX seq numbers: 32749/3474
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x24d04
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.5.3 (2024-09-21 10:23:58, 64-bit)
HTTP+Executed:
> Executing M122
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 13399
Full transfers per second: 37.25, max time between full transfers: 94282.7ms, max pin wait times: 499.9ms/257.3ms
Codes per second: 0.41
Maximum length of RX/TX data transfers: 4788/1212

It was indeed a loose grub screw on one of the xy plane motors. Machine is printing well again.

Thanks all.

@engikeneer

I can cause them to deflect, but not without quite a bit of force.

What should I be checking with pulleys? I already have it on my list to check the grubs on the two motor ones in the back from @Phaedrux's suggestion when I get the back panel back off. Basically just that?

Unrelated, but I am also a bit worried about Z, I noticed plastic debris resting and tangled with the leadscrew nut.

@generisi

I've tried with tools 1,2,3 all Hemera tools. They all produce exactly the same artifacts. So unless it's the gantry side that has the issue, I don't think this is play in the tool.

Here's a print from tool 3, notice how it's distortion in the top left quadrant exactly like the two I show with the annotated green lines.(made with tool 1)

and here's another of the original part without infill better showing perimeter distortion.

Going to have another play about with the mechanics of it today, belt tension, gantry squareness, etc.

@generisi

Fair on the lubricant I'll buy a suitable one. It's just all I had on hand at the time.

All my tools are currently the Hemera tool, which is something I only did a few months ago. I didn't notice any play when testing that, but actually on this specific tool the press fit insert in the tool block did fall out once... I should possibly check that.

It'll have to be tomorrow now. But I'll test the print again on tool 2 and 3 to see if it's the same. If it's not then it'll have to be down to the tool.

As for the possibility of it being skewed. Me messing around with the belt tension might have introduced that honestly, but it did still seem square within about 0.1mm when measured it against the frame on both sides. I'd just settle for it not shifting for the moment.

Hi, it's a bit of a strech to post this here I'll be honest. But this is the forum I've had the most luck with in the past.

I'm getting unusable prints out of my machine as of late, so far I've had no luck at all in figuring out what's wrong.

Before looking at what I've tried, so as to not prejudice potential new ideas/poison the well. Take a gander at these images.

Simplified Test Print, section with green line is shifted. As is the circular mount hole, which should have been concentric.

Back and front of original part.

Macro shots.

Macro shot, different tool. Different polymer.

The Machine: 2019 E3D toolchanger, running Duet 2 Wifi + Duex 5, RRF3.4.

I rebuilt all the tools and updated the firmware in January this year, but it's been seemingly working fine.

Machine Troubleshooting:

• Checked bed is secure.
• Checked wiring harness doesn't impinge on tool causing a deflection.
• Checked no play in tool itself.
• Checked no obstructions in belt path.
• Checked no obvious wear on belts.
• Checked x-gantry is square to within the best tolerances of my measuring tools.
• Cleaned x-rail with alchohol to clean dust and... 'seasoned' with some silicone lubricant.
• Increased belt tension*[1]

*[1] - bit of a shot in the dark, wanted to see if I got any result. Not really. It did seem to do something,

Firmware Troubleshooting:

• Updated from RRF3.3 to 3.4
• Reduced max accel, jerk, and motor speeds back to what I used to have in my archieved RRF2.x config the machine originally shipped with.

Slicer Troubleshooting:

• Reduced Speeds
• Tried a different tool.
• Disabled z-hop for retraction. (noticed the issue in the basic test was occuring after a large move with retraction/z-hop)

Any ideas?

This just shows that my time estimation skills are awful. @deckingman

It takes 31 seconds to go from 23C to 60C at full power. If 10 seconds is about 3 times overpowered, then funnily enough.. 31 seconds would be about right.

Okay, what's the proper solution to this if I still want to use the UPS? Wire the relay to a second IEC C14 power connector and power them independently? Or do I need to fork out for an 800W UPS?

@dc42 - yeah, 71.2 omhs measured across the bed power.

I mean... sorry to concern you all. It says right on the heater 240V, 800W. 2400W was a guess based on what the maximum I thought it could even be since it wasn't blowing any fuses on tripping any breakers.

I didn't time that 10 seconds, I just know it heats up to 60C fast.

I'll run it off the mains without the UPS and time it, I used to have a power meter, but that's gone walkies.

Yeah, that did the trick. I think the relay I am using is 10A, so at 240v. Max power draw would be 2,400W. 500/2400 gives me roughly 20%.

Tried P0.2 and it works a charm, no more tripping the overload alarm.

It's obviously a lot slower now, but I still think it's heating up faster than my other printers. I can live with it.

Thanks.