[BUG] Firmware crash if stopping print during MMU2S loading

[amatulic]

Printer type - MK3S
Printer firmware version - 3.12.2

MMU upgrade - MMU2S
MMU upgrade firmware version - 1.0.6

SD card or USB/Octoprint - SD card

Description of bug
This may be related to issue #4109 and #4110 but it is hard to determine. In any case, I seem to have hit upon a repeatble way to crash the firmware. I have done this twice, with the same result.

To reproduce

1. Using PrusaSlicer 2.5.2, create a g-code file that uses filament 2 on the MMU2S (I don't know if the tool ID matters, but this is what I was doing), and save it to the SD card. An example g-code file is attached.
2. Put the SD card into the MK3S and select that g-code file to print.
3. Pull filament 2 out of the MMU2S so that it has nothing to load.
4. While the MMU2S is trying to load the non-existent filament to the nozzle, select "stop print" on the printer.
5. Observe "FW crash detected!" message appear on the display.

After it crashes, the only thing one can do is factory-reset the printer, erasing all data, and go through the half-hour setup process again. The message displayed says "you can resume printing" but I have not found any way to do this. Observations:

• The selector button does nothing while the message is displaying.
• The reset button resets the printer, which then returns to the crashed state with the same message displayed.
• Cycling the power does not help; after starting up, the printer returns to the crashed state.

Expected behavior
Stopping the print job during filament loading should not result in a FW crash. This was working fine with the previous firmware release. Also, once the crash message is displayed, there should be a way to clear it without a factory-reset.

Lest anyone think that step 3 (pulling out the filament) is unrealistic, it isn't. I have a low-friction filament path combined with rewinder dryboxes. Occasionally, the filament slips out of the MMU2S. In this case, I was using a particularly slippery filament that didn't want to stay in the MMU2S by itself.

Update: (1 May 2023) It crashed again yesterday when I had to interrupt a repeated load/unload cycle due to a bad filament tip. This time I was able to push the selector button to clear the message and continue, without needing to perform a factory reset. However, the way to get the firmware crash is repeatable, just stop the print while the filament is loading from the MMU.

G-code
rolodex_frame_0.3mm_PLA_MK3SMMU2S_38m.zip

[amatulic]

Side note: this thread in the Prusa forum has a Spanish-language comment that suggests the problem might be with the SD card, because in that poster's experience, replacing the SD card with a new one and powering up the printer fixed the problem.

[PhLacoude]

Exact same problem as you guys. I could no longer print with Octoprint after a printer firmware upgrade.

I was able to print small multicolored models via the SD card. I did not try large models but I did try all 5 filaments. They all worked for prints whose GCode was coming from the SD Card (with the Octoprint unplugged.)

My MMU2S has been erratic since the latest printer firmware upgrade. In the MMU2S Single mode, the printer had trouble picking the filament. In MMU2S mode, the MMU2S unit was cashing regularly. It would flash 5 red+green lights. Manual loads of the filament via the LCD screen menu or via the MMU2S buttons were difficult or impossible. I had my very first “firmware crash” errors. I have 2 printers and I have at least 5000 hours on each one. Yet, again, I never had a “firmware crash” message before.

My Octoprint logs look exactly like the O.P. logs. Same codes. And my Octoprint sends an M112 code after each crash to prevent thermal issues (as expected, I guess...)

So I proceeded in the following order.

1. Verified I had the latest MMU firmware (which was the case).
2. Factory reset the MMU
   https://help.prusa3d.com/guide/service-menu-factory-reset_86232
3. Retested with and without the Octoprint units. (Mine are Raspberry Pi 3B+ units connected via a USB cable.)
4. As a last resort, I went back to the previous printer firmware. This also fixed it for me.

Thank you very much for raising the issue and for suggesting reverting to firmware 3.11.

[Prusa-Support]

Thanks for your feedback.

Is it safe to say that the only difference between this and issue #4110 is that you were intentionally un/loading filament, while in the order issue the filament changes were automatic? If so, I suggest closing this issue as a duplicate.

All in all this seems to be related to a combination of
FW 3.12.x + MMU + filament un/loading operations
hence a duplicate of issue #4110.

Michele Moramarco
Prusa Research

[amatulic]

The difference between this issue and #4110 is that I describe a 100% repeatable way to reproduce the crash. Just stop a print while the MMU is loading the filament. The description in #4110 does not let me reproduce it reliably.

[gudnimg]

This is very likely a duplicate of #3990

Unfortunately the MMU operation is a blocking operation so the firmware does not expect to be able to abruptly stop the MMU process. The action of stopping or pausing during the MMU operation causes the planner to be aborted hard, and this eventually causes a watchdog timeout (the crash).

[amatulic]

Yes, I agree, this is likely a duplicate of #3990 not #4110. I didn't try pausing the print during a load operation, I just tried stopping it. If either 'pause' or 'stop' causes the same internal abort, then this issue is the same as #3990.

[GWdd]

As more info: I just had this FW Crash Detected. I wasn't paying a lot of attention the first time it happened. Reset the printer and restarted a new print.

Second time it happened the printer seemed to be trying to unload or reload filament. My gcode had no filament change commands. Attempting to unload the filament failed: the printer didn't respond, looping back to the FW Crash error display.

I cancelled the print. Error came back almost instantly when starting a new print. Reset didn't clear it. Power cycle didn't clear it.

I was using a blue transparent PLA - brittle and had broken during print on prior occasions, filament out detection worked prior times, but filament looked okay when this error happened.

While I couldn't start a print, I was able to unload the filament. I was pretty sure the printer had failed, so I powered down and walked away for a bit.

After a half hour I powered up and loaded new filament. Starting a print was successful.

I had recently (the day before) updated configurations. Found the latest thread and commented. Because this error showed almost immediately after the config update I rolled configs back to the last update I had done in 09/2022.

So far, there has been no repeat of the FW Crash error.

Prusa MK3
FW 3.10-1-4697
Uses new 3-wire proximity detector - other electronics else pretty much stock.

[amatulic]

Thank you @GWdd - I was beginning to think it was just me who couldn't clear the error message by resetting or power cycling. Prusa Support recommended performing a factory reset of my printer, which I did. In subsequent tests, I was able to clear the error message by pushing the selector button. It's good to know that powering it down and leaving it off for a while also works. I'll remember that next time, assuming this issue isn't fixed by then.

[Prusa-Support]

I believe this issue is duplicated several times indeed (#3989, #3990, #4022, #4110, #4155, and maybe more).

We are aware of the bug and it will most likely no longer persist on the next firmware - #3989 (comment)
For now, if nothing seems to help, you can temporarily downgrade to FW 3.11.0 (not ideal).
In many cases though, this glitch is fixable or traced back to other related problems - #4110 (comment).

I hope you don't mind me closing this issue as a duplicate.
Thanks for your collaboration and understanding.

Michele Moramarco
Prusa Research

[amatulic]

I don't mind at all. Thanks for your attention. I wish the PrusaSlicer project was as responsive as the firmware project. There are a lot of open PRs that need resolving. Maybe experienced reviewers and testers could be drafted from the community to help out.