1
0
Fork 0
mirror of https://github.com/maziggy/bambuddy.git synced 2026-05-09 08:25:54 +02:00

[GH-ISSUE #671] [Feature]: Allow for multiple models of printers in a queue item. #443

Open
opened 2026-05-07 00:10:14 +02:00 by BreizhHardware · 4 comments

Originally created by @brainomite on GitHub (Mar 11, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/671

Problem or Use Case

I have two printers: an H2S and an H2C. I have some print jobs that I do not care what model printer is used.

Proposed Solution

It would be great if I can upload multiple G-Code files for a single queue-item. Therefore, it can go to the first available printer despite the model.

Alternatives Considered

No response

Feature Category

Print Queue & Scheduling

Priority

Nice to have

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 @brainomite on GitHub (Mar 11, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/671 ### Problem or Use Case I have two printers: an H2S and an H2C. I have some print jobs that I do not care what model printer is used. ### Proposed Solution It would be great if I can upload multiple G-Code files for a single queue-item. Therefore, it can go to the first available printer despite the model. ### Alternatives Considered _No response_ ### Feature Category Print Queue & Scheduling ### Priority Nice to have ### 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
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:4116102158 --> @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 (Apr 4, 2026):

Thanks for the suggestion! I can see how this would be useful for mixed-fleet setups.

After looking into this, the implementation would be quite complex — it would require fundamental changes to how queue items, archives, and file relationships work throughout the app. A queue item currently links to a single file, and that assumption runs deep through the archive system, queue cards, reprint flow, batch operations, and the scheduler.

For now, the existing model-based assignment feature covers a good chunk of this use case — you can queue a job to "any H2S" or "any H2C" without picking a specific printer. The gap is cross-model queuing with different G-code files per model, which would need a many-to-many file relationship and significant rework across the stack.

Given the scope of changes needed, I'm going to hold off on this for now unless there's more community demand. If this would be useful to you, please give the issue a 👍 so we can prioritize accordingly.

<!-- gh-comment-id:4186804656 --> @maziggy commented on GitHub (Apr 4, 2026): Thanks for the suggestion! I can see how this would be useful for mixed-fleet setups. After looking into this, the implementation would be quite complex — it would require fundamental changes to how queue items, archives, and file relationships work throughout the app. A queue item currently links to a single file, and that assumption runs deep through the archive system, queue cards, reprint flow, batch operations, and the scheduler. For now, the existing model-based assignment feature covers a good chunk of this use case — you can queue a job to "any H2S" or "any H2C" without picking a specific printer. The gap is cross-model queuing with different G-code files per model, which would need a many-to-many file relationship and significant rework across the stack. Given the scope of changes needed, I'm going to hold off on this for now unless there's more community demand. If this would be useful to you, please give the issue a 👍 so we can prioritize accordingly.
Author
Owner

@brainomite commented on GitHub (Apr 4, 2026):

Thank you for the response. I have another idea. What if we had multiple queued jobs as we do now, but a queued job can be linked to another? As soon as the item is picked up by a printer, it cancels the other linked item.

<!-- gh-comment-id:4187157797 --> @brainomite commented on GitHub (Apr 4, 2026): Thank you for the response. I have another idea. What if we had multiple queued jobs as we do now, but a queued job can be linked to another? As soon as the item is picked up by a printer, it cancels the other linked item.
Author
Owner

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

Should be possible, yes.

<!-- gh-comment-id:4187164842 --> @maziggy commented on GitHub (Apr 4, 2026): Should be possible, yes.
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-maziggy-1#443
No description provided.