Inductive Automation reserves the first 1024 codes(0x0000 through 0x03FF) for codes that it will define. By convention, our codes are broken up into four bands within the range of 0 through 1023 Values 0-255 are "good" codes. Values 256-511 are "uncertain" codes Values 512 - 767 are "bad" codes that represent a condition that should have been expected (something didn't work in a way that was entirely predictable, like Values 768 - 1023 are "worse" bad codes that represent a condition that was unexpected
Third parties may use codes 1024 through 65535 (0x0400 through 0xFFFF) for their own codes, although doing so will tend to cause very generic "good / bad" representations of the quality.
The (optional) diagnosticMessage field in this class is used to add contextual information about the circumstance in which the quality code was generated. It is NOT meant to be the name or description of the quality code. In many cases, only the code will be stored / transferred for efficiency, and the diagnostic message may be lost in the long term (e.g. if the code is stored as part of tag history)
You might be able to use those free codes and implement your own qualities
The initial status of a tag is e.g. set to Bad_WaitingForInitialData (0x80320000). It there is no communication the status is set to Uncertain_NoCommunicationLastUsableValue
(0x408F0000).
I do find references to these "OPC UA Status/Error Codes" here.
It seems that the Ignition list found here is incomplete?
Thanks, and the “other ones” like Bad_WaitingForInitialData are not implemented?
They do seem valid quality codes if I look over here…
Edit:
It is a bit of an issue because they are used on our current implementation of the OPC-UA server so we have to modify the contract if we make changes.
QualityCode is Ignition’s version of an OPC UA StatusCode. There is not a 1:1 mapping between them.
You are trying to replace what sounds like a custom built OPC UA server by combining a handful of Ignition features that will sort of behave the same in the end. You’re going to lose a lot of fidelity in the process because that’s not what Ignition is really built for.
Sure, but what you’re missing is that our server exists primarily as a mechanism to host our drivers and bring that data into Ignition. Secondary, it can expose Ignition platform tag data to 3rd party OPC UA clients.
It’s not a generic OPC UA server, as you found out with your earlier approach trying to use the Node Management services.
At the moment we want to use Ignition to get our data out to the DCS / other OPC clients. This will act as an add-on to our solution and will be provided to customers who need the OPC connectivity.
Later on we also want to use Ignition to get data into our system. Using the Ignition OPC-UA client functionality and the Ignition modules / drivers. Hope I use the correct terminology…
I am coincidentally working on some improvements to the "Exposed Tags" feature and it includes some additional mappings from QualityCode to StatusCode.
Thanks for taking the time to answer. I appreciate it.
Please bear in mind: I'm not trying to be a smart ass, just trying to understand how this works.
The Ignition quality codes look a lot like the OPC DA or Data Access quality codes.
It seems there is no similarity with the Ignition or OPC DA quality codes.
In the OPC-UA server we currently are using, you can set these status codes to the node/tag.
These status codes are then visible in the OPC client status code field.
The Ignition OPC quick client calls this Quality but ihmo this should be Status code.
I find this confusing.
Also because the quality in the Tag Browser and the status code in the OPC quick client so not always match.
Ignition distills the OPC UA status code from the (Ignition) quality codes and at the moment only do this a limited set (Good maps to Good and everything else maps to Bad).
Isn't it possible in the future to have a status code that you can assign to tags in Ignition as well?
Imho at the moment the OPC UA server in Ignition is more a OPC UA server lite version because of the missing status code which again imho is an essential part.
Yes, over a decade ago Ignition's quality concept was highly influenced by OPC Classic/DA, and some of that influence can still be seen today.
But listen to me: that is no longer the case, and while there is some overlap, Ignition has its own tag system that exists entirely independent of OPC of any flavor, and these tags have values and associated QualityCodes that are defined by the Ignition platform.
The automatic mapping of QualityCode to StatusCode by the Exposed Tags feature will be improved in a future version.
You need to understand that what you're building right now with the Web Dev module and setting data into Ignition tags has absolutely nothing to do with OPC UA except for the fact that we happen to have a feature that exposes Ignition tags over OPC UA, and that feature currently does a poor job of mapping the QualityCode to StatusCode. You are not building an OPC UA server in Ignition. You do not have the fine-grained control you wish for.
I really hesitate to mention this because I don't want to muddle this any more or send you down another path that may not be able to meet your requirements, but Ignition does have a module SDK, and one of the supported "extension points" is for adding new Device types to the server. This abstraction operates at the OPC UA level and provides pretty direct control over OPC UA stuff... but it's also coupled to the Ignition concept of "Devices" and the idea that you will be adding multiple instances of them, each with their own settings, so it may not be exactly what you're looking for.
