Large purge blob created by MMU2 when using single filament

[rogerfroud]

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.

[michalxfanta]

Which version of firmware do you use?

[rogerfroud]

It's 3.7.2-2363

[tutulino]

Same here, even sometimes extruder start clicking.

[rambopierce]

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 notifications@github.com 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.

[vintagepc]

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.

[Daghis]

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 mmu_load_to_nozzle(), it looks like it's extruding a whole bunch at one spot. Could this be responsible for the behavior we're seeing?

[mmcglumphy]

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

[ACETyr]

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. After cutting the tip and recovering by pushing the button filament gets loaded, some gets extruded and you get the "Did color change correctly?" question on the lcd. If you answer Yes the printhead returns to the previous position over your print and extrudes a huge blob - ruining the print for good.

Happened 4 times today alone..

Firmware 3.8.1, MMU2 firmware 1.0.6. I've seen this behaviour in prior firmware versions also.

[rogerfroud]

Any progress on this from Prusa?

[vintagepc]

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. After cutting the tip and recovering by pushing the button filament gets loaded, some gets extruded and you get the "Did color change correctly?" question on the lcd. If you answer Yes the printhead returns to the previous position over your print and extrudes a huge blob - ruining the print for good.

Happened 4 times today alone..

Firmware 3.8.1, MMU2 firmware 1.0.6. I've seen this behaviour in prior firmware versions also.

Your issue sounds like false filament runouts. Calibrate/check your IR sensor.

[ACETyr]

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.

[leptun]

I think you need to check the FINDA, not the ir sensor. That is the one that regusters a runout.

[ACETyr]

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. I checked the FINDA and calibration seemed spot on. Also tripple checked the cables and did not find a fault. Started some small testprints and switched to Sensor Status on the LCD but problem did not appear. Then I made a print (rather big one) and on the 2nd layer on a very long diagonal move the issue happened again. I was able to glimpse FINDA status switching from 1 to 0 for a brief moment before the printer went into his unloading routine. Out of curiosity I loaded the filament to nozzle and then lowered the finda until it nearly touched the ball so that I definately trigger (falsely) the FINDA to get a constant filament reading (even if no filament was present in truth). I reprinted the gcode and that time on a long diagonal fill move on layer 5 it happened again. Either I have a faulty FINDA that refuses to show the error in my tests or for some reason the printer thinks FINDA status changes although it does not in reality. The fact that the issue did not manifest in my small testprints but only when printing large objects might be pure coincidence - it baffles me and I have no explanation for that. Other than ordering a new FINDA on my expense is there any test I can do to troubleshoot further?

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...

[JohnOCFII]

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.

[rogerfroud]

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.

[ACETyr]

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!

[rogerfroud]

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.

[psfbc]

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 G1 X5.0 E29.0 F1800.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, Paulo Carmo

[rogerfroud]

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.

[brad-stone]

+1 I see the exact same problem when doing single filament prints - a really large blob in the left hand corner before the line prints across the front of the print bed. As far as I can tell, it happens every single time; however, sometimes I hear the print head gears grinding as it tries to force out the filament quite rapidly.

i3 MK3s Firmware: 3.8.1-2869 MMU2s Firmware: 1.0.6-372 Octoprint: 1.3.12 PrusaSlicer: 2.1.0+win64

[rogerfroud]

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?

[vintagepc]

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.

[rogerfroud]

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.

[vintagepc]

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...

[TheMrPhantom]

Having the same problem in mmu single mode

[rogerfroud]

If you update to all the latest firmware and Slicer, the problem in MMU2 seems to be much less ie the blob size is smaller than it used to be.

What frustrates me, is that if the software developer had once printed using MMU2 Single mode, he would have immediately seen that this was an issue. It just goes to show that they don't bother checking the software in the obvious ways that people will use it. Most people who have MMU2 won't be printing in multiple colours or with soluble supports, they'll be using MMU2 Single, so Prusa should at least do one trial print in that mode!

[scooper4711]

+1 for this issue. Firmware 3.9.0-3421. Prusa slicer 2.2.0

[mmcglumphy]

I've made this issue a little better for myself by adjusting the Start G-Code in Slic3r. I've changed it so that it purges the blob 1.5mm above the sheet instead of .4mm. Also, I made it so it doesn't retrace as far back as the blob on the return bead.

It could probably be tweaked further, but it's way better for now. Also, I'm not sure why the blob comes out, unless it has something to do with the Tc line where it selects the extruder.

Here are relevant lines that I changed at the bottom of the full Start G-Code...

;go outside print area G1 Y-3.0 F1000.0 ; start higher up at Z1.5 and not at Z0.4 G1 Z1.5 F1000.0 ; select extruder Tc ; purge line G1 X55.0 F2000.0 G1 Z0.3 F1000.0 G92 E0.0 G1 X240.0 E25.0 F2200.0 G1 Y-2.0 F1000.0 ; off set this section to the right by 10mm G1 X65.0 E25 F1400.0 G1 Z0.20 F1000.0 ; offset to the right 10mm to avoid blob G1 X15.0 E4.0 F1000.0

M221 S{if layer_height<0.075}100{else}95{endif} G92 E0.0

[FlashTech]

Thank you @mmcglumphy because I will be trying that. My issue is perfectly described by this issue's Title and I tried comparing the "MMU2S" vs "MMU2S single" Start G-code and all I can figure is that the command Tc extrudes too much compared to T[initial_tool]. I have had this problem throughout my many firmware and slicer upgrades. I literally bend over with a thin spatula and scrap the excess filament that sticks around the nozzle during the initial-purge-line to avoid small globs falling into the print later. I love that regular MMU2S mode does not have this problem at all.

i3 MK3s Firmware: 3.9.0-3421 MMU2s Firmware: 1.0.6-372 PrusaSlicer: 2.2.0+win64 Printing from SD Card

[Photogad]

I've made this issue a little better for myself by adjusting the Start G-Code in Slic3r. I've changed it so that it purges the blob 1.5mm above the sheet instead of .4mm. Also, I made it so it doesn't retrace as far back as the blob on the return bead.

It could probably be tweaked further, but it's way better for now. Also, I'm not sure why the blob comes out, unless it has something to do with the Tc line where it selects the extruder.

Here are relevant lines that I changed at the bottom of the full Start G-Code...

;go outside print area G1 Y-3.0 F1000.0 ; start higher up at Z1.5 and not at Z0.4 G1 Z1.5 F1000.0 ; select extruder Tc ; purge line G1 X55.0 F2000.0 G1 Z0.3 F1000.0 G92 E0.0 G1 X240.0 E25.0 F2200.0 G1 Y-2.0 F1000.0 ; off set this section to the right by 10mm G1 X65.0 E25 F1400.0 G1 Z0.20 F1000.0 ; offset to the right 10mm to avoid blob G1 X15.0 E4.0 F1000.0

M221 S{if layer_height<0.075}100{else}95{endif} G92 E0.0

thank you

[Jeltesteur]

+1 for this occuring to a recent mmu2s upgrade to prusa mk3s with firmware 3.9.1-3518 +1 thank you to mmcglumphy for the work around Jelte

[FEsmondeWhite]

This is the same experience I just had with a newly installed MMU2, latest firmware on mk3s, with latest PrusaSlicer RC and default filament profile.

This giant blob in single-material print mode is not the normal exquisite Prusa experience!

I paused my print to clean the nozzle immediately during the purge line. I don't understand how this could make it through testing...

[rogerfroud]

Frankly I don't think this has been tested else it would have been picked up. My guess is that all of the testing done with the MMU2 is done with more than one filament and a wipe tower. I suspect the issue doesn't happen when you do that, but I may be wrong. However, I use my MMU2 with a single filament without a wipe tower all off the time, and it's about time someone at Prusa stepped up and sorted this out! Does anyone at Prusa read these threads?

[vintagepc]

I'm thinking this isn't really a firmware issue (the prime line is generated by the slicer), I think it would be better filed over on the Prusaslicer issue list where it could be more easily addressed.

[FEsmondeWhite]

I posted to twitter as well... I'll cross post to the PrusaSlicer issue list. I'm surprised no one at Prusa seems to have replied to this.

As far as I can tell, I don't have any mechanical/electrical issues in my new setup. This shouldn't be the out of box experience!

[vintagepc]

In all fairness I have some insight into what the goings on are... it just boils down to this sort of thing just being much lower on the priority list. It's annoying when it happens, but the printer still works fine - as opposed to things like LA1.5 not working right, or the superPinda/other hardware supplier support.

Not to mention they're basically on a skeleton crew in house in the midst of a pandemic.

[rtyr]

This is firmware issue. It happens right after Tc command (before purge line gcode generated by PrusaSlicer).

[FEsmondeWhite]

@wavexx @DRracer

A giant blob is caused when starting prints in single filament sliced prints using mk3s + MMU2.

Have you seen this issue?

[FEsmondeWhite]

The Prusa devs are amazing. The recent work on firmware and PrusaSlicer has been exceptional. Between new features and fixes, the Prusa team continues to deliver!

Please also consider that this bug occurs on every single mode print, can break printers, and should have a fairly simple fix. It's also really easy to test since it occurs right after heating & probing.

In all fairness I have some insight into what the goings on are... it just boils down to this sort of thing just being much lower on the priority list. It's annoying when it happens, but the printer still works fine - as opposed to things like LA1.5 not working right, or the superPinda/other hardware supplier support.

Not to mention they're basically on a skeleton crew in house in the midst of a pandemic.

[Area5142]

I print primarily in PETG and this firmware error results in strings being pulled and debris getting stuck on the nozzle, even on the coated non-stick ones. I try to clean the nozzle before each print, but this error prevents a neat print even before it starts. Maybe raising the nozzle before the tc g-code will help, as suggested by @mmcglumphy.

[wavexx]

@FEsmondeWhite I don't have an MMU unit :), but I do remember we fixed a problem earlier on this year that would cause the first extrusion to jerk in the first move immediately after a G92. The move would be worse when it was combined with the Z move (lowering to the build plate).

I wonder if this could be a similar situation?

Could somebody post a complete serial log when this happens?

[vintagepc]

The nozzle doesn't lower to the build plate in this case, it's already parked at the correct Z height at the beginning of the prime line after the home.

[wavexx]

@rtyr do you have a minimal repro for this already? (just up to the first G1 of the purge)

[FEsmondeWhite]

@rtyr do you have a minimal repro for this already? (just up to the first G1 of the purge)

I can run testing for you.

Could somebody post a complete serial log when this happens?

What would you like me to log? Just plug the einsy into usb and log the serial output from the printer during the start of printing?

I can send you the associated gcode as well.

[wavexx]

@FEsmondeWhite having the gcode (and serial log too would help) cut up to the point where it happens would be a good start. If you feel especially willing, removing all the gcode parts that are not relevant to the issue would help even more (so that even if I don't have experience with the mmu I can still have a look)

[rtyr]

@wavexx just look at Slack, it is described there.

[rtyr]

It is about Tc command. Its purpose is to load the filament further to the nozzle before the print. It apparently loads too much filament for "S" extruder (shorter path than non-S) and creates a blob. It usually doesn't cause any issues, but it is not optimal. The blob on the first photo looks too big though (probably incorrect IR sensor calibration).

[rogerfroud]

I don't see how it can be incorrect IR sensor calibration when you get great prints. It's just sitting there stationary at the start of every print, extruding for no good reason for several seconds. This ought to be so easy to fix. Why would it ever extrude when it's stationary and at the level of the first layer?

[rtyr]

@rogerfroud If it is extruding for several seconds, than you have some different issue (most likely IR sensor related).

[FEsmondeWhite]

Hi @rtyr @wavexx

Here are some test results... I have (bad) videos, but think video is probably not very helpful. Serial output from Putty is in notes.txt.

Tested two start configurations:

1. Filament loaded to MMU only.
2. Filament loaded to MMU and at nozzle.

Note that the printer crashes & reboots when starting a single-mode print with filament already loaded to the nozzle.

Tc-test-gcode.txt notes.txt