Posts made by andywm

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.

I have one of E3D's high temp heatbeds. Which is fine, in isolation my machine has no issue with it.

The problem is I like to run my machines off a UPS, and the poor 500W UPS gets very cross at me during bed heat up, constant-tone. The bed will go from room temperature to 60C in about 10 seconds, so it's not like I have to deal with the tone for long... but deliberately overloading my UPS doesn't quite sit right with me.. and buying a more expensive, more appropriate UPS just for these 10 seconds seeems silly.

So, I think I need to either need to find a way to current limit it. Or to do what I'm thinking is more likely, just have the duet tell it to heat up slower. And then just deal with the slightly longer heat up time.

How would I go about that?

Oh..
okay, yes - that's all this was.

I don't know why you're answering idiot questions at 10pm, but I'm glad you are.

Thanks!

I recently got hold of E3D's toolchanger platform, on first power up I noticed I couldn't get all but one of the hotend fans to spin.

The way the machine is structured is it allocates 2 fan pins per tool, one for the heatbreak cooling and one for the part cooling fan. If I swap the connectors for the part cooling fans with the heatbreak fans all the heatbreak fans come on. It also turns out the one that was spinning was wired wrong, I had the PCF and HE fan's switched, though, interestingly that part cooling fan is fully dead, as in I can't get it to spin even on a bench supply, it takes no current.

So, I broke out a multimeter and measured the output from the duet.

M107 (P0 to P8)

Pin Voltages -
Duet
P0 0.6-0.8v
P1 0.6-0.8v
P2 0v
Duex
P3 0.6-0.8v
P4 0v
P5 0.6-0.8v
P6 0v
P7 0.6-0.8v
P8 0v

M106 (P0 to P8) S255

Pin Voltages -
Duet
P0 0.6-0.8v
P1 0.6-0.8v
P2 24v
Duex
P3 0.6-0.8v
P4 24v
P5 0.6-0.8v
P6 24v
P7 0.6-0.8v
P8 24v

What's likely happened here?

Alright. I made the suggested changes. I've not tried printing with it yet, but here's the results. And yeah, my probing macros are weird, they were originally just 4 corner tests for probing the distance at the corners, back when I had a screw adjustable bed. It's now fixed in place using washers.

Front

Right

Back

Left

Still definitely has a curvature to it near the edges, which you wouldn't think likely for a piece of glass.

Curvature

CSV: https://pastebin.com/PEhNDRiy

Firmware?
Main firmware 2.02 at the moment. But I've had the issue since I built the machine, which would have been 1.17.
DWC 1.22.6

The macros are nothing special.

;end probe
M280 P3 S160 I1

;probe near left.
G1 Z10 F6000 S2 ; lift Z relative to current position

;G0 X0 Y-10
G0 X0 Y0

M280 P3 S10 I1
G30 S-1

As for why I'm setting z to 0.9. I can't rememebr my reasoning for this, I think it's because if I don't then homing fails on account of z being a negative value when the probe completes.

I'll have to test that later.

I've been having issues getting a good first layer to span my entire bed.

The machine is an i3 style cartesian machine, glass bed, and has a bl touch. Which I am using as both the z stop and probe. (p3steel frame, e3d titan aero (gantry is 3D printed, held on with zip ties)

config.g : https://pastebin.com/VrEz3pKg
homeall.g :https://pastebin.com/2VRW9rK6

I built it a year ago or so, I can get away with fairly small prints, as I can just find a decent average for the bed height, and it works. However, if I want a print that spans the bed, I'll have patches where the nozzle is either too high, so leave gaps, or parts where it's too low and drags material.

I have been using the mesh bed compensation for a while, and it helps a bit. But not drastically

I've gone through a few things, I've replaced the bed, I've replaced all the rods (and bearings). (I considered that it might be sag in the gantry, but if it was sag, why would the bump be in positive..)

I thought I should probably stop living with it, and finally get some advice on how to remedy this.

Front

Right

Back

Left

(also, while I'm here. It thinks the bed is offset significantly in z - because the probe is the z stop, I guess it's applying the offset before it sets the z height. Any way to fix this, just so the visualisation makes sense?)

That would be direct from the shop on this site. I'll wait until you're all back in hours on the 2nd.

Issue didn't occur when using E1 as the Y axis driver.

It did print on a weird part of the bed, but it sounds like the bed just got caught on the wire for the heated bed. So I'll have to do some repeat tests, and I'll have to actually calibrate my machine now that its possible to do so. But yeah, that seems to be the problem, the Y driver is faulty somehow.

Firmware as reported is 1.19 (could have swore I put 1.20 on it)

At idle:
Never used ram: 7448
Supply voltage: min 12.4, current 12.5, max 12.6, under voltage events: 0, over voltage events: 0

In operation, with issue present:
Never used ram: 3232
Supply voltage: min 11.6, current 12.5, max 12.7, under voltage events: 0, over voltage events: 0

Edit:
upgrading the firmware to 1.20 made no difference.

Hmm. Maybe?

I'll try recrimping the y motor connector. While it doesn't feel hot to the touch, I feel like I has to be something like that, because from cold it works for a few layers before it goes awry.

And remapping the E1 as Y would just be changing an #define in the firmware? Is it straight forward enough to compile it?