Professional OPC
Development Tools


Online Forums

Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.

Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.

Do not use the Contact page for technical issues.

OpcUaClient Subscription has Stoped, after write To subscribed object from other task

13 Feb 2018 07:40 #6043 by support
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:
Best regards

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

07 Oct 2017 09:36 - 07 Oct 2017 09:37 #5577 by support
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.

Last edit: 07 Oct 2017 09:37 by support.

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

03 Oct 2017 05:58 - 05 Oct 2017 09:56 #5568 by bmts
I think that is problem on server side.
I try also subscribe data from UaExpert and it is the same.

Server send data cyclically, before.

Is it possible to set up timeout on client side, that required resend all subscribed data again ?

Thank you for help
Last edit: 05 Oct 2017 09:56 by bmts.

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

02 Oct 2017 13:09 - 02 Oct 2017 13:11 #5563 by bmts
Hello ,

q1: All task was finished ...
q2: yes
q3: The callback function on datachange (EasyUADataChangeNotificationEventHandler) is not called any more
q4: I think it happens after 1. write (but I am not sure on 100%)

In attachment is communication catch when notification start and finish. In Seccond catch, i try to reinitialize subscription.

Today, I have tried some code modification but withous success.

Thank you
Last edit: 02 Oct 2017 13:11 by bmts.

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

30 Sep 2017 10:57 #5561 by support
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

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

28 Sep 2017 08:15 - 28 Sep 2017 08:15 #5553 by support
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.

Last edit: 28 Sep 2017 08:15 by support.

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

26 Sep 2017 17:08 #5547 by bmts
I am using version 2017.1

In class: PlcAccessClass I am craating OpcObjectsMapper classes. In this class is instance of EasyUaClient.
OpcObjectsMapper in constructor creating clients an call function for subscribe.

At the end of constructor in PlcAccessClass, is colled function StartDequeueing(). This queue of tasks is dequing on different task, as you can see. In queue is task that trhough write value to plc and after this subscription stop.

Simple project is problem, becouse my project works only with Siemens Plc on specific project.

I can catch some communication with wireshark if is needed.

Thanks for help

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

26 Sep 2017 12:50 #5544 by support
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.


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

26 Sep 2017 12:39 #5543 by bmts

I am using in my application 4 EasyOpcClients per one UaServer/PLC.

2 clients has subscription on diferent structures, and other 2 client only write or read some structure to/from server.

1. client, that only has object with subscription works fine. (only receive data and display it)

2. client, has a subscription on Structre, and after datachange notification wants to write () to this object/structure (to specific node in subscribed structure ) on different System.Threading.Task.

After success Write the subscription/datachange notification has stopped.

Can You explain why it stopped.

Thank's for quick reply

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

Moderators: support
Time to create page: 0.073 seconds