[GH-ISSUE #752] [Feature]: Staggered batch start for multi-printer jobs (start in groups with interval) #500

Closed
opened 2026-05-06 12:30:20 +02:00 by BreizhHardware · 14 comments

Originally created by @UVCXanth on GitHub (Mar 18, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/752

Originally assigned to: @maziggy on GitHub.

Problem or Use Case

When sending a print job to multiple printers at once, all printers start simultaneously.

For small setups this is fine, but in larger farms (10+ printers) this creates a significant power spike, especially during bed heating.

In my setup this leads to:

high peak load on inverter and electrical system

risk of tripping breakers

reduced overall system stability

Current workaround is manual:

start printers in small groups (2–3 at a time)

wait for heating peak to pass

start next group

This works, but requires constant manual control and breaks the “one-click multi-printer workflow”.

Proposed Solution

Add an optional staggered start mode for multi-printer jobs.

When sending a job to multiple printers, allow the user to define:

Group size — how many printers start at once

Interval (minutes) — delay between groups

Example:

10 printers selected

Group size: 2

Interval: 5 minutes

Behavior:

2 printers start immediately

next 2 after 5 minutes

next 2 after 10 minutes

and so on

Implementation can reuse existing queue system:

create queue entries per printer

assign scheduled_time based on group index

no need for complex scheduling logic

This keeps behavior simple and predictable.

Alternatives Considered

Manual staggered start (current approach)

works, but requires constant attention

not scalable as farm grows

External scripts using API

possible, but complex and fragile

requires handling printer configs, AMS mapping, presets, etc.

duplicates logic already present in Bambuddy

Full automation (based on power usage / sensors)

unsafe without reliable “printer ready” detection

risk of starting print on uncleared build plate

Because of this, a simple built-in staggered start is the most reliable and practical solution.

Feature Category

Print Queue & Scheduling

Priority

Would improve my workflow

Mockups or Examples

No response

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 @UVCXanth on GitHub (Mar 18, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/752 Originally assigned to: @maziggy on GitHub. ### Problem or Use Case When sending a print job to multiple printers at once, all printers start simultaneously. For small setups this is fine, but in larger farms (10+ printers) this creates a significant power spike, especially during bed heating. In my setup this leads to: high peak load on inverter and electrical system risk of tripping breakers reduced overall system stability Current workaround is manual: start printers in small groups (2–3 at a time) wait for heating peak to pass start next group This works, but requires constant manual control and breaks the “one-click multi-printer workflow”. ### Proposed Solution Add an optional staggered start mode for multi-printer jobs. When sending a job to multiple printers, allow the user to define: Group size — how many printers start at once Interval (minutes) — delay between groups Example: 10 printers selected Group size: 2 Interval: 5 minutes Behavior: 2 printers start immediately next 2 after 5 minutes next 2 after 10 minutes and so on Implementation can reuse existing queue system: create queue entries per printer assign scheduled_time based on group index no need for complex scheduling logic This keeps behavior simple and predictable. ### Alternatives Considered Manual staggered start (current approach) works, but requires constant attention not scalable as farm grows External scripts using API possible, but complex and fragile requires handling printer configs, AMS mapping, presets, etc. duplicates logic already present in Bambuddy Full automation (based on power usage / sensors) unsafe without reliable “printer ready” detection risk of starting print on uncleared build plate Because of this, a simple built-in staggered start is the most reliable and practical solution. ### Feature Category Print Queue & Scheduling ### Priority Would improve my workflow ### Mockups or Examples _No response_ ### 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:30:20 +02:00
Author
Owner

@maziggy commented on GitHub (Mar 24, 2026):

Before we commit to building this, I'd like to gauge community interest. If you'd find this feature useful, please give this issue a thumbs up (👍) reaction so we can prioritize accordingly.

<!-- gh-comment-id:4116110055 --> @maziggy commented on GitHub (Mar 24, 2026): Before we commit to building this, I'd like to gauge community interest. If you'd find this feature useful, please give this issue a thumbs up (👍) reaction so we can prioritize accordingly.
Author
Owner

@maziggy commented on GitHub (Mar 26, 2026):

Before we start building, a few questions for the community:

  1. Stagger settings scope — Should the group size and interval be saved as a default preference (in settings), or set each time you send a batch? Or both (defaults you can override per batch)?
  2. Failure handling — If a printer in an earlier group fails or errors out, should the later groups still start on schedule? Or should the whole batch pause?
  3. Interval timing — Should the delay be measured from when the previous group starts printing, or from when it finishes heating? Start-based is simpler and more predictable, but heat-based could be more useful for the power spike concern.
  4. Queue integration — Should this only apply when sending a job to multiple printers at once, or should it also work for queued jobs that target different printers?

Any other edge cases or preferences from people running larger farms would be helpful.

<!-- gh-comment-id:4136282975 --> @maziggy commented on GitHub (Mar 26, 2026): Before we start building, a few questions for the community: 1. Stagger settings scope — Should the group size and interval be saved as a default preference (in settings), or set each time you send a batch? Or both (defaults you can override per batch)? 2. Failure handling — If a printer in an earlier group fails or errors out, should the later groups still start on schedule? Or should the whole batch pause? 3. Interval timing — Should the delay be measured from when the previous group starts printing, or from when it finishes heating? Start-based is simpler and more predictable, but heat-based could be more useful for the power spike concern. 4. Queue integration — Should this only apply when sending a job to multiple printers at once, or should it also work for queued jobs that target different printers? Any other edge cases or preferences from people running larger farms would be helpful.
Author
Owner

@UVCXanth commented on GitHub (Mar 26, 2026):

My preference for a first implementation:

  1. Stagger settings scope:
    Both. Farm users usually have a common default (for example 2 printers every 5 minutes), but sometimes need to override it per batch depending on printer type, material, or current power constraints.

  2. Failure handling:
    Default should be to continue with later groups even if one printer in an earlier group fails. One problematic printer should not block the whole farm.
    An optional toggle to pause remaining groups on failure would be useful for more cautious workflows.

  3. Interval timing:
    Start-based, not heat-based.
    Start-based is predictable, easy to understand, and much simpler to implement reliably. Heat-based sounds attractive, but introduces more complexity and edge cases.

  4. Queue integration:
    For the first version, I would keep this only for multi-printer send / batch launch.
    Applying it to general queue workflows across multiple printers feels like a second step and adds a lot more complexity.

Additional suggestions:

  • The printer grouping order should be explicit and predictable (selection order or sorted order).
  • A preview of groups/times before submitting would be very helpful.
  • Existing readiness / clear-plate checks should still apply per printer.
  • I would keep this feature intentionally simple: deterministic grouped delayed starts, without power-aware automation.
<!-- gh-comment-id:4137526974 --> @UVCXanth commented on GitHub (Mar 26, 2026): My preference for a first implementation: 1. Stagger settings scope: Both. Farm users usually have a common default (for example 2 printers every 5 minutes), but sometimes need to override it per batch depending on printer type, material, or current power constraints. 2. Failure handling: Default should be to continue with later groups even if one printer in an earlier group fails. One problematic printer should not block the whole farm. An optional toggle to pause remaining groups on failure would be useful for more cautious workflows. 3. Interval timing: Start-based, not heat-based. Start-based is predictable, easy to understand, and much simpler to implement reliably. Heat-based sounds attractive, but introduces more complexity and edge cases. 4. Queue integration: For the first version, I would keep this only for multi-printer send / batch launch. Applying it to general queue workflows across multiple printers feels like a second step and adds a lot more complexity. Additional suggestions: - The printer grouping order should be explicit and predictable (selection order or sorted order). - A preview of groups/times before submitting would be very helpful. - Existing readiness / clear-plate checks should still apply per printer. - I would keep this feature intentionally simple: deterministic grouped delayed starts, without power-aware automation.
Author
Owner

@maziggy commented on GitHub (Mar 28, 2026):

Available/Fixed in branch dev and available with the next release or daily build.

Unfortunately I'm not able to test, because I don't have multiple printers of the same model. May I ask you please to test and let me know howe it goes? A screenshots from the queuing options would also be nice. Cannot check if the layout is correct.

Docs -> https://wiki.bambuddy.cool/features/print-queue/?h=stag#staggered-batch-start

Image
<!-- gh-comment-id:4147866650 --> @maziggy commented on GitHub (Mar 28, 2026): Available/Fixed in branch dev and available with the next release or daily build. Unfortunately I'm not able to test, because I don't have multiple printers of the same model. May I ask you please to test and let me know howe it goes? A screenshots from the queuing options would also be nice. Cannot check if the layout is correct. Docs -> https://wiki.bambuddy.cool/features/print-queue/?h=stag#staggered-batch-start <img width="651" height="383" alt="Image" src="https://github.com/user-attachments/assets/80272466-15ee-4944-9b00-3ded6f75ed73" />
Author
Owner

@UVCXanth commented on GitHub (Mar 29, 2026):

Thanks, I tested it on a real farm setup.

The stagger logic itself is useful, but the current UX does not fully solve the workflow problem yet.

Main issues from real usage:

  1. Entry point / workflow
    Right now stagger is only available through:
    Schedule Print -> ASAP -> Stagger printer starts

For farm usage, this is not the ideal place.
What I actually expected was:
Print -> [x] Stagger printer starts

In other words, staggered start should feel like a normal print action with an optional launch mode, not like a scheduling-only workflow.

  1. Clear plate / ready confirmations
    The current implementation still requires repeated per-printer confirmation that the plate is cleared / printer is ready, via the Printers page.

This is understandable from a safety perspective, but it reduces the practical benefit a lot.

The desired workflow for farm use is:

  • I physically check the selected printers
  • I press Print once for all selected printers
  • I enable staggered start
  • I leave it running without further confirmations

Right now staggered start still depends on multiple later confirmations, so it does not yet deliver the “start once and walk away” experience.

  1. Possible misunderstanding on my side
    It's also possible that I’m not fully understanding the intended queue workflow here, since I wasn’t really using the queue before.

My primary workflow has always been the simple “Print” action:
select printers → press Print → jobs start immediately.

This worked very well for batch production of identical parts and required minimal interaction.

So I might be missing something in how stagger is supposed to be used together with the queue, but from my current understanding it adds extra steps compared to the original Print flow.

Suggestion:

  • make stagger available directly in the normal Print flow
  • consider a batch-level “all printers are ready” confirmation instead of repeated per-printer confirmations

So in short:

  • the stagger logic itself is good
  • but the current UX does not yet match the typical farm workflow
<!-- gh-comment-id:4150074751 --> @UVCXanth commented on GitHub (Mar 29, 2026): Thanks, I tested it on a real farm setup. The stagger logic itself is useful, but the current UX does not fully solve the workflow problem yet. Main issues from real usage: 1. Entry point / workflow Right now stagger is only available through: Schedule Print -> ASAP -> Stagger printer starts For farm usage, this is not the ideal place. What I actually expected was: Print -> [x] Stagger printer starts In other words, staggered start should feel like a normal print action with an optional launch mode, not like a scheduling-only workflow. 2. Clear plate / ready confirmations The current implementation still requires repeated per-printer confirmation that the plate is cleared / printer is ready, via the Printers page. This is understandable from a safety perspective, but it reduces the practical benefit a lot. The desired workflow for farm use is: - I physically check the selected printers - I press Print once for all selected printers - I enable staggered start - I leave it running without further confirmations Right now staggered start still depends on multiple later confirmations, so it does not yet deliver the “start once and walk away” experience. 3. Possible misunderstanding on my side It's also possible that I’m not fully understanding the intended queue workflow here, since I wasn’t really using the queue before. My primary workflow has always been the simple “Print” action: select printers → press Print → jobs start immediately. This worked very well for batch production of identical parts and required minimal interaction. So I might be missing something in how stagger is supposed to be used together with the queue, but from my current understanding it adds extra steps compared to the original Print flow. Suggestion: - make stagger available directly in the normal Print flow - consider a batch-level “all printers are ready” confirmation instead of repeated per-printer confirmations So in short: - the stagger logic itself is good - but the current UX does not yet match the typical farm workflow
Author
Owner

@maziggy commented on GitHub (Mar 30, 2026):

Your request description is refering to Print Queue & Scheduling, so it was not clear to me that you are talking about manual prints.

Regarding the Clear plate / ready confirmations: the current implementation was requested and is used by users. So we cannot remove it. We could add a setting to enable/disable it.

To avoid unneccessary work and to make sure that I understand your requests, please elaborate your exact desired workflow.

<!-- gh-comment-id:4152689282 --> @maziggy commented on GitHub (Mar 30, 2026): Your request description is refering to Print Queue & Scheduling, so it was not clear to me that you are talking about manual prints. Regarding the Clear plate / ready confirmations: the current implementation was requested and is used by users. So we cannot remove it. We could add a setting to enable/disable it. To avoid unneccessary work and to make sure that I understand your requests, please elaborate your exact desired workflow.
Author
Owner

@UVCXanth commented on GitHub (Mar 30, 2026):

Thanks for the feedback! To make sure we are on the same page, let me describe the typical "farm day" workflow. This should explain why the current Queue-based implementation feels a bit disconnected from the actual process.

The "Physical" Workflow (The Farm Reality):

Preparation: I physically walk to the printers (I have 5x P1S and 5x A1 mini, often running 10+ jobs a day). I remove finished parts, clean the plates, and apply 3D adhesive/lacquer where needed. Sometimes I even take the plates to the freezer to help remove stubborn parts.

Verification: At this exact moment, I have 100% manual confirmation that all selected printers are ready and plates are empty.

Execution: I return to my PC or tablet, select the printers, and want to hit the big green "Print" button.

Why the current "Queue + Per-Printer Confirmation" is a bottleneck:

The Location issue: Right now, I have to go into a separate "Schedule" menu to find the Stagger settings. It adds extra clicks to a routine I do many times a day.

The "Nagging" issue: If I use the current staggered start, I still have to wait for the UI to pop up a "Clear Plate" confirmation for each printer when its timer hits. If I have 10–15 printers, I can't just "start and walk away" to my other tasks (like fixing my car or managing the server room).

Proposed "Dream" Implementation:

Integration: Add the Stagger options (Group Size / Interval) directly into the standard Print Dialog.

Batch Confirmation: Add a single checkbox in that same Print Dialog: [x] I have manually verified all plates are clear.

If checked, Bambuddy should trust the user and skip all individual "Clear Plate" pop-ups for this specific batch.

Summary: I don't want to remove the safety checks from the app entirely — they are great for remote prints. But for a "local" farm workflow, where I just came back from the printers, I need a way to say: "I've checked everything, now please just handle the power-safe staggered launch while I go do other work."

If you have any questions about the farm operations — I would be more than happy to answer them. If necessary, I can record a video of the workflow or take photos of the setup to show how it looks "in the field."

Thanks again for being so open to feedback and for building such an amazing tool!

<!-- gh-comment-id:4154483066 --> @UVCXanth commented on GitHub (Mar 30, 2026): Thanks for the feedback! To make sure we are on the same page, let me describe the typical "farm day" workflow. This should explain why the current Queue-based implementation feels a bit disconnected from the actual process. The "Physical" Workflow (The Farm Reality): Preparation: I physically walk to the printers (I have 5x P1S and 5x A1 mini, often running 10+ jobs a day). I remove finished parts, clean the plates, and apply 3D adhesive/lacquer where needed. Sometimes I even take the plates to the freezer to help remove stubborn parts. Verification: At this exact moment, I have 100% manual confirmation that all selected printers are ready and plates are empty. Execution: I return to my PC or tablet, select the printers, and want to hit the big green "Print" button. Why the current "Queue + Per-Printer Confirmation" is a bottleneck: The Location issue: Right now, I have to go into a separate "Schedule" menu to find the Stagger settings. It adds extra clicks to a routine I do many times a day. The "Nagging" issue: If I use the current staggered start, I still have to wait for the UI to pop up a "Clear Plate" confirmation for each printer when its timer hits. If I have 10–15 printers, I can't just "start and walk away" to my other tasks (like fixing my car or managing the server room). Proposed "Dream" Implementation: Integration: Add the Stagger options (Group Size / Interval) directly into the standard Print Dialog. Batch Confirmation: Add a single checkbox in that same Print Dialog: [x] I have manually verified all plates are clear. If checked, Bambuddy should trust the user and skip all individual "Clear Plate" pop-ups for this specific batch. Summary: I don't want to remove the safety checks from the app entirely — they are great for remote prints. But for a "local" farm workflow, where I just came back from the printers, I need a way to say: "I've checked everything, now please just handle the power-safe staggered launch while I go do other work." If you have any questions about the farm operations — I would be more than happy to answer them. If necessary, I can record a video of the workflow or take photos of the setup to show how it looks "in the field." Thanks again for being so open to feedback and for building such an amazing tool!
Author
Owner

@maziggy commented on GitHub (Mar 31, 2026):

Available/Fixed in branch dev and available with the next release or daily build.

Since I don't have multiple printers of the same modell, I cannot test. May I ask you please to test and let me know how it goes?

<!-- gh-comment-id:4161189826 --> @maziggy commented on GitHub (Mar 31, 2026): Available/Fixed in branch dev and available with the next release or daily build. Since I don't have multiple printers of the same modell, I cannot test. May I ask you please to test and let me know how it goes?
Author
Owner

@UVCXanth commented on GitHub (Apr 3, 2026):

Thanks a lot! I’ve tested the new implementation in the dev branch on my farm, and it works perfectly. This is exactly the workflow I was looking for — being able to configure the stagger and confirm plate readiness directly in the Print dialog is a huge time-saver for a multi-printer setup.

The power load is now much more manageable, and the "start and walk away" experience is finally there.

One small follow-up request: it would be great to have a global toggle in the settings to completely disable the "Clear Plate & Start Next" confirmation button/popup (the one shown in my screenshot). While it's a good safety feature for some, in a high-volume farm environment where I've already checked the plates physically, it’s the last remaining "extra click" I’d love to optionalize.

Image

Thanks again for being so responsive and for such an amazing tool!

<!-- gh-comment-id:4182267080 --> @UVCXanth commented on GitHub (Apr 3, 2026): Thanks a lot! I’ve tested the new implementation in the dev branch on my farm, and it works perfectly. This is exactly the workflow I was looking for — being able to configure the stagger and confirm plate readiness directly in the Print dialog is a huge time-saver for a multi-printer setup. The power load is now much more manageable, and the "start and walk away" experience is finally there. One small follow-up request: it would be great to have a global toggle in the settings to completely disable the "Clear Plate & Start Next" confirmation button/popup (the one shown in my screenshot). While it's a good safety feature for some, in a high-volume farm environment where I've already checked the plates physically, it’s the last remaining "extra click" I’d love to optionalize. <img width="455" height="141" alt="Image" src="https://github.com/user-attachments/assets/a74dcd2f-5a4d-4b83-a394-01c075745000" /> Thanks again for being so responsive and for such an amazing tool!
Author
Owner

@maziggy commented on GitHub (Apr 3, 2026):

It's already there.

Image

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

<!-- gh-comment-id:4182335877 --> @maziggy commented on GitHub (Apr 3, 2026): It's already there. <img width="915" height="205" alt="Image" src="https://github.com/user-attachments/assets/a355aef4-c9ae-44c6-afca-5185331bc17d" /> ----- If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/maziggy/bambuddy) — it helps others discover the project!
Author
Owner

@UVCXanth commented on GitHub (Apr 3, 2026):

Thanks for the quick update! I see the settings are there, but I've run into a small issue.

Even with the "manual verification" checked (or the safety settings disabled), the "Clear Plate & Start Next" button (shown in the screenshot) still pops up in the queue/status area. It seems like the app doesn't fully "trust" the global setting yet and still asks for that final manual click before actually sending the job to the printer.

Image
<!-- gh-comment-id:4182362235 --> @UVCXanth commented on GitHub (Apr 3, 2026): Thanks for the quick update! I see the settings are there, but I've run into a small issue. Even with the "manual verification" checked (or the safety settings disabled), the "Clear Plate & Start Next" button (shown in the screenshot) still pops up in the queue/status area. It seems like the app doesn't fully "trust" the global setting yet and still asks for that final manual click before actually sending the job to the printer. <img width="756" height="217" alt="Image" src="https://github.com/user-attachments/assets/b90abb6d-25ec-44e6-b416-f340bee6e57e" />
Author
Owner

@maziggy commented on GitHub (Apr 3, 2026):

Available/Fixed in branch dev and available with the next release or daily build. Please let e know if it works now.

<!-- gh-comment-id:4182781678 --> @maziggy commented on GitHub (Apr 3, 2026): Available/Fixed in branch dev and available with the next release or daily build. Please let e know if it works now.
Author
Owner

@UVCXanth commented on GitHub (Apr 8, 2026):

Thanks for the fix! I’ve been testing it for the last 4 days on my farm, and everything works perfectly now. The 'start and walk away' experience is finally 100% complete, and the power management is spot on. Thank you so much for your hard work and responsiveness — this is a game-changer for my workflow!

<!-- gh-comment-id:4205375226 --> @UVCXanth commented on GitHub (Apr 8, 2026): Thanks for the fix! I’ve been testing it for the last 4 days on my farm, and everything works perfectly now. The 'start and walk away' experience is finally 100% complete, and the power management is spot on. Thank you so much for your hard work and responsiveness — this is a game-changer for my workflow!
Author
Owner

@maziggy commented on GitHub (Apr 8, 2026):


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

<!-- gh-comment-id:4205685463 --> @maziggy commented on GitHub (Apr 8, 2026): ----- If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/maziggy/bambuddy) — it helps others discover the project!
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/bambuddy#500
No description provided.