V2 of my endeavour to improve multi color printing and depending on how far you choose to optimize:
| V2
|
G-code is tested or reported to work with:
The value “Flushing Volumes” set by the user in Bambu Studio is the amount of filament in mm³ that is to be pooped or be flushed into an object. → Attention, it does not go into the optional prime tower, despite that one is printing before any optional object that is bound to be flushed into!
The filament that goes into the prime tower finally is presented separately. It is an additional expense to prime the nozzle after the filament change. With a following retract and pressure advance active by default, a huge prime volume may not be needed anymore.
The printing sequence itself makes sense but has some consequences based on the attached calculations.
Once the filament is cut, there are around 107mm³ present between the nozzle and the cutting position and it can't be retracted by the extruder. If a secondary object to flush into “eats” more filament within the present layer than what is specified in the Flushing Volume for that change, no poop may be created. → Great to save filament via printing only a small prime tower (which is required for flush into object), but potentially not so great when it comes to reliability with losing oozed out material from the nozzle or when any retractions would have been required during the 107mm³ that followed.
Until proper calibration prints are included in slicers, it may be useful to know what to look out for when choosing a flushing volumes calibration print.
Under “Printer settings” → “Machine G-code” → “Change filament G-code”
If you want to know exactly what is going on in the code, what each command is supposed to do or even tweak it a bit yourself, I made lots of annotations.
Side note:
If you're using a small nozzle like 0.2mm, double check the set “Max. volumetric speed” (Bambu Lab's variable name, otherwise known as “max. volumetric flow rate”) of your filaments. It regularly becomes a bottleneck that adds several hours to a print.
Bambu Lab understandably leaned more towards a stable process under a wide variety of circumstances rather than optimizing for filament efficiency.
Besides the filament specific flushing volumes there also is the option to reduce the constantly lost few mm³ during the filament cutting operation by retracting filament before it is cut. The maximum amount of additionally saved filament by pulling filament back from the melting zone is limited by the length of the filament that already became gooie due to the heat influx.
With a length of approximately 25mm (heated part of the stock Bambu Lab hotend + transition zone) the safe length to retain at each and every filament change could well be 20mm => 48mm³.
Because this maximum length might lead to trouble along the way, the values in the given G-code are set relatively low to:
If you want to play around with these values, please go for it and report back, more feedback may result in greater savings for all.
A fair warning though: Risking molten filament becoming a problem up in the cold end is a realistic mishap and one would have to save a lot of purging material to offset even one failed print.
Yes, this additional modification is not interpreted by the slicer. The retracted amount seems to go unnoticed within the slicers estimation.
The lower recommended flush volume of 107mm³ is based on the hotend volume from the nozzle to the filament cutting blade.
A good reason to not set the flushing volumes too low is the wiping process. If there is not enough mass dangling from the nozzle below the wiper, the chances of flinging that material back into the area of operation is greatly increased.
During my trials I found no noticeable difference between purging material at a constant extrusion vs. in a pulsating manner or with little pulses, so constant without slow downs it is.
If you get an error, reading something like “machine_start_gcode Parsing error at line…”, you very likely inserted the code at the wrong place. Try again by restoring the start gcode and only replace the code in the “Change filament G-code” section with the one given here.
The here suggested calibration print does the job just good enough, I would prefer a proper & more precise calibration pattern generated by the slicer as well. → If you find yourself here, that probably means still nothing better exist…
The alternative G-code does not do wonders as well, it only is an improvement in details. If your printers poop was an absolute mess before, it very likely will be that way with my code too.
If you have found a bug in my code or would want to have a certain feature, simply tell me about it. I will see what I can do.
Remember, using my code happens at your own risk. There is a lot to cover when it comes to creating a reliable process over a wide range of (even seemingly identical) machines and materials. - I am not Bambu Lab, instead just a next best dork online who thinks he can improve some stuff and spare you the hassle of doing it. A future firmware or slicer update may result in this code not working properly. Keep that in mind and test/use it with care.
You shall not share, sub-license, sell, rent, host, transfer, or distribute in any way the digital or 3D printed versions of this object, nor any other derivative work of this object in its digital or physical format (including - but not limited to - remixes of this object, and hosting on other digital platforms). The objects may not be used without permission in any way whatsoever in which you charge money, or collect fees.