-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
i3 MK3s+ &MMU2s wrong Filament Selection #3281
Comments
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. |
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.
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 |
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. Hope could give you a tip. |
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. |
I can absolutely confirm the same behave you catched in video. The problem I try since mothes to reproduce it, with no success.
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 doen |
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. |
I have asked, because someone on the forum mentioned the following:
This might relate to my issues, but since you are not using the Zero port, this doesn't explain yours. |
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. |
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. |
@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. |
Closing as this is now resolved with FW 3.13.0 and MMU FW 3.0.0 :) |
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. |
@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 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)? |
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. |
This sounds exactly like #4323 🤔 |
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. |
PrusaSlicer
Version: 2.3.3+win64
Build: PrusaSlicer-2.3.3+win64-202107161027
i3 MK3s+ & MMU2s
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:
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
.......
`
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
The text was updated successfully, but these errors were encountered: