This is an interesting topic. According to the OPC XML-DA Specification, the fields (represented as attributes) inside the OPCQuality complex type have defaults, which in end denote a Good quality. Therefore, one can legally have an element like <Quality />, and it represents a good quality, no problems there.

The OPCQuality complex type is then used within the ItemValue complex type, and in the schema, it is declared like this:

Therefore it can, but it does not have to appear.

On the "raw" service level, having no quality is thus legal. The OPC specification may, on top of that, put another restrictions on what is allowed or not.

The reason why the Quality (and other fields) in the ItemValue complex type are optional is clearly because it needs to be used within the Write service, which allows combinations such as writing only the value, or writing the value, quality, and timestamp together.

Now the question comes, is it also allowed to omit the quality altogether (the whole element) in responses to Read, or in subscription notifications?

For those that know the history of OPC specs (and also as explained in the OPC XML-DA spec), it is clear that the OPC XML-DA is designed to closely "mimic" the functionaly of classic (COM-based) OPC Data Access. In COM-based OPC-DA, there is no way to omit the quality in these cases - not just conceptually, but also because it is a binary protocol where the quality is always present and "goes together" with the value and the timestamp. And, I could not find any mention of this being intentionally change for OPC XML-DA. At the same time, however, I could not find any specific mention that omitting the quality is *not* enabled.

The QuickOPC implementation so far is based on the idea that, at least as far as the data itself (value-timestamp-quality triples) the client library is just a "pipe" that transports this data from the server to the application code (or in the opposite way). In case of problems, we never create our "own data", or modify the data that comes from the server - for example, by sticking in a "Bad" quality. We have other ways to indicate client-side problems (errors, exceptions). This approach has paid for itself numerous times over the years, Not only it makes the behavior clear and comprehensible, but saves a lot of tech support. Whenever we got a customer who felt that the data he is receiving is not correct - such as getting a Bad quality for unknown reason - we told him right away that it must be the data that the server is providing, because our code never touches the data - and we were right in 100% of the cases. So this is just to explain the philosophy.

My original feeling was that we can't assume a quality in the case you have described either, but after digging into it deeper, it seems that in this particular case we can and should do it, because 1) the spec is not really clear on this issue, therefore the server behavior might just be right, and 2) it is a server from a respected vendor, and a server that may also be relatively common.

We have made a modification that should interpret a missing Quality fields as "good" quality. The change was not tested with the server, but given its relative simplicity, I believe that it will work. Please download the latest QuickOPC (5.34.395.1 as of today - or any higher version later) from the download area of this site, reinstall it, rebuild your app, and test again.

Best regards

Hello.

Can you please answer this:
1. Which OPC Server are you connecting to? Is there a demo of it available?
2. Which version of QuickOPC are you using?

I will answer your questions then.

Thank you, and best regards