Auto-Queue Routing¶

Auto-Queue distributes work into per-printer queues. Choose the file, plate, and print rules; the router finds a printer of the exact model that can supply every used filament channel.

Printers of the same model with and without AMS are checked against their actual configurations. See Filament Routing for the complete rules, multicolor and dual-nozzle examples, and waiting reasons.

How it works¶

Self-contained queued files¶

When BamDude accepts a job it takes one verified immutable copy of the actual bytes into data/queue-sources/. Routing, preparation and upload read that copy from then on. A laptop can sleep, an SMB share can disconnect, an external library file can move or be deleted, and archive retention can run without changing work already in either queue. Identical bytes queued many times are stored once. The shared copy is released only when its last printer-queue or Auto-Queue job is removed. Portable backups include the ready queue copies named by their database snapshot, so a restored farm does not need the original folders. The staging/ subdirectory contains unfinished copies only; it is never queued or backed up.

Rows created before this change remain legacy rows until they are captured by a later operation. A missing or checksum-mismatched snapshot, or a vanished legacy source, produces File error and is skipped. Other jobs continue; the printer queue is not paused and no failed physical print is counted. Failed AutoQueue jobs remain visible with Retry and removal actions; printer queues show them under Issues. Restore access only for a legacy row, then retry explicitly. A ready snapshot never retries an old NAS path.

Assignment¶

On submission, BamDude validates the selected plate in the sliced 3MF, its matching G-code, model, and used channels. A source error blocks adding the job; a temporary lack of compatible printers does not.
The background router reads pending work in queue order, or SJF order when enabled.
It looks for a printer of the required model and location with a complete suitable set of feeds. Each used channel needs its own source.
Among eligible printers, one ready to start wins. The job moves to that printer's queue with its routing rules; if no candidate exists, the panel shows a waiting reason.
The printer queue applies its usual plate-clear, drying, staggered-start, and swap-macro gates. Filament and source checks run again before the actual start command.

SJF + starvation guard¶

When Queue Shortest First is enabled (Settings → Printing → Queue & Scheduling → Auto-Queue Routing → Queue Shortest First), pending rows are sorted by:

ORDER BY been_jumped DESC,
         estimated_print_time_seconds ASC,
         position ASC

The been_jumped sticky bit prevents starvation: every time SJF promotes a shorter print past a longer one, the longer one gets been_jumped=True and floats to the top of the next round regardless of its print time. This way a 14 h print can't sit indefinitely behind a stream of 30-min jobs.

When the toggle is off, items dispatch in FIFO order (by position).

Settings¶

Settings → Printing → Queue & Scheduling → Auto-Queue Routing:

Setting	Effect
Queue Shortest First	Enables SJF + the starvation guard. Default: off (FIFO).

The router itself is always on — there's no master switch. If no auto-queue items exist, the scheduler is a 30 s no-op.

Adding to the auto-queue¶

Choose the entry point that fits your workflow:

Open Print for a library file or archive and choose Auto.

Field	Meaning
Target Model	The exact model from the sliced file. An empty selection means detect it from the 3MF, not allow any model.
Target Location	An optional printer-location restriction.
Filament source	Automatic: AMS or external spool; AMS only; External spools only.
Force exact color match	Off by default: exact colours are preferred, but another compatible colour is allowed. Material and nozzle requirements remain.
Allow match by base material	On by default: compare base materials, such as `PETG`, rather than vendor or profile names — the family's material when the catalogue knows the profile, the material the file declares when it does not. No profile id refuses while this is on. Turn it off to require the profile type and, where known, its variant.
Plate channels	Material and color for each used channel; Require this color pins one channel's color.

Below the fields, AMS connected / Without AMS / AMS state unknown groups show compatible and ready counts separately, with reasons. A valid job may be added with zero counts and wait. A source-reading error must be resolved before adding it.

For a library file, the same dialog carries an Order field — the open orders that still need this plate, ranked so the ones that need it come first (a reprint from an archive keeps the original print's own filing, so it is not asked again). Choosing one files the item under that order and, where the plate belongs to exactly one of its lines, under that line too, so the order's plan stops asking for work you have already queued. Without an order is always available. See Filing a print under its order.

2. Virtual Printer `auto_queue` mode¶

Slicer "Send to Printer" → VP saves the file in the library → validates its plate → adds it to Auto-Queue. See Virtual Printer → auto_queue for the UI side.

The router chooses the machine under the job's rules. Plate-clear confirmation and the other start gates still apply.

3. Drag-and-drop on the Auto-Queue panel¶

Drop as many sliced files as you like anywhere over the Auto-Queue panel at the top of the Queue page. Each is uploaded into the library root, and then the files that would be answered the same way are grouped — one Print Modal per group, with a group 1 of 3 · 12 items badge — locked to Auto mode (no specific/auto toggle, no printer picker, the Auto rules: model, location, filament source, and colors).

Each item's target model is pinned to that file's own sliced_for_model, and cannot be changed. Per file, not per run: two files sliced for two different machines keep two different targets in one drop. Setting it explicitly rather than leaving it blank matters — blank means "work it out from the 3MF", which usually lands on the same answer but shows nothing on screen where the constraint is, so a run of ten files would say nothing about what any of them is waiting for.

A file with no recorded model is refused, by name, before the dialog opens. There is nothing to pin and nothing to verify; queueing it on a guess would leave an item waiting for a machine nobody chose.

The auto-mode form no longer offers a target the file cannot run on either. Choosing a mismatched model never failed — it produced an item waiting for a printer that would never take it, with nothing explaining the wait.

The Load from library button on the panel opens the same file picker, with every printable file offered rather than one machine's worth.

Permission-gated on queue:create. The panel renders even when empty so the drop target is permanently available; an empty-state hint nudges first-time operators.

Channel-specific choices belong to the file: after such an answer, the next file in the group opens for review.

4. REST API¶

POST /api/v1/auto-queue/
{
  "library_file_id": 42,
  "target_model": "P1S",
  "plate_id": 1,
  "feed_policy": "external_only",
  "force_color_match": false,
  "allow_base_material_match": true
}

Full schema in API reference. Quantity > 1 creates N rows in one call (same batch_id semantics as print_queue).

5. Order plans and Telegram¶

An order plan can send one row or the whole plan to Auto-Queue; plate validation happens before queue items are created. Telegram uses the same source validation. A large quantity does not relax color or feed rules.

AutoQueuePanel on the Queue dashboard¶

The Queue page has an Auto-Queue panel above the per-printer queue cards. Always rendered so the drop-zone is permanently available; when there are no pending auto items the panel collapses to a one-line hint inviting a drag-drop.

Since 0.5.5 the panel is a real queue, not just a pile:

Items list in true dispatch order. Adjacent copies of one submission collapse into a compact ×N row; the row expands into its individual copies.
Everything drags. A collapsed batch moves as a block, an expanded copy moves anywhere in the order — queue five copies of A, add two of B, pull one B to the front and leave the other at the end, and the list shows exactly that. With Queue Shortest First enabled the drag handles hide and a hint explains that the distributor owns the order.
Every copy edits in the full Schedule dialog — the same one the per-printer queue uses: target model and location, schedule, print options, macros. Editing a batch applies the change to all of its copies at once; a single copy can also be edited, deleted or force-assigned on its own.
Each row still shows thumbnail, name, plate, target model, estimated print time and the waiting reason when no printer is eligible.

Once an item is assigned to a printer, it disappears from the panel and shows up in that printer's queue card with a small "auto-assigned" badge.

Eligibility rules¶

The printer must be active, unarchived, available to the router, and free to take new work. The route icon on its queue card lets you opt it out of automatic assignment without stopping its ordinary queue.

It needs the exact model, the selected location, and a complete mapping for every used channel: material under the saved matching rule, nozzle, source rule, and required colours. One PLA slot does not satisfy two PLA channels. Manual physical selections cannot move arbitrarily between printers.

Among eligible candidates, readiness comes first, then the best color match. See Filament Routing for worked examples.

«Drain the emptiest spool first» picks the tray, not the printer

prefer_lowest_filament plays no part in choosing which printer gets the job. It decides, on the printer already chosen, which of its slots an equally-good match is mapped to: the one with the least filament left, so a nearly-empty spool is burned down instead of a fresh one. The same switch governs automatic matching for print-dialog and virtual-printer jobs. An explicit physical slot selection is retained instead of ranked again.

It is on by default and lives under Settings → Filament → Filament checks → «Drain the emptiest spool first». On BamDude's own dispatch paths — this router and the queue scheduler — it is additionally skipped for a printer whose AMS Filament Backup is off; see Print Queue for why.

Color, material, and profile variant¶

Colour and material are separate decisions. With Allow match by base material on, a custom PETG profile and Generic PETG match despite different names or vendors — including a profile this install cannot resolve at all, which is the usual shape when several people slice for one farm. With it off, a known tray_info_idx variant remains a restriction. A missing variant is never invented. See material matching and colour rules.

Routing is not dispatching¶

Choosing which printer a job belongs to and deciding when it may start are two different questions, answered in two different places.

The router only answers the first. It will hand a job to a printer that cannot start right now — one waiting for a Clear Plate confirmation, mid plate-change, drying, or held by staggered start. The job then sits visibly in that printer's queue until the printer is ready, and every safety check still applies at the moment it actually matters.

Before 0.5.1.2 the router refused to route to such a printer at all. That sounded safer and was not: the printer's queue stayed empty, so nothing on screen explained the hold-up, and the Clear Plate prompt — which appears on a printer's queue — never had a chance to show. Operators saw idle machines reported as busy and a farm that looked dead. Placing the work is what makes the reason visible.

A printer that is ready still wins when there's a choice.

Rebalancing across printer models¶

An order line's work is split between printer models when it is queued — by hand, or with the farm's proposal — and a queued copy belongs to its file's model. When the P1S machines free up faster than the forecast assumed, the X1C copies keep waiting in their own pile. Rebalancing lets the auto-queue move still-pending copies of an order line to idle printers of another model when that finishes the line sooner — including a model whose plate makes a different number of parts, in which case the plates and the number of prints are recalculated.

The rule. A pending copy moves only when all of these hold: its own model has no printer ready right now; the other model has at least one printer that is idle and ready (an empty queue is not enough — a printer still waiting for a plate clear only looks free); the line has a sliced file for that model with a print-time estimate; and the prints needed to cover the same parts there would finish no later than waiting at home. Among several models that qualify, the earliest finish wins, then the least surplus.

Parts, not prints. A copy is a claim on covering N parts. Moving a 6-part P1S plate to an A1 mini whose plate makes 2 parts turns one print into three; moving 2 parts onto a bigger bed turns them into one print with a surplus of less than one plate's worth, which lands on the shelf like any other surplus.

Three ways to run it.

Automatically — Settings → Printing → Auto-Queue Routing → Rebalance across printer models (off by default). The scheduler checks after every placement pass, moves at most one copy per idle printer per pass, and leaves a line alone for five minutes after a move.
Per line — the Rebalance button on an order line's plan, shown while the line has pending auto-queue copies. It runs regardless of the setting and ignores the five-minute pause.
Per copy — Rebalance on a pending row or a collapsed ×N block of the auto-queue panel. A row that cannot move says why.

What is never moved. A copy that is already handed to a printer, scheduled for a time, staged for a manual start, pinned to specific filament slots, aimed at a location, queued from an archive rather than a library file, or not filed under an order line. Those either belong to a printer already or carry a decision of yours.

What you see. A moved row carries a ← P1S badge on the panel, naming the model it was queued for before; the copies created with it share its batch. Routing, dispatch and filament rules are untouched: a moved copy is written by the same writer every enqueue uses and passes the same file and filament checks.

Estimates decide

Rebalancing compares the same print-time estimates the ETA uses. A file without an estimate is never chosen as a target, and a copy without one is treated as if it could start at home the moment a printer frees.

Drying takes lower priority than a print¶

Queue Auto-Drying keeps idle spools dry between prints. When Settings → AMS Display Thresholds → Queue Auto-Drying is in its default non-blocking mode (queue_drying_block=false, "prints take priority over drying"), a job queued directly to a printer already stops an in-progress dry cycle and starts printing.

The auto-queue router behaves the same way, and since 0.5.1.2 it does so by ranking rather than excluding: a printer that is free to take work but currently drying still receives jobs, it simply loses to one that can start immediately. The per-printer dispatch then stops the dry cycle and begins the print (the same _stop_drying step described in AMS → Queue Auto-Drying flow).

When Queue Auto-Drying is set to blocking (queue_drying_block=true), drying still holds the queue — the job waits in that printer's queue until the dry cycle ends, exactly as a directly-queued item would.

Behaviour added in 0.4.5

Before 0.4.5 the auto-queue treated a drying printer as plain "busy" and skipped it, so an auto-routed job could sit waiting behind a dry cycle even though a directly-queued job would have taken priority. This is most noticeable on P2S / H2 farms with AMS auto-drying enabled.

AMS mapping at assign time¶

Mapping is computed from the chosen printer's current sources and the job's saved rules. The printer-queue item keeps those rules independently of the original Auto-Queue row.

Checks repeat before preparation and immediately before the start command. A changed spool, connection, file, or current job can return the print to waiting with a reason; a partial mapping is not sent. See Before printing.

Cancel / edit semantics¶

Action	Effect
Cancel a `pending` auto-queue item	Row deleted. No printer ever saw it.
Cancel an `assigned` auto-queue item	Cancels the per-printer queue item the router created. The auto row stays in `assigned` for audit.
Edit a `pending` item	The full Schedule dialog — target model / location, schedule, print options, macros. A batch edit applies to every copy; a single copy edits alone.
Edit after assignment	Edit the per-printer queue item instead.

When to use it¶

Use case	Recommendation
Single printer	Skip the auto-queue, use the regular per-printer queue — no router overhead, simpler UI.
2-3 printers, one model	Auto-queue is great for load-balancing — drop jobs in, the scheduler picks the next free one.
Mixed-model farm	Auto-queue with explicit `target_model` per job — same load-balancing within the model, no cross-pollination.
Color-critical jobs (logos, signage)	Turn on `force_color_match` so a job won't dispatch to a printer with the wrong color loaded.
Hands-off slicer flow	VP `auto_queue` mode + auto-queue → routing under the job's rules with the usual start gates.

Migration from per-printer queues¶

Per-printer queues remain the way to choose a specific machine; Auto-Queue defers that choice. Both paths apply complete filament checks before starting.

After an upgrade, older jobs retain established source restrictions and physical selections. If there is not enough saved evidence to recover their rules, mapping review is required. Schedule edits, copies, and repeats retain the rules; a different printer or plate requires a new answer for a manual mapping. See Editing and repeats.