[BUG] Printer goes into endless reboot mode.

[MadOtis]

Printer type - MK3S
Printer firmware version- 3.8.1

MMU Upgrade - MMU2S
MMU upgrade firmware version - 1.0.6

Describe the bug
Since flashing to the 3.8.1 firmware (and associated 1.0.6 MMU firmware), I cannot print a single thing. The printer starts normally, I send a print job to it either via SD card, or Octoprint and the following sequence happens:

1. heaters cycle up, as usual
2. Bed probe leveling happens
3. Print head homes itself, as usual
4. printer preps to purge/prime the nozzle across the front of the build plate
5. Printer reboots itself
6. After recycling, get a message in the display that the gcode was sliced for a different printer. continue?
7. After displaying that for approx. 10 seconds, the printer goes back to step 1 and cycles endlessly until you power off the printer.

To Reproduce
Slice ANYTHING in PrusaSlicer 2.1.1 and send to the printer

Expected behavior
The specified filament is selected, loaded, and a print starts from it.

G-code
labyrinthGiftBox_bottom_0.15mm_PLA_MK3SMMU2S_1d1h8m.gcode.zip

Video
Please attach a video. It usually helps to solve the problem.

[MadOtis]

Note: After flashing, I did also complete a reset/calibration wizard setup to reinitialize CMOS with latest 3.8.1 values, just to be sane.

[michalxfanta]

Thanks for reporting the problem, we will test it.

[lew-robobionics]

I also seem to be having the same issue on the MK3S MMU2S

[leptun]

@MadOtis @lew-robobionics What do the IR sensor and the FINDA register before you start the print? Is any of them triggered when it shouldn't?

[vintagepc]

^^ What Leptun said. There's a known issue that causes a reboot if the sensor states are inconsistent (e.g. IR reports 1 and FINDA reports 0.

[MadOtis]

I just powered mine back on and checked: PINDA = 1, FINDA=0, IR=0

print head is homed, and no filament is loaded past the MMU2S, yet.

[MadOtis]

I've tried to attach a video showing what it is doing, but it's too large. The sensor display shows what I've posted in my previous comment and I just tried sending a freshly sliced model to it, and after bed mesh sensing, homes then reboots after about 5 seconds, then re-displays the message about the model being sliced for a different printer, then the process starts all over again unless I power-off the printer.

[michalxfanta]

We can confirm this endless loop when printing with Octoprint. We will look into this more.

[lew-robobionics]

@MadOtis @lew-robobionics What do the IR sensor and the FINDA register before you start the print? Is any of them triggered when it shouldn't?

How do you check this when the printer is doing a reset?

It usually does one reset and then the issue is solved

[michalxfanta]

After we downgraded Octoprint from 1.3.12 to 1.3.11 everything works fine. We have to find out if there is an error in our firmware or in Octoprint. For now, please use the older version.

[MadOtis]

Yes, I can confirm that downgrading octoprint back to 1.3.10 (octopi image v.0.16.0) does resolve the issue, at least for me.

[Auge103]

You'll need to set up the extruder correctly in the Octoprint settings, else the MMU2 and the printer will end up in undefined states and/or will do strange things like constant MMU resets, even moving the selector with filament in it, thus creating a jam.
[Set the extruder amount to 5, shared nozzle, in Octoprint]

This seems to happen because Octoprint will maybe modify or ignore certain commands regarding the MMU / multiple extruders when its not set up correctly, in addition to the MMU2 firmware interpreting those commands wrongly and ending up in undefined states. There is no known specific reason why this happens yet, only how it can be avoided by a correct setup.
Honestly, this is a big issue, can create mechanical problems and should be mentioned somewhere on the Prusa help sites regarding MMU issues with Octoprint.

Reference: OctoPrint/OctoPrint#3314

[JohnnyDeer]

@MadOtis, did recommendation of @Auge103 helped? Please update or close this issue, thank you.

[github-actions]

This issue has been closed due to lack of recent activity.