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. |
|
OK, @djglaze and @LostFool I have committed the change to this PR. Now when switching to a lower temperature, it waits for the wiping loop to exceed 50%. This results in slightly more than 50% being wiped at the hotter temperature. This should eliminate the cooldown pause at the end of the wipe, while still purging nearly all of the high-temperature material at the higher temperature. I made a box that flips between different temperature materials every millimeter. Here is a picture showing the temperatures on the wipe tower when switching from 215° to 205°: |
|
@amatulic Sorry for not getting back to you sooner. Switching temperatures mid-way through the wipe layer does sound like the ideal solution that should keep everyone happy. I'll definitely try it out and get back to you, although it may be a couple days. I'm having issues with this PLA/BVOH print unrelated to these changes (the two filaments are not sticking to each other very well and things are coming apart during the print), so I need to babysit a majority of the 14-hour print. I can't do that until I get a day off work. It should hopefully be either Friday or Saturday. |
|
@djglaze - no hurry. It's been over a year since I first created this PR. It doesn't appear that Prusa has plans to merge it anytime soon. @tschaerni - please try again. Everything seems to be working fine now. You can compile from the fix-wipe-tower-mmu branch directly. |
Oh, I already compiled it a few days ago, right after you fixed the botched merge. But I didn't wanted to spam the pull request here with it >.< |
|
@amatulic I just gave it a try, and it works much better. Setting the new temperature mid-way through the wipe (with the set-and-continue M104 command) seemed to work as expected. The temperature dropped all the way down well before it got to the end of the wipe. Interestingly, the final set-and-wait with the M109 command still paused the print for a few seconds and led to some oozing even though the temperature was exactly right. It seems like it takes the printer a few seconds to figure out that the temperature is already good. During one filament swap, the nozzle temperature happened to be one degree low at the end of the wipe and it paused for about 10 seconds before it wandered back up to the set temperature and continued. It oozed the BVOH filament quite a bit while waiting. I'm wondering if we even need the final set-and-wait command if the intent is for the temperature to be correct by the end of the wipe anyway. I guess there's a chance that a big temperature change might mean that it's not caught up yet at the end, but it seems like the temperature drops pretty quickly while it's feeding filament into the nozzle. If it did ever leave the wipe tower while running too hot, I don't think that would last very long and probably wouldn't be a big deal. On a side note, Prusa Slicer is visualizing the temperature change differently for me than what you posted in the above image. Even though I can see the M104 command added half-way through the wipe, the temperature for the entire wipe layer remains stuck at the high value. It drops down when printing the model, so it seems like only the M109 command changes the visualization for me. And, now that I think about it, if you end up removing the final M109 command, it might not show a temperature change at all. It's strange that you're seeing a different behavior. |
|
@djglaze - thank you for testing this. The final M109 command just tells the printer to wait for the new temperature to stabilize. It might have undershot the target temperature during the wipe, ending at 204.51° instead of 205° but your printer would display 205° because it rounds to the nearest degree. I don't know of any gcode to tell the printer "within 1° is good enough, don't wait anymore". In the earlier version of this PR when the new cooler temperature was set at the beginning of the wipe, there was no wait at all at the end, even though that final M109 has always been since the earliest version of this fix. It might be a good idea to eliminate that final M109. Even if the nozzle hasn't had time to cool all the way from a really hot filament (like polycarbonate, which can be 300°C), it should still be safe to resume printing even if the nozzle is a bit warmer than desired, it's going to be at the correct temperature before the first inner perimeter or infill line is done printing. I'm just worried that there's some use case in which it's more desirable to let it stabilize first. I don't know what to tell you about what you're seeing in PrusaSlicer. The picture I posted previously is what I got when I compiled it a few days ago. |
|
We really need this implemented into pruca slicer.. |
Well, you can compile the fork yourself. The instructions for doing it work pretty well, but getting an environment set up can take some time, and compiling the entire program takes my computer all night. Another option is try printing with a higher PLA temperature that still works with PETG. Or use PVA, which uses the same temperature as PLA. Finally, I found the MMU to be incredibly useful even when I wasn't switching between different temperature materials. Even printing a single material, it's convenient to be able to select which of 5 tools to use in the slicer. |
|
@amatulic My vote is solidly in favor of removing the final M109. I've stopped using this patch because it just makes too big of a mess and risks ruining the print on every filament swap that reduces temperature (specifically with BVOH filament). The "official" behavior of PrusaSlicer when doing a filament swap is to issue an M104 and just keep going. I don't think I've seen it wait for the temperature to stabilize with an M109 any time other than at the initial nozzle warm-up at the beginning of a print. During printing, the temperature naturally oscillates a little bit around the set temperature. If that's enough to cause the printer to wait a long time when issuing an M109 even though the temperature is already "good", then it can only do harm to the print. I understand your hesitation to removing it, since there might be a corner-case somewhere where it helps. I can't think of one, though. And again, while filament is being fed through the nozzle, its temperature can drop really fast. I think the chances of leaving the wipe tower while still too warm are exceedingly rare. Even if it does happen, I'm not too worried because it should be very brief. Thanks again for this change! |
@djglaze I agree. But before I update this PR again, I'd like you to confirm something. Looking at the wipe towers in my wastebasket, visually they show the old color covering about 40% of the surface and the remaining 60% is the new color. Is that also what you observe? If so, then I can change the temperature transition to occur at 40% of the wipe instead of 50%. This would give the final temperature even more time to stabilize, further reducing any need for that final M109 command. I had put that command in there because scripts I had seen for post-processing g-code to fix this temperature issue also included that command. But you're right, by the time the wipe is done, the temperature is already so close to the final temperature that it shouldn't be needed. |
|
@amatulic Yup, my wipe towers seem to show the same thing. A switch at 40% might be just about right. Lately, I've been doubling (or more) the purge volume for special circumstances. Things like black bleeding into yellow or white bleeding into black have been a problem for me, and also if there's any hint of BVOH filament mixed in with the PLA, I get terrible strength and layer adhesion. In these cases, a switch at 40% would leave plenty of time for the temperature change. Even at a "normal" purge volume, I think that's still plenty of time. I wouldn't be worried at all. |
…nt to about 40% of wipe tower surface
|
@djglaze - all right! New commit. I observed, in that 40% of the top surface area needed to see the color change visibly, the first 20% is taken up by cooling moves, meaning that the temperature change can occur much earlier than 50% from the start of wiping (if you look at the picture a few posts above where I changed it at 50% of the wipe, the actual change appears to be around 60% on the wipe tower). So I made it change after 30% of the wipe. This results in the temperature actually changing at about the halfway point (40%-50%) on the wipe tower top surface. I eliminated the final M109 wait at the end too. I think there's a bug in the g-code viewer in PrusaSlicer. Sometimes it misses the M104 and doesn't display the temperature change. I can see it there in the g-code but the viewer skips over that command for some reason. Not all the time, but it happens if you make the wipe tower width 30 mm or less. |
|
In the meantime, I wonder if there's a way to reduce the purge speed to give it more time to change temperatures without actually requiring more purge? |
|
+1 |
|
If it's useful to anyone to save time recompiling, and you use Windows 11 64-bit, I have started to release the prusaslicer.exe builds with this fix in my GitHub repository. Version 2.8.1 is here: https://github.com/amatulic/PrusaSlicer/releases/tag/wipetower CC: @RickM777 @Mirarkitty @Jackjan4 @Sebastian1989101 @3Delights @doug006 @pgilfernandez @kazibole @Skaronator @Sionree @SalmonSays @paulcopping @beavis69 @djglaze @LostFool @tschaerni @Tomijorg @reinux @mw75 |
|
Updated fork release to 2.9.0: https://github.com/amatulic/PrusaSlicer/releases/tag/wipetower |
|
Tried https://github.com/amatulic/PrusaSlicer/releases/tag/wipetower 2.9.0 Printing model in PETG with support in PLA. When nozzle moves from PETG (230) to wipe tower it immediately sets to lower temperature of 215 and clogs? Is there a way for me to check the gcode and see if the code is getting written correctly, what whould it look like? Thanks for your hard work. |
|
Tried https://github.com/amatulic/PrusaSlicer/releases/tag/wipetower 2.9.0 Printing model in PETG with support in PLA. When nozzle moves from PETG (230) to wipe tower it immediately sets to lower temperature of 215 and clogs? Is there a way for me to check the gcode and see if the code is getting written correctly, what should it look like? Thanks for your hard work. |
|
If it immediately sets the lower temperature when the filament unloads, then you aren't using this mod. It shouldn't immediately set the lower temperature when it moves to the wipe tower, but after it starts wiping back and forth and gets about 30% done, it should switch. There's a g-code viewer built into PrusaSlicer (in the sliced view, it's that horizontal drag bar at the bottom of the window). Set the legend to display temperature. Without the g-code viewer you may see the wipe tower change temperature, but often this preview misses the temperature change g-code where it happens, so you can look at the g-code viewer and find the M104 command. Here's a situation where the visual preview worked, in the modded PrusaSlicer 2.9.0, showing a temperature change from 230° to 205° on the wipe tower: |
|
Thank you very much, I re installed, seems to be working better. Although 1st layer material still didn't look quite right to me, not all the higher temperature PETG got extruded at the higher temperature before the temperature reduced to 215 and the filament swap was done to PLA Then more PETG was purged before PLA came through, although temperature was high enough (215) to purge the PETG in this case. After the 1st layer it worked perfectly, swapping back and forth and holding the higher temperature until the PETG was purged.
|
|
That's correct behavior for the most part although I don't understand what you say is happening on the first layer. It shouldn't be doing anything different. Most of the high-temp material has already been purged by the time the temperature is set lower. At that time, most of the material coming out of the nozzle is the new, cooler material, and the remaining high-temperature material is diluted enough that it isn't a problem as the rest of it purges out. The temperature switches mid-purge to ensure that the temperature is correct by the time the print resumes. The color indication in PrusaSlicer's preview often isn't correct, and sometimes the color change doesn't appear at all until the next layer, even though the M104 command still happens at the correct spot. |
This PR 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:
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 instead of when the purge begins, but still 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.
Update 2024-05-16: Based on further feedback below, I have modified the logic so that the cooldown starts after 50% of the wiping on the tower has completed. This is a happy medium between starting the cooldown early (which risks jamming a fast-cooling extruder) and starting the cooldown too late (which risks a blob forming if the nozzle must pause for a few seconds waiting for the final temperature before resuming the print). This PR has always included g-code to wait at the end anyway if needed, but the idea is to start the cooldown after most of the hot material is purged so that waiting shouldn't be necessary.
Update 2024-06-03: I made a further refinement after observing that the color change during a wipe appears complete after about 40% of the top of the wipe tower is covered. About 20% of the top of the wipe tower coverage comes from the inital cooling moves, which suggests that another 20% is needed to purge most of the old material using the default purge volume in PrusaSlicer. The new lower temperature is now set at 30% of the wipe (instead of 50% from the prior commit). This corresponds to about 50% of the total top of the wipe tower, a bit past the point where the new color is fully visible. Because the temperature change occurs a bit earlier, it has more time to stabilize, allowing the elimination of the final wait (and potential glob) at the end of the wipe for the final temperature, which should be close enough.
Download Windows binary: Because people have asked, I am placing my Windows builds with this fix into the releases in my GitHub repository here: https://github.com/amatulic/PrusaSlicer/releases/tag/wipetower -- the zip file contains drop-in replacements for the .exe and .dll files.