Excessive Purging on A1 (and other models)

Bambu Lab A Series General Discussions
1

I have been having a serious issue with my A1 - it has been purging an excessive amount of filament every swap, and Bambu support refuses to acknowledge this issue. They keep dismissing it as regular function. Per swap, my printer flushes about 0.11g extra than what the slicer estimates. I have been speaking with support and talking to other people about this issue for a while now, and I was hoping the community here could help me gather more information. I will also say that some of the people that I have been talking to also experience this issue on other printers with the quick-swap nozzles, like the P2 and H series printers. I only have a P1 and an A1, and I haven’t observed this on my P1.

If you can, can you please observe your A1, H2, or P2 printers in the same way? Before sending a multicolor print, take note of the estimated flush and number of swaps. When it is done, weigh the flush and compare. It would really help me understand if this issue is far spread, or if it is only affecting me.

Here is some of the data I have collected and tabulated so far. All of this data was collected from prints sent via Studio on my main PC. However, I do test Handy and other PCs below. I will also go into detail about other experimenting/research and my communications with Support up to this point below the table.

File Swaps Calculated Purge Actual Purge Difference Extra/Swap Flow Dynamic? Tangle Detect?
C:[…]\Documents\Bambu&3D=PLATES READY\shark-elephant-14hrs.3mf 90 2.00 12.65 -10.650 0.118 X ✓
C:[…]\Documents\Bambu&3D=Purge Calibration=PURGECALIBRATION.3mf 13 0.00 1.25 -1.250 0.096 X X
C:[…]\Documents\Bambu&3D\ForgeCore=Games\CactiChess - Roll up Cactus Chess Set\CactiChess.3mf 78 9.37 16.42 -7.050 0.090 X X
C:[…]\Documents\Bambu&3D\ForgeCore=Games\PlayBook’d Chess.3mf 31 0 4.56 -4.560 0.147 X X
C:[…]\Documents\Bambu&3D\ForgeCore=Games\PlayBook’d Chess.3mf 31 0 4.45 -4.450 0.144 X X
C:[…]\Documents\Bambu&3D\Cinderwing=Tadlings\painted tadlings.3mf 96 18.99 31.14 -12.150 0.127 X X
C:[…]\Documents\Bambu&3D\ForgeCore\Morning Glory Magnets - Ivy Fridge Magnet - Flower Magnets (1)\1-Easy print 3mf - Morning Glory.3mf 20 2.67 5.27 -2.600 0.130 X X
C:[…]\Documents\Bambu&3D\ForgeCore\Morning Glory Magnets - Ivy Fridge Magnet - Flower Magnets (1)\1-Easy print 3mf - Morning Glory.3mf 20 3.66 5.95 -2.290 0.115 X X
C:[…]\Documents\Bambu&3D\ForgeCore\Morning Glory Magnets - Ivy Fridge Magnet - Flower Magnets (1)\1-Easy print 3mf - Morning Glory.3mf 20 2.37 4.69 -2.320 0.116 X X

I first observed this issue when I was printing a plate with 209 swaps, and a calculated flush of 16.69g. The poop bucket seemed to be much more than that, and it weighed 44g. This is creating an excessive amount of waste that I could have better planned for had the slicer (or my printer) been more accurate.

I also ran a purge calibration, which sets purge volumes to zero, but it was still purging more filament than expected. For a 0 flush, there is normally just a tiny small thread of filament. But on my A1, I was seeing full sized poops, each weighing about 0.11-0.12g. So in reality, a 0 flush is impossible on my A1. When I run this same purge calibration on my P1, I get true flush volume results. When comparing the same color swaps on the A1, it results in flush values about 75 less than what the P1 reads.

I next tested a few other variables with this same purge calibration file: From the Handy app, from Studio on my normal PC but with flush volumes set to 1, and from Studio freshly downloaded on a computer that has never had the software on it. They all performed similarly.

At this point, Support had provided me with custom G-Code which did not affect my results for the purge calibration or any other standard multicolor print. I was still seeing very excessive purge.

My concern was transferred to an engineer, and they told me:

Hello,
Thank you for your patience, the engineer just got back to me.
We have reviewed the ticket again, kindly note that the flush process during the complete printing process cannot be waived for the A1 series and the H2 series, which have the auto flow calibration function.
If you want to reduce the flushing filament when you exchange the color, you can kindly refer to the Wiki to check in detail and further adjust the G-code: Disable unloading and flushing to save filaments when printing the same material
Kindly check if it works and let me know if there are any further issues, I will help you further check.
Thank you for your cooperation and sorry for the inconvenience caused again. If you have any other questions, you can contact me at any time, I will always provide you with the best service!
Best regards,
Bambu Lab Customer Support

Next, an online friend of mine who also has an A1 ran a CaliDragon, and got the following results (we measured total print weight instead of just purge):
Total swaps: 133
Friend’s A1 Slicer Results: 77.02g total
Friend’s A1 Print Results: 82g total
Summary: 5g more than estimated

She also ran this file on her H2D and X1C and got -2g and +5g estimated, which is reasonable over 133 swaps. We also confirmed we had the same software version on Studio and firmware versions on our printers.

I downloaded the same file from the same link and had identical settings, and printed the model on my A1. These are my results:
My A1 Slice Results: 73.55g total
My A1 Print Results: 84g total
Results: 9.5g more than estimated

Almost double than what my friend experienced.

The next step in research was that my friend sent me the exact GCODE file she used for her A1. She showed me her slicer results before exporting the gcode and sending it to me.
I sent the gcode to my A1 via SD card:

Cali-Dragon_2-Color.gcode.3mf
Friend’s A1 Slicer Results: 76.04g total
My A1 Print Results: 89g total
Summary: 13g more than estimated

Clearly something is not right with my printer. This is very abnormal.
Next: I FACTORY RESET my A1, did NOT add it to wifi, ran the required machine calibration, and sent the SAME GCODE file via SD card:
Friend’s A1 Slicer Results: 76.04g total
My A1 Print Results: 89g total
Summary: 13g more than estimated – identical results to the previous test.

An additional 13g over 133 color swaps averages out to an additional 0.1g of purge per swap. This is a consistent amount that I have been experiencing and reporting. This adds up exponentially over larger prints.

I sent all of these CaliDragon tests between me and my friend to support, and included this message:

Your response does not address the issue I am having of excessive waste 'compared to the slicer.
I have also included gcode and 3mf files mentioned in the document.
My friend has also observed more conservative waste when doing the purge calibration tests that have been mentioned in previous messages in this thread.
Automatic flow calibrations have been turned off for all of these prints, so using that as an explanation to my problem is unacceptable.

And this was their reply:

Hello,
Thank you for your reply and sorry for the misunderstanding.
I just checked the results and the PDF file with the engineer, kindly note that there are more steps for the A1 series to process before starting printing or during printing, which could cause more flush. For example, since there is no filament buffer on the A1 series, there could be a preloading process to detect if the filament has been extruded.
The other detection, such as the Nozzle Clumping Detection function, will also cause more flushing.
The flush mentioned in the steps above will not be included in the data in the Bambu Studio, hence the result may be different.
I can totally understand your feelings and I really want to help you further, I will note the inquiry and I will transfer it to the engineers. I will mention the importance of the inquiry to them and check if we can adjust it further. Kindly keep following our official website for the latets update.
Thank you for your cooperation and sorry for the inconvenience caused again. If you have any other questions, you can contact me at any time, I will always provide you with the best service!
Best regards,
Bambu Lab Customer Support

I had replied:

I am positive that the only printer settings I had turned on during these tests outlined in the PDF (before and after the factory reset) was * auto-recovery from step loss. I’m looking forward to your response.

*I had also said tangle detection, but I double checked. It was off and sent a follow up reply correcting myself along with “I would like to reiterate that my friend and I ran the exact same gcode file and got 2 completely different final weights.”

Their response was pretty baffling:

Hello,
Thank you for your reply and sorry for the misunderstanding again.
Kindly note that some steps I mentioned earlier, such as the preloading process, are included in the firmware default setting. Hence, it will turn on in each printing.
As a warm reminder, since I really want to help you further, I have noted the inquiry and I have transferred it to the engineers. I have also mentioned the importance of the inquiry to them and checked if we can adjust it further. Kindly keep following our official website for the latest updates.
Thank you for your cooperation and sorry for the inconvenience caused again. If you have any other questions, you can contact me at any time, I will always provide you with the best service!
Best regards,
Bambu Lab Customer Support

I had quickly said that that explanation was beyond absurd and asked for documentation or a source claiming that environmental factors can affect purge.

A senior technical support representative took over the support chain and apologized for that rationale, but also added:

Regarding the issue you raised about flushing volumes, I would like to explain that the weight displayed in the Bambu Studio Preview interface refers solely to the filament weight required for printing. However, the actual generation of flushing volumes involves various processes: extrusion during loading, a certain amount of purging to ensure correct extruder loading, Flow Calibration where the eddy current sensor tests filament through flushing, and flushing at the wiper position during Tangle Detection to confirm the presence of a tangle issue.

This part of the support chain just starts to get cyclical. I asked this Senior to please review the previous information I had shared, including the identical g-code that was ran and the largely different results.

Dear Customer,
As previously explained, A1 requires extrusion of filament to determine if printing can proceed normally. The pre-extrusion action is necessary and is written into the firmware, thus cannot be modified. Variations are expected between different machines and filaments; this is a normal occurrence.
Kind regards,
Bambu Lab Customer Support

My reply:

why does Bambu consider it an acceptable outcome for the same model of printer within a product line running the same gcode using the same filament to have waste differences of .1g per filament swap? Reminder that on a multicolor print this can easily total 90g on a single plate, leading to excess waste generated by a single printer of 1kg every 11 plates printed…This lack of urgency and blatant dismissal to my issue will be shared with the community and other outlets.

They responded:

Dear Customer,
For printers of the same model, perfect uniformity cannot be guaranteed. Slight deviations are normal. In terms of pre-extrusion, factors like extruder or nozzle clogging leading to under extrusion, or excessive resistance in the PTFE tube, can cause increased flushing volumes during pre-extrusion. These are uncontrollable variables. The machine needs to ensure data integrity before undergoing testing to ensure proper printing functionality…
Kind regards,
Bambu Lab Customer Support

My reply consisted of the table I have provided at the top of this post.

I am still collecting data, but please explain why my A1 printer is consistently purging more than estimated by the slicer? How do I fix this? This is creating an incredible amount of waste that I cannot predict, affecting both my inventory and pricing.

Their reply:

Dear Customer,
Thank you for your reply，
We are unable to analyze the data you have provided at this time. As previously explained, during operation, the printer may perform flushing operations beyond the slicing process, such as preloading. These are all normal occurrences.
Kind regards,
Bambu Lab Customer Support

4 Likes
2

A 1kg spool is typically 330 meters of filament. This conveniently also works out to 330mm/g. So .1g excess on a swap is 33mm - over an inch of filament shoved out. Let’s go a bit further.

The volume of the A1 series nozzle is 94mm³. The expected diameter of filament is 1.75mm+/-.03mm. The volume of 33mm of filament is the volume of cylinder πr²h, or π x .875² x 33 which is 79mm³.

So expected variance is for some printers to extrude 84.4% of the volume of the nozzle on a swap while others extrude under 8%? Running the same gcode?

That seems unlikely.

3 Likes
3

I’ve also reported this to Bambu support regarding my H2D - there is a minimum of .1g of flush per filament swap on the same nozzle, even when the flush is set to 0.

I wasn’t able to get my grasp of the issue across clearly to support though and it was just dismissed as normal function.

Any time I have a print with many swaps I feel a deep sense of regret that I purchased an H2D.

4

Only guessing: That could be related to the fact that Bambu can’t (don’t want to?) unload a filament from the nozzle like my Prusa does. Bambu always cuts the filament above the hotend. That means the extruder gears are no longer able to grab that filament piece still sticking in hotend and nozzle.

My guess is they have to poop it out b/c otherwise a retract will no longer be possible.
So until Bambu learns how to unload a filament from the hotend I guess there’s no way around at least some amount of poop.

A printer that constantly pooping is basically Bambu’s trademark. People wouldn’t recognize their printer anymore if at some point there was zero poop. :wink:

1 Like
5

tbf, the P1 and X1 don’t have this problem. It’s only been apparent in any of the quick-swap type nozzles. And if that is the case, then they need to update their slicer to reflect these forthcomings. However, not every A1 is experiencing this. So something is different and wrong and that’s what I’m trying to figure out.

1 Like
6

Totally fair that there should be some amount of waste, but this is beyond what other Bambu series printers will produce from a swap.

I take time to calibrate the amount of purge I need to achieve a clean colour swap and I want to reduce the amount of waste produced. If I have a print with 200-400 colour swaps, there is at least 20-40g of waste that I can do nothing about on my H2D. If I had the same print on a P1S there wouldn’t be that extra purge and I would happily be pumping that into purge objects instead.

7

Here are a few more parts of the conversation since I wrote the original post:

Me:

The issue has not been resolved. Every response has been incredibly dismissive of my concern. My machine is producing substantially more waste than the slicer estimates. I have ran the same g code on my machine that a friend also ran on her A1 and I got twice as much waste. There is something wrong and all I’ve been told is that it’s normal operation. This is not normal or other machines would experience it. No one has offered me direct instruction on how to further diagnose or correct the issue.

Bambu:

Variations between different machines are normal. The amount of filament consumed during preloading assessment is uncontrollable and should be determined based on actual measured values.

Me: (taking the math from illuminator23, thank you!)

Since you are refusing to look at the evidence I have provided previously, I will explain the last print I ran. It had 302 swaps, and the slicer estimated 5.71g of flush. After it was complete, the flush weighed 40g. This is 34g more than expected, which averages to 0.114g additional waste per swap.
A 1kg spool is typically 330 meters of filament. This conveniently also works out to 330mm/g. So 0.1g excess on a swap is 33mm - over an inch of filament shoved out.
Let’s go a bit further.
The volume of the A1 series nozzle is 94mm³. The expected diameter of filament is 1.75mm+/-.03mm. The volume of 33mm of filament is the volume of cylinder πr²h, or π x 0.875² x 33 which is 79mm³.

So expected variance is for some printers to extrude 84.4% of the volume of the nozzle on a swap while others extrude under 8%? Running the same gcode?

That seems unlikely. Can you please confirm it’s expected that the “preloading assessment” consumes the majority of the nozzle volume?

1 Like
8

Can this be right what the slicer calculates?
I believe the H2D and A1 hotends are rather similar.
On a brand new H2D hotend I can move a piece of filament 18 mm into the nozzle. The cut during change is slightly higher and the 18 mm also ignore the amount of the filament already loaded into the nozzle.
So I guess it is a really conservative calculation to assume that at least 20 mm of filament have to be flushed. Also this does not even take into account any remainders on the inside walls of the nozzle.

302 x 20 mm = 6040 mm
Considering the mentioned 330 m/kg the 6040 mm of filament equals 18.3 g of filament. And again, this is extremely conservative and it must be significantly more in reality and unless I miss something it’s basically zero chance that less than 18.3 g of filament must be flushed. Double of that 18 g (depending on the used colors) is absolutely realistic.

So I have no idea how the slicer calculates the 5.71 g for 305 changes unless it all goes into the tower.

9
  1. That’s disregarding the flush volumes set in the slicer, unless your math is assuming its set to zero. The sentence you quoted me on was for a print with purge volumes set to non-zero values.
  2. The tower is a separate column in the slicer filament summary
  3. I had purge objects on the plate too for that example. The 5.71g of flush is what is being expelled off the printer after purge to object was considered.
10

So big discovery: Long Retract before cut (LR) is causing my purge amount to double. I will include the last 2 messages between me and Support to explain…

Bambu replied (finally taking this seriously):

Dear Customer,
Hello! Thank you for your inquiry.
We sincerely apologize for the prolonged delay in addressing your concerns. We have thoroughly reviewed all of your previous communication records. Regarding the purge-related issue you are experiencing during filament changes, would it be convenient for you to re-upload the most recent log files? Specifically, the logs from when you performed the tests outlined in the table. We will examine the control signals sent to the extruder motor during the purge process.
After uploading all the logs, you can also try downgrading the printer’s firmware by 1-2 versions. If the same slicer settings work normally on the P1S with the older firmware, it typically indicates the issue is not software-related. Verifying the behavior on earlier firmware would be very helpful for us to pinpoint the problem. You can perform this downgrade using Handy.
Firmware Downgrade | Bambu Lab Wiki
Wish you a pleasant day!
Best regards,
Bambu Lab Customer Support

I replied with my new findings:

Thank you,
But before I downgrade my A1 (my P1 is behaving as normal), I would like to present something I found to you that is very alarming.
I have discovered that the Long Retraction setting is actually causing a majority of this problem. It is doubling my waste.
I ran two identical prints with 100 color changes. The only thing I changed was going into the filament settings and turning Long Retraction (set to 18) on and off.
I also had the flush volume set to 0, so the slicer did not present me with a “flushed” column in the filament summary.
With Long Retraction turned off the print finished with the expected appearance of color bleed and 6.77g of purge, equaling 0.07g of extra purge per swap, which is reasonable.
When I turned Long Retraction on, and set it to 18, the waste doubled to 12.65g, and resulted in the flush equaling an additional 0.13g per swap, which equals my original concern.
I also ran two purge calibration strips, and when long retraction was turned off, I got similar results to my P1, which does not have any purge issues.
Lastly, I reran a print I had shared with you previously in the PDF document where I got 13g more waste than the slicer estimated. When I turned Long Retraction off, my waste cut in half.
Please see the attached images, including a screenshot of a post from Bambu in April of 2024, claiming that this feature can reduce waste by 25%. This is not what I am experiencing.
Is this feature affecting the Eddy detector? Is it overriding some other feature? Please explain what is going on. I will be sharing this discovery with other communities to see if my experience is isolated.

Imgur link to the 4 images referenced.