[GH-ISSUE #104 ] [Feature]: Send print to multiple printers #53

Docs -> https://wiki.bambuddy.cool/features/print-queue/?h=multi#multi-printer-selection

Author

Owner

@maziggy commented on GitHub (Jan 20, 2026):

Available in branch 0.1.6b10.

@maziggy commented on GitHub (Jan 20, 2026): Available in branch 0.1.6b10. Docs -> https://wiki.bambuddy.cool/features/print-queue/?h=multi#multi-printer-selection

BreizhHardware commented

Author

Owner

@RyanEwen commented on GitHub (Jan 20, 2026):

Amazing, thank you. However my use case unfortunately doesn't allow for us to have the same filaments in each printer (in fact it's purposely not the same, so that we can print the product in different color combinations).

@RyanEwen commented on GitHub (Jan 20, 2026): Amazing, thank you. However my use case unfortunately doesn't allow for us to have the same filaments in each printer (in fact it's purposely not the same, so that we can print the product in different color combinations).

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Jan 20, 2026):

You can just do so. The filament color must not match to start a print.

@maziggy commented on GitHub (Jan 20, 2026): You can just do so. The filament color must not match to start a print.

BreizhHardware commented

Author

Owner

@RyanEwen commented on GitHub (Jan 20, 2026):

Gotcha. Are there docker builds for branches here?

@RyanEwen commented on GitHub (Jan 20, 2026): Gotcha. Are there docker builds for branches here?

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Jan 20, 2026):

Not yet. I'm pushing new docker images only for releases.

docker compose build --no-cache

@maziggy commented on GitHub (Jan 20, 2026): Not yet. I'm pushing new docker images only for releases. docker compose build --no-cache

BreizhHardware commented

Author

Owner

@RyanEwen commented on GitHub (Jan 20, 2026):

You can just do so. The filament color must not match to start a print.

Just had a look and I guess the issue is that it assumes the same slots in each AMS which is not the case.

Here's another s/w for example (and I think Bambu's on farm manager allows this as well):

The print is sliced with Green, and I am able to choose a different color/slot on each machine

@RyanEwen commented on GitHub (Jan 20, 2026): > You can just do so. The filament color must not match to start a print. Just had a look and I guess the issue is that it assumes the same slots in each AMS which is not the case. Here's another s/w for example (and I think Bambu's on farm manager allows this as well): <img width="1523" height="589" alt="Image" src="https://github.com/user-attachments/assets/357bb8bb-5947-4c37-83d8-c070603c3b8e" /> The print is sliced with Green, and I am able to choose a different color/slot on each machine

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Jan 20, 2026):

Yes, that's right. It assumes the same slots. You can have an umlimited number of printers and we would need a modal for each single printer.

@maziggy commented on GitHub (Jan 20, 2026): Yes, that's right. It assumes the same slots. You can have an umlimited number of printers and we would need a modal for each single printer.

BreizhHardware commented

Author

Owner

@RyanEwen commented on GitHub (Jan 20, 2026):

I think there are 2 use cases then. One is for large farms where it is assumed that the same materials are always in the same slot of each AMS. The other case is like ours where the materials are constantly changing position and want to manually choose which slots to use every time we print.

Is there a way we could have the option for either case?

Something I think would help for my case is to move the AMS mapping UI up in the printer selection UI:

I also think it would make sense to first choose the plate (if multi-plate file) before choosing the printer, as that is needed first to do AMS mapping anywya.

@RyanEwen commented on GitHub (Jan 20, 2026): I think there are 2 use cases then. One is for large farms where it is assumed that the same materials are always in the same slot of each AMS. The other case is like ours where the materials are constantly changing position and want to manually choose which slots to use every time we print. Is there a way we could have the option for either case? Something I think would help for my case is to move the AMS mapping UI up in the printer selection UI: <img width="744" height="1186" alt="Image" src="https://github.com/user-attachments/assets/470f5f0a-e720-40ee-832f-601778d1def1" /> I also think it would make sense to first choose the plate (if multi-plate file) before choosing the printer, as that is needed first to do AMS mapping anywya.

BreizhHardware commented

Author

Owner

@RyanEwen commented on GitHub (Jan 20, 2026):

Another small thing is that I think it makes sense not to collapse the mapping UI as it's always good to verify what is happening even if no selection is needed. "Trust, but verify"

@RyanEwen commented on GitHub (Jan 20, 2026): Another small thing is that I think it makes sense not to collapse the mapping UI as it's always good to verify what is happening even if no selection is needed. "Trust, but verify"

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Jan 20, 2026):

If we are really going to add an AMS mapping modal for each selected printer then it certainly is collapsed. Otherwise it will consume too much space.

@maziggy commented on GitHub (Jan 20, 2026): If we are really going to add an AMS mapping modal for each selected printer then it certainly is collapsed. Otherwise it will consume too much space.

BreizhHardware commented

Author

Owner

@RyanEwen commented on GitHub (Jan 20, 2026):

If we are really going to add an AMS mapping modal for each selected printer then it certainly is collapsed. Otherwise it will consume too much space.

I was thinking it would only appear for printers that are chosen, in which case the user needs to see it anyway regardless of space usage. Unless they choose to use the same mapping on all printers (maybe a checkbox for that or something, and then don't show mappings for each one)

@RyanEwen commented on GitHub (Jan 20, 2026): > If we are really going to add an AMS mapping modal for each selected printer then it certainly is collapsed. Otherwise it will consume too much space. I was thinking it would only appear for printers that are chosen, in which case the user needs to see it anyway regardless of space usage. Unless they choose to use the same mapping on all printers (maybe a checkbox for that or something, and then don't show mappings for each one)

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Jan 20, 2026):

What's about:

trying to auto configure if spools with RFID tags are inserted
if not:
default is as it is now (one mapping for all selected printers)
add per printer override button which shows ams mapping modal

@maziggy commented on GitHub (Jan 20, 2026): What's about: - trying to auto configure if spools with RFID tags are inserted if not: - default is as it is now (one mapping for all selected printers) - add per printer override button which shows ams mapping modal

BreizhHardware commented

Author

Owner

@RyanEwen commented on GitHub (Jan 20, 2026):

In our case we purposefully choose mismatched colors (model is green but want to print in pink, blue, etc, as the customer desired) so matching logic doesn't matter much.

I like the idea of an override, but I think it makes the most sense for it to be inline with the printer selection. Perhaps when a printer is selected, the printer card can extend slightly to reveal an option to either use the same filament mapping as all printers, or to use a custom mapping. If the option to use a custom mapping is chosen, ideally the mapping table would appear in that area as well. I realize this grows the height of the dialog, but I think it makes complete sense to do that, as the user is choosing to do it. I don't like the idea of the mappings being in additional dialogs or hidden, etc.

As for the printers that are set to use the shared mapping (which I assume would be the default), then I think you would show the mapping the same as it shows already today

@RyanEwen commented on GitHub (Jan 20, 2026): In our case we purposefully choose mismatched colors (model is green but want to print in pink, blue, etc, as the customer desired) so matching logic doesn't matter much. I like the idea of an override, but I think it makes the most sense for it to be inline with the printer selection. Perhaps when a printer is selected, the printer card can extend slightly to reveal an option to either use the same filament mapping as all printers, or to use a custom mapping. If the option to use a custom mapping is chosen, ideally the mapping table would appear in that area as well. I realize this grows the height of the dialog, but I think it makes complete sense to do that, as the user is choosing to do it. I don't like the idea of the mappings being in additional dialogs or hidden, etc. As for the printers that are set to use the shared mapping (which I assume would be the default), then I think you would show the mapping the same as it shows already today

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Jan 20, 2026):

Use branch 0.1.6b10

@maziggy commented on GitHub (Jan 20, 2026): Use branch 0.1.6b10 <img width="616" height="887" alt="Image" src="https://github.com/user-attachments/assets/c5b3b16e-e6b1-4106-80a3-811f6183040a" /> <img width="542" height="660" alt="Image" src="https://github.com/user-attachments/assets/41655842-8ec8-45a4-b352-f9ce2ec18db7" />

BreizhHardware commented

Author

Owner

@RyanEwen commented on GitHub (Jan 20, 2026):

This is great!!

I think this is a bug: It seems like the option to make it use custom by-default removes the ability to uncheck Custom mapping and use automatic.

@RyanEwen commented on GitHub (Jan 20, 2026): This is great!! I think this is a bug: It seems like the option to make it use custom by-default removes the ability to uncheck Custom mapping and use automatic.

BreizhHardware commented

Author

Owner

@RyanEwen commented on GitHub (Jan 20, 2026):

I think it would be good to expand the mapping by-default when only a single printer is selected. Users are not trusting and will want to see that everything is mapped correctly, even if it is always correct. It doesn't take much space either if it's just a single printer anyway, IMO.

EDIT: Just noticed that the mapping does expand by-default for single printer prints, when the new "expand custom mapping by default" setting is enabled. So the issue is perhaps that the setting description is inaccurate as it says it's for when printing to multiple printers, but also applies to single printer prints.

@RyanEwen commented on GitHub (Jan 20, 2026): I think it would be good to expand the mapping by-default when only a single printer is selected. Users are not trusting and will want to see that everything is mapped correctly, even if it is always correct. It doesn't take much space either if it's just a single printer anyway, IMO. EDIT: Just noticed that the mapping does expand by-default for single printer prints, when the new "expand custom mapping by default" setting is enabled. So the issue is perhaps that the setting description is inaccurate as it says it's for when printing to multiple printers, but also applies to single printer prints.

BreizhHardware commented