Post work PR #3011

This commit is contained in:
maziggy
2026-09-30 16:19:35 +02:00
+1
View File
@@ -45,6 +45,7 @@ All notable changes to Bambuddy will be documented in this file.
- **The frontend build no longer warns about `path` and `crypto` being externalized for the STEP previewer (#2976)** — `occt-import-js`, the Emscripten build behind STEP previews, requires both modules, but only inside its `ENVIRONMENT_IS_NODE` branches; in the browser it loads its `.wasm` from the URL the preview worker passes and draws randomness from `crypto.getRandomValues`. Vite still externalized both and printed two warnings on every build. `vite.config.ts` now drops exactly those two warnings for that one package through `build.rolldownOptions.onLog`, so an externalization anywhere else, or of any other module, still shows.
### Fixed
- **A Spoolman spool's own empty spool weight is saved, so weigh-ins subtract the right tare (#2908, reported and contributed by @ojimpo in #3011)** — Spoolman keeps an empty spool weight per spool, and Bambuddy already read it ahead of the filament type's. It never wrote it: the Inventory form hid the picker behind "Empty spool weight is managed per filament type in Spoolman", and the backend dropped the value on create, bulk create and edit. A spool whose real empty weight differs from its filament type's, for example a 180 g third-party spool against Bambu's 250 g, recorded a wrong remaining weight on every weigh-in. The picker now shows in Spoolman mode and saves to the spool. It is sent only when you change it, so a spool you don't touch keeps following its filament type. Copying a spool keeps its own empty weight, and a 0 g empty weight (a spool-less coil) loads as 0 instead of 250. The SpoolBuddy quick-add no longer sends a placeholder 250 g, and Inventory's bulk edit, whose Empty Spool Weight field was silently ignored in Spoolman mode, now applies it.
- **SpoolBuddy showed a multi-colour or effect spool as one flat colour (#3033, reported by @Sawtaytoes)** — The Filament page paints a spool's extra colours and effect: a blue-and-yellow split, a marble swirl, a galaxy sheen. SpoolBuddy drew every spool from its main colour alone, so a blue-and-yellow Silk spool was a blue disc, and three Galaxy Black spools were three identical black discs, on the screen used at the printer to pick the spool to load. The spool discs on the Inventory cards, the spool details, the tag-scanned and link-tag screens, and the small colour dots on the Inventory cards, the AMS slot menu, the Assign to AMS screen and the Write Tag screen now use the same painter as the Filament page whenever a spool has extra colours or an effect. A plain spool looks as before. A scanned tag now also sends the spool's extra colours and effect to SpoolBuddy, which it did not before. Spoolman spools show their extra colours; Spoolman has no effect field, so they show no effect.
- **HMS faults show Bambu's own description and the right level, and faults Bambu publishes no text for no longer vanish (#2728, reported by @gzimbric)** — Two problems in how printer faults were shown, both in the same path. **No description for most faults.** A fault from the printer's `hms[]` list is identified by a 16-digit code, but Bambuddy's table of descriptions only had the 8-digit codes of the other kind of fault (`print_error`), and the lookup cut the 16-digit code down to a shape that could never match a real one. So those faults never got text, and the printer card only showed them if they happened to offer action buttons. On the reporter's P2S, three faults the printer was holding showed nothing at all. Descriptions now come from Bambu Studio's own HMS files: about 6,400 codes, with the text for your printer model where models differ (`0300_8001` means "paused by the user" on some models and "paused by a pause command in the file" on others). The 24 texts Bambuddy had that Bambu Studio doesn't are kept. `scripts/generate_hms_catalog.py` regenerates the table from a Bambu Studio checkout. **Wrong level.** The level was read from the part of the code that names the printer part, not from the level the printer sends, so a fault that paused the print could show as blue "Info" and a mere notice as red "Serious". It now uses the printer's level, the way Bambu Studio reads it: **Error** (print stopped), **Warning** (print paused), **Notice** (print carries on). The printer card turns red for Error and Warning, amber for Notice only. A `print_error` has no level of its own, so it takes one from its error number (4xxx Error, 8xxx Warning, Cxxx Notice) instead of always showing Warning. **What counts.** A fault counts toward the printer card, the problem badge and the Camera Wall when it offers action buttons, or when Bambu publishes text for it, except an `hms[]` Notice with no buttons: those are things like "The top cover is open" or "the chamber is hot, fan speed increased" that a printer can hold through a whole print. A `print_error` prompt at the Notice level still counts, as before. Faults that don't count are no longer hidden: the error modal lists them, with their text where Bambu has one, collapsed under **Also reported, not counted**, and **Clear Errors** shows whenever the printer holds any fault. **Notifications and the MQTT relay** follow the same rule. Printer-error notifications now also go out for `hms[]` faults that count and have a description, which before this almost never happened, and the relay's error topic carries the faults that count; the H2S cancel echo, which the old check dropped only by accident, stays out. The old check that was meant to skip minor messages read the wrong field, and on the real level it would have skipped the faults that stop a print (spotted by @ojimpo). A fault already notified was recognised by the printer part alone, so a second fault on the same part, such as the two #1840's H2C held at once (`0500-0600-0002-0005` and `-0006`), was never notified; each fault is now recognised by its full code. **Other changes.** The queue's failure message labels an `hms[]` fault with its full code, as the printer screen shows it, such as `0500-0300-0002-000E`, instead of a short code nobody can look up. The status response, WebSocket and Camera Wall carry `description` and the new `severity` values; anything that reads `severity` through the API or the MQTT relay will see different numbers for the same fault. The level labels and the new modal text are translated in all 15 locales.
- **A print the printer's AI camera stopped for spaghetti is archived with a failure reason (#2946, reported and contributed by @ojimpo in #2954)** — When the onboard AI print monitor halts a print for spaghetti or a model coming off the plate, the printer raises HMS code `0300_8003`. That code was missing from the list Bambuddy uses to name a failed print's reason, so the archive was saved with no reason at all, even though its neighbour `0300_8004` (filament runout) was on the list. `0300_8003` and `0C00_8042`, the same AI detection reported from the motion-controller module, now archive as **Spaghetti / Detached**, the option the archive editor already offers, shown in your language. Two nearby codes are left out on purpose: `0C00_C004` ("Possible spaghetti failure was detected") is a warning while the print keeps running, and `0300_800A` is a filament pile-up in the waste chute, not a failed print. Archives saved before this keep their empty reason and can be set by hand. New tests also check that the failure reasons the backend accepts match the ones the archive editor offers, and that every one has English text.