Prusa-firmware: [3.7.0] MMU2s Loads to nozzle but then retracts before it continues print

[TimothyGold]

I just upgraded from 3.6.0 to 3.7.0 and after implementation of the faster MMU2S load speeds I noticed that when the filament gets loaded to the nozzle it goes into the extruder but then backs out again before it loads and then purges the color. This never happened on 3.6.0. It takes enough time that I wonder if the load is actually faster. It happens on both Normal and Stealth MMU2 modes. Is this intentional or something missed. I checked to see if the IR sensor was being mis tripped and it looks like once the filament reaches the bontech the IR goes to 1 and does not seem to flap. I think it is solid once it sees the filament.

[Jerware]

I'm experiencing the same thing on MK2.5s / MMU2s. The MMU sends filament to the bondtech gears, then the bed preheats, then the printer performs mesh bed leveling, then filament gets pushed to the nozel by the extruder, and then inexplicably the MMU tries to retract the filament. Since it's trapped by the extruder gears, it can't, so the MMU errors out flashing its LED and the print doesn't continue (i.e. start).

[ThaliaFP]

Does also happen without the S upgrade for MK3 and MMU2.

[Gountled]

I have the strange behavior, that it does all the heating, mesh bed leveling and after that it tries to load the filament. All is fine and filament is loaded into the nozzle, but afterwards it is unloaded completely again. After a couple of time doing this, the printer tries to print from back to front instead the "normal" direction, but without an filament and the heater is also switched of.

If I load to the nozzle befor starting the print, everything goes as it should.
Did I miss some special procedure after I flashe 3.7 firmware?

[TimothyGold]

@Gountled I noticed this kind of behavior when I turned the filament sensor on. I turned it off and it seemed to stabilize this behavior. I think there is some issue between the loading from MMU2s and the IR sensor sensing the filament and then tripping the filament out if there is a bounce in the IR trigger. I haven't had time to troubleshoot this but for now I have just left it off. the MMU2s load still uses the IR sensor to sense the filament to the bondtech gears even with the filament sensor is off. I think turning the filament sensor on only enables spool join and filament runout. Which would be great when printing multimaterial if they both worked together.

[Gountled]

Thanks a lot for this hint / workaround.
It worked now when I switched off the filament sensor.
I would still consider this as a bug as the 3.60 version worked fine when the sensor was on.

I guess for Filament run out the F.I.N.D.A. Sensor is used, so I think the combine spool function should work as well.

[TimothyGold]

Might need to open another issue on the IR Sensor being used while using MMU2s. I haven't had enough time to troubleshoot but I also think this is buggy and needs some attention. Ideally we should be able to leave the sensor on so that while printing MMU and a filament runs out we should be able to get a notice to reload this color that ran out. I think using the sensor to load to bondtec and also use it to sense a filament out between the FINDA is challenging. On another note i also had initial issues calibrating the IR sensor and getting a consistent reading. I think those that printed their own upgraded parts might have some variability in this sensor reliability. It is extremely important that the IR sensor consistently reads the filament correctly and does not have a lot of bounce in this reading. Hopefully firmware development can correct for some of this variance but it wont be able to account for all of this.

[Gountled]

The IR sensor worked on 3.60 without any problems. I don´t know what they changed.
My IR sensor is reliable, that can`t be the problem.
Maybe we should open a new issue.

[cjbaar]

I am having the same issue, and I have the filament sensor disabled. I am not sure what the purpose of this change was, but it causes significant load failures from the MMU. About 50% of the time, when it runs the extruder in reverse, the filament comes out and then gets unloaded as a failure. I have had to revert back to 3.6.0 until this behaviour is resolved.

[cjbaar]

@TimothyGold In reference to your IR sensor comment, I had the same issue. I pre-printed parts before my order arrived, and could not get the sensor to trigger value=1. It didn't like my PETG for some reason (too shiny?). I re-printed the tower and the idler door with the Prusa-provided filament and it worked perfectly.

[PavelSindler]

Behaviour described by @TimothyGold at the beginning is intentional. T-code load sequence was modified to minimize missing layers occurence. Printer do 50mm load from bondtech gears to the tubing above nozzle and then 45mm back and checks IR sensor. If filament tip is too wide or had bad shape and printer cant push it whole 50mm forward it is unloaded from bondtech gears and it is detected by IR sensor. It this happens T-code is then repeated (another attempt) and if it fails also, MMU load fail occurs. So this leads to MMU load fail which can be fixed by user, instead of missing layer which would ruin whole print.

[TimothyGold]

@PavelSindler Thanks for the clarification. So far this I think has helped in my MMU2 prints. I do believe there is a bug involved in having the Filament Sensor enabled while doing a MMU2 print. I have not spent a lot of time using the runout sensor option on a single print or spool join but just like others have mentioned I noticed that I had inconsistent issues that were fixed by turning this off in the tuning menu.

[cjbaar]

@PavelSindler Thanks for the update. This seems like a rather tight tolerance. Are you saying then my tips are so bad that 50% are failing to properly load? I didn't have this kind of failure rate before 3.7.0.

[Jerware]

@PavelSindler My experience, as described above, sees the filament trapped by the extruder bondtech gears while the MMU tries to retract it. This is on initial loading of freshly snipped filament (MK2.5s/MMU2s). If this is intentional, why aren't the bondtech gears reversing to let the filament out, especially if the IR sensor is triggered (which I verified) so it knows the filament is still there? I've had to revert to 3.6.0.

[erfreuterstudent]

@PavelSindler thanks a lot ... these are the exact problems i m facing. My trouble is now that i can t switch back to 3.6.0 because for some reason my modified firmware won t run. 3.7.0 works great eventhough i just set min extruder temperature to 140 C in both of them. But 3.7.0 has the mentioned above troubles with loading. Does anybody know where i can change this loadingprocedure in the sourcecode?

[mkbel]

Does anybody know where i can change this loadingprocedure in the sourcecode?

//! @brief load more
//!
//! Try to feed more filament from MMU if it is not detected by filament sensor.
//! Move filament back and forth to nozzle in order to detect jam.
//! If PTFE tube is jammed, this cause filament to be unloaded and no longer
//! detected by pulley IR sensor in next step.
static void load_more()

current_position[E_AXIS] += 60;
plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], MMU_LOAD_FEEDRATE, active_extruder);
current_position[E_AXIS] -= 58;
plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], MMU_LOAD_FEEDRATE, active_extruder);
st_synchronize();

in mmu.cpp

[mkbel]

Are you saying then my tips are so bad that 50% are failing to properly load? I didn't have this kind of failure rate before 3.7.0.

This is strange, as we have about 20 MK3S with MMUv2 testing printers and we are not experiencing this kind of problem. Don't you have some custom extruder, where distance between bondtech gears and nozzle is shorter then in MK3S? Do you hear clicking noise when filament crashes heat brake or nozzle before it is retracting?

[cjbaar]

@mkbel Thanks for the input. I have had prints fail occasionally with grinding, but it certainly isn't near as often as this new method wants to consider it a failure. I have not customized anything on the extruder, although I did break the heatbreak a while back, and order one from Amazon assuming it was just a stock E3D. In some other forums, I learned that you might be using something different, so I have ordered the official "Prusa" heatbreak and will test further with that.

One question on the tips, relative to slicer settings... I have a hard deciphering some of the descriptions like "loading speed" "loading speed at start" etc. But in particular, the printer has settings for center and length of the "cooling zone." Where should the cooling zone be? Is that inside the heatbreak, or inside the PTFE?

[erfreuterstudent]

@mkbel Thanks a lot .... 2 mm seems like hell of a margine to me for a good filament tip. I switched it to 50 45 like @pavelsindler wrote and now it works perfectly.

[vertigo235]

@mkbel are these values in e steps or mm? If one were using a geared extruder would it be prudent to multiply the number by the gearing?

[mkbel]

Those values are in millimeters.

[zjohnson16]

@cjbaar Did the Prusa heatbreak solve the issue? Around 75% of my tips are failing and I am not sure if it is due to the heatbreak as I replaced it a while back.

[cjbaar]

It did help get the tips down. I still haven't figured out the best settings. With the e3d stock heartbreak, my tips were over 2mm wide. With the Prusa, I am around 1.95mm, which still causes issues in the PTFE tubing.

[zjohnson16]

@cjbaar My Prusa heatbreak hasn't arrived yet, but I started using this script to lower temp to 195 before ramming and I haven't had a single bad tip on Matterhackers PLA. Granted I've been running it for less than a day but so far it has been working like a dream. Prusa absolutely needs to implement a ramming temp setting in Slicer because this has fixed all my problems.

[rambopierce]

I have a theory with regard to heatbreaks and the issue definitely happened to me. When I first assembled my MK3, the heater block and heatbreak came preassembled and I didn’t check the assembly very well.

Following the E3D hotend assembly instructions they tell you to heat the heater block way up (I don’t recall the exact temp right now) when doing the final tightening on the nozzle. I suggest heating the block up when screwing the heatbreak in to the heater block as well. This helps to ensure a false bottom has not occurred, i.e. the heatbreak is screwed all the way into the heater block. If it is not, it is possible to screw a nozzle all the way in and even tighten it and still have a small gap between the top of the nozzle and the bottom of the heatbreak. That gap (even very small) will cause all kinds of unloading problems and clogs leading to extruder clicking. In a correct installation the bottom of the heatbreak and the top of the nozzle must touch and seal together. So the possibility exists that folks change out the heatbreak brand or type and they do a better job of the installation than the original installer which fixes a lot of issues and they then falsely conclude the new heatbreak is better.

Ramming settings require a lot of experimentation. Agree, a temperature setting specifically for ramming could be useful.

On Jun 17, 2019, at 5:28 PM, zjohnson16 [e-mail] wrote:

@cjbaar My Prusa heatbreak hasn't arrived yet, but I started using this script to lower temp to 195 during ramming and I haven't had a single bad tip on Matterhackers PLA. Granted I've been running it for less than a day but so far it has been working like a dream. Prusa absolutely needs to implement a ramming temp setting in Slicer because this has fixed all my problems.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[supermage87]

I dont know if it can help someone but I had the same issue. And I think my problem was my spot light directed at my printer. I WATCHEd my mmu2 loand and unload for 2.5 hour until it suddenly work as soon as I took the light away..... damn I was pissed
...

[cookiestomps]

I dont know if it can help someone but I had the same issue. And I think my problem was my spot light directed at my printer. I WATCHEd my mmu2 loand and unload for 2.5 hour until it suddenly work as soon as I took the light away..... damn I was pissed
...

OH MY GOD. I spent the entire day figuring out why my mmu2 was having issues loading. Just now, I stumbled across your comment and I thought: "There's absolutely no way this'll work but eh, why not at least try". Well, I'll be damned, IT WORKED! I turned off the led strip in my enclosure and the issue went away !
I can't even...

[ikanimew]

I dont know if it can help someone but I had the same issue. And I think my problem was my spot light directed at my printer. I WATCHEd my mmu2 loand and unload for 2.5 hour until it suddenly work as soon as I took the light away..... damn I was pissed
...

YUP this worked for me as well! Thank you!

[andsee]

I'm not 100% certain if this is the same issue I'm experiencing, however I've just updated to 3.9.0 on a Mk3S MMU2S. Using the load to extruder menu the mmu loads and then unloads until such a point where it fails. I have a video showing this from the start. The filament has a freshly cut end and moves well in the PTFE tubing, it successfully extrudes some filament a couple of times and then tries to unloads the filament again and fails because the hotend has gripped it. I remove the ptfe from the mmu and you can see the MMU is still trying to pull in the filament.

I've checked the IR sensor and FINDA which appear to be working well. Adjusting the tension at the MMU and the hot end gears has not helped so far after a morning of trying.

https://youtu.be/xMY2kyC9Wf8

[cjbaar]

@andsee I watched your video. It is a bit hard to tell why the printer switches to unload, but I think it can potentially be triggered by either sensor (IR or FINDA). In my experience, they are both a bit finicky, and the IR in particular is difficult to get well-tuned, and there is not a lot of room for error. I think the most likely is that once loaded, some minor variation in the filament or the gears is enough to tell the IR that it has run out. I might try moving the IR sensor ever-so-slightly to the right, and make sure that the tension screw on the filament door is not too tight. Also make sure the bond tech gears are well cleaned; even a small particle can cause the door to move enough to trigger that sensor inadvertently.

[andsee]

@cjbaar Thank you for your time and quick response! I added an LED to the IR sensor and indeed it was not 100% accurate during the load. I used the support menu and sensor info to test the sensor which appeared ok. However I was then testing loading via the load filament to nozzle menu where you can't access the sensor info :-( so had not been able to spot that the reading was unstable.

I've now moved the sensor to the right and it's loaded correctly a couple of times so fingers crossed!

Thank you again for taking the time to view the video and reply.

[cjbaar]

I've seen that hack for the LED on the sensor. It seems pretty useful for troubleshooting these kinds of situations. I may have to give it a try.

[mkbel]

@andsee You can observe what is going on (including filament sensor output in critical phase) on USB CDC. Just connect printer to computer with USB cable, open virtual serial (COM) port associated with printer using any serial communication software like Hyperterminal, Putty, Serial port terminal, ... using baud rate 115200, parity none, bits 8, stop bits 1, flow control none. Don't open port during print as printer is restarted by this action. When the filament is moved outside of nozzle to check, if it was successfully loaded, there is "o" for filament not detected and "O" for filament detected.
Output should look like:
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
if filament was successfully loaded and sensor is working right
OOOOOOOOOOOOOOOOOOOOoooooooooo
if filament was not successfully loaded and sensor is working right

If filament sensor is not working well, there will be some random mix of "o" and "O" like
OOOOoOOOOoOOOoOOOOOoOOOOoOOOoO
OoooooooOoOOOoooooooOooooooooooO

Those "Oo"s can be interleaved with other debug messages and this is ok.