Random overextrusion after 3+hours of printing FW 3.5.2
-
Ok this time it was 1h 1m 28s when the over extrusion started. Any Ideas of what I could try next? Would making a new RJ11 cable from the tool distribution board help? Or re cabling the whole thing? At this point I’ll try anything.
Diagnostics:
MB6HC=== Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.5.2 (2024-06-11 17:13:58) running on Duet 3 MB6HC v1.01 (SBC mode) Board ID: 08DJM-956BA-NA3TN-6JTD0-3SJ6S-1V82V Used output buffers: 1 of 40 (29 max) === RTOS === Static ram: 155360 Dynamic ram: 89912 of which 5048 recycled Never used RAM 92192, free system stack 136 words Tasks: SBC(2,nWait 7,0.9%,821) HEAT(3,nWait 6,0.0%,323) Move(4,nWait 6,2.5%,211) CanReceiv(6,nWait 1,0.0%,794) CanSender(5,nWait 7,0.0%,327) CanClock(7,delaying,0.0%,346) TMC(4,nWait 6,9.7%,53) MAIN(2,running,86.7%,101) IDLE(0,ready,0.0%,29), total 100.0% Owned mutexes: HTTP(MAIN) === Platform === Last reset 01:00:13 ago, cause: software Last software reset at 2024-07-01 22:29, reason: User, Gcodes spinning, available RAM 95744, slot 0 Software reset code 0x6003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0043c000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a Error status: 0x00 Aux0 errors 0,0,0 MCU temperature: min 41.9, current 44.6, max 44.7 Supply voltage: min 23.7, current 23.9, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0 Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/48/48, gc cycles 0 Events: 1 queued, 1 completed Driver 0: ok, SG min 0, mspos 444, reads 10183, writes 0 timeouts 0 Driver 1: ok, SG min 0, mspos 867, reads 10184, writes 0 timeouts 0 Driver 2: ok, SG min 0, mspos 508, reads 10184, writes 0 timeouts 0 Driver 3: ok, SG min 0, mspos 852, reads 10184, writes 0 timeouts 0 Driver 4: ok, SG min 0, mspos 628, reads 10184, writes 0 timeouts 0 Driver 5: ok, SG min 0, mspos 460, reads 10184, writes 0 timeouts 0 Date/time: 2024-07-01 23:29:26 Slowest loop: 31.88ms; fastest: 0.05ms === 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 26, maxWait 991ms, bed compensation in use: mesh, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00 next step interrupt due in 166 ticks, disabled Moves shaped first try 2755, on retry 1709, too short 1471, wrong shape 35430, maybepossible 500 === DDARing 0 === Scheduled moves 61679, completed 61619, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3 === 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 Heater 0 is on, I-accum = 0.1 Heater 1 is on, I-accum = 0.0 === GCodes === Movement locks held by null, null HTTP* is doing "M122" in state(s) 0 0, running macro Telnet is idle in state(s) 0 File* is doing "G1 X337.981995 Y325.506012 E0.063910" 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 1, axes/extruders owned 0x80000007 Code queue 0 is empty Q1 segments left 0, axes/extruders owned 0x0000000 Code queue 1 is empty === CAN === Messages queued 65895, received 49465, lost 0, errs 0, boc 0 Longest wait 6ms for reply type 6024, peak Tx sync delay 254, free buffers 50 (min 48), ts 12359/12359/0 Tx timeouts 0,0,0,0,0,0 === SBC interface === Transfer state: 5, failed transfers: 0, checksum errors: 0 RX/TX seq numbers: 11409/11409 SPI underruns 0, overruns 0 State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x24cfc Buffer RX/TX: 1920/3424-0, open files: 0 === Duet Control Server === Duet Control Server version 3.5.2 (2024-06-12 07:12:47, 64-bit) HTTP+Executed: > Executing M122 File 0:/gcodes/Guiro 12in_3.4.6Test_0.6n_0.3mm_PLA_EXOCUBE_8h39m.gcode is selected, processing HTTP: >> Doing macro 0:/macros/Diagnostics, started by M98 P"0:/macros/Diagnostics" File: Buffered code: G1 X337.982 Y325.506 E.06391 Buffered code: G1 X338.172 Y326.122 E.04473 Buffered code: G1 X338.373 Y326.988 E.06169 Buffered code: G1 X338.475 Y327.605 E.04339 Buffered code: G1 X338.532 Y328.208 E.04203 Buffered code: G1 X338.576 Y329.165 E.06648 Buffered code: G1 X338.54 Y329.812 E.04496 Buffered code: G1 X338.477 Y330.421 E.04248 Buffered code: G1 X338.404 Y330.875 E.03191 Buffered code: G1 X338.17 Y331.76 E.06352 Buffered code: G1 X337.971 Y332.224 E.03503 Buffered code: G1 X337.819 Y332.486 E.02102 Buffered code: G1 X337.248 Y333.118 E.0591 Buffered code: G1 X336.888 Y333.48 E.03543 Buffered code: G1 X336.109 Y334.03 E.06617 Buffered code: G1 X335.767 Y334.23 E.02749 Buffered code: G1 X335.59 Y333.679 F15000 Buffered code: G1 F1500 Buffered code: G1 X334.92 Y333.853 E.04803 Buffered code: G1 X334.282 Y333.984 E.04519 Buffered code: G1 X333.634 Y334.091 E.04557 Buffered code: G1 X332.588 Y334.206 E.07302 Buffered code: G1 X331.473 Y334.279 E.07753 Buffered code: G1 X328.705 Y334.286 E.19207 Buffered code: G1 X327.414 Y334.206 E.08975 Buffered code: G1 X326.38 Y334.093 E.07218 Buffered code: G1 X325.719 Y333.984 E.04649 Buffered code: G1 X324.531 Y333.728 E.08433 Buffered code: G1 X324.202 Y333.548 E.02602 Buffered code: G1 X323.572 Y333.103 E.05352 Buffered code: G1 X322.915 Y332.457 E.06394 Buffered codes: 1472 bytes total Code buffer space: 1920 Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0 Full transfers per second: 39.44, max time between full transfers: 54.9ms, max pin wait times: 54.5ms/4.6ms Codes per second: 19.17 Maximum length of RX/TX data transfers: 4436/1124
1LC
Diagnostics for board 121: Duet TOOL1LC rev 1.1 or later firmware version 3.5.2 (2024-06-10 13:24:04) Bootloader ID: SAMC21 bootloader version 2.8 (2023-07-25) All averaging filters OK Never used RAM 3372, free system stack 71 words Tasks: Move(3,nWait 7,0.3%,88) HEAT(2,nWait 6,0.3%,90) CanAsync(5,nWait 4,0.0%,52) CanRecv(3,nWait 1,0.1%,70) CanClock(5,nWait 1,0.0%,58) ACCEL(3,nWait 6,0.0%,52) TMC(2,nWait 6,3.7%,52) MAIN(1,running,90.7%,314) IDLE(0,ready,0.0%,26) AIN(2,delaying,4.9%,112), total 100.0% Owned mutexes: Last reset 01:00:15 ago, cause: software Last software reset data not available Driver 0: pos 0, 405.0 steps/mm, ok, SG min 0, read errors 0, write errors 2, ifcnt 168, reads 27122, writes 16826, timeouts 4, DMA errors 0, CC errors 16827, failedOp 0x71, steps req 0 done 2205650 Moves scheduled 57511, completed 57507, in progress 1, hiccups 80, segs 26, step errors 0, maxLate 0 maxPrep 354, maxOverdue 106, maxInc 52, mcErrs 0, gcmErrs 0, ebfmin 0.00 max 1.00 Peak sync jitter 0/6, peak Rx sync delay 252, resyncs 0/0, no timer interrupt scheduled VIN voltage: min 11.6, current 24.2, max 24.5 MCU temperature: min 34.6C, current 45.2C, max 46.0C Last sensors broadcast 0x00000002 found 1 143 ticks ago, 0 ordering errs, loop time 0 CAN messages queued 49415, send timeouts 0, received 65795, lost 0, errs 0, boc 0, free buffers 18, min 18, error reg 0 dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 398, adv 36262/74666 Accelerometer: LIS3DH, status: 00 I2C bus errors 0, naks 0, contentions 0, other errors 0
-
@charliedrums Looking at this logically, any print move looks like this. G1 Xnn Ynn Enn. Which means move a certain distance in X and/or Y while extruding a certain amount of filament. What you are saying is that at random times, when printing a gcode that you have printed many times before, that Enn becomes something greater. I.e, the fimant moving through the extruder randomly moves further or faster than it should do. There are many reasons why it might move less (partial blockage, temperature too low, motor or wring issue, missed steps, etc), but none that I can think of that would make the filament move further than it should. So the only logical conclusion is that something else is happening which gives the appearance of over extrusion when in fact it isn't. My best guess, as I've stated before, is that your Z axis isn't moving the full layer height.
-
I would have guessed the same but I have checked all 4 Z motors and their harnesses. Here is what leads me to determine it is over extrusion. First once the issue begins, I remove the print from under the extruder and let it print in air for a while and visibly one can tell the more amount of plastic is being forces through the nozzle.
Second, I am using the Orthus Filament Monitor. The orthus has a light that flashes intermittently when filament is running through it. The faster the blink of the light the faster the filament if passing through the sensor, when the problem begins the light flashes faster as in filament is passing faster trough the sensor/extruder. I can move the printer to the max height(365mm) and home without any problems.
I’m going one thing at a time right now I eliminated the z scanning probe and the filament sensor. Still happening. This time around I re did the harness that powers the tool distribution board (two cables 24v Vin ground) and am currently running the print to see if the problem continues after this, I’ll re do the RJ11 cable. Then continue from there.
-
@charliedrums If you are certain that it is genuine over extrusion after some seemingly random period of time, then the only explanation I can think of is that somehow, something is changing the G1 Xnn Ynn Enn commands that exist in the gcode file to something like G1 Xnn Ynn E(some other value that is always higher). I note that you are using a SBC. Is there any chance that you could run stand alone mode and print directly form an SD card?
-
@charliedrums One other suggestion - try a print without input shaping. I can't offhand think why it should make a difference but who knows?
-
@deckingman
Yes, I can I don’t see why not. The only reason I have SBC is so I could get WIFI. Looking through the documentation I see that I can connect to the board directly with an ethernet cable. Next thing Ill do is that go Direct an eliminate the SBC and see. Thanks for the idea. -
@charliedrums said in Random overextrusion after 3+hours of printing FW 3.5.2:
@OwenD I have printed the gcode before. Probably like 30 t50 times and it has always worked. Still gave it a look but found nothing out of the ordinary.
Good that you're keeping an open mind.
Having printed the code before may not prove anything.
For example in my case the Gcode extrusion values were far above the capabilities of the extruder, but I wasn't getting skipped steps because my maximum extruder speed values were limiting it to achievable amounts (albeit way over extruded).
If in the interim you had for example increased your max extruder speeds then a problem that wasn't obvious before may now appear.
Loading the code into Prusa Slicer and viewing it by volumetric flow rate would show up any odd areas most likely a lot more than just scanning the code by eye.Have you tried swapping the drivers around that the extruder is on?
That should rule out a hardware fault on the board at least.EDIT: Just saw that you're using a tool board and have swapped it.
-
Just noticed a similar post also using a toolboard
https://forum.duet3d.com/topic/35869/overextrusion-out-of-nowhere
One for @DC42 I think -
@charliedrums One other thing to try, I think you said that once it gets into this "over extrusion mode" then it stays in it even when starting a new print? If that is the case can you try checking the extruder calibration when in this state see: https://docs.duet3d.com/en/How_to_guides/Calibration#h-3-calibrating-extruder-e-steps-per-mm and then do a reboot and perform the same task again and see if there is any difference.
-
-
After many weeks of testing, I figured out the problem. I started re-wiring every cable to eliminate any problem with the harnesses. Once I got to the power from the Mainboard 6HC to the tool distribution board. I measured the power from this cable with a multimeter and everything was reading normal. For some reason once I rewired this harness everything seems to be working now.
I’ve done dozens of 20–50-hour prints with no problem so far. Updating this post in case someone is having the same issue. Check the power from the main board to the tool distribution board.
-
-
@charliedrums I'm glad you solved it! Thanks for the update.