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.
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.
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
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.
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
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)
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.
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!
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.
it is not easy to test now since the sd card contains a file system that's not corrupt any more.
but yes, it would have been good to redo and test it further
something is not quite right yes.
due to other issues with serial communication i've had the serial logging turned on for a while now.
i tried to find the relevant lines in the log but could not find it since files have already been cycled out and expired
but i did find this in the octoprint.log file from last week:
2019-10-17 14:57:07,656 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2019-10-17 14:57:30,253 - octoprint.util.comm - INFO - Changing monitoring state from "Printing" to "Cancelling"
2019-10-17 14:57:30,263 - octoprint.printer.standard.job - INFO - Print job cancelled - origin: local, path: PLA_MK3_ECOR_TOWER.gcode, owner: admin, user: admin
2019-10-17 14:57:30,264 - octoprint.plugins.DisplayLayerProgress - INFO - Printing stopped. Detailed progress stopped.
2019-10-17 14:57:30,281 - octoprint.plugins.stats - INFO - Printer Stats - on_event
2019-10-17 14:57:30,988 - octoprint.plugins.DisplayLayerProgress - INFO - Printing stopped. Detailed progress stopped.
2019-10-17 14:57:30,996 - octoprint.plugins.stats - INFO - Printer Stats - on_event
2019-10-17 14:58:39,932 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2019-10-17 14:58:43,766 - octoprint.util.comm - INFO - Got a resend request from the printer: requested line = 1, current line = 25
| Last lines in terminal:
| Recv: ok
| Send: N22 M105*23
| Recv: ok T:215.1 /215.0 B:60.5 /60.0 T0:215.1 /215.0 @:31 B@:15 P:37.4 A:33.5
| Send: N23 M108*27
| Recv: fsensor_stop_and_save_print
| Recv: echo:Enqueing to the front: "PRUSA fsensor_recover"
| Recv: .echo: 3.8.0-2684
| Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
| Send: N24 M105*17
| Recv: echo: Last Updated: Sep 6 2019 19:51:14 | Author: (none, default config)
| Recv: Compiled: Sep 6 2019
| Recv: echo: Free Memory: 2116 PlannerBufferBytes: 1392
| Recv: echo:Hardcoded Default Settings Loaded
| Recv: adc_init
| Recv: CrashDetect ENABLED!
| Recv: FSensor ENABLED
| Recv: echo:SD card ok
| Recv: echo:busy: processing
| Recv: Error:Line Number is not Last Line Number+1, Last Line: 0
| Recv: Resend: 1
2019-10-17 15:00:31,400 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2019-10-17 15:00:35,277 - octoprint.util.comm - INFO - Got a resend request from the printer: requested line = 1, current line = 29
| Last lines in terminal:
| Recv: ok T:215.1 /215.0 B:60.2 /60.0 T0:215.1 /215.0 @:32 B@:40 P:37.9 A:33.7
| Send: N26 M105*19
| Recv: ok T:215.1 /215.0 B:60.2 /60.0 T0:215.1 /215.0 @:32 B@:40 P:37.9 A:33.7
| Send: N27 M84*42
| Recv: fsensor_stop_and_save_print
| Recv: echo:Enqueing to the front: "PRUSA fsensor_recover"
| Recv: .echo: 3.8.0-2684
| Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
| Send: N28 M104 T0 S0*27
| Recv: echo: Last Updated: Sep 6 2019 19:51:14 | Author: (none, default config)
| Recv: Compiled: Sep 6 2019
| Recv: echo: Free Memory: 2116 PlannerBufferBytes: 1392
| Recv: echo:Hardcoded Default Settings Loaded
| Recv: adc_init
| Recv: CrashDetect ENABLED!
| Recv: FSensor ENABLED
| Recv: echo:SD card ok
| Recv: echo:busy: processing
| Recv: Error:Line Number is not Last Line Number+1, Last Line: 0
| Recv: Resend: 1
there is one more thing that's relevant to know about my setup.
i had problems with the usb interface on my mk3 where it somehow made the usb port in computer connected to printer stop working completely until i reboot computer (port got screwed up with errors in dmesg and no other usb device worked in it until a reboot, reason for my RMA)
this force me to make use of the raspberry pi port instead, so currently i'm using a ftdi adapter connected to tx, rx and gnd in that port.
this also means no auto reset when serial port is opened.
this have worked very reliably and no usb issues at all.
oh, and one more thing, cancel doesn't really work, so when i got the loop i had to restart octoprint entirely to get it to stop.
so cancel isn't really cancel and i think there a bug in there or room for improvement.
once you click on cancel octoprint should never try to send more commands from the gcode file.
