Print Queue¶

Queue and schedule prints with drag-and-drop ordering, timed starts, batch grouping, batch orders with a quantity per plate, a Gantt timeline, and smart plug automation.

Queue Overview¶

The Queue page has five tabs along the top:

The active tab is remembered across reloads.

The Queue tab lets you:

• Queue prints from your archive, file manager, library, or virtual printer
• Group as batch — multi-plate prints auto-group; any 2+ selected items can be grouped manually
• Multi-drag — pick N items, the whole block moves together
• Schedule specific start times
• Automate with smart plug integration

Per-job ETA¶

Since 1.2.6 (#2736) a queue row shows an ETA beside its print duration — the clock time the job would finish if it started now, in your configured 12/24-hour format. It is a per-job answer, not a forecast of the whole queue.

The ETA only appears on jobs that could actually start now, so it is shown on:

• The next job up on an idle printer — following the same order the scheduler uses, including Shortest Job First when that is enabled
• Any staged job whose printer is free, since staged jobs wait on you rather than on the queue (the scheduler skips them without claiming the printer, so they neither hold up nor wait for the job behind them)

It is hidden for jobs waiting behind a print on the same printer, jobs scheduled for a later time, jobs blocked with a stated reason, jobs conditional on a previous print succeeding, and jobs with no print duration in their metadata.

Adding to Queue¶

From Archive¶

1. Go to Archives page
2. Click Print on the archive card
3. Choose the target printer, plate, dispatch option, and any filament mapping
4. Optionally configure filament mapping (see below)
5. Print is added to queue

From File Manager¶

1. Go to File Manager page
2. Select sliced files (.gcode or .gcode.3mf)
3. Click Print in the toolbar or context menu
4. Choose the target printer, plate, dispatch option, and any filament mapping
5. Files are archived and queued automatically

From Queue Page¶

1. Go to Queue page
2. Click Print
3. Browse and select an archive
4. Choose the target printer, plate, dispatch option, and any filament mapping
5. Submit the print

From Virtual Printer¶

When a virtual printer is set to Print Queue mode, prints sent from your slicer are automatically archived and added to the queue. The virtual printer's Auto-dispatch setting controls what happens next:

• Enabled (default): Incoming prints start automatically when a printer is available
• Disabled: Prints are added to the queue but require manual dispatch

Virtual Printer setup

AMS Filament Mapping¶

When adding multi-color prints to the queue, you can configure which AMS slot to use for each filament:

1. Expand the Filament Mapping section
2. View auto-matched filaments (type + color)
3. Click any dropdown to manually select a different AMS slot
4. Color names shown for easy identification (decoded from Bambu filament codes)
5. Mapping is stored with the queued print

Dual-Nozzle Printers (H2D/H2D Pro):

On dual-nozzle printers, filament matching is nozzle-aware. Each filament requirement shows an L or R badge indicating which nozzle the slicer assigned it to. Auto-match prefers trays on the slicer-assigned nozzle via ams_extruder_map. Since 0.2.5 (#1722) the dropdown also shows trays on the other extruder so you can manually pick a cross-extruder slot when you've loaded the required filament there on purpose — the L/R badge stays as a hint, but it doesn't hide options. The printer's firmware decides at start-print whether the resulting ams_mapping is physically valid.

Nozzle-Rack Printers (H2C):

The H2C's Vortek rack holds six hotends, and a multi-colour plate is sliced to use a different one per colour so it can skip the purge between changes. Since 1.2.6 (#1784) each filament bound for the rack carries a rack position dropdown beside its AMS slot dropdown, listing all six positions with the nozzle each one currently holds. Positions are numbered exactly as on the printer and on the nozzle rack card — 1 to 6.

• A position that is empty, or holds the wrong diameter or flow type for that filament, is shown greyed out with the reason rather than hidden, so looking for position 4 finds it
• The nozzle currently picked up onto the carriage is offered too. The firmware drops its rack position from its report entirely rather than sending a placeholder, but it is usually the position you want — it is the one the last print left mounted
• Filaments the slicer put in the same group share one hotend, so they share one dropdown; changing either changes both
• Filament on the fixed hotend keeps the plain L badge — there is no choice to make

You do not have to pick anything. Positions are assigned for you, preferring one already loaded with that colour so the print matches what is on the machine without moving any filament.

This is the same filament mapping panel used when reprinting from Archives, including the Mapping button that reuses a slicer-saved AMS pick — see Reuse the slicer's saved mapping.

Prefer Lowest Remaining Filament:

When multiple AMS spools match the same type and color, the auto-matcher normally picks the first one by slot order. Enable Prefer lowest remaining filament in Settings → Filament to instead select the spool with the least filament remaining. This helps consume partial spools before starting new ones, avoiding a buildup of nearly-empty rolls.

• Applies to queue scheduling, print modal pre-selection, and multi-printer mapping
• Unknown remain values (e.g. external spools without sensors) are treated as full and sorted last
• The matching priority chain is unchanged (tray_info_idx > exact color > similar color > type-only) — sorting only affects which spool wins within the same tier
• Disabled by default to preserve existing behavior

Plate Selection (Multi-Plate 3MF)¶

For 3MF files with multiple plates:

1. Click Edit on a queued item
2. Scroll to Plate Selection section
3. Browse plates with thumbnails and print times
4. Click to select the plate to print
5. Filament requirements update to show selected plate's filaments

Cost Center¶

When billing is enabled, every queued print must name a cost center, and its estimated cost is held against that center's budget until the print runs. The picker appears in the print dialog above the print options; a job that would exceed the remaining budget is refused when you queue it, not when it reaches the printer.

Print Options¶

Configure printer settings for each queued print:

1. Click Edit on a queued item
2. Expand Print Options section
3. Set options as needed:

Configurable Default Print Options¶

You can change the default values for print options so that every new print dialog starts with your preferred settings. Individual prints can still be overridden as needed.

1. Go to Settings → Workflow
2. Set the defaults for each option:

These defaults apply to:

• The Print dialog
• All new queue items

Batch Grouping¶

Bambuddy groups related queue items into a single collapsible row with aggregate stats. Three ways to create a batch:

Auto-grouping: Multi-plate prints¶

When you queue multiple plates from one source 3MF in a single submission (multi-plate selection or model-based assignment to a single printer), Bambuddy automatically creates a batch named e.g. MyModel - 3 plates and assigns every queued plate to it.

Auto-grouping: Batch print quantity¶

1. Open the Print dialog
2. Set the Quantity field to the number of copies (default: 1). On a multi-plate file this control is per plate instead
3. Submit — Bambuddy creates one queue item per copy, all in the same batch

Any submission that produces more than one run from a single file becomes a batch order with per-plate targets, so it can tell you what it still owes.

Batch Behavior¶

• Every copy is inserted into the queue and handled by the scheduler
• ASAP copies are added at the top of the queue
• Queue copies are added at the end of the queue
• Schedule copies wait in the queue until their scheduled time
• Manual Start items stay staged until you release them
• Batch items appear on the queue page with a batch badge showing the group
• In direct print mode, the first copy prints immediately and the remaining copies are queued under the batch
• In queue/schedule mode, all copies are added to the queue together
• Combined with multi-printer selection, quantity applies per printer

Manual grouping: Group as batch¶

Pick any unrelated items and stitch them together as a batch:

1. Select 2 or more pending items that are NOT already in a batch (checkboxes on the left of each row)
2. The selection bar at the top of the queue gains a Group as batch action
3. Click it — an empty batch is created, every selected item is assigned to it, and they collapse into one parent row

How a batch looks¶

• The batch parent row shows the source file name, aggregate item count, total estimated time, total filament weight, and a chevron to collapse / expand the children
• Children are indented under the parent with a cyan left border
• Inside an expanded batch, children remain individually draggable, but only within the batch (you can't drag a child out without ungrouping first)
• Per-batch collapse state is persisted in localStorage so it survives reloads

Moving a batch in the queue¶

The batch parent row has its own drag handle (next to the collapse chevron). Grab it to reorder the entire group as one unit — the drop ghost shows the batch name and copy count, and every child item lands contiguously at the new position. Works while the batch is collapsed or expanded; collapsed batches no longer act as obstacles for adjacent items.

Ungroup¶

To break a batch back into individual items:

1. Click the Ungroup action on the batch parent row
2. All items the caller owns lose their batch association and become independent queue items again
3. If no members remain, the batch row itself is deleted

You can also cancel an entire batch at once — Cancel Remaining on the Batches tab, or the API endpoint (see API Access below). Either way the batch's pending items are cancelled and the batch is marked cancelled; items that already ran are left alone.

History batches¶

Sibling history rows from the same batch collapse into one parent with status-rollup chips — e.g. 3 OK / 1 failed — and the latest activity timestamp. The chips link straight to the per-archive Print Log for the underlying file.

Loading older history¶

History shows the 50 most recent prints first. If you have more, a Show more button below the grid loads the next 50 (with a Showing X of Y count), and keeps loading in pages until the whole history is on screen. Changing the sort or the location filter resets the view to the first page.

Batch Orders¶

Grouping tells you which queue items belong together. An order additionally records how many runs of each plate you wanted — and that difference is what lets it tell you a print still needs doing after one burned.

The Batches tab on the Print Queue page is where orders live. It is a separate tab because an order outlives the queue that produced it: once its runs finish they leave the active queue entirely, so the Queue tab and the History tab each hold only half the picture.

What an order tracks¶

A failed, cancelled or skipped run does not satisfy a target. That is deliberate: if two parts are wanted and one fails, the order still owes one, and says so. A cancelled order is left alone entirely — cancelling is you saying you no longer want the work.

Queueing what is still owed¶

An order dispatches everything immediately when you create it, so the default flow is unchanged. When runs are outstanding — because one failed, or because you raised a target later — the order shows a Queue N remaining button, and each plate row has its own Queue remaining for a single plate.

New items are copied from the most recent run of that plate in the same order, so they inherit the printer or model target, AMS mapping, filament overrides and print options you originally chose. They are appended to the end of the relevant printer's queue, never inserted ahead of work already lined up.

Cost¶

Cost is measured, not estimated. Each finished run's material and energy cost is attributed to the order through the queue item that produced it, so a reprint of the same file outside the order never lands in its total. Multi-plate orders get each plate's own cost rather than the whole file's.

Until an order has completed at least one run there is no honest number, so the cost reads as unknown rather than as 0.00. Once runs complete, the remaining-cost estimate is their observed average multiplied by what is still owed.

Status¶

An order is active until every target is met and nothing is still in flight, at which point it becomes completed — recorded the moment its last run lands, not the next time somebody opens the page. Raising a target on a completed order reopens it. Cancel remaining cancels the order's pending items and marks the order cancelled; a cancelled order is never reopened automatically.

A grouping (rather than an order) whose every item was cancelled one at a time is marked cancelled too. It is finished, but nothing was produced, so calling it completed would be false. This does not apply to orders: an order states its intent independently of its runs, so cancelling every run still leaves it owing the work and still offering to queue it again.

Filtering the list¶

The Batches tab opens on Active and offers Completed, Cancelled and All. Batches with neither queue items nor per-plate targets are never listed — those are empty shells, left behind when a grouping's items were deleted along with their source archive, and they have nothing to show, track or dispatch. A newly created order is listed before its first run is queued, because its targets already say what it owes.

Shortest Job First (SJF)¶

Prioritize shorter print jobs so more jobs complete sooner.

Enabling SJF¶

1. Go to the Queue page
2. Click the SJF badge in the pending queue header (next to the sort dropdown)
3. The badge turns green when active

How It Works¶

When SJF is enabled, the scheduler picks the shortest pending print for each printer instead of following FIFO order:

1. Jumped items first — jobs that were previously skipped get top priority (starvation guard)
2. Shortest duration next — among remaining items, the shortest print time wins
3. Position as tiebreaker — equal-duration items use their original queue position

The queue page automatically reorders to show the scheduler's actual execution order when SJF is active.

Starvation Guard¶

Without protection, a long job could be postponed indefinitely as shorter jobs keep arriving. SJF includes an automatic fairness mechanism:

• When a shorter job jumps ahead of a longer one, the longer job is flagged as "jumped"
• A jumped job cannot be skipped again — it moves to the front of the queue on the next cycle
• This guarantees every job eventually prints, regardless of duration

Requirements¶

• Print duration must be available in the 3MF metadata (the prediction field in slice_info.config)
• Items without a known print time are sorted last
• SJF applies independently per printer — each printer's queue is sorted separately

Auto-Print G-code Injection¶

Inject custom G-code at the start and/or end of prints for third-party bed-clearing systems like Farmloop, SwapMod, AutoClear, and Printflow 3D.

Configuring Snippets¶

1. Go to Settings → Workflow
2. Find the G-code Injection card
3. For each printer model you use, enter:
   • Start G-code — injected at the end of the printer's startup block, immediately before the first print move (matches where a slicer-side custom-start-gcode would land)
   • End G-code — appended after the last line of the print's G-code
4. Changes save automatically when you click out of the text field

Only printer models that you have connected appear in the list.

Placeholders¶

Snippets can reference values from the print's 3MF header using {name} placeholders. These are resolved per print, so a snippet that drops the head to the top of the model works regardless of how tall the model is:

Beyond the named placeholders above:

• Any header key works — any key from the 3MF's ; HEADER_BLOCK_START block is addressable directly (lowercased, spaces → underscores, [units] suffixes stripped)
• Typos stay verbatim — unknown placeholders are left in the snippet as-is and a warning is logged; a typo never silently expands to an empty string

Enabling Per Queue Item¶

1. Open the Print dialog or edit an existing queue item
2. Check Inject auto-print G-code
3. Submit — the queue item shows a green G-code badge

When the scheduler dispatches the print:

1. Looks up the G-code snippets for the target printer's model
2. Resolves any {placeholder} values from the 3MF header
3. Creates a temporary copy of the 3MF with the snippets injected at the anchors below
4. Uploads the modified copy via FTP
5. Cleans up the temporary file after upload

Where the snippets land:

Enabling Per Virtual Printer¶

For Virtual Printer queue-mode setups you don't tick each queue item by hand — opt the whole VP in instead:

1. Open the virtual printer card (queue mode)
2. Turn on G-code injection (off by default)

From then on:

• Every Bambu Studio Send / VP upload to that VP is queued with injection enabled — the per-model start/end snippets fire without any per-item edits
• It's a no-op when no snippets are configured for the target printer's model

Quantity¶

When reprinting with quantity > 1, what happens depends on the Inject auto-print G-code checkbox:

• Unticked — the first copy prints immediately and the remaining copies are queued.
• Ticked — all copies are queued instead, so every one is injected by the scheduler. This matters for auto-eject: a directly-dispatched first copy would skip injection and stay stuck on the plate, blocking the copies queued behind it.

Drag and Drop Ordering¶

Reorder prints in the queue:

1. Hover over a queued print
2. Grab the drag handle
3. Drag to new position
4. Release to reorder

Prints execute in order from top to bottom.

Multi-drag¶

Move several items as a contiguous block:

1. Tick the checkboxes on 2 or more pending items
2. Grab the drag handle on any one of the selected items
3. A +N ghost follows the cursor showing how many items are moving
4. Release at the target position — the whole selection lands as a contiguous block in selection order

Multi-drag works across batches and unrelated items; the batch parent stays with its children (a batched child can only be moved within its batch, see Batch Grouping).

Scheduling¶

Immediate Prints¶

Add to queue without a schedule - prints start when:

• Printer is idle
• Previous prints complete
• No scheduled prints are pending

Scheduled Prints¶

Set a specific start time:

1. Click Schedule on queued print
2. Choose date and time
3. Print starts at scheduled time

Schedule Priority¶

Scheduled prints take priority:

1. Check for scheduled prints at scheduled time
2. If none, check immediate queue
3. Start next print

Queue (Staged Prints)¶

Stage prints without automatic scheduling:

1. In the Print dialog, select Queue
2. Print shows with purple Staged badge
3. Print won't start automatically
4. Click Play button to release to queue

Use Queue Only to:

• Prepare print batches before activating
• Stage prints across multiple printers
• Review and approve before printing starts
• Build a queue without immediate execution

Preheat & Heat Soak¶

Heat the bed (and the chamber, on supported printers) and hold at temperature before each queued print starts. Useful for engineering filaments — PA, ABS, PC, PETG-CF — where adhesion and warp depend on a warm chamber.

Bambuddy waits between the FTP upload and the start_print command, so the heat-soak runs while the printer is otherwise idle rather than burning print time. M191 (wait-for-chamber-temp) is silently ignored by Bambu firmware, so slicer-side "wait for chamber" lines in start G-code do not work — orchestrating this from the queue side is the only place it works.

Global defaults¶

Settings → Workflow → Queue & Dispatch → Preheat & Heat Soak card.

The bed target is normally read from the print file's bed_temperature metadata — no manual override. If the file has no parseable bed temperature, the behaviour depends on the chamber:

• The print needs chamber heat — the bed is heated to the Keep-warm bed temperature above, because on most printers the bed is how the chamber gets warm. Preheat's bed target only applies while the file uploads; the print's own G-code sets the real bed temperature the moment it starts.
• The print needs no chamber heat — the preheat stage is skipped and the print starts immediately. No bed temperature is invented for the print itself.

Bundled per-filament defaults¶

Edit any row to retune for your local conditions; the Reset button reverts to these bundled values.

Per-print override¶

The Print Options panel in any print / queue-edit dialog has a Preheat & Heat Soak sub-section:

The Chamber target override field (shown when override ≠ Off) accepts an explicit °C target (0–65) that bypasses the per-filament map. Leave blank to use the per-filament derivation. Setting it to 0 explicitly disables the chamber phase for this print while keeping the bed phase + soak timer active.

The 65 °C ceiling is the highest any Bambu chamber heater reaches — the H2 series (H2C / H2D / H2D Pro / H2S) and X2D. X1E tops out at 60 °C and its firmware clamps anything above that, so the ceiling is shared rather than per model (the per-filament map is global, not per printer).

Per-printer behaviour¶

Bambu printers have three distinct hardware tiers for chamber heat, and the preheat stage branches on the connected printer's model:

Airduct flap (H2C / H2D / H2D Pro / H2S / X2D / P2S)¶

These printers have a motorised airduct flap with two positions: cooling (open exhaust, vents heat — right for PLA / PETG / TPU) and heating (closed exhaust, recirculates warm air — right for ABS / ASA / PC / PA / PETG-CF). Bambu's firmware does NOT auto-switch the flap when M141 fires; whatever mode you (or the printer's own start-G-code from a previous print) left it in, it stays.

The preheat stage flips the flap before dispatching M141, based on the resolved chamber target:

The flap is only moved when its current state differs from the desired state — no MQTT chatter or unnecessary flap-motor cycling when it's already where it needs to be. After the print finishes, Bambuddy leaves the flap where the preheat set it (the print itself wants the same airflow); the next preheat decision flips it for the next print.

What you'll see in the queue¶

While the preheat stage is running:

• The queue item shows as In Progress (the dispatch is committed; this is the printer's pre-print phase, not a queue stall).
• The printer card's bed (and chamber, if active) temperatures rise toward target.
• The print itself starts the moment the soak timer elapses — no second click needed.
• Cancelling or deleting the item stops the preheat within seconds; the bed and chamber are switched off and the printer is free for the next job rather than finishing a heat-up for a print that is no longer happening.

If the printer drops MQTT during the wait, the stage exits gracefully and the normal upload + start path still fires (best-effort: a printer that goes offline mid-soak should not turn a queue item into a failed print). If the dispatch fails for any other reason before the print starts — a failed upload, for instance — anything preheat switched on is switched back off. The one exception is a bed whose target has changed since: if the printer reports something other than the temperature preheat set, that target belongs to whoever set it and Bambuddy leaves it alone rather than switching the bed off underneath them.

Keep bed warm between prints¶

When running back-to-back prints that require chamber heating, the chamber can cool during the bed-clearing window between jobs — triggering a full re-soak on the next print even though the chamber was still hot.

Enable Keep bed warm between prints (Settings → Workflow → Queue & Dispatch → Preheat & Heat Soak card) to prevent this. While a printer sits in FINISH state awaiting plate-clear confirmation, Bambuddy holds the bed hot so the chamber stays warm.

The hold works on any printer. On one that reports a chamber temperature it also pays off directly, because smart soak reduction can then credit the time the chamber spent warm against the next print's soak. Without a chamber sensor there is nothing to measure, so the next print still runs its full configured soak — the hold keeps the chamber warmer than it would otherwise be, but you have to shorten the soak yourself to benefit.

During the hold the bed is a heater for the chamber, not a print surface: nothing is printing, and the next print's own G-code sets its real bed temperature as soon as it starts. So the hold runs at the Keep-warm bed temperature (default 90 °C) rather than at the next print's bed temperature — raised to the print's own value whenever that is higher, so the bed is never held cooler than the job needs.

Requirements:

• Preheat & soak must be enabled (the toggle above this one in the card).
• Require plate-clear confirmation must be enabled — the keep-warm window only exists during the bed-clearing pause.
• The next queued item must require chamber heating. This is resolved exactly like preheat's own chamber target: the per-print override wins if set, otherwise the maximum across the loaded AMS slots. Prints that resolve to a 0 °C chamber target (PLA, PETG etc.) are skipped automatically.

All three are re-checked on every scheduler pass, so switching any of them off stops the hold immediately rather than at the next print.

When the hold ends. The bed is switched off as soon as any of these happens:

If you change the bed temperature yourself while a hold is running, Bambuddy leaves it alone — it only ever switches the bed off if the printer still reports the exact target keep-warm set.

Not covered in this version:

• Queue items not yet assigned to a specific printer (model-based items). Library-file items are covered: whether the chamber needs heat comes from the loaded AMS filament rather than the item, and the item's own bed temperature is only consulted to raise the hold above the configured temperature.
• The hold drives the bed only. It does not command the chamber heater or the air-duct flap during the wait, so on printers with an active chamber heater the chamber coasts on bed radiation plus whatever it was already doing.

Smart soak reduction via chamber history¶

Bambuddy continuously samples each printer's chamber temperature (every scheduler tick, typically every 3–30 s) into a 2-hour rolling history. Before running the heat-soak wait, it checks how long the chamber has been above the configured target and credits that time against the soak duration.

"Above target" allows a 2 °C tolerance throughout, so a chamber sitting at 49 °C against a 50 °C target still counts as at temperature.

This works alongside keep-warm: if the chamber stayed at temperature the whole time you were clearing the bed, the next print either soaks for a reduced time or skips the soak completely.

Why brief dips are ignored. An enclosed chamber has enough thermal mass that it cannot lose and regain several degrees quickly — measured on an X1C, falling from 55 °C to below 48 °C takes 23–73 minutes. A reading that drops below target and recovers within six minutes is therefore a door being opened or a sensor glitch, not the chamber actually cooling, so it does not discard soak credit you have genuinely earned. Opening the door to lift the plate off — exactly what you do during the keep-warm window — produces one of these. A longer excursion is treated as real cooling and does restart the credit.

Tips¶

• Keep the soak short for printers in the chamber sensor only tier (X1C / P2S): the bed warms the chamber slowly, so most of your "real" soak time is already happening during the max-wait phase. 300 s on top is usually plenty.
• For printers with an active chamber heater (H2 series, X2D, X1E), the chamber reaches target in a few minutes; treat the soak as the actual heat-soak interval. ABS prefers 10–15 min (600–900 s) of soak after target.
• For printers with no chamber sensor (P1S etc.), there's no way to verify chamber temp, so soak is your only lever. Try 600 s for ABS, less for PETG.
• Enable Keep bed warm for all-day print runs with engineering filaments — it eliminates the 30-minute re-soak penalty between consecutive jobs.

Smart Plug Automation¶

Combine with smart plugs for full automation:

Auto Power On¶

When a queued print is ready:

1. Bambuddy checks if printer is on
2. If off and smart plug configured, powers on
3. Waits for printer to boot
4. Starts the print

Auto Power Off¶

After print completes:

1. Print completes
2. Cooldown period (configurable)
3. Check if more prints queued
4. If no more prints, power off

Configuration¶

1. Go to Settings > Smart Plugs
2. Configure plug for printer
3. Enable Auto Power On and Auto Power Off
4. Set cooldown temperature and time

Smart Plugs setup

Queue Status¶

Print States¶

Queue Card¶

Each queued print shows:

• Thumbnail (shows the selected plate's thumbnail for multi-plate files)
• Print name
• Target printer
• Estimated duration
• Scheduled time (if set)
• Status
• Added by (username who queued the print, when authentication is enabled)

Timeline View¶

The Timeline tab renders the upcoming and active fleet as a true Gantt swimlane — one horizontal row per printer (plus per target_model and unassigned) with jobs as colored bars positioned by start time and sized by duration. It's a forecast view: if a lane is empty, that printer / model has nothing committed to render.

Layout¶

• One swimlane per active printer, plus extra lanes for each active target_model (e.g. "Any X1C") and an "unassigned" lane
• Hour axis at the top with ticks every 2 hours
• NOW marker — a vertical red line at the current time
• 24-hour rolling window starting at the current hour, with ±12h step buttons to scroll forward or back
• Bar colors: blue for currently printing, cyan for queued-within-batch, green for queued
• Idle stretches show diagonal stripes so it's clear when a printer is free

What renders¶

The Timeline only shows committed schedules so it reads as a real forecast:

A lane is dropped entirely if it has no active print AND no scheduled item that meets these criteria. If the whole fleet is idle with nothing committed, the tab shows an empty-state notice instead of a misleading blank Gantt.

Per-bar tooltip¶

Hover any bar to see:

• Source file name
• Start — scheduled or estimated
• End — computed from print duration
• Progress percentage (for actively printing items)
• Batch name (for batched items)

Interactions¶

• Click a queued bar to edit the item
• Click an active bar to open the printer card

Managing Queue¶

Remove from Queue¶

1. Click the X on any queued print
2. Confirm removal
3. Print is removed (not deleted from archive)

Cancel Running Print¶

1. Find the currently printing item
2. Click Cancel
3. Print stops on printer
4. Marked as cancelled in queue

Clear Plate Confirmation¶

When a print finishes or fails and more items are queued for the same printer, the next print does not start automatically. Instead, the printer card shows a "Clear Plate & Start Next" button.

1. Remove the finished print from the build plate
2. Click Clear Plate & Start Next on the printer card
3. The scheduler starts the next queued print within 30 seconds

This prevents prints from starting on a dirty plate. The button appears whenever the printer is awaiting a plate-clear acknowledgment — which is set when a print finishes or fails and cleared only when you tap the button or the scheduler dispatches the next job.

Disabling Plate-Clear Confirmation¶

If you want the scheduler to start the next queued print automatically without waiting for manual plate-clear confirmation:

1. Go to Settings → Workflow → Queue & Dispatch
2. Disable Require plate-clear confirmation
3. The scheduler will now start queued prints automatically on printers with finished or failed jobs

This is useful for print farms or workflows where you trust the plate is cleared between prints (e.g., with auto-eject or flexible build plates). The default is enabled, preserving the existing behavior of requiring manual confirmation.

Watching the Gate From Outside Bambuddy¶

The pending confirmation is not something only the Web UI can see:

• MQTT — the per-printer status topic carries an awaiting_plate_clear field, and every transition is published on a retained bambuddy/printers/{serial}/plate_clear topic. Subscribe to bambuddy/printers/+/plate_clear and your automation knows the state of every printer the moment it connects. See MQTT Publishing.
• Notifications — enable Plate Clear Required on a notification provider to get a push when a printer starts waiting. Off by default, because it fires after every print at the same moment as the print-complete notification. See Notifications.
• REST — GET /api/v1/printers/{id}/status returns awaiting_plate_clear, and POST /api/v1/printers/{id}/clear-plate acknowledges it, so a custom dashboard can do both halves without the Bambuddy UI. See the API reference.

Clear Queue¶

Remove all queued prints:

1. Click Clear Queue button
2. Confirm action
3. All pending prints removed

Bulk Editing¶

Edit multiple queued items at once:

Selecting Items¶

1. Look for checkboxes on pending queue items
2. Click checkbox to select/deselect individual items
3. Use Select All / Deselect All in the toolbar

Bulk Edit Modal¶

When items are selected, click Edit Selected to open the bulk edit modal:

Bulk-Edit States¶

Each setting starts as Unchanged (—) so it isn't modified unless you pick a value:

Only settings you explicitly change are applied - other settings remain as they were.

Bulk Cancel¶

Click Cancel Selected to cancel all selected pending items at once.

Multi-Printer Queue¶

Queue prints across multiple printers:

Per-Printer Queues¶

Each printer has its own queue:

• Filter by printer to see specific queue
• Prints wait for their assigned printer
• Different printers can print simultaneously

Multi-Printer Selection¶

Send the same print to multiple printers at once:

1. Open the Print modal
2. Select multiple printers using checkboxes
3. Use Select all / Clear buttons for quick selection
4. Configure filament mapping (default applies to all printers, or use per-printer mapping)
5. Click submit to send to all printers

Concurrent Uploads¶

Printers receive files slowly. The bottleneck is the printer's own SD-card write, not your network — a Bambu printer sustains roughly 150 KB/s, so a 40 MB .3mf takes about four minutes to transfer. That is per printer, and printers are independent machines, so there is no reason for them to wait for each other.

Settings → Workflow → Queue & Dispatch → Concurrent Uploads controls how many printers the queue may send files to at the same time.

Raise it on a bigger fleet. With uploads running one at a time, the last printer in a batch waits out every transfer before it: at four minutes each, ten printers means the tenth starts roughly 40 minutes after you pressed Print. The delay grows linearly with the number of printers, which is why it is only noticeable on farms.

Lower it (or set it to 1, which uploads to one printer at a time) if your network or the machine running Bambuddy struggles with parallel transfers.

Staggered Batch Start¶

When sending a print to multiple printers, you can stagger the starts to avoid power spikes from simultaneous bed heating — especially useful for larger farms (10+ printers).

Staggering is available in the Print dialog whenever multiple printers are selected.

1. Select multiple printers in the Print dialog
2. A Stagger printer starts checkbox appears automatically when multiple printers are selected
3. Enable the checkbox, then set the Group size (how many printers start at once) and Interval (minutes between groups)
4. A preview shows the schedule: e.g., "6 printers → 3 groups of 2, starting every 5 min (total: 10 min)"
5. Submit — the first group starts immediately (ASAP) or at the scheduled time, subsequent groups start at computed intervals

Default values can be configured in Settings → Workflow → Queue & Dispatch → Staggered Start and overridden per batch in the Print dialog.

Per-Printer AMS Mapping¶

When multiple printers are selected, you can configure filament slot mapping individually for each printer:

1. Select multiple printers
2. Under each printer, check Custom mapping to enable per-printer configuration
3. The mapping section expands showing:
4. Required filaments with color indicators
5. Dropdown to select AMS slot for each requirement
6. Match status: exact, type-only, missing
7. Click Auto to auto-configure using RFID data
8. Click Re-read to refresh the printer's loaded filaments

Choosing a Printer¶

When adding to queue:

1. Select one or more target printers
2. Prints join each printer's queue
3. Different archives can go to different printers

Load Balancing¶

Manually distribute prints:

• Add long prints to less-used printers
• Queue time-sensitive prints on fastest printer
• Keep specific materials on specific printers
• Use multi-printer selection for batch production

Model-Based Queue Assignment¶

Queue prints to "any printer of matching model" for automatic load balancing across identical printers.

How It Works¶

1. When you add a print to the queue, select Any [Model] instead of a specific printer
2. Optionally select a Location to further filter available printers (e.g., "Any X1C in Workshop")
3. Bambuddy extracts the printer model from the sliced 3MF file (e.g., "X1C", "P1S")
4. The scheduler automatically assigns the print to the first idle printer of that model (and location, if specified)
5. If filament validation is enabled, it only assigns to printers with the required filaments loaded

Adding Model-Based Queue Items¶

1. Open the Print modal
2. In the printer selection, choose Any X1C, Any P1S, etc.
3. Optionally select a Location from the dropdown to filter by printer location
4. Configure other options as usual
5. Submit - the print joins the queue without a specific printer

Location Filtering¶

When you have multiple printers of the same model in different locations:

1. Choose Any [Model] for the printer
2. Select a Location from the dropdown (shows all locations from your printers)
3. The scheduler only considers printers at that location
4. Queue items show the target location (e.g., "Any X1C - Workshop")

Filament Validation¶

When a model-based queue item has required filaments:

1. Scheduler checks each printer of the matching model
2. Only printers with all required filament types loaded (in AMS or external spool) are considered
3. Jobs wait until a compatible printer becomes available
4. The Waiting status (purple badge) shows why a job is waiting

Filament Override¶

When using model-based assignment, you can override the filament colors and types from the original 3MF file:

1. Select Any [Model] for the printer
2. The Filament Override section appears showing each filament slot from the sliced file
3. For each slot, a dropdown shows all compatible filaments loaded across printers of the selected model
4. Select an override to change the color or type for that slot
5. Click the reset button to revert to the original 3MF value

The scheduler uses the overridden values when matching filaments:

• Color preference: Printers with exact color matches for your overrides are preferred
• Type filtering: Only filaments of the same type are shown in the dropdown (e.g., PLA slots only show PLA)
• Nozzle-aware (auto-match): On dual-nozzle printers (H2D), the scheduler prefers filaments on the slicer-assigned extruder when matching. The manual override dropdown shows slots on either extruder so you can pick cross-extruder when intentional — the firmware validates the final mapping at start-print.

Waiting Status¶

Model-based queue items show detailed status:

The waiting reason tells you exactly what's needed:

• Waiting for filament: Which printers are missing which filament types
• Busy: Which printers are currently printing
• Offline: Which printers are disconnected. If one of them has an enabled Auto Power On plug, Bambuddy switches it on by itself and the job starts once it has booted.
• Offline, no Auto On smart plug: The printer is off and Bambuddy has no way to bring it back — switch it on yourself, or enable Auto Power On on its plug.
• Waiting on \<sensor>: A Home Assistant sensor set to hold prints is alerting — an enclosure door left open, say. The job starts by itself once the sensor clears; nothing is cancelled.

Compatibility Warnings¶

When queuing to a specific printer that doesn't match the sliced model:

• A warning shows "File was sliced for X1C, but printing on P1S"
• This helps avoid issues from mismatched print profiles

Cross-Model Alternatives¶

Model-based assignment spreads one job across identical printers. Cross-model alternatives spread it across different models — for a job you don't care which machine runs, when each machine needs its own slice.

How It Works¶

1. Slice the same job once per printer model (an H2S slice and an H2C slice, for example)
2. In the File Manager, select both sliced files and press Print
3. The print modal replaces the printer picker with the candidate list, in priority order
4. One queue item is created, carrying both files

The scheduler walks the candidates in your order and dispatches the first whose model has an idle printer. The moment one is chosen, its file, plate and nozzle mapping are written onto the queue item — from that point it is an ordinary single-file job, and history, reprint and archiving behave exactly as they do for any other print.

Priority Order¶

Use the arrow buttons to order the candidates. Order only matters when more than one printer is free at the same moment: the topmost candidate wins, so the outcome is reproducible rather than depending on which printer the scheduler checked first.

If a printer accepts the file but never starts, that candidate drops behind the others for the next attempt, so the alternative gets a turn instead of the job spending its whole retry budget on the machine that is stuck.

Rules¶

A cross-model item holds no file of its own — the files live on the candidates. Deleting one alternative leaves the job and its remaining candidates intact. If every candidate is deleted or trashed, the item is held with an explanation rather than failing during upload.

Filament Overrides¶

The filament override list offers everything loaded across all the candidate models, not just the first. A spool loaded on only one of them is still offered — the job can land there, and choosing it simply narrows which candidates can match.

As everywhere else, the dropdown only offers filaments of the same material as the slot: overriding PLA with PETG isn't a colour swap. The list is empty (and the section hidden) when Bambuddy can't see any loaded filament, for instance when the printers are switched off.

There is no AMS slot mapping on a cross-model job, exactly as there is none on an ordinary "Any [model]" job — no printer has been chosen yet, so there are no trays to map to. The scheduler derives the mapping against the printer it actually picks.

In the Queue¶

A pending cross-model item shows Any H2D / X1C, naming every model it is waiting on, and is grouped under the same heading rather than filed under one of them. Its name comes from the first candidate, as x1c.gcode.3mf +1 more.

If it can't start, the waiting reason is given per model — for example H2D: Busy: H2D-1; X1C: No matching material/color. When every model is merely busy, that reads as a plain busy message and raises no notification, since nothing needs your attention.

Editing a Queued Job¶

Opening Edit on a cross-model item shows its alternatives read-only. You can still change the schedule, quantity and print options; you cannot assign a specific printer or narrow it to one model, and the API refuses both.

That's deliberate: a queue item that had both alternatives and an assigned printer would dispatch down the fixed-printer path, which has no file to send. To change the candidate set, cancel the item and queue it again.

Grouping Files Permanently¶

Selecting files each time is fine for a one-off. To make it stick, select the sliced files and choose Group as versions. After that, printing any member offers the whole group automatically — useful when you sliced the second version weeks after queueing the first.

Grouped files show a N versions badge in the File Manager. The count covers the whole group, including members in other folders.

Files sliced through Bambuddy's own Slice button are grouped automatically on upgrade, where the same source produced two or more slices for different printers.

Queue Notifications¶

Get notified about queue events. Configure these in Settings → Notifications under "Print Queue":

Set up notifications

Queue History¶

The History tab shows completed, failed, cancelled, and skipped prints in a responsive 1 / 2 / 3-column grid that adapts to viewport width, so a long history uses available horizontal space instead of one row per line.

What each history row shows¶

• Status icon and colored left border (green for completed, red for failed, orange for skipped, grey for cancelled)
• Source file name and small thumbnail
• Relative time (e.g. "2h ago"), with the absolute timestamp on hover
• Filament color swatch + weight + type when known
• User attribution — who started the print (when authentication is enabled)
• Print duration
• Inline error message on failed / skipped rows, so you don't need to expand the row to see why it failed
• Re-queue and Remove actions

Thumbnail hover preview¶

Hover any small thumbnail to pop out a 192×192 preview next to it. Desktop only; touch devices skip this affordance.

Batch parents in history¶

Sibling rows from the same batch collapse into one parent row with status-rollup chips (e.g. 3 OK / 1 failed) and the latest activity timestamp. Click the parent to expand and see each child individually.

History helps you:

• Track throughput
• Identify patterns
• Debug issues

API Access¶

Manage queue programmatically:

# Add to queue (accepts an optional batch_id to attach to an existing batch)
POST /api/v1/queue

# Get queue status
GET /api/v1/queue

# Remove from queue
DELETE /api/v1/queue/{id}

# List all batches
GET /api/v1/queue/batches

# Get a batch
GET /api/v1/queue/batches/{batch_id}

# Create a batch — empty, with existing pending item_ids to group manually,
# or with `plates` to make it an order carrying per-plate targets
POST /api/v1/queue/batches

# Edit an order: name, notes, due date, project link, or the per-plate targets
PATCH /api/v1/queue/batches/{batch_id}

# Queue the runs an order still owes — all of them, one plate, or capped by `limit`
POST /api/v1/queue/batches/{batch_id}/dispatch

# Ungroup a batch — clear batch_id from every owned member; delete the batch row when empty
POST /api/v1/queue/batches/{batch_id}/ungroup

# Cancel a batch
DELETE /api/v1/queue/batches/{batch_id}

See API Reference for details.

Background Print Dispatch¶

When the scheduler starts a queued print, the FTP upload and print-start command run in the background. The UI responds immediately and you can continue browsing while the file transfers.

Progress Tracking¶

A persistent toast notification shows real-time dispatch progress:

• Upload progress bar for each active job
• Status badges: Dispatched → Processing → Completed / Failed / Cancelled
• Cancel button to abort an in-progress upload (cleans up partial files on the printer)
• Batch progress (e.g., "⅔ complete") when dispatching to multiple printers

How It Works¶

1. You click Print and Bambuddy creates queue item(s) through POST /api/v1/queue/
2. When a queue item is ready, the scheduler creates a dispatch job
3. The background dispatcher picks up the job and starts the FTP upload
4. Progress updates stream to all connected clients via WebSocket
5. After upload completes, the dispatcher sends the print-start command to the printer
6. If you cancel mid-upload, the partial file is deleted from the printer's SD card

Tips¶