Files
bambuddy/backend
maziggy 743d657b46 fix(drying): dry a composite spool as its base material (issue #3067)
The reporter's AMS-HT would not auto-dry PA6-CF, and drying the same spool by
    hand worked. The scheduler reduced a tray to a preset key by splitting on spaces
    only, so "PA6-CF" stayed "PA6-CF", matched none of the eight rows the preset
    table has, and the tray was read as holding nothing worth drying. The AMS was
    then passed over on every scheduler sweep, silently, because every caller reads
    "no row" as "nothing to do for this tray".

    It was never only nylon. Of the 41 types a printer can report, 33 had no row
    under that rule, and 20 of those have a base material sitting right there: every
    -CF, -GF and -AERO variant of PLA, PETG, ABS, ASA, PC and PA.

    Doing it by hand worked because the drying popover has resolved composites since
    exact key first, so a row the user added for the exact type still wins, then the
    suffix, then an alias map reading PA6, PA11, PA12, PAHT, PPA and Nylon as PA.

    PPA is the one alias that is a judgement rather than a spelling. Polyphthalamide
    is a distinct polymer, not a grade of nylon -- but it is an aromatic polyamide,
    it takes up moisture the same way, and PA's row is the hottest the table has.

    A material with no row and no alias is still skipped rather than dried at a
    number nothing here can source. That is where this parts company with the
    popover, which falls back to PLA because a dropdown has to show something.

    The table is user-editable JSON, so a preset row can be present and empty. That
    has always meant "skip this material" and still does: the temp and hours reads
    fall back per field to 55C/12h, which would dry a PLA spool at 55 degrees.

    Two more callers had the same line and move with it: per-filament humidity
    thresholds, where the override set for a material never applied to that
    material's composites, and the chamber preheat target, which had the suffix half
    of this from #2902 but not the aliases.

    The preheat test for that half reimplemented the lookup inline rather than
    calling it, so it would have passed whatever the function did. It calls it now.
2026-09-20 13:34:32 +02:00
..