mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-05-09 08:25:54 +02:00
[GH-ISSUE #1121] [Bug Report] Prints from queue seem to follow AMS slot of the printer the file was originally #803
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
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-maziggy-1#803
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 @maziggy on GitHub (Apr 24, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1121
Originally assigned to: @maziggy on GitHub.
Prints from queue seem to follow AMS slot of the printer the file was originally sliced with. If the AMS has a different filament it will use that disregarding the specified filament. If the slot is empty it will complain about filament ran out, even though the proper filament is in another spot.
Reporter Contact
Email: grussell@itape.com
System Information
Logs (sanitized): bambuddy.log
Submitted via BamBuddy Bug Report
@maziggy commented on GitHub (Apr 25, 2026):
https://wiki.bambuddy.cool/features/print-queue/#ams-filament-mapping
@GRussell94 commented on GitHub (Apr 27, 2026):
This is not completed. when scheduling a print to use ANY printer, it completely ignores AMS slots per printer. Force color match does nothing. The only thing I have found to work is to use "Specific Printer" and choose all the printers, then choose custom mapping. I would think this is also a bug as I don't need "custom mapping" if the filament of the file matches filament in any AMS slot.
@maziggy commented on GitHub (Apr 27, 2026):
Sorry the close felt premature. Let me explain what the code actually does so we can pin where it's going wrong for you.
When you queue a print to a model (Any printer of model X) on a recent build, two things happen automatically without you needing custom mapping OR force color match:
That's exactly what you're describing as the expected behaviour, and it's what the code is meant to do — without Force Color Match and without picking a specific printer.
Force Color Match is a stricter knob on top: it tells the scheduler "don't even pick a printer for this slot unless it has this exact type+color loaded right now." Useful when colour matters more than wait time. If the scheduler can't find one, the job sits waiting instead of dispatching to the wrong colour.
A few things worth confirming so we can isolate the actual failure:
- The queue item's filament_overrides (visible in the DB or via GET /api/v1/print-queue/{id}),
- The printer's AMS state at dispatch time (what was actually loaded in each tray),
- The line from bambuddy.log that looks like Queue item N: Computed AMS mapping for printer P: [...].
That triplet — what the file asked for, what the printer had, what Bambuddy decided — tells us in one shot whether the picker chose wrong, the mapping logic chose wrong, or the right mapping was computed but the print used a different one.
Reopening the issue while we wait for the debug data.
@maziggy commented on GitHub (May 2, 2026):
?