mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-10-18 11:56:01 +02:00
Show which Filament Track Switch inlet each AMS feeds
With a switch fitted, an AMS is not wired to a nozzle any more. It is plumbed into one of the switch's two inlets and reaches both nozzles through it, so every unit reports its extruder as "not fixed" (0xE) and ams_extruder_map comes back empty on these machines. The printer card had nothing to fall back on but the AMS unit number, so AMS-A was badged R and AMS-B was badged L purely because their unit ids are 0 and 1, a third unit got no badge at all, and every one of those labels was wrong. The SpoolBuddy assign modal had the same fallback in a worse form, mapping anything that was not extruder 1 to R. The binding turned out to need no new telemetry. BambuStudio reads it out of bits 24-27 of the same AMS info string we already parse for the AMS type and the extruder id -- 0 is In-B, 1 is In-A -- and it is only meaningful when a switch is installed, because without one 0xE really does mean an uninitialised unit and those bits carry nothing. That gates the read, which in turn forced the switch block to be parsed before the AMS block: _handle_ams_data runs early in _process_message and _update_state only much later, so the binding was lost on every frame that carried both. _parse_fila_switch is split out and called first, and left in _update_state as well so that stays a complete absorb step. The badge keeps L and R rather than A and B, because the lettering is familiar and matches the physical layout. It is a different colour from the plain nozzle badge, and its tooltip names the inlet in full, since the letter is the inlet's position and not a claim about which nozzle that AMS feeds -- the switch can route either inlet to either outlet. An AMS still reporting a real extruder id keeps its ordinary badge, which BambuStudio also treats as authoritative over any switch binding, and a switch that has been fitted but not yet set up on the printer shows nothing rather than a guess. The print dialog's slot dropdown gets the same label. It replaces a left/right hint that never once rendered: ftsExtruderForSlot compared snow-encoded in[] values against global tray ids and could not match. Decoding it correctly would not have saved it -- the firmware reports which slot sits in each inlet and which nozzle each outlet feeds, but never which inlet is currently paired with which outlet, so no per-slot nozzle can be derived. That function is gone rather than fixed. The dialog also points out when every filament a print needs sits behind one inlet. Bambu's own guidance is that this is legal but slow: a change between two filaments on the same inlet retracts the outgoing spool all the way back to its AMS before the next can be fed up the shared tube, where a change across the two inlets only retracts as far as the switch. All on one inlet means every change in the job takes the slow path, and moving a single spool fixes it. So it advises, it does not block. Both views update live. Two things were stopping that. fila_switch and ams_switch_inlet were absent from printer_state_to_dict, and the frontend shallow-merges each WebSocket push over its cached status, so a field the push omits keeps whatever the last full fetch left behind. And the broadcast dedup key had no term for either, so "Join IN-B" on the printer screen moved nothing: the binding is not in the tray component of that key, and it is not in the AMS change-hash either, which covers tray fields only and must stay that way because it drives Spoolman sync. Assigning an AMS to an inlet remains printer-side. BambuStudio can read the binding and has no command to write it -- its switch class is parse and getters only, and the recommended-arrangement popup draws and publishes nothing -- so there is no wire format for us to copy. Adding the two fields to PrinterState broke four test modules whose SimpleNamespace stubs predate them. The stubs are fixed rather than the production reads made defensive: the real dataclass always carries both, and a getattr in the dedup key would silently stop tracking the field if it were ever renamed.
This commit is contained in:
@@ -492,14 +492,21 @@ export interface PrintOptions {
|
||||
|
||||
export interface FilaSwitchState {
|
||||
installed: boolean;
|
||||
// in[track] = currently loaded slot for that track (-1 = empty)
|
||||
// Raw wire arrays, ordered **In-B first, then In-A** (BambuStudio's SwitchPos
|
||||
// enum). in[] values are snow-encoded (bits 8-15 = AMS id, bits 0-7 = slot,
|
||||
// -1 = empty); out[] values are the extruder each *outlet* terminates at, or
|
||||
// 0xE when unset. Neither array says which inlet is currently routed to which
|
||||
// outlet — that pairing is not reported. For per-AMS side information use
|
||||
// PrinterStatus.ams_switch_inlet instead.
|
||||
in_slots: number[];
|
||||
// out[track] = extruder this track terminates at (0 = right, 1 = left)
|
||||
out_extruders: number[];
|
||||
stat: number;
|
||||
info: number;
|
||||
}
|
||||
|
||||
// Which FTS inlet an AMS is plumbed into: 'A' | 'B'.
|
||||
export type FtsInlet = 'A' | 'B';
|
||||
|
||||
export interface PrinterStatus {
|
||||
id: number;
|
||||
name: string;
|
||||
@@ -565,6 +572,11 @@ export interface PrinterStatus {
|
||||
// AMS slots aren't tied to a specific extruder; the FTS routes any slot to
|
||||
// either extruder, so per-extruder slot filtering must be skipped.
|
||||
fila_switch: FilaSwitchState | null;
|
||||
// Per-AMS FTS inlet binding, {ams_id: 'A' | 'B'}, as set on the printer's
|
||||
// "Manual AMS Setup" screen. Empty unless a switch is installed. An AMS with
|
||||
// an entry here reaches BOTH nozzles through the switch, which is why it has
|
||||
// no ams_extruder_map entry and must not be badged left or right.
|
||||
ams_switch_inlet: Record<string, FtsInlet>;
|
||||
// Currently loaded tray (global tray ID, 255 = no filament loaded, 254 = external spool)
|
||||
tray_now: number;
|
||||
// Runout / filament-replacement guidance (#2587). Populated only while PAUSED.
|
||||
|
||||
Reference in New Issue
Block a user