Off Topic Hobbies > 3D printing

Printer paused mid-print and then skipped a layer


I have had a print failure today where i am not sure what the issue might have been.

Two hours into a 7 hour print, i noticed that the printer paused for a couple of seconds. Something that i have never seen before. It just paused and stopped moving, the fans kept running, their noise did not change, and also no noises that i noticed from the steppers.
It resumed though after some time. At first i thought that nothing happed, but on subsequent layers the printer dragged extruded filament around corners, that is when I aborted the print.
For me it looked like the printer just skipped a layer, or parts of a layer, and subsequent layers could not stick properly anymore, causing the printer to drag the filament around corners.

I do not think it's a mechanical issue at that specific height. I am now printing another part, and that is already above the height where the issue occured. The printer has been recently relubricated.
Could that be a corrupted GCODE file? A dying or damaged SD Card? I can't see anthing special on the original GCODE file that i have on harddisk when i look at it. I can't access the file on the SD card at the moment since the printer is currently printing.

Printer: Prusa i3 MK3s+
Slicer: Prusa Slicer
Filament: Prusament PETG

If you use the same SD card again, and it went further, it doesn't seem like an SD issue. You'd think even if it buffered, or hit some transient temperature condition and paused it should simply resume ok.

Sorry, took me a while to come back to this.

When i loaded the GCODE directly from the SD-Card into a GCODE viewer, the issue became blatantly obvious: The GCODE was really missing a line.
The original on harddisk does not have that line and looks fine.

My takeaway from this: i will now always check the file after copying it to the card. That was actually the first time with removable media that i got a file corruption like that.

Then time to replace the card, as it likely has a failed location that the controller detected on read, and has simply marked out and swapped with a spare block, causing the missing line. You could test the card with a few dozen write cycles that fill it up, and each time issue a trim command to get the controller to run through all the spare cells, but if it has bad blocks already it is near the end of the write endurance for that particular card. They are not expensive, and not too reliable either long term.


[0] Message Index

There was an error while thanking
Go to full version