Prusa MMU2s Not working in 1.3.12. I've a Prusa i3 MK3s. It never switches filament. Just reloads the same one. Created a new disk image with no plugins, nothing special, and the printer operated the same way... not switching the filament. The printer is fine. Current versions of the printer and MMU2 software is installed. I'm using the newest version of PrusaSlicer. It works if I print off the SD card.
To be honest, I have not run the MMU2 for quite a while, so I'm not sure when this broke. If I get time I'll try and roll back the plain vanilla install to the previous version and see what happens. Anyone else with this problem?
So after installing the new octoprint 1.3.12 I got the same restart failures again. In the moment it should start to print... the printer resets it self and stops completly. Can anyone confirm this failure?
Mine behaves identically. Worked perfect in 1.3.11, then upgrade to 1.3.12 and right when it should 'reset' the MMU2 unit and start loading filament, the entire printer resets itself and starts over again.
Raspi Pi 3, OctoPrint 1.3.12
OctoPi Version 0.16.0, running on Raspberry Pi 3 Model B Rev 1.2
Prusa MK3S (3.8.0-2684) + MMU2S (1.0.5-297)
I'm going to need serial.logs for this, and close collaboration (I don't have an MMU2, I don't want one, I need to work together with someone tech savvy who has one to get to the bottom of this). Please open a full bug report. For the record, I'm not aware of any changes which could have caused this right now.
Got a chance to look at the available logs (again though, those don't help me a lot here, I need serial.logs, runs in safe mode, the whole nine yards that belong to a full bug report which this actually should be moved to)
I don't see anything that hints at a cause in there, but I do see that you are using an MMU specific plugin that is running into issues. I suggest to take this out of the equation for now to rule it out as a factor. Other than that I only see what we already know: the printer resetting and sending a start during the reset, contrary to:
What I see in your octoprint.log looks like an issue with the filament sensor triggering and causing a reset or some recovery routine that causes at least a line number reset or maybe a full blown reset but without the preceding start message that should be sent:
| Last lines in terminal:
| Send: N36 G1 Y-2.0 F1000.0*28
| Recv: ok
| Send: N37 G1 X55.0 E25 F1400.0*101
| Recv: fsensor_stop_and_save_print
| Recv: echo:Enqueing to the front: "PRUSA fsensor_recover"
| Recv: echo: 3.8.0-2684
| 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:Stored settings retrieved
| Recv: adc_init
| Recv: CrashDetect ENABLED!
| Recv: FSensor ENABLED
| 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: N38 M105*28
| Recv: echo:SD card ok
| Recv: echo:busy: processing
| Recv: echo:busy: processing
| Recv: Error:Line Number is not Last Line Number+1, Last Line: 0
| Recv: Resend: 1
I don't have anything else to go on at the present time and am eagerly awaiting a bug report with full template.
2019-10-22 21:21:19,229 - serial.log is currently not enabled, you can enable it via Settings > Serial Connection > Log communication to serial.log
2019-10-22 21:47:37,247 - serial.log is currently not enabled, you can enable it via Settings > Serial Connection > Log communication to serial.log
Still disabled. Or maybe the wrong zip? Because this looks like the one you already shared above.
I definitely need some more information here. That makes it sound like it only happens with single color prints?
I want to understand this and if it's something that I can fix I'm also happy to rollout a hotfix release but I really need something to chew on here and so far all I know is that the MMU2 apparently does reset for some people, but not under which conditions, what goes over the line when it happens, whether the same happens in safe mode, if this is even a general issue or if there are maybe people out there who have this running just fine (I seriously struggle to believe that of the almost 1000 people who tested the RC noone had a similar setup - and if so that means that needs to change somehow). Flying completely blind here. Give me something to work with please.
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.
