Prusa MMU2s Not working in 1.3.12

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?

1 Like

Just rolled back to 1.3.11 and it works fine so something is up in the latest version.

Logs would help to find out what is wrong :wink:

Same here, just copied this from the other tread:

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?

Setup:
Raspi Pi 4, OctoPrint 1.3.12 - OctoPi 0.17.0
Prusa MK3S (3.8.0) + MMU2S (1.0.6)

Here is the logoctoprint.log (82,3 KB)

I do have the same reset problem with the 1.3.12 release and my Prusa MK3S + MMU2S. Printing the same GCODE directly from the SD card works fine.

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)

log file octoprint.log (57.5 KB)

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.

1 Like

@Ewald_Ikemann if I remember correctly you have an MMU. Can you confirm/deny/help?

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)

@Sigmund

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:

@rajahb

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.

Here are my serial logsserial.log (296 Bytes) logs.zip (579 Bytes)

@Sigmund you need to enable the serial.log first, otherwise nothing gets written. It's explained in the serial.log :wink:

Here you go - hope this helps. logs.zip (579 Bytes)

This time with safemode and logging.

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.

There is some issue with the upload... I can try any file and it only shows me the same logs.zip...

https://filebin.net/uuhp8oqzug7zd1pm/test.zip?t=rofu4al1

please try this

That's the exact same zip once again. 579 bytes size, two empty serial.logs therein.

Same issue, one way to solve this very easly it's using the OctoPrint-Mmu2filamentselect Plugin.

later I will upload my serial.log with and without the plugin enabled

hope this helps. :smile:

1 Like

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.

edit

Tracking this now in https://github.com/foosel/OctoPrint/issues/3314.

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.

Hi @foosel, I'll give it a try ASAP.

1 Like