|
|
@@ -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 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.
|
|
|
- **A drying command the AMS never started no longer shows as an active cycle, or holds the queue forever (#2896, reported and contributed by @M2ABRAMSTANK in #3096)** — A printer can accept an AMS drying command and set its timer without ever starting the cycle. On the reporter's H2D, mid-print, two AMS-HT units were counting down and heating while a third sat at 720 minutes, cold, and its card still showed the amber drying badge. Bambuddy now notices when a unit's countdown hasn't moved for 150 seconds while the AMS reports no drying phase. A live countdown moves once a minute, so a real cycle is never mistaken for one. The card then shows a grey **Drying not running** badge instead, without the countdown and with Stop still available. It says "not running" rather than "not started" because a cycle paused partway looks the same. If the AMS does report checking, drying or cooling, it always counts as drying. The same timer also never reaches zero, so everything that waited for drying to end waited for good. With **Block queue until drying finishes** on, the queue held that printer indefinitely. A scheduled drying run stayed "running" forever, and the AMS temperature alarm stayed muted on a unit that wasn't heating. Now a printer whose only timers are parked doesn't hold the queue, and doesn't make a scheduled run wait. A scheduled run whose timer parks goes back to the queue if a print is running. On an idle printer it fails with the reason "the printer accepted the command, but the AMS did not start drying". In both cases the timer is left on the printer, since it may still start once power frees up. The temperature alarm treats a parked unit as not drying, and the printer card no longer counts one when deciding whether a dropped file prints now or queues. A failed scheduled drying run now shows its reason in your language instead of in English. Translated in all locales.
|
|
|
- **Saving an empty value for a number setting through the API no longer breaks the Settings page** — A direct API call, script or Home Assistant `rest_command` could send `null` for a number setting such as the keep-warm bed temperature. Bambuddy stored it as the text "None", and from then on every load of the settings failed with an error, for every setting on the page, until the database was fixed by hand. A `null` for a setting that can't be empty, whether a number or an on/off switch, is now refused with a message that names the setting, and nothing from that request is saved. A setting already stored that way now loads as its default, so an affected install recovers on its own.
|
|
|
- **"Reset usage to 0" on a Spoolman spool set it back to full (#2906, reported and contributed by @ojimpo in #2939)** — The reset set Spoolman's `used_weight` to 0. Spoolman calculates the remaining weight as initial minus used, so the spool jumped back to full and its measured remaining weight was lost: a roll with 737 g left read 1000 g, and later prints were charged against filament that wasn't there. The confirmation dialog promised the opposite, that the spool and its remaining weight would not change. The reset now stores the used weight at that moment in a Bambuddy field in the spool's custom fields (`bambu_weight_used_baseline`), the same way it has always worked without Spoolman, and Bambuddy subtracts it when it shows the consumed counter. Spoolman's initial, used and remaining weights are left untouched, and so is every other custom field. The value is stored as text because Spoolman sets a field's type on first use and never lets it change; a number would have been rejected on every install. The bulk reset works the same way. Spools already reset by the old version stay as they are: their remaining weight was overwritten in Spoolman, so they need re-weighing.
|
maziggy