MMU2 idler sometimes stays in engaged position, blocking the extruder idler from functioning properly

[Mirarkitty]

My MMU2(S) sometimes leaves the idler (idler-body) in the wrong position, where the MMU2 idler is engaged even though filament has reached the extruder and print has started.

This gives underextrusion since the extruder has to push both the filament and the MMU2 idler.

Have not found any good triggers, seems random in occurrence. Uncertain if I noticed it on any other filament than 5.

1. make gcode in PrusaSlicer for printing on filament 5
2. start print
3. filament 5 is selected
4. extruder starts printing filament 5, but MMU2 idler is sometimes still engaged on filament 5
5. underextrusion because extruder idler has to pull MMU2 idler
6. ruined print

[rackley096794]

I have seen this as well. Sometimes it is a partial engagement - the wheel is halfway between the engaged and disengaged positions, which causes friction, popping as the filament jumps over the gears and filament dust in the MMU gears.

[rambopierce]

I’m not claiming that this is the correct solution, but try slightly loosening the right screw (the screw closest to filament 5)on the MMU2. I’ve found the tension on the MMU2 springs to be difficult to hit a small sweet spot. Too loose and the filament doesn’t feed correctly or too tight (especially on the end furtherest from the motor and the tumbler doesn’t always position properly.

On Jun 29, 2019, at 10:05 AM, Ray Ackley notifications@github.com wrote:

I have seen this as well. Sometimes it is a partial engagement - the wheel is halfway between the engaged and disengaged positions, which causes friction, popping as the filament jumps over the gears and filament dust in the MMU gears.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Mirarkitty]

This is a firmware issue. I put some markings on and it's on the engaged position, same as when loading to the extruder. I'm NOT going to losen a screw to solve that issue.

[rambopierce]

I’m hoping it is a firmware issue and that it can be found and corrected. I did experience the case where the screw on the right was too tight and the idler body did not turn properly. Not saying that it isn’t a firmware bug it’s just strange that it was only position 5.

On Jul 3, 2019, at 3:16 AM, Mirarkitty notifications@github.com wrote:

This is a firmware issue. I put some markings on and it's on the engaged position, same as when loading to the extruder. I'm NOT going to losen a screw to solve that issue.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[Mirarkitty]

I've noticed the same issue on filament 1 and 2 now. But I had it 50% of the time on filament 5 for a while. (Same gcode sent again would randomly work.)

[rambopierce]

The random works part sounds more mechanical than it does firmware unless something like the current setting to the motor is marginally low or high. When I was having a similar issue I guessed that if I could reduce the tension/friction on the idler tube it could turn more freely. Mine ran much better after loosening the right-hand screw.

I don’t like what I found because my theory is that the tension setting on those screws is critical to success, but I see no good way to get the correct tension without a lot of experimentation. If I ever have to open the MMU2, I think I may scribe some marks and count screw turns like you do on a carburetor. As much as I like Prusa’s products, I think the MMU2 could use some design improvement, but I’m not a mechanical engineer.

On Jul 3, 2019, at 7:21 AM, Mirarkitty notifications@github.com wrote:

I've noticed the same issue on filament 1 and 2 now. But I had it 50% of the time on filament 5 for a while. (Same gcode sent again would randomly work.)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[rackley096794]

I think this may fall into the "design problem" category. I loosened my screws up (top of head level with surface) and I haven't had this problem since.

[rambopierce]

Glad that helped. Too loose and the filament won’t feed properly, too tight and the idler body won’t always rotate properly. I actually have the left screw tighter than the right (looking from the front of the printer). I had to do a ridiculous amount of tuning and experimentation to arrive at a tension that works well. I think it is a “design problem” as well.

On Jul 3, 2019, at 9:10 AM, Ray Ackley notifications@github.com wrote:

I think this may fall into the "design problem" category. I loosened my screws up (top of head level with surface) and I haven't had this problem since.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[Mirarkitty]

If it would be a design issue, this would be easy to test and see slippage when it was doing self calibration or when selecting other filaments. I don't have that. These are very strong and precise motors.

After an aborted print with the idler engaged, it can still select another filament (or same filament) and print the same gcode again but this time without the idler engaged.

I quote don't understand why some minor tension would have an effect here, please explain. Are they programmed to stop differently when self calibrating and when working normally? And if so, why doesn't the MMU2 warn that the load limit was hit?

If a tension adjustment helps, this is still a firmware issue.

The way I see it is that either

1) random behaviour because the code use uninitialized variables or have race conditions 2) erratic behaviour because of really badly programmed stuff 3) the tension theory is correct, and a load limiter is hit but isn't detected or compensated for in the firmware 4) erratic behaviour because of current supply issues and this is a hardware/board problem, and this can possibly also be compensated for in the firmware since it seems to know the position of the idler selector motor still

[AndrewR15]

I have the exact same problem. Trying to get it fixed with love chat now

On Jul 4, 2019, at 3:20 PM, Mirarkitty notifications@github.com wrote:

If it would be a design issue, this would be easy to test and see slippage when it was doing self calibration or when selecting other filaments. I don't have that. These are very strong and precise motors.

After an aborted print with the idler engaged, it can still select another filament (or same filament) and print the same gcode again but this time without the idler engaged.

I quote don't understand why some minor tension would have an effect here, please explain. Are they programmed to stop differently when self calibrating and when working normally? And if so, why doesn't the MMU2 warn that the load limit was hit?

If a tension adjustment helps, this is still a firmware issue.

The way I see it is that either

random behaviour because the code use uninitialized variables or have race conditions erratic behaviour because of really badly programmed stuff the tension theory is correct, and a load limiter is hit but isn't detected or compensated for in the firmware erratic behaviour because of current supply issues and this is a hardware/board problem, and this can possibly also be compensated for in the firmware since it seems to know the position of the idler selector motor still — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[vertigo235]

Don't have too much fun with the love chat.

[AndrewR15]

Live Chat 😞

[JohnOCFII]

I have the exact same problem. Trying to get it fixed with love chat now

Damn, yet ANOTHER reason to recommend Prusa Printers over the other guys. :)

[AndrewR15]

So the live chat fixed my issue. What I did was: flash the firmware sent by the attendant (Shane) which might be modified a slight bit and factory reset the printer. This seems to have solved the idler issue completely

[Mirarkitty]

DId you flash the MMU or the MK3? Would you be ok with sharing the firmware?

[AndrewR15]

http://prusa3dprinters.vshcdn.net/downloads/firmware/prusa3d_fw_3_7_1_MK3S_1_0_5_MMU2S.zip

Looks like the same thing but it changed something good. I think the main bit is factory reset after adding MMU2s

[workinghard]

Can confirm still an issue on the recent firmware 3.7.2 and 1.0.5 on MK3s+MMU2s. After the upgrade from MK3+MMU2 to MK3s+MMU2s the factory reset is happening anyway. Or is it a different factory reset?

[Mirarkitty]

I'm already running 1.0.5 since May... I guess I could try a factory reset, but that would still point to a fw issue.

[workinghard]

I'm already running 1.0.5 since May... I guess I could try a factory reset, but that would still point to a fw issue.

The question is it MMU2 FW or MK3 FW? For me it's printing all the time this way in single color print. The sensors are working fine and loading/unloading is happening like expected, no special stuff. Waiting for the next FW iteration ...

[Mirarkitty]

I don't know the code well enough, so I don't know what controls the MMU2 is getting... It could very well be that it never gets the "please move away the idler" command from the MK3.

[rambopierce]

I seriously doubt ‘love chat’ fixed the issue 😊 My theory is that tension on the MMU2 springs has something to do with the issue and the issue is intermittent. I know the motor is ‘strong’ (a relative term), but perhaps motor current tuning is needed. I’m hoping someone will chime in that knows the physics lots better than me.

On Jul 9, 2019, at 4:45 PM, Mirarkitty notifications@github.com wrote:

I don't know the code well enough, so I don't know what controls the MMU2 is getting... It could very well be that it never gets the "please move away the idler" command from the MK3.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[AndrewR15]

I’m under the impression that the factory reset with the MMU2 installed fixed it

[AndrewR15]

Working hard: I think the issue is that when we update firmware there is some sort of memory stored that is messing up the functionality of the firmware. I’ve seen this because I tried to run the Mk3s firmware (without MMU2) but it still ran the MMU2 firmware since it was still connected. Factory reset from the printer(all data)(write down custom settings like z axis tuning) is what fixed it for me

[rambopierce]

Interesting, I’ve had very strange behavior fixed by that painful process as well, e.g. seemed like the printer was trying to resume a print like after a power failure, but it wasn’t in the middle of a print. Powering off and back on again wouldn’t fix it, only the ‘all data’ factory reset. I wish there was a more minor reset that only cleared the data related to resuming a print so that all the calibrations wouldn’t have to be done over again.

On Jul 9, 2019, at 7:45 PM, AndrewR15 notifications@github.com wrote:

Working hard: I think the issue is that when we update firmware there is some sort of memory stored that is messing up the functionality of the firmware. I’ve seen this because I tried to run the Mk3s firmware (without MMU2) but it still ran the MMU2 firmware since it was still connected. Factory reset from the printer(all data)(write down custom settings like z axis tuning) is what fixed it for me

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[Mirarkitty]

Add a feature request for that?

[rambopierce]

Yes, please.

On Jul 10, 2019, at 12:55 AM, Mirarkitty notifications@github.com wrote:

Add a feature request for that?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[Mirarkitty]

This issue is tentatively fixed with the latest beta. I haven't seen it since flashing.

Edit: Nope, it's still there. Testing 1.0.6 and 3.8.0 now.

[github-actions[bot]]

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

[github-actions[bot]]

This issue has been closed due to lack of recent activity.