Fix: MaterialType enum values to match OpenPrintTag specification#5
Open
gienne wants to merge 10 commits into
Open
Fix: MaterialType enum values to match OpenPrintTag specification#5gienne wants to merge 10 commits into
gienne wants to merge 10 commits into
Conversation
WriteDataWithURL was calling writeNTAGPages(card, 4, ...) for all non-MIFARE cards, including ISO 15693 (NFC-V) tags such as the NXP ICode SLIX2 used on Prusa filament spools. Two bugs for ISO 15693: 1. Wrong start block: NTAG user memory begins at page 4; ISO 15693 NDEF begins at block 1 (block 0 holds the Capability Container). 2. Padding to card.Size (320 bytes) caused writes to blocks 80-83, which are out of range for ICode SLIX2 (80 blocks, 0-79). Fix: detect NFC-V protocol and write CC to block 0 then NDEF TLV from block 1, mirroring the correct logic already present in WriteMultipleRecords. Tested on ACR1552U with blank NXP ICode SLIX2 tags and with Prusa-branded filament spool tags (write + readback verified).
Add BrandSpecificInstanceID, BrandSpecificPackageID and BrandSpecificMaterialID
to the Response struct so they are included in the JSON output of the card read
API endpoint.
These fields are already decoded from the CBOR payload (MainSection keys 5-7)
but were not propagated to the API response, making them invisible to consumers
of the /v1/readers/{n}/card endpoint.
Use cases:
- BrandSpecificInstanceID: per-spool serial/lot number (e.g. Prusa instance ref)
useful for traceability and inventory management systems
- BrandSpecificPackageID: product/SKU reference for the package
- BrandSpecificMaterialID: material reference identifier
JSON keys follow the existing camelCase convention used by the other UUID
fields (instanceUuid, packageUuid, etc.).
Binary payloads (CBOR/OpenPrintTag) can contain 0xFE as a data byte. Once NDEF TLV length is known, use length-based termination instead of byte-scanning for the 0xFE terminator. Fixes ICode SLIX2 reads stopping at 60 bytes when a UUID byte equals 0xFE.
…reheatTemp/lengths
… (keys 5,6,42-45)
…nominalFullLength
…n, règle Input+Response
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
1 participant
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.
Problem
The
MaterialTypeenum constants inopenprinttag.godo not match the official OpenPrintTag specification (material_type_enum.yaml).The enum was shifted from position 1 onward, causing incorrect material type decoding. For example, a Prusament ASA Signal White spool is returned as
"materialType":"PC"instead of"materialType":"ASA".Root cause
Only value
0(PLA) was correct. Every other type was misidentified.Fix
Enum constants updated to match the official spec order (values 0–22 corrected). Composite types (PA-CF, PLA-CF, etc.) not defined in the base spec are assigned vendor-specific values above 100 to avoid collisions.
Tested with
materialTypenow correctly returns"ASA"