How to set tag quality (sub?) codes like Bad_WaitingForInitialData?

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.

That doesn’t sound very reassuring for something that is included in the Ignition platform and seems like a core component?

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.

Understood.

Thanks for the clarification. Much appreciated.

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 find it confusing though…

The first time I tried, I have set the Quality to Good and Bad ans saw the OPC client follow this behavior.

But now I have set the quality to Uncertain the behavior is not consistent between Ignition and an OPC client.

In the Ignition Tag browser the field is called Quality and the value is Uncertain.

In the Ignition OPC quick client the field is called Quality and the value is Bad instead of Uncertain.

In another OPC client the value is Bad as well and the field is called Status code.

What is the mapping of the Quality and Status codes?

So my question is:
Can I only expose the Status codes Good and Bad to an OPC client?

Yes, the current implementation works that way.

I am coincidentally working on some improvements to the “Exposed Tags” feature and it includes some additional mappings from QualityCode to StatusCode.

But isn’t it odd that one of the three main qualities i.e. Uncertain is shown as status code Bad in the OPC client?

To be honest, I don’t know that much of OPC, but to me the concept of quality codes vs. status codes looks very confusing.

Quality Codes
https://honeywellprocess-community.force.com/opcsupport/s/article/What-are-the-OPC-Quality-Codes

Status Codes
https://honeywellprocess-community.force.com/opcsupport/s/article/What-are-the-common-OPC-UA-Status-Code

QualityCode is an Ignition concept, not an OPC concept, though it seems to share a name with the OPC Classic equivalent of StatusCode.

Yes, it’s a bit “odd”, but it’s a result of essentially no mapping logic being implemented.

It’s essentially just returning StatusCode.GOOD if the QualityCode is good, and StatusCode.BAD otherwise.

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.

Those OPC DA or Data Access Quality Codes can be found over here:
https://honeywellprocess-community.force.com/opcsupport/s/article/What-are-the-OPC-Quality-Codes

As you can see there are some overlapping codes like e.g. Good is 192.
But a lot of the codes are different which imho is very confusing.

The OPC UA or Unified Architecture Status Codes can be found at:
https://honeywellprocess-community.force.com/opcsupport/s/article/What-are-the-common-OPC-UA-Status-Code

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.

Thanks.

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.

2 Likes

Thank you for the honest answer.

I think I have found the document that talks about the OPC DA Quality Code and OPC UA Status Code relationship:

So basically you can go from Quality Code + HRESULT to a Status Code and back again.

I guess it is a bit too late to implement this…

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!

I mentioned this in the middle of other posts, but this is on its way for probably Ignition 8.1.18.

1 Like

Nice!

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.

My post on the OPC foundation forum:
https://opcfoundation.org/forum/opc-ua-standard/quality-codes-vs-status-codes/

Thanks Kevin.

Any idea when this version will be available for testing?

And if you would consider adding additional Ignition quality codes and quality / status code mappings? As described in my previous post.

Thanks. Appreciate your input.

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.

1 Like

Thanks.

Last question… :wink:

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?

The nightly releases are available on our downloads page and we update this thread regularly with the changes being merged in.

As for the actual mapping… I think that’ll have to get added to the user manual as part of this ticket work.