3.8.1: MK3S/MMU2S randomly (?) ejects the filament at start of a print

[Mirarkitty]

Firmware: 3.7.0 bundle

1. print something on filament 1
2. load filament in 4 (not load to nozzle)
3. print something with filament 4
4. printer ejects filament 4 and asks me to replace it
5. it loads the filament and now has a blob around the extruder, ruining the print

and this case

1. print something on filament 1
2. load filament 5 (not load to nozzle)
3. print something with filament 5
4. printer ejects filament 1 and asks me to replace it
5. it loads the filament and now has a blob around the extruder, ruining the print

I have no idea why it does this. It loads the filament perfectly without cutting it.

[Mirarkitty]

And again. It seems to be confused by the fact I'm loading a filament and then using it.

[Allram]

Do you have spooljoin activated? Maybe the Ir sensor does not trigger correctly (have you done the Ir sensor calibration?) so that it looses the triggerpoint somewhere during the print and then tries to unload so that you can remove the "rest" filament (aka empty spool) and then load the new filament?

[Mirarkitty]

I do not have spooljoin activated. MMU prints can get very confused with that activated.

I have seen it three more times. The last time I had printed with filament 1 for about 10 prints in the same way (rapid prototyping) when it decided to eject filament 1.

This does not happen during the print but before bed level calibration, judging from what it does afterwards:

1. start print
2. heating
3. filament ejected
4. manual interaction
5. filament loaded with purge (blob, the blob that might follow the print around)
6. manual interaction (yes, it's the right colour)
7. bed level calibration (!!)
8. unload filament
9. load correct filament
10. purge line
11. actually print

(where 8 and 9 doesn't happen if it loaded the correct filament in 5)

Everything is calibrated to almost perfection. I can run a long multi material print. This seems to only happen in the beginning of the print, before calibration.

[Mirarkitty]

And again, new print, same filament as the previous 15 prints, it heats up and https://youtu.be/vW9FVk8xtgw
It's definitely an EJECT that's happening. And it doesn't happen when it's supposed to load the filament either. (I just pulled it back towards the spool and it loaded fine, again, as always.)

I'm printing with PrusaSlicer + Octoprint (SD card is not involved). I suppose there's a G-code that ejects the filament, but I doubt it's generated or sent.

[mkbel]

You can try disable filament sensor. This menu item name is somehow misleading, as it means it will stop detecting filament run outs, but for all other purposes the sensor is still used. Detected filament run out leads to filament eject and screen on your image. Filament run out is detected by upper sensor - FINDA. Maybe it is false triggering and you need to tighten it. And use later firmware with Octoprint. With 3.7.0 there is serious bug "Octoprint MMU load failed" which destroys your print whenever "MMU load failed" problem occurs.

[mkbel]

Maybe the Ir sensor does not trigger correctly (have you done the Ir sensor calibration?) so that it looses the triggerpoint somewhere during the print and then tries to unload so that you can remove the "rest" filament (aka empty spool) and then load the new filament?

Filament run outs are not detected by bottom IR sensor, they are detected by upper sensor FINDA. As if would be filament run out detected by bottom sensor, there would be no way to eject really short filament.

[mkbel]

We asked our test department to test your scenarios. If you would supply gcode where the problem occurs it would be beneficial.

[Mirarkitty]

I doubt this has anything to do with the filament sensor, unless there's another bug in there. The eject happens before it even picked the right filament, so it really shouldn't care (yet). It can eject a filament that isn't going to be used in this print. And I can't see any scenario where it would eject a filament even if it runs out? Or how it can eject a filament if it ran out since the MMU idler is before the sensor.

I'll try to get gcode when it happens. But it's normal gcode with (except filament fan and temperature) default settings from PrusaSlicer 2. I'm not sure how since I usually don't save it but send it directly to octoprint.

[Mirarkitty]

Here's a gcode that triggered the issue. I had printed with filament 1 (PETG) before and switched to filament 2 with this gcode. It heated up everything and then unloaded filament 1 (which was not going to be used!).

loadfeet_0.3mm_PET_MK3MMU2_27m.gcode.txt

Second time running the same gcode (after a reset), no issue at all. So I doubt it's the gcode.

[Mirarkitty]

Looking at the code, it looks like it's plausible that the filament sensor runs an M600 (there's no filament, so...) and saved_printing is set, causing an eject. I'm not sure why an eject is useful if the filament is out (there's no filament to eject - no way the MMU could roll it back - right?).

In the code there's comments in mmu.cpp that says "save print and issue M600" which looks like it would cause exactly this.

                if (mmu_rx_ok() > 0)
                {
                        fscanf_P(uart2io, PSTR("%hhu"), &mmu_finda); //scan finda from buffer
                        FDEBUG_PRINTF_P(PSTR("MMU => '%dok'\n"), mmu_finda);
                        //printf_P(PSTR("Eact: %d\n"), int(e_active()));
                        if (!mmu_finda && CHECK_FSENSOR && fsensor_enabled) {
                                fsensor_stop_and_save_print();
                                enquecommand_front_P(PSTR("PRUSA fsensor_recover")); //then recover
                                ad_markDepleted(mmu_extruder);
                                if (lcd_autoDepleteEnabled() && !ad_allDepleted())
                                {
                                    enquecommand_front_P(PSTR("M600 AUTO")); //save print and run M600 command
                                }
                                else
                                {
                                    enquecommand_front_P(PSTR("M600")); //save print and run M600 command
                                }
                        }
                        mmu_state = S::Idle;
                        if (mmu_cmd == MmuCmd::None)
                                mmu_ready = true;
                }
                else if ((mmu

[mkbel]

I'm not sure why an eject is useful if the filament is out (there's no filament to eject - no way the MMU could roll it back - right?).

With MMU, FINDA - top sensor on MMU - is used to detect filament runout. So it is possible to return filament to MMU as there is more than 40mm of filament inside extruder. As this filament is unloaded, MMU can catch filament again and eject it.

[Mirarkitty]

Ah, I see. That makes sense. Then it's very plausible that the system goes into a "I've run out" state even though it hasn't loaded anything.

[Mirarkitty]

This bug is alive and well in 3.8.0-rc1

[Mirarkitty]

And in 3.8.1.

[strick213]

I am having the same problem so far printing with PETG and flexible filament. The flex is particularly bad because when it retracts to the MMU2 it sticks out more than it pulls back in and the selector simply rolls over it and pushes it to the side. Apparently the cutter is not cutting it as it shoud. Then when it tries to push it through. it wads up in the gears and has to be manually removed, which is not an easy task. This has happened three times so far 35 minutes into a 1.5 hour print. I eventually learned how much to cut off to keep this from happening, but there is no reason why it should be pulling the filament back in the first place. I have the filament sensor pushed to the right at its most sensitive position as it was having trouble sensing that the flexible filament was loaded. This is a custom design using Prusa Slicer.

[Mirarkitty]

Just happened with 3.9.0-rc1.

[Mirarkitty]

And in 3.9.0-rc3.

It seems to happen after loading the MMU with a new filament (from the menu), at random, once.

[Mjankor]

Just had it happen in 3.9 final too. I have had it happen a lot but haven't bothered reporting it, as I can't yet identify what causes it to occur.

[Mirarkitty]

Same, 3.9.0 release. Thanks for reporting it, nobody seems to care about this bug.
I believe I already have identified the broken code above.

[Mirarkitty]

It seems purely random to me, repeating the same print in the same circumstances and sometimes it goes into eject. Disconnecting and reconnecting the printer in octoprint resets it and I can run the same gcode again with success (most likely).

[wolph]

I can confirm the issue. I do have to say... a badly calibrated sensor seems a likely cause so I'm going to try and check that but I still believe the way it's handling it is an issue.

What's worse... octoprint doesn't seem to understand it so every time this happens I need to restart octoprint because it gets stuck on "paused for user"

[Mirarkitty]

Exactly. Is this fixed in 3.12?