maziggy 88ae595268 fix(dispatch): honor a resolved AMS mapping over a stale use_ams=false (#2595) ...

A print sliced against a Virtual Printer carries use_ams=false — a VP
advertises no AMS, so the slicer sends it and VP intake stamps it on the
queue item. But an "Any [model]" item is colour-matched to a real printer
at dispatch, resolving a real AMS slot in ams_mapping. The command builder
only ever forced use_ams off (all-external) and never back on, so the stale
false shipped with a real-tray mapping and the printer aborted at layer 0 on
the empty external spool.

For single-nozzle printers the mapping is now authoritative: a real tray
(0-253) forces use_ams=true, explicit external (254/255) forces it false,
and an unresolved -1 does neither (preserving the #2589 contract).
Dual-nozzle is untouched — use_ams is nozzle routing there. The correction
sits at the single command-builder choke point, covering the VP, queue, and
manual paths.

2026-07-18 13:18:59 +02:00

..

app

fix(dispatch): honor a resolved AMS mapping over a stale use_ams=false (#2595)

2026-07-18 13:18:59 +02:00

tests

fix(dispatch): honor a resolved AMS mapping over a stale use_ams=false (#2595)

2026-07-18 13:18:59 +02:00

__init__.py

…