Core One MMU3  

RE: Core One MMU3

Hi Peter,

I had problems with Buddy PLA. I have now only Prusa or Pursament PLA and my problems are solved. 

So the profiles will perhaps not be correct for Sunlu PLA+.

RE: Core One MMU3

Yes, with my mk4s with mmu3, no problems like that, not even with cheap filaments.

RE: Core One MMU3

Interesting - I'm seeing the same on the MMU3 that I moved over from a MK4.  Filament sometimes not unloading properly because it gets stuck in the extruder, and if it does make it out it's likely to fail to reload due to the ugly tip.  On the MK4 it was wholly reliable.

I've just switched the CORE One to a non-high-flow nozzle and it seems to be better - no errors in the last dozen or so swaps.  That's not conclusive though, because those have been with the 0.2 Structural profile, whereas previously I'd been using the Speed profile.

And my MK4 also had a high flow nozzle and the MK4S cooling setup for the last few weeks, and I don't recall any problems with the MMU3 in that configuration.  But then again, I wasn't using the Speed profile on that machine.  Too many variables and too little time with it to reach any conclusions yet.

RE: Core One MMU3

No further ideas or solutions...

Do I have to contact support about this?

It's almost absurd that I'm almost completely alone with this problem.

Now, after numerous attempts at adjusting the settings, I'm completely at a loss.

I can't even get five color changes. Even though all the charging tests have been successful multiple times.

(Goggle Translator, german-english)

RE: Core One MMU3

Hi Peter

I did have some success tuning the ramming configuration for the ABS filaments that were causing me the same problem.  I described what I did in this thread.

My main conclusion was that 'fat tips' were the cause of my filaments jamming on the way out of the extruder, and that the amount of time spent ramming (rather than the number of cooling moves) is what dictates the size of the fat tips.  By reducing the ramming time from the standard 1.25s to 0.5s I was able to produce filament tips that more closely resemble the standard tips from the non-MMU setup, and since I made this configuration change I've not had a single loading/unloading problem.  I did also tweak the design of the selector and the selector plate, and I'm about ready to post those tweaked models, but they tackle a related problem, rather than the direct problem of jamming in the nextruder.

What material profile did you use for your Sunlu PLA+?  I note that the standard PLA profile also uses a ramming time of 1.25s, so it may be worth you investigating the shape of the filament tips, and experimenting with a shorter ramming time.  My photos in the linked thread may be of use for a comparison.

RE: Core One MMU3

Yes, thank you very much.

I have tried several times since then, but without success.

My tips look like they have been eaten away and are squashed, as if the next rudder is pushing back too quickly and too hard.

RE: Core One MMU3

Back to my problem:

I have two printers, a Core One converted from my MK4s and an MK3.9s.

Both machines have an MMU3 device. Here's an example from my MK3.9 (see photos).

I've changed almost 700 materials and not a single error.

Now for the Core One with the MMU3, I've changed not even 10 colors without a problem.

Sunlu PLA material, eSun Polymaker MK3.9, no problems.

RE: Core One MMU3

Hi Peter

I'm no expert, but based on what you've shown us and the way you've described it, I think it's possible that your filament isn't cooling enough before it's being withdrawn from the Nextruder.  This could account for the long stringy tips that are visible in the first photo you posted, and also the fact that the tips are being squashed by the Nextruder gear - perhaps the plastic hasn't hardened enough at that stage (do you have any photos of such a case?).

If that really is the case, then you could try increasing the number of cooling moves from 2 to 3 in your PLA profile.

RE: Core One MMU3

This theory could also be consistent with a major difference between your MK3.9 and the CORE One - your MK3.9 is not enclosed, which is a good thing with PLA.  Perhaps the enclosed CORE One is not allowing the PLA to cool quite as much between filament swaps.  I mostly print ABS on my CORE One, where the higher temperature is a big bonus, but I have noticed that when I print cooler materials the vent and the fans aren't really enough to keep the chamber temperature where it needs to be, especially in recent weeks when the ambient temperature has been high.  Leaving the door open is a big help, and I also take off the lid (I permanently removed the rivets to make this easy).

RE: Core One MMU3

Posted by: @chris-hill

This theory could also be consistent with a major difference between your MK3.9 and the CORE One - your MK3.9 is not enclosed, which is a good thing with PLA.  Perhaps the enclosed CORE One is not allowing the PLA to cool quite as much between filament swaps.  I mostly print ABS on my CORE One, where the higher temperature is a big bonus, but I have noticed that when I print cooler materials the vent and the fans aren't really enough to keep the chamber temperature where it needs to be, especially in recent weeks when the ambient temperature has been high.  Leaving the door open is a big help, and I also take off the lid (I permanently removed the rivets to make this easy).

I have a CORE One, MMU3, and the Advanced Filtration system (which reduces the chamber airflow even more) and I have been having terrible problems with stringing and wipe tower blobbing/crashes. To test your theory, I recorded the nozzle temperature and targets and saw that the nozzle wasn't cooling off to the expected amount each cycle. I changed the number of cooling moves from 2 to 5, and had a successful overnight print for the first time in a while!

The current wipe tower gcode produced by the slicer doesn't wait for temperature but instead relies on assumptions about how cool the nozzle will be after a time. It's likely that 2 cooling moves is ok without a chamber, but high ambient temperatures will break that assumption. I hope to try out some gcode variations that work a temperature wait into the cycle.

Thanks again for your insight!