[BUG] MK3S (3.13.3) stops mid print and reboots/resets itself

[N0ciple]

Printer type - MK3S
Printer firmware version - 3.13.2 and 3.13.3 (I had the problem with both)

MMU upgrade - N/A
MMU upgrade firmware version - N/A

SD card or USB/Octoprint
Both SD card and Prusa Link (raspberry py zero W) version 0.7.2

Describe the bug
The printer resets/reboots itself during the print and display "Print aborted"

To Reproduce

1. Download the files thumb_bolt.stl and thumb_nut.stl from here : https://www.printables.com/fr/model/3407-articulating-raspberry-pi-camera-mount-for-prusa-m/files
2. Import the files in PrusaSlicer 2.7.2 (Flatpak on Ubuntu 23.10)
3. copy/paste the 2 items so that you have 3 bolts and 3 nuts (works with other number of part but I am sure of this one)
4. press Ctrl+A and then shift+A to place them automatically
5. Change the number of perimeters to 4 or 5 (I had the issue with both)
6. export the Gcode to the SD-Card or with Prusa link and print
7. After a while the printer stops (I think always at the same spot but I am not 100% sure) and reboot or reset itself (I think). I noticed that the screen displays a loading bar and then the splash screen "Original prusa etc..." with the firmware version, and then the info screen with "print aborted" (or something similar, I dont recall the exact phrasing)

Expected behavior
The printer prints all the objects without reseting / rebooting itself

G-code
Here are 2 gcodes that causes the problem with Prusa Link, but I tried similar configurations straight from the SD and I had the issue too.
bad_gcodes.zip

Video
/

[gudnimg]

I think always at the same spot but I am not 100% sure

This sounds very important. How far into the print does this happen? What Z height?

I noticed that the screen displays a loading bar and then the splash screen "Original prusa etc..." with the firmware version, and then the info screen with "print aborted" (or something similar, I dont recall the exact phrasing)

At that point the printer has already rebooted.

[N0ciple]

I think always at the same spot but I am not 100% sure

This sounds very important. How far into the print does this happen? What Z height?

Honestly I don't remember.

But I narrowed down the problem. The following GCode
test_gcode.zip works or fails (the printer reboot itself) in the following conditions :

• Printing through prusa link / connect -> the print fails (printer reboot) ❌
• Printing from SD card with raspberry pi zero W (prusa link) attached -> the print fails ❌
• Printing from SD card with raspberry pi zero W (prusa link) physically removed -> the print works ✅

So it seems that having the raspberry pi zero W running prusa link connected causes the issue.

For the record, my RPI Zero W is connected directly to the Einsy Rambo board (not via USB) as per this tutorial : https://help.prusa3d.com/guide/prusalink-and-prusa-connect-setup-mk3-s-_221744

[avehome]

Did you check the flex cable on cracks or damages? I had a small crack in the cable (pi zero to pi camera) that made my Prusa reboot. I replaced the cable and now it's running fine again. If the cable is twisted it can crack at some time... (see example below)

[TojikCZ]

I had my raspi soldered poorly. Printer did the same thing. If you want to be sure this is a hardware issue, send me please the syslog file from the settings page in PrusaLink local web interface

[Arcadian1977]

I've had random rebooting during prints and also when doing an auto home. I was mostly trying to print lithos in pla. I've had lots of issues with this release. 3.13.3 revo version.

[TojikCZ]

Are you willing to check whether this is a hardware issue? (send the log, confirm you are using the pi on the einsy pins, jiggle it a bit to see if printer reboots) if you just pile on while not providing little to no info, we unfortunately cannot just snap our fingers and fix your issue magically. We'd like to, but real world is dissapointing like that ☹️

[Arcadian1977]

Pi 3b connected to usb port on the board. Primarily printing through prusa connect or prusa slicer.

[Arcadian1977]

I'm not at the machine at the moment. I'll try to get the log later on.

[N0ciple]

I made a fresh install of PrusaLink on my raspberry pi zero W with another SD Card (I had no reason to suspect the sd card but I had to swap it so I took the opportunity to make a fresh install).
I printed the last GCode I sent without the camera connected and it printed without error.
I inspected the camera ribbon cable but I did not see any cracks. I'll try to print the same GCode with the camera connected to see if it was the issue.
@TojikCZ Do you want to see the syslog files even if there is no error?

[GaryAitken]

I've had similar issues with 3.13.3 and 3.13.1 (backed out 3.13.3 to check). It doesn't always happen at the same place, although several times it seemed like it was close to the same place. Big print covering most of the plate, happened multiple times about 12mm height, then on 3.13.1 at maybe 2.5mm. Stock MK3S from kit, working several years, printing from SD card. Two slightly different .gcode files. Small prints (calibration cube, etc.) seem to work. Using 0.8mm nozzle. However...
This only started happening after I had to replace the hotend (stock V6 hotend) a week ago. I've checked all connections and
nothing seems amiss. I have another (different) hotend so I may try installing that to see if it makes a difference.

[GaryAitken]

I checked all cables and wiggled them with the power on, with no effect. After doing more research I backed out to 3.12.2 and that solved the problem. I can provide the gcode that fails, but not the model or a .3mf file.

[shawneily]

I am also having the same issue on 3.13.3

Printer: MK3S+
FW Version: 3.13.3
Method of Printing: SD Card, Pronterface

I updated the firmware to 3.13.3 about a week ago which is when the failures started:

Video of failure

Note: I sped the video up after the failure 16x until I came to clear the failure which is why the error messages are erratic.

Troubleshooting steps attempted:

• Reflash 3.13.3
• Factory reset, reflash 3.13.3
• Disconnect LCD, reflash 3.13.3 (CS Recommended?)
• Multiple slices of the print with variations of infill, speed, etc..
• Recalibration of the printer (multiple times)

Final Resolution: Flashed back to 3.12.2, was able to print without issues.

No matter the steps that occur that issue still persists in 3.13.3. I did attempt to roll back to 3.13.2 but, experienced the 'ghost layer shift' so I attempted to roll it forward again to 3.13.3.

I experienced I believe about 10 failed prints, might be more I lost count. 80% of the prints were failing around the same time, then the others were also failing at the same time, just later in the gcode.

When connected to PrintRun (Pronterface) I was able to see where it failed, and both times I had it connected it failed right after a WIPE was completed.

Here are the lines of failure from PrintRun, along with the associated GCode from each file.

PrintRun - 1:

RECV: ok
SENT: N62822 G1 X153.224 Y133.224 E-.22294*122
*** FIRMWARE CRASH HERE ***
RECV: start
SENT: M105
RECV: echo: 3.13.3-7094

GCODE:

G1 X153.224 Y133.224 E-.22294
;WIPE_END
G1 Z13.2 F720

---

PrintRun - 2:

RECV: ok
SENT: N14001 G1 X92.12 Y131.992 E-.22268*126
*** FIRMWARE CRASH HERE ***
RECV: start
SENT: N14002 G1 Z2.8 F720*34
RECV: echo: 3.13.3-7094

GCODE:

G1 X92.12 Y131.992 E-.22268
;WIPE_END
G1 Z2.8 F720

gcode file (renamed to .txt to attach, rename to .gcode):
test-gcode.txt

[kosma]

We are currently experiencing similar issues at @HackerspaceWroclaw - two unrelated Prusa MK3S/+ printers seem to be randomly aborting prints.

• The printer says "Print Aborted" with no other messages on the screen.
• One is MK3S, one is MK3S+, both are original. Firmware version is 3.14.0.
• Both have Raspberry Pi Zero W running PrusaLink 0.8.1.
• This happens when printing from PrusaLink and from SD cards.
• We are running some A/B tests on them (different PrusaLink/firmware versions, or no Raspberry Pi at all) but there are no conclusions yet.
• We can collect logs if needed.

[3d-gussner]

@kosma Thanks for the bug report. but as your printers do not reset please open a new issue.

[kosma]

@kosma Thanks for the bug report. but as your printers do not reset please open a new issue.

https://drive.google.com/file/d/1kGqbwYYEZoVChyLyzS98sybz3oWX-Xdk/view?usp=sharing

We have finally gotten around to capturing the error on video. The printer does reset. We are setting up logging of all UART data since more information is clearly needed.

[kosma]

I forgot a crucial piece of information: the crash only happens when a Raspberry Pi running PrusaLink is connected. Physically removing the Raspberry Pi stops the crashes from happening. Reinserting it brings the crashes back pretty much immediately.

[kosma]

We have tracked down the issue on our side down to a long camera cable (50cm) causing EMI issues and most probably causing voltage glitches on the RESET line, physically resetting the printer. Adding a flat ferrite (random one we had in the drawer) to the camera cable fixed all our reset issues:

[3d-gussner]

@kosma Glad to see that you have found a solution to your issue.