Why the slicer-first flow falls apart at fleet scale, and how BamDude's virtual-printer routing solves it without changing your habits.
Slicer talks to the printer directly. You hit Print in BambuStudio or Orca and the file flies to the printer over LAN. In this model BamDude - like any external service - is a passive listener: it catches events from the printer, builds history "where it can," tries to track filament on best-effort.
Works fine when you have one or two printers and the cost of fuzzy history is acceptable. Once your fleet grows - or accurate logs and real spool control start driving business decisions - the slicer-is-in-charge model stops holding water.
Slicer talks to BamDude. BamDude talks to the printers. You slice as usual, but Print routes the file to a BamDude virtual printer in File Manager mode. Inside BamDude you pick which printers run the job and in how many copies.
This is the canonical shape of a fleet manager: one source of truth orchestrating everything else. Bambu Farm Manager and Bambu Handy do the same job - BamDude does it self-hosted, with its own history, swap mode, queue, energy tracking, flexible notifications, and a full access-control system.
10 A1 minis, swap mode, one copy per printer.
That's it. Files dispatch across the fleet, swap macros run, history is written, spools are accounted for.
BamDude steps in for Bambu Farm Manager and Bambu Handy when you want:
BamDude knows how to pick that up after the fact - it'll add it to history and try to fetch the 3MF from the printer. But that path is the exception, not the rule.
Bambu's firmware is closed, which puts a hard ceiling on what an external server can learn after the event. If BamDude is offline at the moment something happens (link drops, server restart, anything), and the operator does 10 reprints by hand in that window - those 10 reprints stay invisible to BamDude forever. No passive listener can recover them with full accuracy, because they were never in the event stream the server got to see.
As long as 3D-printer firmware stays closed, there's only one shape that holds up for a serious fleet:
Slicer ↔ Fleet manager ↔ Printers.
Not slicer talks to printers directly while a manager somewhere listens in. Not three different UIs steering the same printers with no knowledge of each other. One centre that sees everything - because everything passes through it.
Virtual printers exist precisely to make that shift painless: you don't have to break the slice-and-Print habit. You just point the same Print button at the right place.