Filament gets stuck during unloading

[ufoDziner]

Hello,
I have found that filament can easily get stuck in the hot end PTFE tubing during the unload process. Occasionally a small blob breaks off in the hot end PTFE tubing requiring disassembly of the extruder. I've tested with a short loading function prior to the unload, and this eliminates this issue entirely. It would be great to have this short ramming function built in to the unload function to ensure an easy removal. Thanks

[nataliefl]

@ufoDziner Could you share this function?

[wavexx]

I remember I've seen this report along with #417, I would suggest the same behavior.

I generally never have unloading issues when printing. It just works.
However, I do have trouble when powering on the printer, preheat and then unload the filament.

In this case I incurred in both problems:

• filament getting stuck between hotend and hobbed gears (lower ptfe section)
• filament getting stuck between gears and ptfe (upper ptfe section)

I'm not fully sure why this happens when the machine is cold, but I never had it happen when swapping filaments after printing or doing filament swaps.

As suggested here and in #417, I resolved the issue in both cases by doing a small extrusion before attempting the unload again. The unloaded filament looks absolutely perfect after this procedure and I don't think it would harm.

[matt-3]

I get exactly the same issue on my printer, except a lot more often (about once every other time) and likewise I have noticed that a short extrusion before unloading makes for a perfect unloading, smooth as a hot knife in butter.
I would be really great to have the firmware extrude a couple of mm automatically before each unload.

[wavexx]

How much do you need to extrude before you get a perfect unload?

I'm planning to implement this in the next week and it would be great if we could find the smallest extrusion needed to always get a perfect unload.

[matt-3]

That'd be great, thanks! I have not tried to fully optimise/minimise this but I can tell that 2mm works just fine and it uses very little filament. I'll try with 1mm to see if that works too and I'll let you know.

[wavexx]

On Wed, Apr 17 2019, matt-3 wrote: That'd be great, thanks! I have not tried to fully optimise/minimise this but I can tell that 2mm works just fine and it uses very little filament. I'll try with 1mm to see if that works too and I'll let you know.

I just tried to preheat, go to settings->move->extruder and extruded 1mm (which is the minimum you can do from there). There's still half a mm of somewhat thicker filament in my case, but it unloaded correctly. Is it the same in your case? Next swap I'll try with 2mm. Maybe the right spot is 1.5.

[matt-3]

To be honnest I don't think trying to save 1mm of filament is relevant here, especially in the view that when you will load a new filament the printer will extrude about 200mm of the new one to ensure color change.

[wavexx]

On Fri, Apr 19 2019, matt-3 wrote: To be honnest I don't think trying to save 1mm of filament is relevant here, especially in the view that when you will load a new filament the printer will extrude about 200mm of the new one to ensure color change.

No, but if the nozzle is low and you extrude more, then having to raise the nozzle (like autoload does) might be necessary as well.

[wavexx]

After a few trials, I realized I could just use the mmu ramming sequence to unload.
And of course, it works.

@bubnikv: any reason why the manual filament change sequence couldn't just call mmu_filament_ramming() as opposed to do each own their own thing?

A few notes:

Prusa-Firmware/Firmware/variants/1_75mm_MK3-EINSy10a-E3Dv6full.h

Line 331 in ca449ef

// Load filament commands

these constants (including the UNLOAD_* ones) are not actually used.

The FILAMENTCHANGE_* ones are used both in M600 and during filament runout/jam detection.

Both "unload filament" from the menu and M702 call either unload_filament() or the mmu sequence (extr_unload -> mmu_ramming_filament+some mmu comm) depending if the mmu is detected or not.

But calling mmu_filament_ramming in unload_filament() doesn't sound stupid in regular "unload_filament", M600 and M702.

As I said, for a test I replaced the hard-coded sequence in unload_filament() by just calling mmu_ramming_filament. The filament is perfectly shaped and the unload is flawless.

@matt-3 I could push some code for you to test or also provide a precompiled firmware if you want to try.

[matt-3]

Using the mmu code for this sounds like a good idea indeed. Sure I could help with validation by testing a precompiled firmware (from Wednesday as I'm currently away).

[wavexx]

For which variant I should build? MK3, MK3S?

[matt-3]

mk3 please

[wavexx]

Here's the prebuilt firmware for the MK3:

https://www.thregr.org/~wavexx/tmp/MK3-ramming_unload_test.ino.hex

Just as an info, the above is based on the current MK3 code, which disabled the PWM bed heating due to some issue (just so you know).

Here are the changes, which are quite simple:

https://github.com/prusa3d/Prusa-Firmware/compare/MK3...wavexx:mk3_ramming_unload_test?expand=1

I tested the ramming with both pla and petg, both with very good results.
Any feedback would be appreciated.

A few things I'd like to do are the following:

• raise the extruder when unloading filament if low, since some extrusion is performed
• swap the filament change procedure (which uses another unloading procedure) with the same

[matt-3]

Hi wavexx,
Thanks for the test firmware. Unfortunately it did not work as intended for my printer:

• First attempt: from cold printer with PLA loaded, pre-heat to 215C, unload: it made this loud horrible gear-skipping noise like it is forcing too much filament too quickly into the extruter. A sizeable blob came out of the extruder, but I could not pull the filament out. See attached picture to see how the tip looked like.
• Second attempt: right after that first attempt. This time the gears did not skip (I guess the heat had time to spread more evenly in the extruder so the filament could melt quickly enough) but the tip of the filament was still too big and odd-shaped to be pulled out of the tube. See https://youtu.be/CUccmY_BdcE

Overall I think it needs to extrude much more slowly (2mm in 1 second is fine) instead of ejecting 10cm of filament in a fraction of a second. This will help leave enough time for the heat to propagate into the tip of the filament, making it softer so that it can change its shape to the shape of the tube when being pulled out.

[wavexx]

The video was very helpful. There should be a slower insertion and ejection sequence before the filament is spat out, which I cannot spot during the video (looking at the gear marks).
This is when filament is given some time to cool off.

Maybe I initialized something wrong or incompletely: I'll give that a look.

But before trying to use the ramming code, I did a few iterations of extrude/eject and it didn't work as nicely as I would have expected.

In the end, the minimal extrusion length required to always clear off the blob was no less than 4mm. I was inserting, ejecting, inserting, cooling-off, heating, ejecting.. and still had cases where I had a larger tip jamming above the gear. Still better than a plain eject, but not working as consistently as one would have hoped for.

Doing a couple of moves to shape the filament did improve things, but that's when I though about the ramming code.

[matt-3]

The video in my previous post does start at the very beginning of the sequence, the first beep you hear is when I selected "unload filament", there is no other movement before that.

Here is another one with the official firmware showing how I usually actually unload the filament to avoid it getting stuck (extrude 2mm then unload). It has always worked as far as I can remember and when I pull the filament it feels very smooth. https://youtu.be/JQ9J_3Zb5fs

One other thing to keep in mind, if this can help, is that we just need to be able to pull the filament out, the tip does not have to be perfectly shapped for automated re-insertion like with the MMU, it's ok to have to clip it once pulled out.

[wavexx]

On Thu, Apr 25 2019, matt-3 wrote: Here is another one with the official firmware showing how I usually actually unload the filament to avoid it getting stuck (extrude 2mm then unload). It has always worked as far as I can remember and when I pull the filament it feels very smooth. https://youtu.be/JQ9J_3Zb5fs

I did this as well, but when trying multiple times these days I found that I do frequently get a very stringy tip.

[wavexx]

I have prepared another MK3 firmware for testing:

https://gemex.eurac.edu/dl/?t=1dedbacd4e0ccd47d9b676b028d580cf

It does the following:

• slow 2mm extrusion
• very slow 0.2mm extrusion to relieve leftover pressure (mostly for flexible materials)
• 2mm retract at max speed
• filament ejection

[wavexx]

Here's the worst tip I got with the above:

White pla, left in in the hot extruder for ~5m @ 215.
This is what always had a tendency to generate clogs for me.
Comes out a bit stringy, but the string actually detaches cleanly and there's no blob at all.

Prusa's silver comes out clean, as does most of the PETG I've tried here.
I'm curious about your results.

[matt-3]

Thanks for the firmware. Unfortunately it did not work at all as described.

• Attempt 1, from cold printer https://youtu.be/BpWjw_FyeXw it has extruded way more than 2mm and the tip was not looking good, but at least it worked
• Attempt 2, hot printer just after this first attempt https://youtu.be/xagGvW8MvYI likewise it has extruded a lot of material (about 20cm) and ejection did not work, the tip got stuck in a bad place between the top of the "chamber" and the fixed wheel. Incidentally, as I tried to pull it out it ended up triggering filament load...
  It is surprising that the behaviour is so different than what is expected. Could it be a mix-up of firmwares in the build / upload?
  Thanks.

[wavexx]

On Fri, Apr 26 2019, matt-3 wrote: It is surprising that the behaviour is so different than what is expected. Could it be a mix-up of firmwares in the build / upload?

From the bootup screen, yes :(, sorry for this. I'll rebuild.

[wavexx]

On Fri, Apr 26 2019, matt-3 wrote: It is surprising that the behaviour is so different than what is expected. Could it be a mix-up of firmwares in the build / upload?

Hopefully correct: https://gemex.eurac.edu/dl/?t=7e58a7a73043a4aa5823edebc5cbbdeb

[matt-3]

Ah, perfect ! I've tried with PLA, PET-G and FlexiSmart filament and they all give a results similar to the picture that you've posted above, and could be pulled out easily without blockage. Good job !

[wavexx]

On Fri, Apr 26 2019, matt-3 wrote: Ah, perfect ! I've tried with PLA, PET-G and FlexiSmart filament and they all give a result similar to the picture you've posted above, and could be pulled out easily without blockage. Good job !

Somehow I was expecting the mmu ramming code to do a better job than that so, in a way, I'm still a bit let down :/ But after trying multiple times, I've also found issues with the ramming sequence anyway. Ramming works definitely better with PLA, but the built-in sequence it's not that much better with PET, and the ramp waaaay is too aggressive for polycarbonate (I was trying out a roll of PC-MAX which is not even 100% pc). So, all things considered, if you plan fancy materials, this solution is probably safer.

[wavexx]

On Fri, Apr 26 2019, Yuri D'Elia wrote: On Fri, Apr 26 2019, matt-3 wrote: > Ah, perfect ! I've tried with PLA, PET-G and FlexiSmart filament and > they all give a result similar to the picture you've posted above, and > could be pulled out easily without blockage. Good job !

The firmware I've sent also contains this fix: #1768 it will raise the carriage (when needed) also during unload, as there's now some extrusion. I want to see if the above gets merged (or at least commented on) before submitting another PR, since there are some code dependencies intermixed and I've submitted quite a few already ;)

[matt-3]

A few more thoughts:

• I've tried the M600 gcode command (to change color mid-print) and after ejecting and inserting new filament, after the "right color?" question, strangely more filament gets extruded right before resuming the print, about the same length than what it extruded for the unloading. Could it be a side effect, a function called at the wrong place? tbh, I should have tried with the official firmware to compare but I have not.
• about this slow "0.2mm" that you mentionned above to relieve the pressure, it is really necessary? The other end of the extruder is open, so any pressure would cause extrusion anyway. Imo it would probably be better to not have this to save the time it takes and unload right away while the filament is hot and soft.
• thinking again about the MMU code that you have tried using, I find strange that it extrudes so much filament for an "unloading" procedure. Could it be that a piece of the code from the MMU "loading" procedure is also accidentally called?
  Thanks!

[wavexx]

In M600, some extra priming is performed just before resuming to print. This was already in place and I didn't change it.

I do indeed use exactly the same constant in the code just before the unload.

I used M600 rarely on the MK3, so I'm open to anything here. If you ack the lcd just after the loading has been done, 5mm does indeed seem excessive. Some value <1mm would probably be enough to stabilize the nozzle pressure. But if you pull the excess just as the print head is moving, some extra material is useful to "grab on". I use a piece of paper to pull the excess. I do this all the time when using a bowden printer on stock marlin and it results in a cleaner resume, but that's mostly because the bowden tube tends to accumulate backpressure, so doing it "as late as possible" does help.

The slow part did seem to improve the results for me. Some extra time to soften the filament helps in shaping the blob and avoid sharp protrusions just at the tip.

How familiar are you with running GCODE manually? You can run the ejection sequence manually for testing which is much easier if you want to experiment. I normally use "pronsole" from https://github.com/kliment/Printrun

The current sequence:

M109 R215
M83
G92 E0
G1 E5 F120
G1 E0.1 F60
G1 E-2 F2100
G1 E-100 F1000

I didn't realize I shortened it to 0.1mm at 60mm/m, which is only half a second.
More testing would be nice though.

As for the ramming, it's useful to point out what I discovered while reading the source, since I don't have an MMU2 unit. I assumed initially that the built-in ramming sequence would be used (and be updated) by slic3r using some custom GCODE, but it's not the case. Slic3r "rams" while extruding on the purge tower, which results in a different pressure dynamic on the nozzle. It also uses different ramps with different materials, but the firmware has no knowledge of what is loaded. Running the built-in ramming sequence on a difficult material such as PC is not a good idea.

[matt-3]

I have been using my printer quite a bit for the past weeks with your firmware, and the filament has unloaded correctly every single time. Thanks for the info about the unloading sequence gcodes but since it has worked fined I have not tried playing with them. Tbh I think it's a wrap. I hope your change is accepted in the master branch. Thanks!

[neslekkim]

Is this done for normal mk3 operation, or only with mmu use?, I hope it will be changed for normal firmware also, forgetting to extrude filament when unloading sometimes, and it tend to get reall stuck.

[wavexx]

It is done when using the LCD and when issuing a filament-change command without an MMU (lcd or GCODE). The mmu filament handling is actually untouched.

[neslekkim]

Which firmware?, not happening on 3.7.0. (no mmu)
I had to take apart the extruder, because I forgot it when unloading ASA.. :(

[wavexx]

This feature is not yet available in the official firmware. If you look above, I provided this experimental firmware for the MK3 that does this.

I didn't submit a patch for this yet, as I'd love Prusa to merge some other conflicting changes first.

[Lacehim]

I didn't submit a patch for this yet, as I'd love Prusa to merge some other conflicting changes first.

This is the biggest issue I have with the MK3. The printer is going great, so I don't like to keep pulling it apart to fix the filament getting stuck. It's in my garage so I don't always hear the beeps, and if it cools, it's going to get stuck! :( otherwise I haven't had any issues and even with half the magnets missing off the heat bed it's still going.

I've been checking the internet for a fix for this issue, and found this! Yay. I'll check out your firmware and report back. I use M600 a lot for printing cake decorations, and dog tags. :)

[wavexx]

As a heads up/note for everyone, this has been working very well for me, except sometimes when combined with filament runout.

If a filament change is scheduled because the filament has finished, the additional extrusion might bring the filament too low (below the top PTFE tube), to the point that the final retraction doesn't always work as planned.

In these cases I simply pushed the filament down (to be melted) with the new filament, but you need to open the spring door to do so.

The supplemental extrusion needs to be disabled when an M600 is scheduled by runout.

[Argolein]

This works for me with the Mosquito Hotend. It does extrude +11 which is enough to clean the tip and the gears can still grab the filament for retraction. I also adjusted the speed a bit (slower) for the first retract. I find this lowers the risk of the tip getting ripped off. Changes are in the ultralcd.cpp. I dunno how to contribute here in "the right way" on GitHub so I'm just sharing this here:

void lcd_load_filament_color_check()
{
	bool clean = lcd_show_fullscreen_message_yes_no_and_wait_P(_T(MSG_FILAMENT_CLEAN), false, true);
	while (!clean) {
		lcd_update_enable(true);
		lcd_update(2);
		load_filament_final_feed();
		st_synchronize();
		clean = lcd_show_fullscreen_message_yes_no_and_wait_P(_T(MSG_FILAMENT_CLEAN), false, true);
	}
// anti-blob
  current_position[E_AXIS] -= 6;
  plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], 5, active_extruder);
  st_synchronize();
//Anti blob
}

#ifdef FILAMENT_SENSOR
static void lcd_menu_AutoLoadFilament()
{
     uint8_t nlines;
     lcd_display_message_fullscreen_nonBlocking_P(_i("Autoloading filament is active, just press the knob and insert filament..."),nlines);////MSG_AUTOLOADING_ENABLED c=20 r=4
     menu_back_if_clicked();
}
#endif //FILAMENT_SENSOR

void unload_filament()
{
	custom_message_type = CustomMsg::FilamentLoading;
	lcd_setstatuspgm(_T(MSG_UNLOADING_FILAMENT));

	//		extr_unload2();
// anti-blob unloading filament (also mid print)
  current_position[E_AXIS] += 11;
  plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], 5, active_extruder);
  st_synchronize();
//Anti blob
	current_position[E_AXIS] -= 45;
	plan_buffer_line_curposXYZE(5200 / 60, active_extruder);
	st_synchronize();
	current_position[E_AXIS] -= 15;
	plan_buffer_line_curposXYZE(1000 / 60, active_extruder);
	st_synchronize();
	current_position[E_AXIS] -= 20;
	plan_buffer_line_curposXYZE(1000 / 60, active_extruder);
	st_synchronize();

[wavexx]

The code I was depending on was merged yesterday. The new PR #2318 now implements this (handling the runout state as well) on the current FW.

[github-actions]

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

[github-actions]

This issue has been closed due to lack of recent activity.