Serial Nr. in OPT

[foxeefox]

My suggestion is to store serial numbers (SN) in the Open Print Tag (OPT). Especially in an industrial environment, SNs have to be tracked for documentaion and quality assurance. It would be neat to be able to have a machine readable SN on every spool in the form of it being stored in the open print tag.

[CZDanol]

Hello, this is already covered in multiple ways.

• Each NFCV tag has an unique UID, burned to the chip in the factory.
• Additionally, the OPT format has the brand_specific_material_id field: https://specs.openprinttag.org/#/nfc_data_format?id=_51-field-list. This is where we at Prusa store our spool IDs you can find read from the package/QR code.
• In addition to that, the OPT standard defines a standardized UUIDv5 instance_uuid: https://specs.openprinttag.org/#/nfc_data_format?id=_32-uuids that can be automatically derived from the tag UID to save space.

[yanshay]

From some experience using NFC tags on spools for some time now, here are a few use cases to when the NFC uid are not sufficient:

1. Users want to duplicate tags for various reasons - they want one on the swatch and another on the spool and a third on the box. For such usecase its required.
2. Some automated systems require tags on both sides of the spool. I know that the standard specifically states this is a bad approach and I agree, but sometimes tecchnical constraints may require that.
3. When personal user (probably less in industrial environmetns) wants to encode their own tags they usually get the cheap ones from AliExpress/Amazon which work great but are not reliable in terms of UID and there's no gurantee that even the same source would not deliver two tags with the same ID. I've seen tags that were missing basic mandatory information (e.g. tag size) on tags as well.

However, for filament manufacturers this is way more expensive to encode a different ID on every tag as part of the manufacturing process.

The way I would solve this (actually did) is that there would be a placeholder in the tag to store the same 7 bytes UID of the spool. If it exists then it takes precedence over the tag UID. With that you fix all of the above:

1. When there's a need for duplicate tags it is possible to just have first one as master (let's say the manufacturer's if exist) and in the others one can encode the master's uid.
2. Manufacturers don't need to deal with it and use the NFC tags.
3. User who gets tags from an unreliable source can encode the field with a custom UID if required

Obviously there are issues with duplication of tags such as storing back information on them need to be done on both, but my guess this would be less common since it involves many technical issues to be reliable enough to do, and the tags would serve mostly as read only.

[CZDanol]

And in those cases, the instance_uuid field can be provided that overrides the default tag UID-based UUID derivation.

Please note that having two tags on a single spool should not only be unnecessary if the both tag and reader specs are followed, but that would also break the "dynamic" part of the tag system like usage tracking.

[CZDanol]

Is that a usage defined by the spec? So if I develop a system that needs to store UID of a spool and that field contains a value I shoud treat as the UID instead of the nfc UID.

Please read https://specs.openprinttag.org/#/nfc_data_format?id=_32-uuids . You want to be working with the instance_uuid. If the field is present on the tag, you use that UUID (not UID - those are two different things) to reference the tag. If not, you use the algorithm described in the link to generate the instance_uuid from the tag UID.

If two independent systems need to refer to a spool, they should always use the same algorithm, defined by the spec, to deterimine the one, single UUID. There is no duality from the outer perspective.

I'm not sure hardware wise this is always feasible. If there are spools one next to the other (e.g. AMS like) it means you would need to have double the NFC readers (so one per spool) and double the costs, double the GPIO's to work with both, etc. And I believe there are other cases where physically it won't work to have a tag on just one side.

We have taken this into consideration when designing the system.

[yanshay]

Please read https://specs.openprinttag.org/#/nfc_data_format?id=_32-uuids . You want to be working with the instance_uuid. If the field is present on the tag, you use that UUID (not UID - those are two different things) to reference the tag. If not, you use the algorithm described in the link to generate the instance_uuid from the tag UID.

If two independent systems need to refer to a spool, they should always use the same algorithm, defined by the spec, to deterimine the one, single UUID. There is no duality from the outer perspective.v

Oh, I missed that part. The UID section was a bit complex to understand there so I ... skipped it.
I thought the NFC UID is the id as is. Good I asked.
Going to be a problem for me to use such large UID though in my current system.

I'm not sure hardware wise this is always feasible. If there are spools one next to the other (e.g. AMS like) it means you would need to have double the NFC readers (so one per spool) and double the costs, double the GPIO's to work with both, etc. And I believe there are other cases where physically it won't work to have a tag on just one side.

We have taken this into consideration when designing the system.

Is that in the Hardware Specifications (not available yet)? So you "enforce" som hardware constraints?
What about existing systems that may not fit? (I've seen lately someone mentioning drawers system that identify spools stored, if you place the spool upside down not sure how it will work for them, but probably too late to change his system).

[CZDanol]

Going to be a problem for me to use such large UID though in my current system.

I am also not overly happy about the UUID size :( But it's an established and widely supported standard, so we decided to go with it - and we can also apply it on references to other entities portrayed by the NFC tag. Plus, for the standard use cases, noone needs to actually store any of the UUIDs on the tag, so it's actually quite economical.

Is that in the Hardware Specifications (not available yet)? So you "enforce" som hardware constraints?

Yes. The "up-to-spec" OpenPrintTag will have defined dimensions, coil type, positioning and such, that we tested to behave well in various scenarios (provided you also use up-to-spec NFC communication hardware)

[CZDanol]

Btw, physical spec has been partly released: https://specs.openprinttag.org/#/physical_spec

[yanshay]

Btw, physical spec has been partly released: https://specs.openprinttag.org/#/physical_spec

This may be relevant to HW manufacturers, but since it's about open source (which rarely develop custom HW), what ready made NFC readers are known to exist with reasonable open source software support?