Can there be a tag where you can't tell material type?

[yanshay]

Probably the most important field of filament is the basic type, so PLA vs PETG.;
If I only had to tell one thing about a spool that would be it.

In the spec I see now that:

1. material_type is a recommended field.
2. material_abbreviation - If not present, the material inherits the abbreviation from the material type. (implies not required, and material_type also not required)
3. material_name - recommended field as well.

So if none is present, is there a way to tell the material type from the tag?
I mean, could there be a spool with OpenPrintTag that follows the spec where one can't tell the material type of the spool from?

Also, the multiple options to get material_type puts a burden on the developer to check multiple fields, and that would not be consistent across systems so potentially yield different results in different software.

[CZDanol]

I mean, could there be a spool with OpenPrintTag that follows the spec where one can't tell the material type of the spool from?
Hello, yes, basically all the data is inherently optional, so there can be a tag where you wouldn't be able to tell the type.

Few notes:

1. material_type is mostly about chemical composition information. It SHOULD be left out if a filament does not match any of the standard base compositions. We (Prusa) are doing that for our "Woodfil" filament for example IIRC.
2. material_abbreviation is intended to have something short to show to the user for example in a footer or in some overview page. It material_type is not present, it SHOULD be filled in, but there is never a guarantee. It can also "extend" the base material type, for example when you have a PCCF filament, material_type would be PC and material_abbreviation would be PCCF
3. material_name SHOULD and is heavily recommended to be filled in either case (standard or non-standard material type). We do heavily recommend doing that, but again, the format is designed in such way that we cannot prevent anyone from not filling it in.

Also, the multiple options to get material_type puts a burden on the developer to check multiple fields

1. Having just material_type wouldn't be enough, because it is an enum and it doesn't expressing non-standard chemistries.
2. Changing material_type to a non-enum would mean un-standardization and risking data inconsistencies of for example PETG vs PET-G
3. Requiring to always enter both material_type and material_abbreviation would not be enforceable, as all fields are inherently optional. So rather than trying to enforce something and then getting angry when someone ignores it, we are taking the stance of "hey, don't necessarily count on this, and here is what you should do if the fields are missing".

and that would not be consistent across systems

If the systems follow the spec, it will be consistent.

[yanshay]

So let's make this a simple question for the simplest use case.

How should I get the material type value that is required to configure a Bambu Lab AMS given an OpenPrintTag tag. So many options, yet none is guaranteed to work. With any other tag format I've seen, they are far less sophisticated, yet that part is simple and guaranteed to be available.

That's probably the main request any Bambu Lab user (probably also any other printer) is looking for in an open alternative to Bambu Lab tags - to be able to configure the AMS slot automatically. Before anything else.

[CZDanol]

How should I get the material type value that is required to configure a Bambu Lab AMS

Depends on what the Bambu considers to be a material type. Does it only accept a few predetermined values, or can you enter any string?

If it is any string, give it material_abbreviation (with fallback to material_type).

If it is just an enum, you should probably do some mapping based on the OPT material_type.

So many options

Two. It's two.

that part is simple and guaranteed to be available.

Guaranteed perhaps in the way that there is a fixed position in memory that is guaranteed to be dedicated to contain some data. There is no guarantee that anyone bothered to put the correct data there. We are developing an open standard where we won't have much control over the data quality, any manufacturer and any hobbyist will be able to create their own spools with their own data.

[yanshay]

Let me start at the end

Guaranteed perhaps in the way that there is a fixed position in memory that is guaranteed to be dedicated to contain some data. There is no guarantee that anyone bothered to put the correct data there. We are developing an open standard where we won't have much control over the data quality, any manufacturer and any hobbyist will be able to create their own spools with their own data.

The equivalent for someone filling bad data or not filling data in another tag fixed format is someone using a float value for material_type in OpenPrintTag. That's a bug/error/mistake - and both cases the tag is not compliant with the spec.
I only refer to cases where tag is compliant with the spec, so data is filled correctly by the spec authors both in OpenPrintTag or in any other format.

With other formats to be compliant with a spec the material type is mandatory. Here it isn't and a tag that's compliant with the spec could be unusable for the most basic application of configuring a printer with filament type and color. Not for some edge case, I see it as the basic and I think most end users do as well though I'm less exposed to large production facilities.

Two. It's two.

Way more:

• Third standalone is by searching known material types in material name. Actually this sounds to be the safest option to use since I expect vendors to never miss that field they already have available in all their systems in a way that fits the tag as is. It's valid becasue the other two are not guranteed to work. Just like I extract color name today from that field in some way.
• And then all permutations of orders between them for fallback, the entire trio in all orders and every pair in all orders.
• So in total - given 3 standalone options, all next permutations are valid: 1, 2, 3, 1->2, 2->1, 1->3, 3->1, 2->3, 3->2, 1->2->3, 1->3->2, 2->1->3, 2->3->1, 3->1->2, 3->2->1.

This means that without clear instructions, every developer can develop their own algorithm to extract the material type and then in two systems using the same tag there would end up with a bit different results, including case when one system can read a tag and another saying it is invalid because the data is missing.
This is what standards are meant to prevent. Reduce ambiguity to a minimum for the basic use cases.

Anyway, seems to me the algorithm should be as follows:

1. Check material abbreviation - if it is there take it and use it if it fits your need and stop here
2. Check material type - if it is there take it and use it if it fits your need and stop here.
3. Search the material_name - if it is there, search it for known material types / materials your application supports and stop
4. If all three steps fail, report to the user the tag is invalid for use.

It's doable but over complicated, I'm probably not going to implement it until I see real tags out there to see if this complexity is required or helpful, but writing it here for the future me.

[CZDanol]

I only refer to cases where tag is compliant with the spec, so data is filled correctly by the spec authors both in OpenPrintTag or in any other format.

🤔 We could add to the spec that at least one of abbreviation and material_type SHALL be filled in, it makes sense. Would that satisfy your needs? It would be just words though, so the enforceability would be questionable.

Though, to be honest, I don't see much difference in failing because "a tag doesn't meet the spec" vs because the tag is missing data for the current application.

Third standalone is by searching known material types in material name.

I cannot really recommend that, as that is rather a wild heuristic and would not provide consistent results between different products. If you just keep steps one and two, that is simple, straightforward, and in the spec, so no matter where you use the spool, you will get the same. It's not a shame to fail sooner and prompt the user to fill the data properly - I'd say its even better as it promotes data standardization. And the manufacturers should provide the data the standard way.

Also, it feels like you're using combinatorics to artificially inflate the count. Even if we considered trying to pull the data from material_name, there would still be a single reasonable fallback chain abbreviation → material_type → material_name.

[yanshay]

🤔 We could add to the spec that at least one of abbreviation and material_type SHALL be filled in, it makes sense. Would that satisfy your needs? It would be just words though, so the enforceability would be questionable.

I don't know what SHALL means, but if it is stated as required like material_class then that would work.
Whether you add it or not I think you need some section in the docs that state "mandatory requiremetns to be compliant with spec" and include there what you define as required rather than spreadit on fields and have the readers search.
Obviously you can't enforce anything on manufacturers, they could also fill numbers where strings are supposed to be if they want but usually parties who join a standard wants to comply, just need to make it easy for them so they don't make mistakes.

Also, it feels like you're using combinatorics to artificially inflate the count. Even if we considered trying to pull the data from material_name, there would still be a single reasonable fallback chain abbreviation → material_type → material_name.

Of course that was a theoretical discussion, but my initial implementation which was based on just going over the document started from material_type and I could have easily fallback to abbreviation and only then to material_name. Only after your explanations I understood that was probably the correct chain. The point it, to prevent mistakes, it needs to be more explicit.

Anyway, all that said, given the PN532 HW limitation, unfortunately this is all less relevant right now until/if I find some alternative board in the future, my current users won't be able to use these tags anyway (at least not the tags that come on the spools). That's something probably too late to change in the spec, but would surely slow down adoption in the open source world where PN532 is quite widely used - sw changes are reasonable to expecct but HW is a different story. Not sure why that tag type was chosen, given so many more common options out there, maybe for good reasons, but given there are spools being manufactured already it's probably too late to change.