The first part of this series ended on a genuinely promising note: two BCMU units flashed with the AMS A and AMS B firmware, the A1 switched from AMS Lite mode to AMS mode, and the printer’s own interface confirming both units were detected and ready. That was the easy part. This is part two, and it is also the last part, because after several months of genuinely trying to make this work, I have decommissioned the setup entirely. This post is the honest account of why — the specific technical problems, what I actually had to do to get it running at all, the money and time that went into it, and why I concluded that four reliable colours across two printers beats eight unreliable colours on one.
Yes, it genuinely works — as a proof of concept
Let me be clear about this before getting into everything that went wrong, because it is worth stating plainly: two BCMU units on one A1 is absolutely possible, and it is not just me claiming this. Both units need their firmware flashed specifically as AMS A and AMS B respectively — critically, neither can be running the AMS Lite firmware variant, since that uses a different communication protocol that the dual-unit chained configuration does not support, exactly as flagged in part one. Plenty of people are running a single BCMU on their A1 as a straightforward AMS Lite replacement, and there are several YouTube videos out there showing people running two BCMUs for a genuine eight-colour total. The reality for me, specifically: does the printer recognise both units correctly? Yes, without any issue at all. That part of the puzzle genuinely works as advertised, and if all this post covered was “does the hardware detect correctly,” it would be a straightforwardly positive result. The rest of the story is where things become considerably more complicated.
The filament path problem nobody warns you about properly
This is where the real complexity starts, and it is the first thing I would flag to anyone considering this setup. You need at least one 4-to-1 PTFE filament adapter to actually merge four filament channels into a single feed path heading toward the toolhead — realistically, running two full BCMU units, you need two of these adapters, one per unit. This is not a trivial add-on part. It is a genuine additional point in the filament path with its own geometry, its own friction characteristics, and its own failure modes, and it sits on top of everything the PTFE tube guide already covers about wear and feed reliability in a standard single-tube setup. Doubling the number of merge points in the path is doubling the number of places something can go slightly wrong.
What the adapter is actually doing mechanically is worth understanding, because it explains a lot of what follows in this post. On a stock AMS Lite, each of the four filament channels has its own dedicated, short, direct path all the way to the toolhead — there is no merging, no shared bottleneck, and no single point where four separate filaments are being asked to occupy the same physical tube one after another. A 4-to-1 adapter deliberately creates exactly that bottleneck, funnelling four independent inputs down into one shared output tube. That is a sensible way to physically connect two BCMU units to a printer that only has one toolhead feed port, but it introduces a genuinely different mechanical reality from anything the AMS Lite was ever designed around, and every downstream problem in this post traces back to that one structural compromise.
Retraction: not the small number you are used to
This is the single detail that most differentiates a dual-BCMU setup from the AMS Lite experience the A1 ships with, and it needs to be understood properly before anyone attempts this. On a standard AMS Lite, retraction during a colour swap is a few centimetres — the physical distance between the AMS unit and the toolhead is short, and the retraction settings post covers why that short, direct path keeps retraction distances modest even during a full filament change rather than just a travel move.
With a dual-BCMU setup and a 4-to-1 adapter in the path, retraction needs to be far more aggressive — realistically in the region of 15-20cm, depending on exactly where the 4-to-1 adapter physically sits relative to the toolhead. That is not a settings tweak. That is a fundamentally different scale of retraction than anything covered in the standard retraction guidance on this site, and it exists purely because the filament genuinely has to travel that much further back through the merged path before the next colour can be fed cleanly through the same shared tube section. Every single colour swap on this setup was adding several seconds purely to accommodate that much longer retraction and re-feed cycle — multiply that across a genuinely complex eight-colour print with dozens or hundreds of colour changes, and the total time overhead becomes considerable before you have even accounted for anything going wrong.
It is worth being specific about what that overhead actually looked like in practice rather than leaving it as an abstract “a few seconds.” A retraction and re-feed cycle at 15-20cm, run at a sensible retraction speed rather than pushed dangerously fast, adds a genuinely noticeable pause to every colour swap — and unlike the AMS Lite’s short retraction, this is long enough that you can actually watch it happen if you are stood beside the printer. On a print with a modest number of colour changes, that overhead is a minor curiosity. On the kind of genuinely complex, high-swap-count multicoloured model this whole eight-colour project was meant to enable, it compounds into a real and substantial addition to total print time — on top of, rather than instead of, the purge waste and time overhead already covered in the hidden workflow cost post for standard single-nozzle multicolour printing generally.
Physical placement: the problem that never really got solved properly
I placed both BCMU units on top of the printer, which was the straightforward part. The genuinely difficult problem was where and how to place eight actual spools of filament feeding into those two units. My workshop space is limited, and four spools on each side of the printer was the logical layout — but that immediately created a second problem I had not fully anticipated: I needed to find or design a suitable spool holder for each individual spool, since a standard single-spool holder setup does not scale cleanly to eight independent feed points crowded around one machine.
The false starts here are worth being honest about, because they cost real time before I landed on something workable. The first attempt used simple, fixed, non-rotating spool mounts — the kind of basic holder that works perfectly well for a single external spool feeding an A2L directly. With eight spools crowded into a limited footprint, that approach produced exactly the tangling and drag problems you would expect: adjacent spools interfering with each other’s unwind path, filament from one spool occasionally catching against the frame of the holder next to it, and a general sense that the whole arrangement was one careless movement away from a genuine snarl. A second attempt tried simple rotating holders without any tension management at all, which solved the interference problem between adjacent spools but reintroduced a different one — a spool with no tension control sitting slack after a long retraction simply unwinds a little further than it should, leaving loose coils that then feed unevenly on the next pull.
After those false starts I established something that should probably have been obvious from the start: you genuinely need spool holders with auto-rewind specifically for this kind of setup. Without auto-rewind, a spool that has just been retracted 15-20cm during a colour swap sits with slack filament loosely wound rather than properly tensioned — and that slack is exactly the condition that produces tangles and feed inconsistency the next time that specific colour is called for. This connects directly to the drybox and spool storage work covered in the BMCU drybox post earlier in this series — auto-rewind was already part of that build’s reasoning, and it turned out to be even more essential once the actual retraction distances involved became clear. Sourcing, printing, and fitting eight individual auto-rewind holders, rather than the simpler mounts I started with, was itself a small project within the larger project, and it is not a step worth skipping if anyone else attempts this.
The reliability problem that actually ended it
This was a genuinely fussy setup. It took real time and effort to get everything running together — the firmware, the 4-to-1 adapters, the retraction distances, the auto-rewind holders — and once it was all assembled, the honest overall verdict is that it was unreliable. Regularly enough to be a genuine problem rather than an occasional annoyance, there would be a misfeed somewhere in the extended path. The BCMU’s own retraction handling was not perfect at this scale, and the combination of a longer path, a mechanical merge point, and a system genuinely at the edge of what it was originally designed to do meant we would periodically end up in a proper pickle mid-print — a failed colour swap, a tangled spool, a jam somewhere in the 4-to-1 adapter that needed manual intervention to clear.
What made this genuinely frustrating rather than merely inconvenient was the unpredictability of it. A print that had run through the same colour sequence cleanly the day before would fail at a different point entirely on the next attempt, with no obvious change in filament, settings, or environment to explain the difference. That kind of intermittent, hard-to-reproduce failure is considerably more draining to troubleshoot than a consistent one, because there is no single fix to chase — every failure needed its own fresh diagnosis, and by the time I had worked through several of these in succession, the pattern that emerged was not “here is the one thing to fix” but “this system is operating close enough to its own limits that almost anything can tip it over.” That is not a sustainable place to run a machine you actually want to rely on for finished projects rather than ongoing experimentation.
The firmware update that was the final straw
This is worth flagging specifically because it is exactly the kind of ongoing maintenance burden that a community-driven workaround on top of proprietary hardware always carries, and it connects directly to the caution raised at the end of part one about Bambu Lab tightening AMS compatibility over time. I updated the A1’s own firmware in the normal course of keeping the machine current — nothing unusual, just a standard update. That update then required both BCMU units to be reflashed with their own latest compatible firmware before the dual-unit setup would work correctly again. That is not a one-time setup cost. It is an ongoing tax on every future Bambu firmware update, and it was the specific moment I decided the whole project had stopped being worth the tinkering it demanded.
The broader pattern this illustrates is worth naming explicitly, because it is not unique to the BCMU specifically. Any community-maintained hardware or firmware sitting on top of a manufacturer’s own proprietary, actively-updated platform is inherently exposed to exactly this kind of maintenance debt — every official update is a potential compatibility break for the unofficial layer built alongside it, and keeping both in sync becomes a recurring task rather than a one-time setup. This is the same underlying tension covered in the closed versus open ecosystems post from a different angle — a genuinely open platform with community-maintained extensions does not eliminate this risk entirely, but a closed platform that periodically tightens its own compatibility surface makes it considerably worse, because the community side has no visibility into what the next official update might quietly break.
Dual BCMU versus two AMS Lites: the honest comparison
| Factor | Dual BCMU on one A1 | Single AMS Lite per printer (A1 + A2L) |
|---|---|---|
| Maximum colours | 8, in theory | 4 per machine, 8 total across two prints run separately |
| Retraction per swap | 15-20cm, several seconds added per colour change | A few centimetres, minimal added time |
| Reliability in practice | Genuinely unreliable — regular misfeeds and jams | Reliable, officially supported, and well understood |
| Firmware maintenance | Ongoing — every A1 firmware update risks breaking BCMU compatibility | None — standard Bambu firmware update path |
| Physical setup complexity | High — two units, two 4-to-1 adapters, eight spool holders with auto-rewind | Low — standard AMS Lite mounting, one per machine |
| Cost | Two BCMU units, adapters, and custom holders — genuinely cheap hardware, but real time investment | One additional AMS Lite unit at full retail price |
| Fits current workflow | Built for genuinely complex single-object multicolour work | Fits a workflow now dominated by multi-part colour separation rather than single-object multicolour |
Where I landed
After that firmware episode, I decommissioned the dual-BCMU pair entirely. In its place: a single genuine Bambu AMS Lite went to the A2L, and the original AMS Lite went back onto the A1, giving me four colours reliably on each machine rather than a theoretical eight colours unreliably on one. That is the actual reality I have settled into, and it works considerably better for how I actually print. It keeps both machines inside a reliable, officially supported Bambu configuration rather than a community workaround that breaks every time Bambu ships an update. And, honestly, it matches how I actually work these days more closely than eight-colour single-nozzle printing ever would have — most of what comes off these printers now is multi-part, colour-separated builds, exactly the workflow covered in the multi-part printing post, rather than genuinely complex single-object multi-colour jobs that would actually benefit from eight simultaneous channels.
That last point is worth dwelling on, because it is not a coincidence that my own printing habits shifted in this direction over the same period this experiment was running. Splitting a model into separately printed, single-colour parts sidesteps the entire category of problem this whole BCMU project was trying to solve at the hardware level — no purge waste, no extended retraction path, no eight-spool juggling act, just individually reliable single-colour prints assembled afterward. The Nutcracker build and the various seasonal figures covered elsewhere on this site are the direct beneficiaries of that shift, and having lived through the dual-BCMU experiment specifically has made me considerably more confident that multi-part is the right default for complex colour work on this hardware, rather than something to fall back on only when a genuine multicolour AMS approach proves impractical.
What I would tell someone considering this
If you have considerably more physical space than a typical home workshop desk — enough to properly spread eight spools out with real clearance between them rather than crowding them into a tight footprint — and genuinely more patience for ongoing firmware maintenance than I turned out to have, a reliable version of this setup may well be achievable. The core mechanism works. The printer detects both units correctly, the AMS-mode switch functions as documented, and the eight-colour concept is not a fiction. What it demands in return is a level of ongoing fiddling that a standard, officially supported Bambu configuration simply does not ask of you, and that trade-off is the entire decision. If reliability and the ability to just start a print and walk away matter more to you than the theoretical colour count, my own conclusion stands: stick with the AMS Lite the machine actually ships with, or run a second one on a second printer, and lean on multi-part printing for anything that genuinely needs more colours than four in a single object.
The honest summary
This was a genuinely interesting experiment, and I do not regret trying it — it was something to properly tinker with, and the process taught me a lot about how the AMS protocol, retraction, and the physical filament path actually interact that I would not have learned otherwise. But it tried my patience more than it rewarded it. With more physical space to spread the eight spools out properly, and more time to iterate on the specific PTFE routing and adapter placement, I suspect a genuinely reliable version of this is achievable for someone with the patience for it. For me, reliability is the actual priority, and a fussy eight-colour setup that periodically jams mid-print does not deliver that. Four colours per machine, on two properly supported printers, running the setup Bambu actually engineered and continues to maintain, is the answer I have settled on — and given how much of my current output is multi-part rather than multi-colour anyway, it is genuinely the better fit for how this workshop actually operates now.
