Files
bambuddy/backend/app
maziggy 0d8d67c866 Say when AMS drying was running and a print never started (#2758)
Dispatching to an X2D with two AMS units mid-drying failed silently: the
    file uploaded, the printer accepted it and stayed idle. The watchdog waits
    for an active state or HMS_MQTT_VERIFY_FAILED, and a drying refusal is
    neither, so it timed out, re-uploaded the whole 3MF twice more, and closed
    with advice about the printer screen and the SD card. Studio, asked
    directly, said it could not start the job because of the drying.

    Latch the AMS dry_time telemetry across both watchdog phases and name the
    units in the give-up message, plus an INFO log on every failed window so
    the correlation reaches a support bundle from the first attempt.

    Detection only, no gate. These models support drying CONTINUING through a
    print (supports_drying_while_printing covers X2D from 01.01.00.00), so
    drying is not incompatible with printing and stopping it before every
    dispatch would tear down cycles the hardware is happy to run. One of the
    two units was also drying without its external PSU, which would make this a
    power budget problem at start-of-print calibration rather than a drying one
    -- dry_sf_reason 1/8 exist for exactly that. The message names both
    possibilities rather than asserting one.

    Also correct _sync_drying_state's docstring, which claimed to adopt drying
    it did not start; it only prunes. Behaviour unchanged -- populating it would
    let the scheduler stop a cycle the user started by hand.
2026-08-15 14:06:29 +02:00
..
2026-06-26 14:40:25 +02:00
…