From 88e8ca81c31fd488214f0f65ac8449059dd364c0 Mon Sep 17 00:00:00 2001 From: maziggy Date: Sat, 22 Aug 2026 11:41:28 +0200 Subject: [PATCH] Give an AMS slot a material type, not a product name (issue #2902) Assigning a spool wrote its material straight into the slot's tray_type. A slot that says "PLA+" satisfies nothing that asks for PLA: not OrcaSlicer, not Bambu Studio, and not Bambuddy's own dispatch matcher, which compares the type the printer reports to the one the 3MF declares as plain equality. The reporter's slot was unusable for every PLA plate he had. Not only a label, either. The same string went into the generic-filament lookup, which missed, so the slot went out with no tray_info_idx at all -- the half-configured state #2604 documents the printer as reverting from -- and took the 200/240 catch-all nozzle range instead of PLA's 190/230. PLA+ is not a special case. Bambuddy's own colour catalogue supplies the material dropdown, and around forty of its values are vendor product lines rather than filament types: HTPLA, PolyTerra PLA, PLA Matte, ASA Extrafill, Flexfill TPU 98A. So the four routes that configure a slot reduce the material to a name the printer knows before sending it, and the product name moves to tray_sub_brands -- which is where Bambu Lab puts it too: their catalogue carries a preset named "eSUN PLA+" whose type is PLA. A name the reduction cannot place is sent exactly as before rather than guessed at, so this can only repair a slot, never break a working one. The spool's own wording still leads the id and temperature lookups with the reduced type appended behind it, so "PETG HF" keeps its own generic preset (GFG96) rather than being traded down to plain PETG's. Two guards decide whether a candidate filament id is really a material name -- the resolver's, which discards one, and slot reuse, which will not carry one forward. Both saw only bare types, so "PLA+" passed as a filament id. They share one answer now, which also refuses to read an id-shaped value: "GFPLA" ends in a material name, and reducing it would throw away the calibrated preset in the slot. One thing had to move with it. on_ams_change auto-unlinks an assignment whose slot stopped looking the way it did when the spool was assigned, and the check that spares a slot Bambuddy itself reconfigured compared the printer's reported type against the spool's raw material. With the slot now carrying the reduced type, every spool this issue is about would have been unlinked from the slot it had just been assigned to. Both sides are reduced there -- the printer's too, so slots configured by an older version, still reporting "PLA+", keep matching. Something starts working as a result: a slot holding a calibrated preset is reused when a same-material spool is assigned to it, which could not happen for these spools while "PLA" and "PLA+" compared unequal. Reverting any one of the behaviours above fails a distinct test -- the reduction's four matching rules and its pass-through contract included, since that contract is what makes the rest of it safe. --- CHANGELOG.md | 1 + backend/app/api/routes/inventory.py | 27 +- backend/app/api/routes/printers.py | 19 +- backend/app/api/routes/spoolman.py | 26 +- backend/app/api/routes/spoolman_inventory.py | 26 +- backend/app/main.py | 16 +- .../app/services/slicer_filament_resolver.py | 18 +- backend/app/utils/filament_types.py | 170 +++++ .../test_ams_slot_material_2902.py | 625 ++++++++++++++++++ .../utils/test_printer_filament_type_2902.py | 191 ++++++ 10 files changed, 1090 insertions(+), 29 deletions(-) create mode 100644 backend/tests/integration/test_ams_slot_material_2902.py create mode 100644 backend/tests/unit/utils/test_printer_filament_type_2902.py diff --git a/CHANGELOG.md b/CHANGELOG.md index a6d85d1d4..955f412be 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -9,6 +9,7 @@ All notable changes to Bambuddy will be documented in this file. - **The K value is on the AMS slot itself, not only in the popover (#2532, requested and contributed by @gyrene2083)** — Reading back a slot's pressure-advance value meant hovering it: the K factor lived in the filament popover alone, so checking whether a calibration had actually taken across four slots was four hovers, and comparing two of them side by side was not possible at all. Every slot card now carries the value under the material name, the way Bambu Studio shows it per slot — on regular AMS units, on AMS-HT, and on the external spool of a dual-nozzle machine. Only a value the printer actually reported is shown: a loaded but never-calibrated slot stays blank rather than inheriting the 0.020 that fills the popover's own field, and a slot the firmware reports as exactly 0 counts as uncalibrated the same way the stored K-profiles do. The label is shortened to **K** with the full localized name on hover, because "K Factor", "K-Faktor" and "Facteur K" ate the value itself — the whole point of the line — on cards under about 350px, and the figure is set in tabular numerals so it measures the same in Safari as in Chromium. Where one slot of a unit is calibrated and its neighbours are not, the neighbours hold the same row open so the fill bars stay level across the card. ### Fixed +- **An AMS slot assigned a PLA+ spool became unusable for PLA (#2902, reported by @doncaruana)** — Assigning a spool wrote its material straight into the slot's `tray_type`, and a slot that says "PLA+" satisfies nothing that asks for PLA: not OrcaSlicer, not Bambu Studio, and not Bambuddy's own dispatch matcher, which compares the printer's reported type to the one the 3MF declares. The same string then missed the filament-id lookup, so the slot went out with no `tray_info_idx` at all — the half-configured state a printer reverts from — and took the generic 200/240°C nozzle range instead of PLA's. PLA+ is not a special case: Bambuddy's own colour catalogue supplies the material dropdown, and about forty of its values are vendor product lines rather than filament types — HTPLA, PolyTerra PLA, PLA Matte, ASA Extrafill, Flexfill TPU 98A. All four routes that configure a slot now reduce the material to a type the printer knows before sending it, and the product name moves to `tray_sub_brands`, which is where Bambu Lab itself puts it — their catalogue has a preset named "eSUN PLA+" whose type is PLA. A material that cannot be placed is sent exactly as before rather than guessed at, so this can only repair a slot, never break a working one; and a material that already had a preset of its own keeps it, so "PETG HF" is not quietly downgraded to plain PETG. One thing that starts working as a result: a slot holding a calibrated preset is now reused when a same-material spool is assigned to it, which for these spools could never happen before. - **A failed upload told you to check the SD card, whatever had actually gone wrong (#2899, reported by @grolmus)** — Every dispatch upload that failed carried the same sentence: "Failed to upload file to printer. Check if SD card is inserted and properly formatted (FAT32/exFAT)." The reporter got it after a TLS handshake failure and restarted the printer on the strength of it. That could not have helped — the handshake never reached the printer's filesystem, and the cool-off that made the next dispatch fail identically lives in Bambuddy's own memory, where power-cycling a printer does not reach. #2780 had already taken operator advice out of this failure's log line, for exactly the reason that the advice was known not to work; it survived in the string people actually read. The information to say something true was never missing. The FTP client separates five connect failures and three upload reply codes, each with its own log line — 553 even gets a spelled-out list of storage causes — and then handed the caller a bare true-or-false, so the dispatch had nothing to go on and guessed storage for all of them. The reason now travels with the result, and the message is chosen from it: a 553 or 552 keeps the card advice, which is the case it was written for, and quotes the printer's reply code so a queue entry and a support bundle can be lined up. A handshake failure says the file service answered without TLS and that the card is not involved. A refused connection points at the access code, a timeout at the network, and anything the client could not classify says so and points at the log rather than picking a plausible cause — a wrong instruction costs more than a vague one, because it sends someone to work on hardware that is fine. No message prescribes a power cycle, which is the restraint #2780 settled on. The failure notification carries the same sentence the queue shows, rather than its own fixed "Failed to upload file to printer", so a push and the screen can no longer disagree. - **One handshake failure took out three queued jobs and every retry they had (#2898, reported by @grolmus)** — A print dispatch that met a TLS handshake failure spent its whole retry budget without opening a single socket. The cool-off that a failed handshake arms (#2780) lives inside `connect()`, so it applied to everything — including the dispatch, whose four attempts two seconds apart were all answered from the gate rather than the network. The reporter's farm logs the shape exactly: the delete that clears the way for the upload took the SSL error at 11:10:04.956, the upload's first attempt started 8ms later, and attempts two through four took one to two milliseconds each. Because the cool-off runs for five minutes, the next two jobs queued for that printer failed the same way inside the same window, and on that farm the failure is transient — a manual connect a second later completes cleanly — so the retry the gate suppressed is the one that would have worked. The gate was serving two callers that want opposite things from it. The background sweeps that fetch a 3MF, a cover or a timelapse after a print walk about a hundred and ten candidate paths against one wedged printer with nobody waiting, and backing off for minutes is right for them; they keep today's behaviour untouched. A dispatch is one delete plus at most four upload attempts with someone watching a progress bar, so it now ignores the cool-off, as does a firmware upload, for the same reason. Callers that do respect the cool-off no longer sleep out a retry loop against it either: the loop stops at the attempt that armed the gate and says so, instead of spending three more attempts and six seconds on connections that cannot happen. What made this a log dive rather than a glance is fixed with it: the cool-off skip was the one connect failure that reported without naming its cause, and did so at debug level, so four identical reason-free warnings were all the operator saw. It now says at warning level that nothing was sent and how long the printer has left — once per cool-off rather than once per attempt, so that raising it does not recreate the log flood #2780 set out to stop. - **Archived projects crowded out the live ones in every project picker (#2888, reported by @e77)** — The reporter files each job under its own project and archives it when the job is done, so five active projects sat behind thirty-odd finished ones in the Project dropdown of the Edit Archive dialog — an unscrolled list of everything ever created, with no way to tell which entries were still live. That dropdown, the one on the pending-uploads panel, the bulk "Add to Project" dialog and the File Manager's folder link now leave archived projects out. Completed projects stay: a project marked completed says the work is done, not that it should be hidden, and filing a reprint under one is ordinary. The Archives right-click submenu had gone the other way and offered active projects only, so a completed project was reachable from the Edit dialog and not from the menu beside it; all five surfaces now apply the same rule. Whatever an archive is already filed under stays on its own list whatever its status — a `