mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-05-09 05:35:30 +02:00
[GH-ISSUE #752] [Feature]: Staggered batch start for multi-printer jobs (start in groups with interval) #500
Labels
No labels
A1
automated
automated
bug
bug
Closed due to inactivity
contrib
dependencies
dependencies
duplicate
enhancement
feedback
hold
invalid
Notes
P1S
pull-request
security
security
ThumbsUp
user-report
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/bambuddy#500
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
Checklist
@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.
@maziggy commented on GitHub (Mar 26, 2026):
Before we start building, a few questions for the community:
Any other edge cases or preferences from people running larger farms would be helpful.
@UVCXanth commented on GitHub (Mar 26, 2026):
My preference for a first implementation:
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.
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.
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.
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:
@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
@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:
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.
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:
Right now staggered start still depends on multiple later confirmations, so it does not yet deliver the “start once and walk away” experience.
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:
So in short:
@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.
@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!
@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?
@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.
Thanks again for being so responsive and for such an amazing tool!
@maziggy commented on GitHub (Apr 3, 2026):
It's already there.
If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!
@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.
@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.
@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!
@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!