Fixed issue #1207 - MMU - Change Temperature/Material Purge Order Issue #9737
Conversation
|
We definitely would like to see this change implemented. We run into problems with temps changing too quickly on silk filaments and on Prusament Galaxy Black which has led to bad tips and/or breakage of the Prusament which in turn has led to numerous jams. |
|
Upvote. We need this |
|
Another upvote. How can this be missed? |
|
+1 |
1 similar comment
|
+1 |
|
Upvote. |
|
Please merge this request. It would be helpful to several who are commenting here. |
|
+1 |
|
+1 for making the MMU2S / MMU3 great! |
|
It would be wonderful to get this merged. |
|
we hope it will be implemented soon |
|
+1 |
|
Please Implement, helps use of MM multi-material. |
|
+1 |
|
For extruders that cool quickly this fix does not work 100% of the time. I still jam up. It should remain at the higher temperature until the wipe is done. Then pause for the cool down. Or give an option to switch between the methods. Does not work for my setup. |
Good point. I'm curious, what extruder cools so quickly? This is trival to fix. A line of code just has to be moved from before the wipe to after the wipe (or middle of wipe). It already waits for the cooler temperature before resuming printing, but this wait never happens in my case because the correct temperature is already there by the time the wipe is done. |
|
I run the following extruder on my voron 2.4 with stealth burner hotend.
Upgrade High Temperature 24V 115W Ceramic Heating Red Lizard K1 UHF Hotend
CHC Pro High Flow Compatible with Voron V2.4 0.1, V6 Dragon Hotend Prusa i3
MK3 MK3S Titan Extruder 3D Printer(K1 UHF) https://a.co/d/9I9s51E
From what digging I did in the code it seems the temperature should remain
the high temperature until the second part of the wipe. Where the order is
wipe current > swap > wipe new > cool down. At most mid second wipe cooling
can begin.
Alternatively adding a toggle option for one of two methods would work to.
My solution for now has been to just have filament start gcode set the high
temperature. In my current super sliced setup, the gcode adjusts the
temperature back before the actual print. Not certain what toggles it. I
swapped to superslicer because it was the best option for all not working
options. Also I have to manually set one more gcode line to swap
temperature to appropriate for the very beginning of the actual print else
the first filament used will be at the high temperature.
I'd love for the functionality to be in prusaslicer so I can switch back.
…On Wed, Sep 13, 2023, 2:41 PM Alex Matulich ***@***.***> wrote:
For extruders that cool quickly this fix does not work 100% of the time. I
still jam up. It should remain at the higher temperature until the wipe is
done. Then pause for the cool down. Or give an option to switch between the
methods.
Good point. I'm curious, what extruder cools so quickly?
This is trival to fix. A line of code just has to be moved from before the
wipe to after the wipe (or middle of wipe). It already waits for the cooler
temperature before resuming printing, but this wait never happens in my
case because the correct temperature is already there by the time the wipe
is done.
—
Reply to this email directly, view it on GitHub
<#9737 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIIPGWPG6HL25JVEVJN7HOLX2ID6FANCNFSM6AAAAAAU5RX3LU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I just fixed this. The change is in When switching from a hotter to a cooler filament, it now waits until the end of the new wipe tower layer before setting the cooler temperature. Then the final step is to wipe the nozzle (this takes very little time) while cooling; the old hot filament is completely purged by then. Then it waits until the new temperature is reached before resuming the print. I could also have it change to a cooler temperature mid-wipe, but that complicates the code due to needing two checks inside the loop that does the wipe: one to check if half the wipe is done, and another to check if the new temperature hasn't already been set within that loop. |
Excellent. Because my stock hotend cools slower than yours, it paused for a couple of seconds on the wipe tower to cool down to the correct temperature before resuming printing, as I expected. Did you also experience a pause? If so, I can try to figure out how to move the temperature change to start at the middle of the purge. |
|
Yes, I experience a pause at the end. It doesn't last too long for me. I don't think it is necessary in my case to switch temp sooner, as it works as needed right now and I like the comfort of all of the high temp material being purged, or more of it. I think this iteration is stable. I will report back if anymore issues. But I am mostly struggling with performance of my ERCF. Though for a first time use I am definitely making it difficult on myself. PLA Tough, PLA, ASA, ASA, TPU, PVA. Now I'd like to install the project as it is currently built, but that part confuses me. Anyone understand how to make the install run properly? The help document says "Now just use cmake and install". I wish it was a little more guided in that spot. |
|
@LostFool - my concern is that if there are a few extra seconds to pause at every layer due to needing a cooldown, then this adds up to a significant but not overwhelming amount of extra duration for a long print.
What I did was this:
At no time do you actually need to be in the Visual Studio environment. You just need it for the build script to work. In fact, I have never figured out how to build this thing from Visual Studio. I use Visual Studio only as an editor. Once it's built, you can simply replace the files WipeTower.hpp and WipeTower.cpp in the src/libslic3r/GCode/ directory with the ones from my repository, and rebuild. |
|
I also worry about it sitting idle on high heat and causing swelling on some printers. My voron will survive, but I bet my ender would swell. If you can figure out how to make it a GUI option you could add a toggle/switch in the GUI so that the logic can be chosen, "when to change temp, pause too cool" or something similar. I got it built and running by launching from visual studio code. I was just hoping to make this branch an official install. So I can launch by icon. |
|
I have done a few tests now and it works perfect presently! Thank you. |
|
+1 this has been an issue for many many years |
|
+1 thanks for considering this fix |
|
+1 upvote |
|
Did this get merged in with the latest release? I didn't see anything about it in the release notes, but this recent activity makes me hopeful... |
|
@LostFool Unfortunately, the recent activity is merely me updating the PR so it works with the latest stable release of PrusaSlicer. I don't know if anybody from Prusa has looked at this yet. It's been over a year now sine I raised this PR. I was hoping that with the MMU3 coming out, there would be more interest from Prusa to fix this bug. It's a really trivial fix, too. |
|
@SachCZ @lukasmatena Can you please have a look ? Thx :) |
After seeing 2.7.2 got released, I misread one of the things it said it added and thought your PR was in there! Here's hoping this can get mainlined! |
I only see visual studio 2022 listed if I go through the song and dance now - do we still require 2019? Are there any containers that can be used to build prusaslicer? |
|
We hope it will be implemented soon, I wouldn't buy an MMU without it. |
|
The latest changes to PrusaSlicer master branch created a merge conflict with this PR. I have just resolved it.
Well, for the typical use-case as a multi-color unit (which is what I imagine most people do with the MMU, rather than use it as a true multi material unit), this change doesn't matter. It matters only if you're using the MMU with different temperature materials. As for me, fortunately I can compile my own version of PrusaSlicer with this change in it, but it would be so much better if it was in an actual release. With the MMU3 shipping, I had hoped that Prusa would be interested in this issue, which is a serious problem for different temperature materials. It would be nice if someone at Prusa would comment about the intent (or not) to include this someday. I see that @lukasmatena , @bubnikv , @enricoturri1966 , and @alranel were pinged in a comment here last year. I'm sure they get a lot of pings and are quite busy, and I apologize for doing so again, but I and other MMU owners are really interested in seeing this simple change implemented. I am available to answer any questions. |
|
Adding this would be great, I am in the process of setting up the MMU3 for the MK4 at the moment and it bugs me that there isn't even a TPU profile if I only want to print that. :( |
I don't believe there is a filament handler in existence (whether it's MMU, AMS, or whatever) that works reliably with TPU, and that's why there is no TPU profile. I have some 87a TPU that's floppy like a wet noodle. My MMU has been able to push it all the way to the extruder some of the time, but pushing a wet noodle is so unreliable that I need to bypass the MMU when I print TPU. |
|
Guys this is not a new Isshu. When i was working on Changing filament with my first RepRap printer it was and Isshu. The hardware your hardware has Finly evolved such it will be posable to implement this in printer farms, and Finly get rid of thoughts ugly over hangs with support material damage. in FDM Printing. Please implement temperature for purge. |
|
Just wanted to drop in to say that this fix has been a lifesaver. I'm working on a project that involves multi-material printing of PLA (220C) and an ABS composite (250C), and without this, I would not have been able to do so. For anyone looking to build PrusaSlicer, just a heads-up, you might need a PC with at least 32 GB of RAM; I wasn't able to build it with 16 GB or 24 GB RAM on my laptop. |
|
@BL1NKED - I'm glad this is helping someone. BTW my laptop is 16 GB and it builds fine from the commandline, but the full compile needs me to set it up before bed and run overnight. |
This fixes issue #1207 and others closed as duplicates (#8201 and #8702). The tool temperature changes have been corrected so that the purge on the wipe tower occurs at the higher of the two temperatures between the current filament and next filament.
This PR affects only single-extruder configurations. Multi-extruder configurations remain unchanged.
This change allows the MMU to be a true multi-material unit, making it possible to print PLA with PETG supports without nozzle jams due to too-early cooling, or mix together PLA and high-temperature PLA+.
Specifically:
wiping startspurging ends on the tower, so that the nozzle purges the leftover hot filament at a higher temperature and cools during the final wipe. When the wipe is done, it waits (if needed) for the lower temperature to stabilize before the print resumes.This PR includes three kinds of changes in the file WipeTower.cpp, all minor:
m_old_temperaturevariableWipeTower::toolchange_Wipe()(which required adding one small change to WipeTower.hpp)I made sure that these modifications affect only the single-extruder MMU configuration, not configurations with multiple extruders.
I tested this fix two ways: by examining the g-code generated for a simple cube with two tool changes, and printing a somewhat more complex 3D model using PLA (205°) and PLA+ (220°) for the part and PETG (215°) for support structure. Each test performed as expected.
Update 2023-03-09: I have since been printing extensively with multiple materials of different temperatures and this fix has been working flawlessly.
Update September 2023: Based on feedback below, I have changed the cooldown to start when the purge completes, but before the final wipe. This prevents jamming in fast-cooling hotends. With my slow-cooling stock MK3S hotend, this results in a pause for a couple of seconds to wait for the final temperature, and then printing resumes at the new cooler temperature.