topic_solved Printer stop moves mid-print but extrudes while stationary
-
We've had this issue for a few months now, where prints that seem longer than a few hours can't complete. What happens is all XYZ motion stops but the extruder sits there dumping filament into a blob and grinding filament in the extruder with no end until we unplug it or do an emergency stop. The PanelDue is completely unresponsive during this, but emergency stopping from the web page works. It's happened seemingly at random, but it's shown some consistency within a given gcode. We've sliced models on various versions of PrusaSlicer, and when we started trying to fix this problem I was on ReprapFirmware v2.04. We've since successfully upgraded to v3.20 in hopes of solving this issue, but it just happened again. I'm running a Duet Ethernet. I was able to run diagnostics as it was happening just now, so I've attached that below. Some things that stand out are very long maxWait values in the Move section, as well as slowest loops of about 200ms. Not sure if this is nominal, but it seems pretty long.
Is this a problem with gcodes that are too long? We recently cleared the SD card too, but it doesn't seem to have helped. Can someone who knows how to interpret this log please offer some guidance? We're a bit stumped and somewhat frustrated at all the filament wasted in these failed prints.
M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.2 running on Duet Ethernet 1.02 or later Board ID: 08DGM-9T6BU-FG3SN-6J9F2-3SN6S-1UWMH Used output buffers: 3 of 24 (20 max) === RTOS === Static ram: 23460 Dynamic ram: 68856 of which 60 recycled Never used RAM 19704, free system stack 108 words Tasks: NETWORK(ready,174) HEAT(blocked,309) MAIN(running,421) IDLE(ready,19) Owned mutexes: === Platform === Last reset 02:54:57 ago, cause: software Last software reset at 2021-01-14 18:40, reason: User, GCodes spinning, available RAM 19740, slot 1 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x00 Aux0 errors 0,0,0 MCU temperature: min 35.6, current 39.4, max 40.8 Supply voltage: min 11.0, current 12.4, max 13.3, under voltage events: 0, over voltage events: 0, power good: yes Driver 0: position 9879, standstill, SG min/max 0/482 Driver 1: position 8396, standstill, SG min/max 0/491 Driver 2: position 4566, standstill, SG min/max 0/734 Driver 3: position 0, ok, SG min/max 0/1023 Driver 4: position 0, standstill, SG min/max not available Driver 5: position 0 Driver 6: position 0 Driver 7: position 0 Driver 8: position 0 Driver 9: position 0 Driver 10: position 0 Driver 11: position 0 Date/time: 2021-01-14 21:35:49 Cache data hit count 4294967295 Slowest loop: 216.07ms; fastest: 0.11ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 9 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest read time 2.0ms, write time 9.8ms, max retries 0 === Move === DMs created 83, maxWait 194850ms, bed compensation in use: mesh, comp offset 0.000 === MainDDARing === Scheduled moves 104550, completed moves 104510, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 6], CDDA state 3 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 Heater 0 is on, I-accum = 0.3 Heater 1 is on, I-accum = 0.9 === GCodes === Segments left: 1 Movement lock held by null HTTP is idle in state(s) 0 Telnet is idle in state(s) 0 File is doing "G1 X99.872 Y70.322 E3.12365" 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 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 194.31ms; fastest: 0.05ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions HTTP sessions: 1 of 8 Interface state active, link 100Mbps full duplex === Filament sensors === Extruder 0 sensor: okThanks to anyone who has any advice here!
-
Please include your config.g and a sample gcode file.
Did you try a new SD card, or just cleared it?
Was that M122 captured when it was stalled, or after it was power cycled?
-
None of the gcode files are small enough to be allowed to be posted so instead here is a Google Drive link for the latest one which failed.
Just deleted most of the gcode files by plugging it into a computer separate of the Duet board. Did not wipe it but have updated the firmware and configs on the card and board. This error was after the update but in the exact same manner.
The m122 was while it was still extruding and then we turned it off after running the command.
-
Why only x8 microstepping on Z and E?
I don't see anything out of place in config.g, but you can send M98 P"config.g" to check for any other syntax errors.
I also notice that your file is sliced with absolute extruder moves. Might want to try setting your slicer to use relative extrusion instead. If that does end up fixing it, it would be worth investigating why absolute extrusion is having an issue.
I would also try a fresh SD card.
-
I'll definitely try a fresh SD card (might just reformat this one and copy the system folders over again), and I'll put it on relative extruder moves too. The absolute extruder moves could explain why it fails in exactly the same spot within a gcode. The 8x microstepping is just me trying to put more holding torque where I think it is needed, although on E it is probably unnecessary. On Z however I'm just really trying to keep both motors in sync.
Thanks for the help, and I'll let you know how these changes go!
-
x8 microstepping won't really get you more torque. x16 with interpolation is definitely the recommended setting on a Duet 2. Best of all worlds.
To keep Z in sync you have 2 options, mechanical linkage via belt, or using a leveling routine to sync them up after the fact. When the motors power off and on they will naturally snap to the nearest full step which could be in different directions.
The reason I say fresh SD card is that it could be failing. A full surface format may help, but only if it has enough spare cells left to replace any bad ones it finds.
-
Ah ok, I'll put all the axes on 16x with interpolation then. I ran M98 and it didn't come up with anything other than reporting the network options that were set so I think that's good. Thank you again for looking into this.
-
UPDATE: It looks like setting the slicer to relative extruder moves has worked! Looking back I'm surprised it did as well as it did with these wires crossed. We were just able to print a part that we've had fail on numerous past occasions, so I'm feeling like this is actually fixed now.
I also want to thank you for the 16x microstepping tip for the Z axis. It's so quiet now
I'll mark this as solved for now, I think we'll try out some other models that didn't work before. Thanks for the help!
-
That's great that it appears to be working now. Not sure why absolute extrusion would fail like that. Please let us know if it really is resolved now.
