mirror of
https://github.com/Klipper4FlashForge/firmware.git
synced 2026-10-22 05:12:16 -05:00
MonstrofilandClaude Opus 5
5718603f1c
OrcaSlicer 2.4.0's Moonraker agent offers to map a project's filaments onto the printer's slots, and it learns those slots from the `lane_data` namespace in Moonraker's database. Nothing in the tree said where that data comes from, so the question "what does this need to work?" had to be answered by reading three codebases: ff_toolchange's status surface, HelixScreen's AMS backend and override store, and MoonrakerPrinterAgent.cpp. The note is that answer as one diagram plus the reasoning around it. Klipper supplies the slot count and nothing else -- it cannot sense what filament is in a tool; the operator supplies the identity through HelixScreen; Moonraker's database is the only durable record; OrcaSlicer reads it once at connect and never writes back. It also records the two things that surprised us. The mapping is not applied at print time -- start_local_print() ignores ams_mapping, so it selects presets and temperatures at slice time and does not rewrite tool numbers. And the reason this does not work on our build yet is not a missing feature but a missing merge: AmsBackendToolChanger was the last AMS backend without a FilamentSlotOverrideStore, upstream gave it one on 2026-08-24, and our last catch-up from upstream is four days older than that. Claude-Session: https://claude.ai/code/session_01PU5nCo85xuFQuub4kJzWt9 Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
