Marlin
Marlin copied to clipboard
MarlinFirmware
Improved filament unload (like original MMU2s)
Description
The original prusa firmware has parameters to make sure there is no filament when switching tools, if so, keep unloading until no filament is detected. I noticed this wasn't implemented in the mmu2.cpp of marlin 2.0.7.1 since it assumes no filament was ever loaded if a different tool was used or load to nozzle was used. It relies on the filament ramming parameters which can be unreliable for flexible materials because it could sometimes keep it loaded in the gears.
Benefits
The PRUSA_MMU2_S_MODE in marlin added benefits for Loading filament and responding to the IR trigger similar to the orignal MMU2s. I added a few more lines similar to the original for the MMU menu function -> load to nozzle which would do a filament ramming first, then keep unretracting if filament sensor is still loaded despite the ramming.
For the T# to a different tool, filament ramming is dependent on the slicer, however there are times where flexible filament may still get stuck in the gears and marlin still doesn't have the function to make sure it is unloaded before letting the MMU unretract with the U0 command.
Configurations
Added "//#define MMU_IR_UNLOAD_MOVE" in the Configuration_adv.h I'm not sure if I should use my whole config for an SKR-Bear-Prusa, but I made a separate config for the bare minimum enabled settings to compile
Related Issues
One concern is that I used a "while" statement to keep unloading until filament sensor is untriggered, I'm still trying to figure out how the whole mmu cycle works in marlin, but it works well so far on my build.
~~I'm still not sure if I should keep the line command(MMU_CMD_U0); //unloading from mmu side but not printer in the tool_change function~~ commented out MMU_CMD_U0 in my recent commit for tool_change() but this is necessary for load_to_nozzle()
Can you describe the scenario where the previous implementation does not work well? I would like to understand how it might ruin print jobs or even damage hardware.
The comment above this configuration block says:
- Using a sensor like the MMU2S
- This mode requires a MK3S extruder with a sensor at the extruder idler, like the MMU2S.
It seems everyone will have this sensor. Have you thought about changing behavior, without making it a configuration option? Is there any reason an MMU2S user would NOT want this option? Maybe problems with clear filament?
AFAIK MK3S runout sensor works in a different position respect to normal. Normal runout detect filament just before gear, so once detected it may be unloaded by printer. MMU runout detect filament detect filament out of gear and printer can't unload it.
this cnf works only when mmu has its own filament runout detection. Extruder one is just used to detect filament into gears (properly loaded).
I think not all people have this cnf (old mmu or pre mk3s extruder)
sorry for my late reply, GMagician is right about the MK3S extruder, it's not dependent on filament color hence this will only work on an MK3S-Type extruder (inclusive of the other S variants) that's why I made it under the PRUSA_MMU2_S_MODE
- additional info, the S variant was designed to improve MMU2 reliability by sensing filament loading directly into the gears instead of a runout sensor just being above the gears
However, I want to add the missed out function of the idler sensor during the UNLOADING not only loading with this line in the Prusa FW as my reference.
My implementation is different though. I somehow threw the printer into a "while" statement instead of using "machine states" (if I used the term correctly) in making sure its unloaded that a printer state of unloading until no filament has been detected. Concerns why this might fail on the hardware side is:
- what if the user hasn't calibrated the idler ir sensor (aka extruder ir of the gears) and the printer might get stuck in an unloading state. The watchdog timer might kick in and kill the printer midprint when the user could just pause and make necessary adjustments
- ^ therefore an advanced pause should be called instead of being stuck in the while loop if a certain unloading timeout is reached (proposed solution if ever but I haven't implemented in code)
Normally Prusa slicer automatically inserts gcode for filament unloading approximately outside the gears (approx -49.50mm of filament retraction as hardcoded as part of the wipe tower block) that's why it has a high probability of being unloaded by the time T0-T1/other numbers is called at this point in time FOR solid filament like PLA/ABS/PETG at the current state of Marlin's PRUSA_MMU2_S_MODE. However the e steps/extrusion multiplier required to unload flexible material may be different because the filament width changes depending on the tension pressed on it, elongation or compression along the path may change the steps necessary to fully unload the filament before the mmu Pulls it away. If the filament is indeed consistent, a remix of the MK3S extruder with a longer filament path length may also benefit with the printer side doing Filament checks during unload and guarantees that it is unloaded from the gears.
to summarize: At the current state of MMU2S (S version to be specific) in marlin, it doesn't utilize the idler during the unloading to make sure that no filament is left. As a result, the MMU might pull the filament and grind or slide on it even if the material is still loaded in the gears which can easily be cross checked by the Printer's idler IR sensor before telling the MMU unit to pull it away
@niccoreyes I pushed a change to resolve merge conflicts with the other recent MMU changes. That unfortunately did not go as planned so I pushed it back to the original state. I'll push the merge/cleanup in a minute.
edit: actually that wasn't right either. Sorry about this, it will be straightened out soon.
OK, so it actually had done what I wanted, but GitHub was slow to reflect it in the view and it mistakenly showed up as hundreds of files modified in the PR. A few moments later it was fine.
I've merged this with the other recent MMU changes and done some very minor cleanup (alignment, trailing spaces, comments).
Please make sure this is still working after all the other MMU changes in the past couple days. I will also post some additional comments on the code itself.
added proposed cleanups, but I haven't made a solution for a way to fix the two while(FILAMENT_PRESENT()) sections at the moment
also I removed the MMU_CMD_U0 command at line 977 since I realized that the succeeding MMU_CMD_T0+index will coordinate with mmu the current extruder anyway on the mmu unit.
will do some tests tomorrow
@niccoreyes what do you think would be the right response if filament can't unload? I can come up with a few options:
-
Return an error in some way - probably useless because G-code would keep running
-
Kill the printer - Prevents damage, but ruins the print. EASY to implement.
-
Perform a filament runout pause...I'm not sure how hard that will be to implement, but seems like the best user experience.
I presume if you are using an MMU you always have "filament runout" support enabled? I have never actually used one myself.
Regarding my last comment, you can probably use manage_response here. I've commented elsewhere about it.
It seems like the infinite loop is the major outstanding issue. Please try using manage_response to resolve that. It will be great if you can fake a jam for testing purposes to make sure it works as intended.
Sorry for the late reply, lots of exams lately. I haven't exhausted testing the MMU function for the week yet. MMU prints do take a while But I think calling the runout menu would be preferable
I haven't explored the runout menu functions and how it is called, but it can be activated with "runout sensor: off" from the configuration right? I noticed that the MK3s type sensor triggers the runout sensor when printing TPU sometimes, because as the gears presses on it the filament can be so compliant to the pressure and the lever slightly moves enough not to be sensed by the IR sensor sometimes midprint. My prints with the mmu + PLA / PETG / ABS has been great with the "runout sensor" function turned on, but not for TPU. I tend to turn off "runout sensor: " from the lcd menu when doing MMU TPU prints and had more success, nevertheless the load to gears() and tool_change() function works ok since it reads the pin of the runout/filament sensor directly.
I'm assuming the mmu runout menu can be called independently from the whole "runout sensor" feature.
I might get back to coding a timeout function in the weekend, sorry for the delay 😥 I wanna do more tests just to be sure everything is good and user friendly.
I may be wrong but runout sensor should not work with mmu as usual. It's used only to be sure tha filament has been "taken" by gears or released by "gears". During print is pinda sensor that should detect filament runout, and that sensor is on mmu2
I suggested using the manage_response function instead of trying to manually do a normal runout, because manage_response is how problems during existing load/unload commands are handled. This in some way requests feedback from the user to resolve the issue.
All I can do right now is point you in what I think is the right direction, since I don't actually use this hardware. If @GMagician has experience with the MMU code their input could really help.
If @GMagician has experience with the MMU code their input could really help.
sorry, no experience, it's just "AFAIK"
Presumably there is no need for ENABLE_AXIS_E0 before a move, because the stepper ISR should automatically enable the E axis as needed. If that isn't happening and this won't work without them, then we might want to investigate.
Presumably there is no need for
ENABLE_AXIS_E0before a move, because the stepper ISR should automatically enable the E axis as needed. If that isn't happening and this won't work without them, then we might want to investigate.
I see, I guess can remove these later as I test, I paralleled the those sections from the non-mmu2s extruder. I don't really have any reason to keep it there if that were the case. I'll be working on testing these for the weekend.
I also added a fix for the DEBUG_ECHOLNPAIR near the unscaled mmu2 moves where it fails to compile I think the compiler was searching for an initiated "fr_mm_m" variable that existed before yesterday's commits
@niccoreyes are you intending to come back to finish up this PR?
Some of us would probably be willing to help work through remaining issues, but have no way to actually test a change.
I've merged the latest code into this and cleaned up extra calls to ENABLE_AXIS_E0. Now it's just waiting on the refinements discussed above to handle bad conditions safely and to prevent infinite looping. We're looking for MMU2 testers to fill in the details.
when compiling I get this error
Marlin\src\feature\mmu\mmu2.cpp: In static member function 'static bool MMU2::load_filament_to_nozzle(uint8_t)':
Marlin\src\feature\mmu\mmu2.cpp:924:5: error: 'filament_ramming' was not declared in this scope
924 | filament_ramming(); // Unloading instructions from printer side when operating LCD
@JohnnyTheOne you may replace such line with:
execute_extruder_sequence((const E_Step *)ramming_sequence, sizeof(ramming_sequence) / sizeof(E_Step));
I think original function has been removed because it was just used once. I think now it should be readded with an inline attribute
It works thanks, this pr adds important function for mmu operation
If you force it to fail by withholding the filament from the feeder, or by withholding the filament from the sensor at the nozzle… does it fail elegantly and have a reasonable timeout and retry procedure?
i wanted to test the latest changes today but printer keeps restarting with and without this pr
Expected behavior: Unloading Filament ramming sequence extruder keep unloading until no filament is detected. mmu unloading.
Actual behavior: Unloading Filament ramming sequence filament still in extruder and damaged by mmu unloading.
I just tested again no change. still same behavior: Unloading Filament ramming sequence filament still in extruder and mmu start unloading.
Does this represent an improvement in its current state, or does it need more fixing? I can merge the current state into bugfix-2.1.x for wider testing if it's reasonably functional. If it's a general improvement in its current state I can also include it in 2.1.3; if not it can be reserved for inclusion in 2.1.4.