Files
bambuddy/backend/app
maziggy 999f5e0afe fix(ams): read the firmware presence bit, not the tray state (issue #3084)
Swapping a Bambu spool for one the AMS cannot read left Assign Spool
    publishing no ams_filament_setting at all. The printer kept showing "?"
    on its screen and in the slicer, and only Configure, which publishes
    unconditionally, put anything there.

    Four places asked the tray's `state` field whether a spool was in the
    slot. It cannot answer that. An AMS-HT reports its LOADED tray as 9
    rather than 11, because it does not feed into a shared buffer the way a
    4-slot AMS does -- the merge has skipped its own state heuristic for HT
    units since #2594 for exactly this reason. And the field is partly our
    own writing: apply_tray_exist_bits stamps state=9 on every slot whose
    tray_exist_bits bit is 0, and when the bit comes back it refreshes only
    the `exists` annotation beside it. Either way the slot sits at
    exists=True, state=9 until something configures it.

    That 9 also kept the deferred-configuration replay from firing -- its
    own "has a spool appeared" test was the same heuristic -- which is the
    deadlock #1322 removed from the assign path, still in place one step
    further along. And it is what deleted the assignments in #3100: with the
    replay never firing, the row kept the empty fingerprint it was stored
    with, and the first tray report naming a filament was read as a swap.

    All four now read tray_exist_bits first, which is the mask firmware
    answers this question with and the one the printer card has drawn its
    "?" from since #2527. The bit is allowed to overrule an "empty" state
    and nothing else: a bit reading empty deliberately does not start
    suppressing pushes that go out today, because the cost of computing a
    bit position wrong is a slot that silently stops configuring, against a
    saving of one message firmware would have dropped.

    A blank tray report from a slot the bit calls occupied no longer unlinks
    anything, off a print as well as during one, in both inventory modes --
    Spoolman's parse_ams_tray calls a tray with no type empty, so a tag-less
    spool assigned through the UI had its row deleted by the first idle push
    after it went in. A filament the AMS cannot identify is not a filament
    that was removed.
2026-09-20 13:40:30 +02:00
..
…
…
…