QuickOPC version 2018.1 (released today) has support for OPC UA Complex Data, and it can decode and encode the extension objects automatically.

More information:

• QuickOPC 2018.1 Released
• What's New in QuickOPC 2018.1
• OPC UA Complex Data Extension
• OPC UA Complex Data Reading

Best regards

Thank you.

I am not sure if I understand your question. Do you mean that somehow the client should recognize the situation and reconnect?

If the server stops sending updates, it can do so in two ways:

A. No updates will be sent, and the server will also not respond in time to the Publish requests from the client. This is a mechanism designed into OPC UA that allows to recognize an unresponsive server. In this case, QuickOPC should recognize the error, disconnect, and reconnect (the periods are configurable). Note that when running under the debugger, QuickOPC tries to negotiate very long intervals, in order to allow the developer to put breakpoints into the code and debug it, without causing the connection to break. You may want to test your code with and without the debugger to see if without the debugger, the lost connection would not be recognized.

B. The server will properly respond to Publish requests from the client, but send no updates even when it should. Unfortunately in this case there is no way the client can recognize that something is wrong, because everything looks normal.

I am afraid that you might be dealing with B ), but please first make sure (if you have not done so) you run your code without the debugger and see that whether in this case, the problem is not at least recognized by the client side.

Using Wireshark it would be possible to tell between A) and B ).

For B ), the server really should be fixed; as an ugly hack, you could try to design some mechanism that would tell you that updates has stopped, but that would be up to you to design. When you recognize the problem, you would then unsubscribe from all items, which would cause QuickOPC to disconnect, and then subscribe again after some time. I strongly recommend *against* going to such lengths, because such resiliency mechanisms are already built into QuickOPC and you will be asking for more problems by colliding with them. One more ugly related idea is to specify Data Change Filter in your Monitoring Parameters to use Trigger = StatusValueTimestamp (the default is StatusValue). This may cause the server to send you notifications more often, even if the value itself does not change, and give you better chance to recognize that the updates have stopped coming in.

Regards

I tried to write a program based on the principle you described, but it has not manifested the problem.

Let me ask you some more questions:

1. Do you see any of your tasks or threads blocked "forever" where it shouldn't be, e.g. in some of the EasyUAClient calls?
2. Have the Write call you are describing returned control to your code?
3. When you say "subscription has stopped", that means that you are no longer receiving any event notifications, right? Or, do you receive a notification with eventArgs.Exception != null
4. Does it happen reliably on first Write, or randomly?

Thank you

Thank you. I apologize because I am out of office until Friday and cannot actually make a good analysis of the source code and how it relates to our internals. I will do that in couple of days and respond again.

In general, I think that the cause can fall into 3 classes:

A ) Server problem.
B ) Client problem - something like deadlock inside our component, unrelated to the use of Task-s.
C ) Client problem - unintended conflict of the Task mechanism with internals of our component.

At this point I actually think that a server problem is not that likely. If you, however, wanted to capture the communication using Wireshark, it would certainly help in order to decide between A) versus B/C).

The reason I have listed C) specifically is because we have seen an issue in the past where the usage of Task-s caused a problem. One has to know a lot to use them properly, especially in combination with code from other party, and there are many things that can go wrong. So I need to look at it again. If this is the case, however, it should be reproducible with other server, too.

Regards

Hello.
Please specify which QuickOPC version you are using.

We would probably need a simple project that reproduces the issue in order to be able to tell more.

For start, please post here the piece of code that creates and starts the Task. You should be aware that most EasyXXClient operations are I/O bound but blocking.

Regards