starred/bambuddy

Fork 0

mirror of https://github.com/maziggy/bambuddy.git synced 2026-05-09 05:35:30 +02:00

[GH-ISSUE #312] [Feature]: Multi‑Printer Slicing & Dispatch from Bambuddy #195

New issue

Closed

opened 2026-05-06 12:27:03 +02:00 by BreizhHardware · 4 comments

BreizhHardware commented

2026-05-06 12:27:03 +02:00

Owner

Originally created by @TheUltimateC0der on GitHub (Feb 9, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/312

Originally assigned to: @maziggy on GitHub.

Problem or Use Case

I run a small “farm” of Bambu printers (X1C, P2S, H2S, and 2× A1), and I frequently need to print the same model multiple times across different machines.

Right now, this means:

Manually opening OrcaSlicer for each job
Selecting the right profile/printer
Slicing the model
Sending it to each printer individually

This is tedious and error‑prone, especially when scaling up and when juggling multiple printers and materials. Since bambuddy already provides a central UI for managing printers, it would be extremely useful if I could also create and dispatch print jobs from there, instead of orchestrating everything manually in the slicer.

Proposed Solution

Add a workflow in bambuddy to upload, slice, and dispatch print jobs to multiple printers:

File upload
Allow uploading a model file (STL / 3MF / STEP) directly from the bambuddy UI.

Profile selection
Let me select an appropriate slicer profile / preset for the job (printer + filament + process profile), ideally per target printer type if needed.

Multi‑printer selection
Let me choose one or more printers (e.g., X1C + both A1s)

Headless slicing via CLI
Use the OrcaSlicer CLI to slice the uploaded model for the selected printer profiles, generating printer‑specific files.

Job dispatch & storage

Send the generated files to the selected printers for immediate printing, using the same mechanism bambuddy already uses to start prints.
Save the sliced job (file + metadata: printer profile, filament, settings) in bambuddy so it can be re‑queued later without needing to re‑slice or re‑upload the model.

This would effectively turn bambuddy into a lightweight “farm dispatcher”: upload once, choose a profile, fan the job out to multiple printers, and keep it available for quick reprints.

Alternatives Considered

No response

Feature Category

File Manager

Priority

Would improve my workflow

Mockups or Examples

Some information about OrcaSlicer CLI:

Contribution

I would be willing to help implement this feature

Checklist

I have searched existing issues to ensure this feature hasn't already been requested

Originally created by @TheUltimateC0der on GitHub (Feb 9, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/312 Originally assigned to: @maziggy on GitHub. ### Problem or Use Case I run a small “farm” of Bambu printers (X1C, P2S, H2S, and 2× A1), and I frequently need to print the same model multiple times across different machines. Right now, this means: - Manually opening OrcaSlicer for each job - Selecting the right profile/printer - Slicing the model - Sending it to each printer individually This is tedious and error‑prone, especially when scaling up and when juggling multiple printers and materials. Since bambuddy already provides a central UI for managing printers, it would be extremely useful if I could also create and dispatch print jobs from there, instead of orchestrating everything manually in the slicer. ### Proposed Solution Add a workflow in bambuddy to **upload, slice, and dispatch print jobs to multiple printers**: **File upload** Allow uploading a model file (STL / 3MF / STEP) directly from the bambuddy UI. **Profile selection** Let me select an appropriate slicer profile / preset for the job (printer + filament + process profile), ideally per target printer type if needed. **Multi‑printer selection** Let me choose one or more printers (e.g., X1C + both A1s) **Headless slicing via CLI** Use the **OrcaSlicer CLI** to slice the uploaded model for the selected printer profiles, generating printer‑specific files. **Job dispatch & storage** - Send the generated files to the selected printers for immediate printing, using the same mechanism bambuddy already uses to start prints. - Save the sliced job (file + metadata: printer profile, filament, settings) in bambuddy so it can be **re‑queued later** without needing to re‑slice or re‑upload the model. This would effectively turn bambuddy into a lightweight “farm dispatcher”: upload once, choose a profile, fan the job out to multiple printers, and keep it available for quick reprints. ### Alternatives Considered _No response_ ### Feature Category File Manager ### Priority Would improve my workflow ### Mockups or Examples Some information about OrcaSlicer CLI: - https://github.com/OrcaSlicer/OrcaSlicer/discussions/8593 - https://github.com/OrcaSlicer/OrcaSlicer/discussions/1603 ### Contribution - [ ] I would be willing to help implement this feature ### Checklist - [x] I have searched existing issues to ensure this feature hasn't already been requested

BreizhHardware

2026-05-06 12:27:04 +02:00

closed this issue
added the
wontfix
label

BreizhHardware commented

2026-05-06 12:27:04 +02:00

Author

Owner

@maziggy commented on GitHub (Feb 10, 2026):

Thanks for the detailed write-up! This is an interesting idea and I can see how it would streamline a multi-printer workflow.

That said, this is a pretty massive undertaking — it would essentially mean building a print farm dispatcher with slicer integration, profile management, job queuing, and multi-printer dispatch. Each of those is a significant feature on its own.

A few specific concerns:

OrcaSlicer CLI stability — Headless slicing support isn't an official stable API yet, so building on top of it could be fragile and hard to maintain across versions and platforms.
Profile management — Slicer profiles are deeply tied to printer type, nozzle, filament, and process settings. Importing/syncing those into Bambuddy would be a large surface area to get right and keep working.

This is something I could see exploring in the future, but it's not something I'd want to take on right now — there's still plenty to do in the core feature set.

If this were ever revisited, a lighter first step might be dispatching pre-sliced 3MF files to multiple printers (skipping the slicing part entirely), since that could build on Bambuddy's existing FTP and print-start capabilities without taking on the slicer integration complexity.

Appreciate the suggestion though — keeping this open for future consideration!

If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!

@maziggy commented on GitHub (Feb 10, 2026): Thanks for the detailed write-up! This is an interesting idea and I can see how it would streamline a multi-printer workflow. That said, this is a pretty massive undertaking — it would essentially mean building a print farm dispatcher with slicer integration, profile management, job queuing, and multi-printer dispatch. Each of those is a significant feature on its own. A few specific concerns: - OrcaSlicer CLI stability — Headless slicing support isn't an official stable API yet, so building on top of it could be fragile and hard to maintain across versions and platforms. - Profile management — Slicer profiles are deeply tied to printer type, nozzle, filament, and process settings. Importing/syncing those into Bambuddy would be a large surface area to get right and keep working. This is something I could see exploring in the future, but it's not something I'd want to take on right now — there's still plenty to do in the core feature set. If this were ever revisited, a lighter first step might be dispatching pre-sliced 3MF files to multiple printers (skipping the slicing part entirely), since that could build on Bambuddy's existing FTP and print-start capabilities without taking on the slicer integration complexity. Appreciate the suggestion though — keeping this open for future consideration! ----- If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/bambuman/bambuddy) — it helps others discover the project!

BreizhHardware commented

2026-05-06 12:27:04 +02:00

Author

Owner

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

Got BambuStudio to run headless. Now trying Orca. If both are running fine in headless mode, I don't see any showstoppers to not implement slicing.

@maziggy commented on GitHub (Feb 20, 2026): Got BambuStudio to run headless. Now trying Orca. If both are running fine in headless mode, I don't see any showstoppers to not implement slicing.

BreizhHardware commented

2026-05-06 12:27:05 +02:00

Author

Owner

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

Orca also works headlessly.

@maziggy commented on GitHub (Feb 20, 2026): Orca also works headlessly.

BreizhHardware commented

2026-05-06 12:27:05 +02:00

Author

Owner

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

Slicing Integration — Not Moving Forward

After prototyping and testing, we've decided not to add built-in slicing to Bambuddy. Here's why:

OrcaSlicer and BambuStudio's CLI interfaces validate slicer profiles far more strictly than their GUIs do. The GUI silently handles many edge cases — sentinel values like -1 meaning "auto", implicit G-code injection (e.g., G92 E0 for relative extruder addressing), cross-profile dependencies between machine and process settings, and more. The CLI simply rejects profiles that don't pass strict validation.

This means that profiles which work perfectly in OrcaSlicer's GUI will fail when passed to the same slicer's CLI. Since there's no documented contract for what the CLI expects vs. what the GUI handles implicitly, integrating slicing becomes a game of whack-a-mole — fix one validation error, hit the next. Every printer model, profile combination, and inheritance chain can surface different issues.

Bambuddy's strength is printer management, file management, and print dispatching. For slicing, the dedicated slicer applications (OrcaSlicer, BambuStudio) are purpose-built — we'd rather complement them than try to replace that functionality with a fragile integration.

@maziggy commented on GitHub (Feb 20, 2026): Slicing Integration — Not Moving Forward After prototyping and testing, we've decided not to add built-in slicing to Bambuddy. Here's why: OrcaSlicer and BambuStudio's CLI interfaces validate slicer profiles far more strictly than their GUIs do. The GUI silently handles many edge cases — sentinel values like -1 meaning "auto", implicit G-code injection (e.g., G92 E0 for relative extruder addressing), cross-profile dependencies between machine and process settings, and more. The CLI simply rejects profiles that don't pass strict validation. This means that profiles which work perfectly in OrcaSlicer's GUI will fail when passed to the same slicer's CLI. Since there's no documented contract for what the CLI expects vs. what the GUI handles implicitly, integrating slicing becomes a game of whack-a-mole — fix one validation error, hit the next. Every printer model, profile combination, and inheritance chain can surface different issues. Bambuddy's strength is printer management, file management, and print dispatching. For slicing, the dedicated slicer applications (OrcaSlicer, BambuStudio) are purpose-built — we'd rather complement them than try to replace that functionality with a fragile integration.

BreizhHardware referenced this issue

2026-05-06 12:34:09 +02:00

[PR #195] [MERGED] Add H2D Pro printer model support #951