Professional OPC
Development Tools

logos

Exception for No Quality Data in Server Response

More
29 Sep 2015 14:11 #3578 by fabio.bellani
good afternoon!
yes, the new library version is the solution for my problems

thank you so much for your help

Best Regards
Fabio

Please Log in or Create an account to join the conversation.

More
25 Sep 2015 14:00 #3574 by fabio.bellani
Thanks for your help.
Monday morning I'll try what you suggest and tell you a feedback.

Best Regards
Fabio

Please Log in or Create an account to join the conversation.

More
25 Sep 2015 13:23 #3569 by support
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:

<s:element minOccurs="0" maxOccurs="1" name="Quality" type="s0:OPCQuality" />
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

Please Log in or Create an account to join the conversation.

More
25 Sep 2015 08:00 #3567 by fabio.bellani
Good morning

OPC Server is a Softing product, version dataFEED OPC Suite V4.01 (V4.01.0.11445)
in this page industrial.softing.com/en/products/software/opc-suite-server...cation/datafeed-opc-suite.html i found: "Supported OPC Specifications OPC Classic Data Access V1.0a, V2.05, V3.0, OPC Classic XML-DA V1.01, OPC Alarms & Events V1.10, OPC Unified Architecture V1.01".
there isn't any demo

QuickOPc is 532. installer version is 5.32.1063.1

thank you,
Fabio

Please Log in or Create an account to join the conversation.

More
24 Sep 2015 16:16 #3566 by support
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

Please Log in or Create an account to join the conversation.

More
24 Sep 2015 08:21 #3565 by fabio.bellani
Good Moorning
I'm using EasyOpc library to read data from a server.
My code is very easy:

OpcLabs.EasyOpc.DataAccess.DAVtq opcValue = EasyDAClient.SharedInstance.ReadItem("server, "id");

for some values I receive this exception:

ERROR OPCXMLAcquisitor Exception read rowtype C-item pr:615080.H:count OpcLabs.EasyOpc.OperationModel.OpcException: An OPC operation failure with error code -1 (0xFFFFFFFF) occurred, originating from 'OpcLabs.EasyOpcClassicNetApi'. The inner exception contains details about the problem. ---> System.InvalidCastException: The item value from OPC NET API (Data Access) does not specify a quality.
at OpcLabs.EasyOpc.NetApi.DataAccess.NetApiEasyToOpcNetApi.ToDAVtq(ItemValue itemValue, OpcTechnologies technology)
at OpcLabs.EasyOpc.NetApi.DataAccess.NetApiEasyToOpcNetApi.ToDAVtqResult(Object state, ItemValue itemValue, OperationResult operationResult, Int32 operationErrorCode, OpcTechnologies technology)
--- End of inner exception stack trace ---
at OpcLabs.EasyOpc.DataAccess.IEasyDAClientExtension.ReadItem(IEasyDAClient easyDAClient, ServerDescriptor serverDescriptor, DAItemDescriptor itemDescriptor, DAReadParameters readParameters)
at OpcLabs.EasyOpc.DataAccess.IEasyDAClientExtension.ReadItem(IEasyDAClient easyDAClient, ServerDescriptor serverDescriptor, DAItemDescriptor itemDescriptor)
at OPCXMLAcquisitor.OPCXMLAcquisitor.ProcessTimerEvent(Object obj) in

Using a sniffer I made server response:

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap=" schemas.xmlsoap.org/soap/envelope/ " xmlns:xsi=" www.w3.org/2001/XMLSchema-instance " xmlns:xsd=" www.w3.org/2001/XMLSchema "><soap:Body><ReadResponse xmlns=" opcfoundation.org/webservices/XMLDA/1.0/ "><ReadResult RcvTime="2015-09-23T14:55:22.277+00:00" ReplyTime="2015-09-23T14:55:22.339+00:00" RevisedLocaleID="de-DE" ServerState="running"/><RItemList><Items ItemPath="" ItemName="pr:615080.H:count" ClientItemHandle="0" Timestamp="2015-09-23T14:57:14.161+00:00"><Value xsi:type="xsd:int">1123</Value></Items></RItemList></ReadResponse></soap:Body></soap:Envelope>

The response server contain value but there isn't quality information.
I read that the quality may not be the answer.

Why I receive an exception and not a data with default quality?

Can I do something in my code? there are some properties to ignore the quality information in the response?

Could you help me?

Thank you in advance

Fabio

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.196 seconds

      

 Recommend this on Google