Files
bambuddy/backend
maziggy eee94ce9c8 File the printer's calibration table under the nozzle it belongs to (issue #2854)
The K value on an AMS slot card went blank after a while and came back after a
    backend restart. It is not the MQTT merge: that preserves a tray's k correctly.
    H2-series trays have no k to preserve. Verified against the H2 wire capture in
    logs/vp_wire -- every tray reports cali_idx and nothing else -- so the number on
    the card is resolved from that index against the printer's calibration table in
    state.kprofiles, and that table was a single global list.

    An extrusion_cali_get response is the complete table for one nozzle diameter,
    and the printer answers whoever asks; BambuStudio's queries arrive on the same
    report topic we subscribe to. Every response was assigned straight to
    state.kprofiles, so any one answer stood for the whole printer. The nightly
    GitHub backup asks for 0.2, 0.4, 0.6 and 0.8 in turn and finishes on 0.8, which
    holds nothing on a 0.4+0.6 machine: logs/bambuddy.log records exactly that at
    17:15 on 2026-08-25, and the table was empty from then until something refilled
    it. Responses are now bucketed by the diameter they describe, so an empty answer
    for a size the printer does not have clears only that size. The three assign
    paths that look an index up by nozzle_diameter get the same fix for free -- they
    were quietly finding nothing whenever the last response was for another nozzle,
    which is what spoolman_inventory has been logging as a stale kp.

    Bucketing makes state.kprofiles a union, and cali_idx is numbered per nozzle, so
    the index alone no longer identifies a profile. The REST serializer has keyed on
    (extruder, cali_idx) since c5e005586; the WebSocket one still keyed on the index
    alone, which meant the first render of a card could be right and every update
    after it wrong. Both now share one resolver. It goes through the extruder the
    slot feeds, and where that does not single out one profile -- a single-nozzle
    printer that has been swapped, so both its tables sit under extruder 0 -- it
    falls back to which diameters are actually fitted. Where neither settles it the
    card shows nothing, because a blank space is a smaller error than confidently
    printing the other nozzle's number. Deliberately no loosening to a bare cali_idx
    lookup on a miss: that is the cross-nozzle bleed the extruder keying was added
    to stop.

    Nothing read the table on connect, which is the other half of the report. It
    arrived by luck -- a visit to Profiles or Configure Slot, a backup, or the
    printer answering someone else -- so a Bambuddy nobody had opened showed a card
    with no K values at all, and "restart and they come back" was the printer
    happening to broadcast rather than anything we did. It is now read once per
    connection, on the same latch the stale-print reconcile uses. Only the fitted
    diameters are asked for, one request on a single-nozzle printer and two on a
    dual; probing the four sizes blind is what the backup does and what blanked the
    table. The edge is gated on a nozzle diameter being known as well as on the
    state being known, because the first push_status is what makes the state known
    and does not always carry the nozzle fields -- latching there would spend the
    connection's one attempt on a printer that could not yet say what was fitted.

    Adopting an unsolicited table now logs at debug. It was the quietest way for the
    card to change underneath us and there was no way to see it in a support bundle.

    Three test files gained nozzles=[] on their PrinterState stubs. The field has
    always been on the dataclass; the connect edge is simply the first thing on that
    path to read it.
2026-08-26 10:22:31 +02:00
..