Professional OPC
Development Tools

logos

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.

Monitor Item Change

More
31 May 2015 06:22 #3173 by adid@contel.co.il
hello,

no problem.
i said i will report no matter what the result will be.
also it would help others that will encountered the same problem.

thank you,
Adi Damty

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

More
29 May 2015 05:32 #3172 by support
Replied by support on topic Monitor Item Change
Great, thanks for letting me know.
The following user(s) said Thank You: adid@contel.co.il

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

More
28 May 2015 07:55 #3171 by adid@contel.co.il
Hello Zbynek,

Due to my conversation with Kepware yesterday, I think we found the problem that causing the problem readMultiple and writeMultiple take a lot of time ( this is just an update ) :
The problem was the Moxa connected to the controller "freaks out" when I try to connect to the controller with high speeds.
The solution was to define in Kepware "Auto Demotion" = 3000 milliseconds. That means that if the controller is disconnected the Kepware will try to connect just one time every 3 seconds, and if more than one read\write take place within the 3 seconds, the Kepware will try to connect just one time to the controller, and if it disconnected the second time it will return status bad fast without trying to connect to the controller.
After changing this properties and it seems to see now that it takes 0-1.5 seconds to read 8 tags if the controller is connected or disconnected. And also I don't succeed to recover the problem data change was stopping.

Thank you for your help in this case,

Adi Damty
Contel

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

More
25 May 2015 11:24 #3165 by adid@contel.co.il
hello,

the only change in configuration i made, by your suggestion, is this :
easyUAClient.IsolatedParameters.Subscription.RetrialDelay = 1000; // default 3*60*1000

and this is because i don't want to wait 3 minutes after disconnection for data change event.

My client requirements is for high performance, and i need to get every data change 1-2 seconds after they occured ( when there is connection ). when there is disconnection, than after the reconnection i need to get it every 1-2 seconds.
the problem is that if now there is disconnection, and than just after 5 seconds lets say there is connection, i am getting the data change after 3 minutes - and this is no reasonable.


thank you,
Adi Damty

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

More
22 May 2015 10:25 #3162 by support
Replied by support on topic Monitor Item Change
Ad 2, Ad 4. The purpose of the keep-alive mechanism is to *detect* problems. The interval has nothing to do with what happens *after* the problem is detected.

To your requirement "reconnect max 2 seconds after disconnection": I must repeat, your ongoing attempts to make everything as fast as possible are only going to make things worse. The parameters should be set up in such a way, that short interruptions do not case disruptions. If there *is* a true communication problem, such as network broken, or the server is down, setting the client to make reconnection attempts every hundreds of milliseconds, or each 1 second, is not going to resolve the problem. It is only going to put unnecessary stress on anything on the client side, and possibly (depending on the situation - e.g. of the network is OK but it is the server that is undergoing some restart or reconfiguration) also on the server side.

Stop tuning the parameters to "fast" levels just because that's the instinctive reaction.

Regards
The following user(s) said Thank You: adid@contel.co.il

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

More
21 May 2015 09:27 #3158 by adid@contel.co.il
hello Zbynek,

there are many problems with read and write and data change as described in the emails i sent to you.
waiting for your response, this is urgent.

thank you,
Adi Damty

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

More
18 May 2015 09:02 #3153 by adid@contel.co.il
Hello,

first of all thank you for your answer.
1. i rebuild my project with the new OPCLabs version ( version 5.34 ) and going to try this.
i will notify you about good or bad progress.
2. when you said that the keep-alive interval is set to 5 seconds - does it means that after disconnection, it will take it at least 5 seconds to reconnect ? if so it's no good. i request to reconnect at max 2 seconds after disconnection. how can i change the UAClientSubscriptionParameters.KeepAliveCount so it would try to reconnect after 2 seconds ?
3. about the BrowseXXXX - i am doing it for every tag just in the first time i try to read or write the tag and than save the value in dictionary. also now was changing to use isolated seprate EasyUaClient for this operation.
4. the value of RetrialDelay is set to 1,000 and i keep it like this for now.
5. i am also using isolated EasyUaClient only for the monitor item change ( i have 2 threads, represents line and different devices, and in each thread i am using isolated EasyUaClient just for the monitor operation ). also now change it to SubscribeMultipleMonitoredItems.

thank you,
Adi Damty

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

More
17 May 2015 18:33 #3151 by support
Replied by support on topic Monitor Item Change
Hello,

I have found the reason for “The OPC-UA subscription publishing has stopped.”. It is a genuine error: That it, the keep-alive mechanism has properly detected the situation. The problem is that the mechanism is probably too sensitive.
Here is what happened, coming from the logs you have sent and the situation around 10:17:55:

You have subscriptions where the publish interval is 100 milliseconds (probably automatically derived from a sampling rate of 200 milliseconds). The default keep-alive count we request from the server is 10, and the server did not revise it. This means that, in order to prove that the subscription is working, the server should deliver a response (a PublishResponse) no later than in 10*100 milliseconds = 1 second, even if there is no data change.

In the logs, this has been true until around 10:17:55. Then, it took over 1 second between PublishRequest (Wireshark frame #8998) and PublishResponse (#9082), and again between #9083 and #9093. This could be due to various factors: Resource stress on the server, client, or the network. Probably not on the client computer (I can tell that because our own reaction own, e.g. between frames #9082 and #9082, does not appear significantly slower as in other cases). Certainly things that we cannot directly influence. But it is nothing critical: The times were not drastically over 1 second. This means that the detection mechanism is just too sensitive.

The probability that this happens increases with faster publish interval (sampling rates), and yours is relatively high. With them using a keep-alive count of 10 is probably not enough; it should be higher. This can be resolved in two ways:
1) On the server: The server can revise it; there is a provision for it in OPC UA Specs. In my view, that would be the most appropriate thing technically, because the “inability to keep up with such pace” is more on the server side. The server can do it the code, or they can have some configurable setting for it.
2) On the client: We can request a higher keep-alive count (and hope that the server won’t revise it to a lower number; most likely not).

With QuickOPC 5.32 that you are using, the keep-alive count requested by the client is fixed to 10 and you cannot change it.
You can (and should), however, download QuickOPC 5.34, and rebuild your project with it. This will bring you two things:

A) Ability to change the keep-alive count. There is now a UAClientSubscriptionParameters.KeepAliveCount for it.
B) But most likely you will not need to touch this property either, because we now have a minimum keep-alive interval built in, and that is set to 5 seconds normally, and to 1 day when a debugger is detected. If needed, we bump-up the KeepAliveCount to higher number so that the keep-alive interval is never longer than these minimums.

In other words, just rebuild with version 5.34, and re-test then.

Other notes – not related to the issues you reported:
- Are you doing some BrowseXXXX calls on the EasyUACLient with fast subscriptions? (it appeared like that from the logs). If so, even though they are only at the beginning, I recommend using an isolated client for them as well.
- Are you repeatedly calling SubscribeMonitoredItem, instead of making one big call to SubscribeMultipleMonitoredItems? If so, consider changing it, for efficiency.

To your last post:

Zero is not valid for RetrialDelay. I suggest you have it set to at least 500 milliseconds, ideally more, at least several seconds. Remember that it handles a situation which should NOT happen, and our task is to prevent that situation - for which I have described the recommended solution above. Setting the retrial to low value goes against its purpose.

Best regards
Zbynek Zahradnik
The following user(s) said Thank You: adid@contel.co.il

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

More
17 May 2015 06:52 #3150 by adid@contel.co.il
hello,

thank you for you answer.
can i set the parameter RetrialDelay (client.IsolatedParameters.Subscription.RetrialDelay) to zero ? i want when the connection lost to retry to connect right away without waiting.
waiting for the solution for the problem why there is disconnections ( this also happened when the Kepware and my service are at the same machine ).

also send you in email the logs fro the second problem where the monitorItemChanage stop working at all, and i stop getting data change events.

thank you,
Adi Damty

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

More
15 May 2015 11:27 #3143 by support
Replied by support on topic Monitor Item Change
Hello,
At least I know where the 3 minutes delay comes from:

At 10:17:55, “The OPC-UA subscription publishing has stopped.”. I am still investigating why.
The consequence of it is that you stop receiving updates for this subscription, we delete the subscription, wait for 3 minutes, and then try to re-create it.

The delay can be configured as follows (default is 3*60*1000):
  var client = new EasyUAClient();
  client.Isolated = true;
  client.IsolatedParameters.Subscription.RetrialDelay = <timespan in milliseconds>;
Obviously that’s not meant as a solution. The true problem is why this whole re-connection mechanism has been triggered, i.e. why the “The OPC-UA subscription publishing has stopped.”. Working on it.

Best regards,
The following user(s) said Thank You: adid@contel.co.il

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

Moderators: support
Time to create page: 0.087 seconds