fix(info): derive has_matl_station instead of copying the raw flag - #14
Closed
RedAces wants to merge 1 commit into
Closed
fix(info): derive has_matl_station instead of copying the raw flag#14RedAces wants to merge 1 commit into
RedAces wants to merge 1 commit into
Conversation
Owner
|
Thank you for this! Please see my comment on your other PR when you have time, I'd like to confirm some information before I merge this as I lack a Creator 5 to test on myself |
FFMachineInfo.has_matl_station was a straight copy of the raw hasMatlStation value from /detail. That field is AD5X-only: a Creator 5 Pro omits it entirely — verified on real hardware (pid 41, firmware 1.9.4) — while reporting a fully populated matlStationInfo with four loaded slots. Consumers gating features on the flag therefore saw no material station on exactly the models that have one. from_detail already computed the correct value for its internal AD5X name heuristic (flag is True OR slotCnt > 0 OR non-empty slotInfos) and then discarded it. Expose that derived value instead; it is now always a concrete True/False. FFPrinterDetail.has_matl_station keeps the untouched firmware value for callers that need to know what the printer actually sent. Add CREATOR_5_PRO_MATL_STATION_INFO, a station block captured from real hardware and deliberately without hasMatlStation. The Creator 5 fixtures had no material station at all, which is why this went unnoticed through v1.3.1. # Conflicts: # CLAUDE.md # ai_specs/TEST_COVERAGE_SPEC.md # docs/models.md # flashforge/api/controls/info.py # flashforge/models/machine_info.py # tests/fixtures/printer_responses.py # tests/test_machine_info_parity.py
RedAces
force-pushed
the
creator5_fix_material_station
branch
from
July 26, 2026 23:40
0e8c9d6 to
d145910
Compare
Contributor
Author
|
Ive rebased my branch onto main and now its empty! Thanks for merging this and for the awesome other fixes! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
FFMachineInfo.has_matl_station was a straight copy of the raw hasMatlStation value from /detail. That field is AD5X-only: a Creator 5 Pro omits it entirely — verified on real hardware (pid 41, firmware 1.9.4) — while reporting a fully populated matlStationInfo with four loaded slots. Consumers gating features on the flag therefore saw no material station on exactly the models that have one.
from_detail already computed the correct value for its internal AD5X name heuristic (flag is True OR slotCnt > 0 OR non-empty slotInfos) and then discarded it. Expose that derived value instead; it is now always a concrete True/False. FFPrinterDetail.has_matl_station keeps the untouched firmware value for callers that need to know what the printer actually sent.
Add CREATOR_5_PRO_MATL_STATION_INFO, a station block captured from real hardware and deliberately without hasMatlStation. The Creator 5 fixtures had no material station at all, which is why this went unnoticed through v1.3.1.