TL;DR: A printer that keeps purging after a color change is usually not stuck. One transition in the Flushing volumes table is set to an enormous value, and the machine is dutifully working through it. Open Flushing volumes in Bambu Studio, find the oversized pair, set it back to a normal few-hundred-mm³ value, and reslice. This guide walks that check step by step, covers the 0.2 mm nozzle catch, and points to the one genuine bug that looks identical.
Why does it look like the printer keeps purging forever?
A printer that keeps purging after a filament change is almost always executing a real instruction, not hanging. Bambu Studio stores a flush volume for every color transition in the project. If one pair is set to an extreme value, the printer purges that entire amount before it touches the model, which can take many minutes and looks like an endless purge. The fix is to open the Flushing volumes table, find the oversized transition, lower it, and reslice.
This exact panic shows up on the Bambu forum over and over. In one representative thread, a user watched their two-color first layer stall while the printer purged and purged. Another user pointed them at the flushing table, and the original poster came back with the answer in one line: "It was the super long purge value that made me think it was just continuously purging." Nothing was broken. The slicer had been told to purge a huge amount for that one color pair, and the printer obeyed.
Here's the check to run when your printer keeps purging, in order.
Step 1 — Watch what the nozzle is actually doing
Stand at the printer for one full cycle. If it feeds filament, extrudes at the chute or prime tower, cuts, and repeats without an error on screen, it is purging on purpose. A genuine fault throws an error message or stops motion entirely. Silent, methodical purging means the instruction came from your sliced file.
Step 2 — Open the Flushing volumes table
In Bambu Studio's Prepare tab, look next to the filament list and click Flushing volumes. You get a matrix: one row per loaded color, one column per loaded color. Each cell is how many cubic millimeters get purged when the print switches from the row color to the column color.
Step 3 — Find the transition that's running
Note which color was printing and which one the AMS just loaded. That pair is one specific cell, for example black → gray. Multicolor projects touch lots of cells, but an endless purge on one swap points at one cell.
Step 4 — Judge the number
Typical flush values sit in the low hundreds of mm³. A dark-to-light change runs higher than light-to-dark. If the cell you found holds a four-digit value, that is your "hang". Oversized cells usually come from a stray manual edit, an imported project file that carried someone else's settings, or a flush multiplier that got bumped.
Step 5 — Set a sane value and reslice
Click Re-calculate to let Bambu Studio regenerate the matrix from the filament colors (multiplier at 1.00), or type a reasonable value into the bad cell yourself. Then reslice and reprint. If a light color comes out slightly tinted afterward, nudge that one cell up in steps instead of returning to four digits. For painted models there's a proper method for that: calibrating flushing volumes for a painted 3MF.
Step 6 — Factor in your nozzle size
A 0.2 mm nozzle pushes far less plastic per second than a 0.4 mm nozzle, so the same flush volume takes several times longer. As one responder in the thread put it: "With a .2 nozzle it will take even longer to flush than a .4mm nozzle." If you printed the same file after a nozzle swap and it suddenly keeps purging much longer, the volume didn't change. The flow rate did.
The prime tower shrinks or grows when you reslice. If the tower on your plate looks comically large for a two-color print, that's the flushing table telling on itself before you waste a single gram. Similar first-layer purge complaints in this thread trace back the same way.
The one case where it really is a bug
There's a known Bambu Studio state where the whole matrix reads zero and Re-calculate does nothing, because the flush multiplier field sits at 0.00. That produces the opposite symptom family, colors contaminating each other because the printer barely purges at all. If your table is full of zeros instead of a giant number, you have that bug, and the fix is in our companion post on the flush multiplier stuck at zero.
Painted 3MFs raise the stakes
A hand-painted multicolor model triggers a purge at every color change, and busy layers can have several, so oversized cells cost real time and real filament fast. When you paint a model in Layerpaint, turn on the Show swap bar toggle to see how many color changes each layer will need before you export the 3MF. Fewer swaps means fewer purges, and palette order alone can cut purge waste noticeably on the same paint job.
Common questions
How long should a normal purge take?
On a 0.4 mm nozzle, a few-hundred-mm³ flush finishes in well under a minute. Multiple minutes of continuous purging on one swap means an oversized cell, a 0.2 mm nozzle, or both.
Will lowering the flush volume cause color bleed?
It can, in one direction. Purging too little leaves the old color tinting the new one, worst going from dark to light. Lower the oversized cell to a normal value first, print, and only raise it again in small steps if you see contamination.
Is stopping the print mid-purge safe?
Yes, but you usually don't need to. If you've confirmed the flushing table is sane and it still keeps purging with no progress on the model, cancel, reslice from a fresh project, and send again.
Does this happen on OrcaSlicer too?
Yes. OrcaSlicer uses the same flushing-volume matrix design, so the same check applies cell by cell.
Check the swaps before you slice
Layerpaint runs in your browser and paints per-triangle color on an STL, OBJ, or 3MF, with a live swap bar so you know what you're asking the printer to purge before Bambu Studio ever sees the file. Your first export is free, then $2.97 for your next 3 models or $39.97 unlimited. No subscription. Drop a model on the painter and look at the swap count before your next multicolor print.