Files
bambuddy/backend
MartinNYHC 9b83e8eba4 Send AMS tray colours as uppercase hex (issue #2987)
Assigning a spool to an AMS slot unassigned it again seconds later, and
    the slot's colour changed at the same time. It presented as Bambu Studio
    and Bambuddy fighting over the slot. The reporter's log shows Bambuddy
    losing to itself.

    P1S firmware 01.10.00.00 reads every lowercase hex letter in an AMS
    tray_color as a zero, and hides it completely: the command response
    echoes back the value that was sent and reports result "success", so
    only the next AMS push says what was really stored. The spool-assign
    path sent spool.rgba verbatim and that column stores lowercase. From the
    bundle:

      sent 09ff00ff  ->  AMS reports 09000000
      sent ff5100ff  ->  AMS reports 00510000
      sent 090000FF  ->  AMS reports 090000FF

    That is the visible colour change, and it is also what deleted the
    assignment. The auto-unlink sweep asks whether the slot still matches
    the spool assigned to it; the mangled colour no longer did, so the
    assignment Bambuddy had made four seconds earlier was removed.
    colors_similar('09000000', '09FF00FF') is False, which is the whole of
    it.

    Re-assigning could not recover, because the Configure Slot dialog seeds
    its colour from whatever the printer currently reports. It wrote the
    mangled colour back and cemented it, which is the loop the report
    describes in its steps 4 and 5.

    Colours are now uppercased where the command is assembled rather than in
    each of the four routes that configure a slot. A caller that forgets is
    exactly how this arrived. Nothing else changes: no padding, no invented
    alpha, no six-to-eight widening, and tray_type and tray_sub_brands keep
    their case, where it carries meaning -- "PLA Matte" is a product line,
    "PLA MATTE" is not.

    Two paths deliberately left alone. The developer-mode probe re-sends the
    colour the printer itself just reported so that the probe is inert;
    uppercasing there would turn it into a write. And the Virtual Printer
    forwards the slicer's own command verbatim -- Studio could in principle
    hit the same firmware bug, but nothing here evidences that it sends
    lowercase, and rewriting a slicer payload inside a transparent proxy is
    not a change to make on a hunch.

    Two more defects from the same log.

    A spool with a brand and no subtype was configured with the string
    "None" in its name: the branded branch interpolated spool.subtype
    without checking it while the unbranded branch guarded it, so
    "Sunlu PLA Matte None" went on the wire and into Studio's display.

    And the FTP log is readable again. A 426 whose bytes Bambuddy has
    already verified against the printer is how Bambu FTPS normally ends a
    transfer, not a fault, so it drops from WARNING to INFO. It fired 54
    times in this one bundle, every one followed by a completed upload, and
    it was burying the 26 TLS handshake failures in the same log that
    actually cost the reporter two prints. A 426 whose bytes do not verify
    is still an error and still fails the upload.

    The handshake failures themselves are printer-side FTPS cool-off under
    load and are not touched here.
2026-08-28 12:44:49 +02:00
..
2025-11-28 10:23:59 +01:00