i3 MK3s+ &MMU2s wrong Filament Selection

[hartmannf]

PrusaSlicer Version: 2.3.3+win64 Build: PrusaSlicer-2.3.3+win64-202107161027

i3 MK3s+ & MMU2s

• Prusa MK3s+ 3.9.3
• MMU2s 1.0.6
• Rpi 4B
• OctoPrint 1.6.1
• Python 3.7.3
• OctoPi 0.18.0

This is really confusing Trouble I am facing. Regularly By downloading Gcode file over Octopi and/or also loading directly over SD Card, The Gcode Tool selection is correct but Physically it selects random slot of an other Filament of MMU2. This morning finally I could catch the case as follow:

Example:

IR_Sensor_State_Window_0.15mm_PETG_MK3SMMU2S_2m.gcode shows `; generated by PrusaSlicer 2.3.3+win64 on 2021-09-25 at 06:13:20 UTC ; ; external perimeters extrusion width = 0.45mm ; perimeters extrusion width = 0.45mm ; infill extrusion width = 0.45mm ; solid infill extrusion width = 0.45mm ; top infill extrusion width = 0.40mm ; first layer extrusion width = 0.42mm

M73 P0 R2 M73 Q0 S2 M201 X1000 Y1000 Z200 E8000 ; sets maximum accelerations, mm/sec^2 M203 X200 Y200 Z12 E120 ; sets maximum feedrates, mm/sec M204 P1250 R1250 T1250 ; sets acceleration (P, T) and retract acceleration (R), mm/sec^2 M205 X8.00 Y8.00 Z0.40 E4.50 ; sets the jerk limits, mm/sec M205 S0 T0 ; sets the minimum extruding and travel feed rate, mm/sec M107 ;TYPE:Custom M862.3 P "MK3SMMU2S" ; printer model check M862.1 P0.4 ; nozzle diameter check M115 U3.10.0 ; tell printer latest fw version G90 ; use absolute coordinates M83 ; extruder relative mode M104 S240 ; set extruder temp M140 S70 ; set bed temp M190 S70 ; wait for bed temp M109 S240 ; wait for extruder temp G28 W ; home all without mesh bed level G80 ; mesh bed leveling

; Send the filament type to the MMU2.0 unit. ; E stands for extruder number, F stands for filament type (0: default; 1:flex; 2: PVA) M403 E0 F0 M403 E1 F0 M403 E2 F0 M403 E3 F0 M403 E4 F0

;go outside print area G1 Y-3.0 F1000.0 M73 P14 R2 M73 Q14 S2 G1 Z0.4 F1000.0 ; select extruder T3 ; initial load .......

`

T3 is correct, but Physically is Loading T1 on LCD Display showing F2 ` I made the test as well downloading from Octopi as well loading over SD Card. Behave in both cases the same way. It seems that somehow ensy or mmu board hangs. So thats the reason why I do not think it is octopi related.

Over octopi once startet job tried to enter in therminal window T0 with no reaction then T2 right away changed filament to T0 tried as well T3 and it changed back again to T1 confusing....

After Restarting (Power OFF / On cycle ) everythings works again as expected.

checked on octopi that 5 Extruder with shared nozzle is configured.

modified filament sensor with LED stat to exclude Loading Filament Issues

I have noticed that behave since really a long time and my turn arround was always before restarting a job to consequently Power Off/ On cycle, and up to know it always worked.

My question it is permanently behaving again that way, but I could not reproduce it up to know. There somebody got me a tip where I might be look at?

thanks a lot

[ulab]

I am having similar issues with 3.10.1-rc1 in combination with PrusaSlicer 2.4.0-alpha3 and PrusaLink/PrusaConnect.

In my case it randomly(?) loads filament before bed leveling (even going to the front right corner like for a manual swap) then sometimes it changes to the right filament and when I cancel the print it loads some other filamentand moves to the center of the bed.

It's really weird behaviour, but I have not yet figured out why and when it is happening.

[hartmannf]

Oh thanks for your support:) At least I am not the only one that strugels with that behave ;)

It seems that a partial trouble I got fixed due paukstelis posted on Octopi Forum. I disabled spool join, I learned something, that I didn`t know. See post link: [https://community.octoprint.org/t/prusa-i3-mk3s-mmu2s-select-wrong-filament-tool/37476]

In my case it randomly(?) loads filament before bed leveling (even going to the front right corner like for a manual swap) then sometimes it changes to the right filament and when I cancel the print it loads some other filamentand moves to the center of the bed.

It's really weird behaviour, but I have not yet figured out why and when it is happening.

But I can absolutly confirm your description. Just yesterday, after finishing a job with T2, restarted a print where T1 was required, Printer loaded filament T2 flushed before bed levelingI (even right corner for a manual swap) then confirmed on LCD right filament color with yes, made bed leveling and then changed filament to T1, and everything turned Right.

What I noticed but not in that case, if MMU2 gots Userintvention messages on LCD, because failed load. then the behave is just luck,

PrusaSlicer-2.3.3 , Prusa MK3s+ 3.9.3 -> Upgraded to 3.10.0, MMU2s 1.0.6 By reading your reply I checked that wipe tower was disabled, and it was. but it shouldn`t matter because both prints are anyway single Color print. I noticed that in previous print where T2 was used wipe tower was Enable even it was a single Color print. But how ever, still searching the logic in that behave... then you do too.

[jlshelby]

Having a similar issue. I had 3.7.2 and 1.0.5 for the MMU2s which was working great with minor problems once in a while. I upgraded to 3.10.0 and 1.0.6 and have had nothing but problems with the MMU2s including random filament changes or switching filaments at the start then dumping out filament and switching to another filament.

The MMU2S will constantly error out and flash all the lights sometimes requiring a reset button press other times it will just sit there and clear on its own.

I tried to downgrade back to 1.0.5 but that became even worse so I flashed back to 1.0.6 and reflashed the printer to 3.10.0 and now I can't get it to work at all as it is setting PLA temperatures for my PETG filaments, randomly selecting wrong filaments and then stopping due to the temperature is not hot enough for the filament and jamming.

[hartmannf]

Having a similar issue. I had 3.7.2 and 1.0.5 for the MMU2s which was working great with minor problems once in a while. I upgraded to 3.10.0 and 1.0.6 and have had nothing but problems with the MMU2s including random filament changes or switching filaments at the start then dumping out filament and switching to another filament.

The MMU2S will constantly error out and flash all the lights sometimes requiring a reset button press other times it will just sit there and clear on its own.

I tried to downgrade back to 1.0.5 but that became even worse so I flashed back to 1.0.6 and reflashed the printer to 3.10.0 and now I can't get it to work at all as it is setting PLA temperatures for my PETG filaments, randomly selecting wrong filaments and then stopping due to the temperature is not hot enough for the filament and jamming.

A few months ago I had a similar issue. It took me a while to figure out that temperature sensor on hotend, the wires where melted to aluminium block, and surrounded with melted plastic . On first and second look I didn not noticed that failure. I assume it made some kind of short cut. it wasn not reliable to get accurate temperature. At that time I can remember that also mmu had some required resets. I don`t think that it is reltated to firmware issue, more like an electrical issue. perhaps you should consider to scan trough and see if some voltage drops might be happen. In my case I noticed that I had to change the temperature on materials that where always working on certain setpoint. of course also check Actual temp displayed with external temperature meassure device might be giving you some idee where the problem might be. and of course I changed the temp sensor, and then I had catched the wrong one with wrong caracteristics...

Hope could give you a tip.

[ulab]

I was able to record a video of my printer doing this with 3.10.1-rc1: https://photos.app.goo.gl/1QAmbK9pxVXaGmUB7

It finishes Z calibration, then loads the wrong color like it's in non-MMU-mode and re-calibrates Z before it starts printing (and tries to overextrude during the purge line)

The gcode is supposed to print using slots 2 and 4, but it starts with 4. The same file printed before started with slot 3 which was wrong either.

I have also attached the gcode I tried to print. letter_elephant_i_0.2mm_PETG_MK3SMMU2S_3h10m.gcode.zip

[hartmannf]

I was able to record a video of my printer doing this with 3.10.1-rc1: https://photos.app.goo.gl/1QAmbK9pxVXaGmUB7

It finishes Z calibration, then loads the wrong color like it's in non-MMU-mode and re-calibrates Z before it starts printing (and tries to overextrude during the purge line)

The gcode is supposed to print using slots 2 and 4, but it starts with 4. The same file printed before started with slot 3 which was wrong either.

I have also attached the gcode I tried to print. letter_elephant_i_0.2mm_PETG_MK3SMMU2S_3h10m.gcode.zip

I can absolutely confirm the same behave you catched in video. The problem I try since mothes to reproduce it, with no success. I went trough your gcode file, and can just confirm what you already wrote in your comments.

• On a certain moment I had a feeling that it happend when I got WIFI lost on octopi, but I couldn`t reproduce. But it became better when I accesed the octopi by hostname and not IP.
• Then I noticed that it happen if on previous print I had some mmu load failures. But also in that case I couldn`t repruduce it.
• Then I tought it had to with splice, and resplice it, but also in that case it didn`t made sense because when I screen the gcode never a wrong toolsettup appears.

Honestly I think it is a pruse either MMU or mainboard bug, but I can`t catch it due missing protocall anlysing possibility.

perhaps there is somebody that knows a turn arround to prevent that behave.

Oh and by the way, I tried also to get over technical support of prusa, but once he told me to make a video, for it doent make sense at all. Logfiles are crutial, to catch random effects. (please dont missunderstand, don`t want to doupt on prusa support or knowledge... I absolutely understand the trouble to get this random beahave catched)

[ulab]

How is your Octopi connected? I am using a Pi Zero with PrusaLink for a while that is directly mounted to the Einsy board.

[hartmannf]

How is your Octopi connected? I am using a Pi Zero with PrusaLink for a while that is directly mounted to the Einsy board.

I bought the printer a second hand, and there was a Pi zero installed. But right away on the beginning I had performance problems, so removed it, and also isn`t recommended from Octopi. Of course prusa gots an other experience then I do, I think it is relly depending how heavy octopi is configured, (but this is just a feeling and not verified on my side) I am using Pi4B connected with usb cable to Ensy board, and over wifi2router. On a seperate Pi4B also connected over wifi2Router I use chrome as UI. In my case RPI Port on PRusa is OFF.

A few days ago I had an idea2be able to log at least a few signals. In the copany we sometimes using a hardware signal logger to monitor analog and digital Signals. Once I got time I would like to connect Pinda and finda Sensor, and see if some flippering or random voltage drops might cause the problem. when I added the external LED https://www.prusaprinters.org/prints/76233-extruder-idler-mmu2s-adjustable-with-screw-adj-hou I noticed strange voltage levels, the problem because of luck of time didnt get in to it. I also switched off the Knife funktion on prusa, but havent run prints since that.

[ulab]

I have asked, because someone on the forum mentioned the following:

I did some digging and it seems MMU2S uses EXT3 socket on the Einsy board where serial ports are exposed. Most likely they use for the MMU2S the same serial port Prusa Link uses to communicate the Raspberry with the Einsy too, thus raising the above-mentioned incompatibility.

This might relate to my issues, but since you are not using the Zero port, this doesn't explain yours.

[5jvm0u4]

I have similar problem, I'm connecting my Pi4 to Einsy via Pi4 GPIO and the pins that Pi zero uses on Einsy, it would randomly load filament during first layer and when I stop the print through LCD instead of Octopi server. Notice the MMU message came out of no where. I'm printing with T2 at start, it switched to T3 in mid-print, and then T4 when I stopped the print, and it stayed loaded.

[jlshelby]

From my results and testing with Prusa I found the MMU2S firmware 1.0.6 was the cause of many problems. After going back to 1.0.5 all the issues I had related to this went away. The misloading of different filaments. The random MMU flashes and required hard resets. Using the 3.7.2 with 1.0.5 seems to be the most stable.

[hartmannf]

as I noticed there are 2 different behaves.

1th it is before or during the print changing to Actual Tool +1 --> exampl: it is selected T3 working with t3, and then changing to T4, pinting and then suddendly to T5 and once reached T5 jump to T0. to prevent that: Turn off spool join on the printer settings and see if it still happens. or adjust, clean fil sensors. the sequncial behave I could solve with that setting.

2th it is radomly changing to any random tool. during print ,on beginning or end... this happens to my printer and it happend with 1.0.5 as well on 1.0.6 at least in my case. there I have at the moment no aproach where 2 look at.

@jlshelby did you chack 1th case?

Hope I could help.

[jlshelby]

@hartmannf my issue is only with v1.0.6 of the MMU2S firmware and during the initialization where it is prepping for a print then will randomly load some other filament then realize it was the wrong filament and go back to the one it is supposed to use then thinks it properly loaded the wrong filament and will extrude a bunch of the correct filament for no reason and taking and extra few minutes to initialize and wasting filament.

This issue never happens with the 1.0.5 firmware and I have gone back to the 3.7.2/1.0.5 firmware set to avoid all these issues.

[gudnimg]

Closing as this is now resolved with FW 3.13.0 and MMU FW 3.0.0 :)

[sruggier]

Not only am I still seeing this, but it seems to happen to me on every single print now since I upgraded the firmware. If there's something I can do to help diagnose why it's happening, please let me know.

[gudnimg]

@sruggier If we could get the logs from the printer when this happens that would help a lot. Given it happens everytime I suspect this has something to do with you setup. Are you by any chance printing via USB? (PrusaLink/Octoprint)

Try sending T0, T1, T2, T3, T4 to the printer respectively. The logs will show how the printer parses for example "T4" as it transmits the command to the MMU and also how the MMU interprets it since the MMU always either accepts the command or rejects it.

When the issue happens do you see any other weird behavior from the printer? Is it only loading a different MMU filament slot or does it do something else also which is unexpected (for example parking the extruder to the side)?

[sruggier]

Yes, I'm printing with Octoprint, so it wouldn't be surprising if that were related. It parks the extruder to the side as well, as it would if the filament ran out, but this happens immediately, before loading even starts. After loading, it goes back and redoes the bed levelling again, similar to other commenters' description in this issue.

Historically, it hasn't happened to me during multi material prints, only at the start. I don't think I've done any prints with tool changes since upgrading the firmware, though, so I won't try to say it definitely doesn't happen during tool changes now.

I'll try printing from the SD card, see if that makes a difference, and report back here. I didn't think of getting logs directly from the printer, so I'll look at that as well when I can find the time.

[gudnimg]

This sounds exactly like https://github.com/prusa3d/Prusa-Firmware/issues/4323 🤔

[sruggier]

Yes, that's my issue exactly. It probably would be better to continue the discussion there instead of reopening this issue, so I'll probably do that.