Large purge blob created by MMU2 when using single filament #2069
Comments
|
Which version of firmware do you use? |
|
It's 3.7.2-2363 |
|
Same here, even sometimes extruder start clicking. |
|
Don’t know for sure, but I’m wondering if this isn’t some bad startup gcode from the slicer. I do recall having a version of the slicer or left over startup gcode in the slicer configuration of a previous version that caused a similar issue for me.
… On Aug 6, 2019, at 12:15 AM, tutulino ***@***.***> wrote:
Same here, even sometimes extruder start clicking.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I've observed this too, primarily with more "liquid" filaments (e.g. PLA at PETG temps from a material change) the incoming filament and trapped air can easily force out the slug of old filament. Often there'll be a snap/pop as the trapped air escapes and it'll stop oozing until the prime line. |
|
I'll add my +1 to this under the same circumstances, when printing something in MMU2S Single mode. It was bad enough that it ended up creating a clog between the PTFE tube and the hot end (Mosquito, in my case). Looking around, in |
|
Also want to chime in to say that I've seen this multiple times. It can lead to jams when loading the first color, because it tries to push a large amount of filament out with the nozzle only slightly above the bed. Can lead to horrible grinding in the extruder. Edit: FW 3.7.2, 1.0.6 |
|
This is not only happening in single mode. Also I've noticed it several times during a multi material print at times when no filament change is due. Printer happily prints and all of a sudden without any visible reason (no jams, no extruder clicking, no indication of any issue) it stops, moves the printhead to a different position and ejects the filament - but no cooling moves or other usual MMU2 stuff - just like when you use the "Eject Filament" command in the menu. Then you get the ".. replace old filament.." message on the lcd and the mmu spits out the filament for inspection. Happened 4 times today alone.. Firmware 3.8.1, MMU2 firmware 1.0.6. I've seen this behaviour in prior firmware versions also. |
|
Any progress on this from Prusa? |
Your issue sounds like false filament runouts. Calibrate/check your IR sensor. |
|
I recalibrated the sensor after the first fail, I measured the sensor after the second fail I swapped the sensor after the 4th fail and I measured the sensor -> einsy cables while wiggling them - they checked out ok. |
|
I think you need to check the FINDA, not the ir sensor. That is the one that regusters a runout. |
|
Thanks leptun for pointing in that direction! It is the FINDA that's making problems in a way (but not the way I would have expected...) or at least the status the printer thinks the FINDA has. None the less: If the printer would refrain from producing a large blob after recovering from a perceived filament runout all prints would not have been lost. So there may be an issue with my FINDA but there is definitely an issue with how the printer behaves after a (perceived) filament runout... |
|
I think @ACETyr issue is different than the OP. I also have the same issue as the OP (ie, only during the starting purge line, I think only on MMU single material prints), but my sensor display is showing the expected state, and not varying state when it shouldn't be. |
|
Could the administrator separate the two completely different issues that are being discussed here? The original thread is about a big blob forming at the start of every print, nothing else. That's what I'd like to see the answer to. |
|
Didn't want to hijack the thread. When I initially chimed in I did not realize there was a different reason for the behaviour (although I think it is the same code being executed by the printer for other reasons). Apologies! |
|
Could someone look into this issue please? I've just downloaded the latest firmware for the MK3S 3.8.1 and mmu2 3.8.2 using PrusaSlicer 2.1.0 and I'm still getting this huge blob. Although that isn't a problem if it manages to extrude all of that material, sometimes it just can't because the head isn't moving. It really shouldn't be doing this. It happens every time, so it ought to be very easy to replicate. I happens when you select to print from SD card, selecting the MMU2 channel, or if you load to nozzle first. |
|
Hello, Same problem with my recent MMU2S build. Don't know if it is provoked by the T code or by the two lines Bellow: G1 X55.0 E29.0 F1073.0 But the quantity of material being extruded in the same spot is huge and has as consequence that the load fails. Maby the nozzle could be higher during the load? Regards, |
|
It's good to hear I'm not the only one with this problem, I get it on every single print with single colour MMU2 printing. It would be great if someone from Prusa would pick this up and do something about it. |
|
+1 i3 MK3s Firmware: 3.8.1-2869 |
|
Come on Prusa, we've shown this is easy to replicate, it's going to be an easy thing to fix so what's the hold up? |
|
If it's so easy to fix, why not fix it yourself and submit a pull request? ;) In all seriousness, they've been working on buttoning up the 3.9 release for the past little while now and all of the internal testing/fixes/tweaks that accompany that. They have an internal list of features/fixes planned out for whatever the pending release is (and often the one after that too) unless something show-stopping shows up, it's not going to get put in the release; it's simply not possible to manage a release with "fix ALL the things" and "add ALL the features. Yes, it sucks if your own issues are not on that list, but unfortunately that's simply the way software development is organized - someone had to make a judgement call at some point that leaves more than one person unhappy, and griping about it isn't going to get things fixed any faster. If you do want to take a stab at fixing it yourself, the relevant section is in Marlin_main.cpp; specifically the handling of Tx and Tc codes (The literals, not the T0-4). Since the blobbing doesn't happen on purge towers, the problem more or less has to be confined to that section and not in further shared code. Without diving in further I'm betting it's the split load-to-bondtech, wait, finish-load that's introducing some extra unexpected distance as opposed to the normal single-shot load during a multimaterial print. Or, for a non-firmware workaround, you can likely modify your startup gcode to not use Tx/Tc and instead set the filament explicitly, with a T# call. You could make 5 "single mode" profiles, one for each slot. |
|
I don't think it's up to purchasers to fix bugs on an individual basis, that's for the system designer to do. I'm well aware that they have lots of things to do, but if there's no response at all to the thread which is now months old, how are we to know they've even registered it as a bug? I'm not about to spend ages fixing something that is not my problem. Not only is that a waste of my time, but are you seriously suggesting that everyone who has this problem has to also fix it themselves? All things have bugs, but this is pretty obvious to anyone who's used it in single colour mode. It seems that all of the testing has been done on multi-colour prints and none on single colour, else they would have picked this up before they even shipped it. |
|
I'm just pointing out you have options if Prusa's internal timeframe for getting to it is unsatisfactory. This is their pubic bug tracker, so yes, it has been registered for them to look at (along with the 702 other open issues...). Someone at Prusa has at least seen it (Michal Fanta is the product manager) What I was suggesting is that there's nothing preventing you from fixing the bug and then sharing your fix here for possible inclusion in an upcoming release. This will undoubtedly get it moving a little faster, because now their only remaining work is to validate that it fixes the issue and doesn't cause any new ones; the legwork of identifying the cause and implementing a fix, by far the biggest task, is already done. Look, I get you're unhappy about the state of affairs here and speed at which things are moving, that's pretty clear. I'm just trying to offer some perspective from the other side of the curtain on why every outstanding issue can't be addressed on the schedule its creator wants. From a software dev's perspective, the words "it'll be easy" and "while you're in there" are words of doom, things are rarely as simple as they seem on the surface. We hear those words and we know we're in for the long haul at the expense of something else... |
|
Having the same problem in mmu single mode |
|
@rogerfroud I mentioned the IR sensor only as possible reason why is the blob on the 1st picture bigger and as possible reason for "extruding for several seconds on one spot" you mentioned.. |
@rtyr: @rogerfroud is correct, it does extrude for several seconds while stationary (the initial Tx/Tc purge lasts around 11 seconds). It only does this in single material mode, not using multimaterial slicing and a single filament. Please see the associated videos for confirmation/evidence. While IR probe false triggering will cause random retraction/feed issues, that's not the issue causing the purge blob here. In my testing the IR sensor is properly calibrated, and the print runs without errors for hours after the initial purge blob is cleared |
You can clearly see on your video, that it is extruding under 1 second (0:34-0:35) ;-). |
|
Anyway, I guess it is clear now, that he is experiencing the same "standard" behavior as on your video. I will leave this issue to FW team. Happy New Year |
|
Happy new year! Thanks for getting eyes on this issue, Francis |
|
I'm seeing exactly the same issue (extruding a big blob at the start of the purge line) in MMU Single mode, latest firmware on both the MMU and MK3S+, latest PrusaSlicer and configuration profiles. With this behaviour, it's infuriating to try and print with PETG since bits of the blob stick to the nozzle and end up ruining the first layer. It also chews up the filament in the bondtech gears, since it can't actually push more plastic into the blob. This causes underextrusions later on in the skirt where the thinner filament makes it into the nozzle. |
|
I see the same big blob of filament in MMU2 Single mode. To avoid the PETG sticking too much to the nozzle, I changed the startup g-code to raise the nozzle to 4 mm for the first part of the introduction line. |
|
Come on Prusa, please do something about this, I raised this issue in August 2019!!! |
|
It is very frustrating that prusa haven't resolved this issue.
The workaround for me has been to use the slicer in multifilament mode for
single filament prints, then disable the wipe tower and just use filament 1
for all single filament prints.
This also means I need to change the filament #1 spool between jobs,
instead of being able to set the spool # for each job on the fly
(pre-sliced parts).
Francis
…On Thu, May 27, 2021, 2:31 AM rogerfroud ***@***.***> wrote:
Come on Prusa, please do something about this, I raised this issue in
August 2019!!!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2069 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIRGDDGGQWYF46W5Z7YFL5DTPXRKNANCNFSM4IJGJTRQ>
.
|
|
There are other issues with the MMU2 firmware that they need to address if
you're only using it for single material prints. I'm trying to put together
a scenario they can repeat. I'm finding that if it fails to unload the
filament successfully at the end of the print, say, it then gets stuck in a
logical loop that you can't get out of where it thinks the MMU2 has an
issue. Turning it off and on again, or trying to force an unload is to no
avail. It can take ten minutes of messing about to finally clear the error
so it can start working normally.
Reset doesn't help. If anyone has a similar problem and knows what triggers
it and how to get out, I'd be interested to know.
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Thu, 27 May 2021 at 10:26, FEsmondeWhite ***@***.***>
wrote:
… It is very frustrating that prusa haven't resolved this issue.
The workaround for me has been to use the slicer in multifilament mode for
single filament prints, then disable the wipe tower and just use filament 1
for all single filament prints.
This also means I need to change the filament #1 spool between jobs,
instead of being able to set the spool # for each job on the fly
(pre-sliced parts).
Francis
On Thu, May 27, 2021, 2:31 AM rogerfroud ***@***.***> wrote:
> Come on Prusa, please do something about this, I raised this issue in
> August 2019!!!
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <
#2069 (comment)
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AIRGDDGGQWYF46W5Z7YFL5DTPXRKNANCNFSM4IJGJTRQ
>
> .
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2069 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMVOBHB5K5Y7Z57CDJSITPTTPYF3JANCNFSM4IJGJTRQ>
.
|
|
When it gets stuck during unloading (maybe 15% of the time), it's usually
from a blob or string on the end of the filament at the mmu in the Bowden
time. I unscrew the Bowden from the selector, and cut off the filament tip.
Usually by holding down the middle button on the mmu2, it will then re-try
the retraction, and complete the unloading. Sometimes I reset the mmu2 with
the button by the mmu2 usb port.
In my case, I installed a slightly longer Bowden tube because the normal
Bowden was slightly kinked with the stock length, and during loading it
runs a sequence of slightly longer pushes until it finally reaches the
extruder gears.
A similar issue to the unloading is when it has trouble loading at some
point during a print (often at the start, with a fresh cut tip). Many mmu2
lights start blinking. After addressing the issue, it gets stuck in the
same loop where the printer won't recognize that the physical problem is
resolved, and the mmu2/mk3s are not in sync. The mmu2 is correctly loaded,
but the mk3s is still paused waiting on the mmu2. Usually forcing the mk3s
to heat back up, then resetting the mmu2 will make it start again.
Francis
…On Thu, May 27, 2021, 5:43 AM rogerfroud ***@***.***> wrote:
There are other issues with the MMU2 firmware that they need to address if
you're only using it for single material prints. I'm trying to put together
a scenario they can repeat. I'm finding that if it fails to unload the
filament successfully at the end of the print, say, it then gets stuck in a
logical loop that you can't get out of where it thinks the MMU2 has an
issue. Turning it off and on again, or trying to force an unload is to no
avail. It can take ten minutes of messing about to finally clear the error
so it can start working normally.
Reset doesn't help. If anyone has a similar problem and knows what triggers
it and how to get out, I'd be interested to know.
<
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
>
Virus-free.
www.avg.com
<
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Thu, 27 May 2021 at 10:26, FEsmondeWhite ***@***.***>
wrote:
> It is very frustrating that prusa haven't resolved this issue.
>
> The workaround for me has been to use the slicer in multifilament mode
for
> single filament prints, then disable the wipe tower and just use
filament 1
> for all single filament prints.
>
> This also means I need to change the filament #1 spool between jobs,
> instead of being able to set the spool # for each job on the fly
> (pre-sliced parts).
>
> Francis
>
> On Thu, May 27, 2021, 2:31 AM rogerfroud ***@***.***> wrote:
>
> > Come on Prusa, please do something about this, I raised this issue in
> > August 2019!!!
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> > <
>
#2069 (comment)
> >,
> > or unsubscribe
> > <
>
https://github.com/notifications/unsubscribe-auth/AIRGDDGGQWYF46W5Z7YFL5DTPXRKNANCNFSM4IJGJTRQ
> >
> > .
> >
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <
#2069 (comment)
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AMVOBHB5K5Y7Z57CDJSITPTTPYF3JANCNFSM4IJGJTRQ
>
> .
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2069 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIRGDDEQLN5G2ODFESB6LLDTPYH5DANCNFSM4IJGJTRQ>
.
|
|
Same blob problem here in single mode... |
|
There doesn't seem to be any ongoing development of the MMU2 as far as I can tell, no new version of the firmware for over a year. Come on Prusa, can we get some bug fixes on this! |
|
FYI it was announced in one of the live-streams that they are reworking the MMU FW - which is probably why the existing MMU FW hasn't seen much movement. https://youtu.be/HgwusaEWNuk?t=4362 (around 1h:12m) |
Let's hope so, because it's hopeless at the moment. It seems like they got it so that it almost worked and then walked away. It's very frustrating when people don't test products thoroughly. If anyone at Prusa had used this in Single mode for just a few days, they would have found all of these problems. |
|
I am not sure if this was ever improved through the FW or PrusaSlicer, but the easy workaround is to slice single filament prints using the MK3S printer profile, instead of the MK3S+MMU2 printer profile. The printer complains about the gcode being sliced for the wrong printer when starting a print, but prints properly like a non-MMU MK3. This also allows the filament to be manually loaded once, and it won't retract at the end of every print. The downside is that you don't get the spool join feature. |
|
Same issue, I would be appreciated if PRUSA could do something to resolve this blob caused by the Tc command. EDIT: Could you please also take in count the new E3D Revo Six hotend internal geometry ?!? |
|
Thank you all for your input. As already emerged in this conversation, the main difference between the printer profiles "MK3x (standalone printer)" and "MK3x MMU2 Single (single filament)" is that the latter profile causes the printer to push filament into the nozzle further because the filament is not supposed to be in the nozzle: the filament should be withdrawn by the Multi Material module at the end of a print, and "re-loaded to nozzle" at the beginning of the next print. If there is filament in the hotend before the start of an "MMU2 single" print, the printer will push extra filament (it should be for a length of 57mm) creating a blob at the beginning of the starter purge line. For those of you who intentionally want to avoid unloading filament at the end of the "MM single print", disconnecting the MMU2 could be a viable way to walk around the unload-reload behavior. The developers already considered changing this behavior, but, unfortunately, we don't have official news about such an update yet. I can't tell if this behavior will change in the next MM-control board firmware release. For now, I'd recommend leaving the issue open as a request for loading filament process enhancement. Michele Moramarco |
|
Please note - it's not so much that we want to avoid unloading filament at the end of the MM Single Print, it's more that getting the MMU mod to load filament is such a crapshoot that we tend to leverage "load to nozzle" to get the filament to load. It only takes about 5-10 attempts, but it's better to do so before the print starts so you can make good use of the reset button when it fails to load and you have to disassemble something. |
|
@scooper4711 I'm no sure if we are talking about an enhancement of the existing feature anymore. Suggestions to improve or ease the loading before a "MM single filament print" are very appreciated. The issue will remain open to that. If we are looking at a different problem, or an anomaly that is not yet a confirmed firmware problem, please feel free to open a new separate issue, or possibly reach our Customer Support for troubleshooting. Michele Moramarco |
|
I suspect the issues with |
|
Please test FW Einsy 3.13.0 + MMU 3.0.0 . Blobs on the purge tower shouldn't be expected. Regarding issues related to the long loading distance in MM-single mode instead, the problems wouldn't persist as long as the filament is unloaded after the print, which is the only scenario the printer will correctly work with. The new firmware release and the act of closing a relevant PR renders this issue obsolete. Michele Moramarco |
|
I'm afraid you're years too late, I'm done with it. I reported the
horrendous and frustrating issues with errors that can't be cleared,
wasting hours trying to get the single filament use to work, and there was
zero response and support.
I've gone back to loading manually because all I wanted was to use the MMU
for soluble supports. I can live without that functionality to avoid the
pain of dealing with an MMU.
If you don't support your customers, they will turn their back on you.
Roger
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
…On Tue, 8 Aug 2023 at 22:34, Prusa-Support ***@***.***> wrote:
Please test FW Einsy 3.13.0 + MMU 3.0.0 .
The MMU firmware has been totally rewritten for improved user experience
and more reliability.
Blobs on the purge tower shouldn't be expected.
Regarding issues related to the long loading distance in MM-single mode
instead, the problems wouldn't persist as long as the filament is unloaded
after the print, which is the only scenario the printer will correctly work
with.
We acknowledge some users strongly want to skip the un/loading operations
in MM-single mode, but based on tests, we can't let that happen - and sadly
we even had to close the PR #4212
<#4212> about that.
The new firmware release and the act of closing a relevant PR renders this
issue obsolete.
Michele Moramarco
Prusa Research
—
Reply to this email directly, view it on GitHub
<#2069 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMVOBHDLH7H5NENOF6CEWETXUKWGPANCNFSM4IJGJTRQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I also removed my MMUs, they weren't reliable and broke the basic mk3 user
experience. I don't trust new Prusa gear anymore. I used to evangelize for
Prusa, but won't make the same mistake with a mk4 or XL. I'm not interested
in investing days of my time or hundreds of dollars into upgrading to
become an unsupported Prusa test engineer again, so I probably won't try an
MMU 3. I have a friend with a Bambu, maybe I'll ask him to do occasional
multicolor prints for me instead?
I understand closing this issue, since the solution by Prusa was to never
fix the issues on the MMU 2. The issue apparently doesn't exist on the MMU
3.
Francis
…On Wed, Aug 9, 2023, 2:05 AM rogerfroud ***@***.***> wrote:
I'm afraid you're years too late, I'm done with it. I reported the
horrendous and frustrating issues with errors that can't be cleared,
wasting hours trying to get the single filament use to work, and there was
zero response and support.
I've gone back to loading manually because all I wanted was to use the MMU
for soluble supports. I can live without that functionality to avoid the
pain of dealing with an MMU.
If you don't support your customers, they will turn their back on you.
Roger
<
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.www.avg.com
<
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Tue, 8 Aug 2023 at 22:34, Prusa-Support ***@***.***> wrote:
> Please test FW Einsy 3.13.0 + MMU 3.0.0 .
> The MMU firmware has been totally rewritten for improved user experience
> and more reliability.
>
> Blobs on the purge tower shouldn't be expected.
>
> Regarding issues related to the long loading distance in MM-single mode
> instead, the problems wouldn't persist as long as the filament is
unloaded
> after the print, which is the only scenario the printer will correctly
work
> with.
> We acknowledge some users strongly want to skip the un/loading
operations
> in MM-single mode, but based on tests, we can't let that happen - and
sadly
> we even had to close the PR #4212
> <#4212> about that.
>
> The new firmware release and the act of closing a relevant PR renders
this
> issue obsolete.
>
> Michele Moramarco
> Prusa Research
>
> —
> Reply to this email directly, view it on GitHub
> <
#2069 (comment)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AMVOBHDLH7H5NENOF6CEWETXUKWGPANCNFSM4IJGJTRQ>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#2069 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIRGDDFGWN2BOWAQA3OSZU3XUMSBNANCNFSM4IJGJTRQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
We appreciate your sincere opinion. I encourage you to reach out the Customer Support. Speaking about this issue, as far as I can see, it can be closed and fixed now. Michele Moramarco |
and others
When I print with a single colour using the MMU2, it always pauses at the front LH corner and outputs a large blob while stationary. It does this whether it loads having selected the job from the SD card, or if I 'Load to Extruder' beforehand.
This causes problems if there's a slightly solidified piece of filament stuck on the nose of the nozzle because it can't escape since there's no sideways motion.
The text was updated successfully, but these errors were encountered: