Hi! I had the same problem yesterday.
Had the printer reset everytime it wanted to switch filaments.
I somehow fixed this (sadly don't really know what fixed it. Maybe because I reflashed the firmware of the mk3s) but then the printer just ignored the MMU change command (T0 - T4).
From there I got it working again by creating a printer profile with 5 extruders in Octoprint.
The number of extruders needs to match the printer or OctoPrint will refuse to send T commands for safety reasons. E.g. if your printer profile does only define 1 extruder (instead of 5 with a shared nozzle in the case of the MMU) and you try to switch to any tool but 0 (e.g. T3) it will refuse to send that and also log this to the terminal tab and octoprint.log.
That doesn't seem to be the case (or at least the only issue) here though (it should show up it in the log) and definitely doesn't explain the observed resets.
Ok, on the third layer now, no issues so far:
OctoPi 0.16.0
OctoPrint 1.3.12
Prusa FW 3.8.0 (1.0.6):
When I'm finished, I can send serial.log as comparison
1 Like
I just ran a successful MMU print with 1.3.12.
However, I did have to update my printer profile with the configuration for 5 extruders using a shared nozzle which is something I did not have to do with any previous versions of OctoPrint with my MMU.
Prior to updating the printer profile, jobs that used Extruder 1 (T0) would start perfectly, but then when trying to switch to any other extruder it would reject the command, reload T0, and then continue printing as if the filament change was successful.
Prusa MK2.5S Firmware: 3.8.0
MMU2S Firmware: 1.0.6
1 Like
Also, everyone running into this please ensure you have configured your Printer Profile correctly with all extruders:
As mentioned above, OctoPrint will refuse to send T commands beyond the extruders it knows about to the printer, and that might be a factor here. Fixing the printer profile solved an issue (though no resetting issues) for one person on the ticket the issue for several people now (so based on the currently available information that seems to be the problem).
Why not an issue with 1.3.11? To quote myself from the ticket:
[...] the code to perform this sanity check was in for a while (and was placed to prevent firmware crashes in case of undefined tools) but it was faulty and didn't trigger properly. It does now in 1.3.12 so a correctly configured printer profile is necessary.
edit case in point, see above comment by @johnnyruz
5 Likes
I'm running the MMU2S.
I have both an MK2.5S and MK3S with MMU2 units. I'll upgrade and see what happens.
1 Like
@Ewald_Ikemann wild idea, but...
Could you try what happens if you only have filament in T1 of the MMU2, slice a print for that, and reconfigure your printer profile wrongly to only have one extruder?
I have a theory (it could be demons... a dancing demon! Nah, something isn't right here...)
The resets might be related to a filament sensor recovery routine, at least one log hinted at that. What if that is caused by a misconfigured profile and a print job that tries to select the only tool that has filament loaded, that fails though due to the tool being unknown due to the wrong profile, the printer thus tries to load from T0, starts printing, the sensor triggers and that resets/behaves like a reset.
Could that be?
I'll can try that, but not until the evening because I have to go to my second shift in some minutes.
2 Likes
No worries. Thanks for the feedback already and have an uneventful shift! And if anyone else wants to give that a shot (or explain to me why it's bs - I definitely lack insight into how the MMU works and if that scenario is even possible) - be my guest 
2 Likes
i'm not sure if this is relevant or not but the behavior seen in this thread is very interesting and is very similar to what i have seen recently.
but first of all i am NOT running 1.3.12 yet, i'm still on 1.3.11
to make a very long story a bit shorter i had to RMA my prusa i3 mk3s with mmu2s controller board for the printer and got a new one.
after that i ran in to a whole bunch of different issues and one of them was a recurring reboot of the printer.
what happened was:
i start a print, printer homes, mesh bed leveling is done and extruder goes back to home position.
then lcd screen goes blank and pritner behaves as if it just rebooted BUT mmu did not do its usual process at a reboot (making noises when the idler wheel is banged against the end stop like usual).
then something really weird happens with octoprint
when i looked at the log, first thing i had was this "PRUSA fsensor_recover" and then a reboot where printer shows its firmware and so on, just like one of the previous posters in this thread.
and after that, when i looked at a print that was running octoprint behaved as if it just restarted the print and i think this has to do with printer responding that line number is not what was expected due to the reboot and then octoprint happily sends the gcode from beginning again and you got a loop.
my problems, i think, but am not at all sure, was related to a corrupt sd card.
after i ran "chdsk /f" on it and fixed the corrupt files i could print from sd card again and problems was gone.
i was about to send a bug report of this "restarting from beginning behavior" when printer gets reset like this.
problem also is that cancel button in octoprint doesn't work when you end up in this loop (probably due to how printer reboots and the responses octoprint gets)
1 Like
Oh, that is interesting and certainly sounds relevant. Would be interesting to know if the reboot issue vanishes with the SD card removed.
Yeah, that's also what I noticed in one of the octoprint.logs above - it's a weird reboot because the start message is missing. If that was there, OctoPrint would detect the printer restart, notify about it and also reset some internal stuff so that specific resend loop would not be entered.
So there seems to be a FW bug here where the start message is missing at the very least.
I’ve done a number of single filament prints through my MK3S+MMU2S without issue. I have not tried a multimaterial print through it yet. I can confirm I have NOT changed my profile to show I have more than one extruder.
I’m out of town but I’d this is still an issue Friday I can run some multimaterial tests.
1 Like
I've got things working now changing my profile to 5 nozzles with a shared nozzle.
Everything seems to be working fine so far.
Multi-filament using the "Original Prusa i3 MK3s MMU2" printer profile in PruaSlicer
Single filament using "Original Prusa i3 MK3s MMU2 Single". Single correctly gave me the option to pick the filament.
I never thought to look at the profile. Thanks everyone!
2 Likes
Hi! I'm back!
And I'm just testing this out.
What I've done was this:
I took a model, set PrusaSlicer to multi material mode, assigned the model to Extruder 1 (T1), set the profile to 1 extruder.
The slicer sliced in single material mode - and so was the printout, except the querry to select the filament/extruder.
No errors, no resets.
Hm, ok, it was worth a shot. Thanks for testing!
My pleasure - anytime 