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.
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.
I guess you are right. Unfortunately we do need more control over the OPC UA implementation i.e. the status code. Really hope the the exposed tags feature can be extended in the future so at least the status code Uncertain will be emitted as well.
Great product, but for now we will look elsewhere. Thank you all for your support!
Would be great if you could do this for the unique mappings between quality and status codes(*) that can be found here:
(*) I am aware that the Ignition quality codes are no longer a 100% match but still you could do a mapping where possible and add Ignition quality codes where needed. Imho a great enhancement to the exposed tags feature.
I’m mapping the ones that make sense, but no we won’t just be adding a bunch of arbitrary codes copied from OPC Classic. As I said previously, we call it a QualityCode, and there is still some remaining influence from OPC Classic in that we have an additional good code that has a value of 192, in addition to the default good code of 0 (for the purposes of backwards compatibility), but it is not an enumeration of OPC Classic/DA quality codes.
The final release of 8.1.18 is scheduled for June 14, but the changes will be available in a nightly release as soon as they’re finished and have gone through QA.
What is the best way to check what mapping is actually implemented and when (and where) the Ignition nightly will be available? I really would like to give it atry it once it is available. Anything I can subscribe to?