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.
- Forum
- Discussions
- QuickOPC-UA in .NET
- Connections, Reconnections, Certificates
- Quickopc reconnect Problem
Quickopc reconnect Problem
Thank you for the additional information. We were able to reproduce the issue on a small program.
We have made a change that should fix it. Please download and rebuild with QuickOPC 5.72.522 or later (currently on nuget.org and on our Web site), and retest.
The fix was quite delicate. Obviously we have run our normal tests, but there is still some danger of regression. I would welcome your feedback.
Best regards
Please Log in or Create an account to join the conversation.
- jian.kong@vskysoft.com
- Topic Author
- Offline
- Senior Member
- Posts: 5
- Thank you received: 0
Thanks for your quick reply.
I just add some comments:
1. Yes, the "slow" parts is caused by reconnecting blocked the result for a while
2.We will try fine tuning "RetrialDelay Property" as temporary solution.
3. I think this post also want the same solution
----https://www.opclabs.com/forum/ua-reading-writing-subscriptions/3622-easyuaclient-instances-set-to-isolated-are-not-behaving-independently#12194
thanks again, we are looking forward to see the reproducible
Br Kong Jian
Please Log in or Create an account to join the conversation.
First, just some clarifications:
- The fact the WriteMultipleXXXX gets slowed down by *any* of its elements is by design. With the model chosen for returning the results, we need to return from the method only when all results are ready, and that means that in some circumstances, the "fast" parts suffer from the "slow" parts. So if your usage cannot tolerate that, it is correct to search for workarounds or different approaches.
- Even if you do not "address" the disconnected server in WriteMultipleXXXX calls, you have them in your subscriptions, and I suppose it is the reconnections made for the subscriptions that are causing the longer times spent in WriteMultipleXXXX calls. If all you wanted was to reduce the frequency the problem happens, you could do so by setting some parameters we have that control the delay between the reconnections (I can give more info on that if you like) . But you probably want to eliminate the issue altogether.
Now to the actual issue. It seems that there is no "hard" reason why the reconnection attempts made for subscriptions on unrelated servers should cause a delay in WriteMultipleXXXX calls. But there may be an internal implementation reason for it. What we need to do is first to try to reproduce the problem on our side (with some simplified scenario), and then, if reproducible, check if it can be resolved.
So I will work on creating a repro. Please allow some time for it. I will report here when I have an update on this.
Regards
Please Log in or Create an account to join the conversation.
- jian.kong@vskysoft.com
- Topic Author
- Offline
- Senior Member
- Posts: 5
- Thank you received: 0
Server condition change log
Attachments:
Please Log in or Create an account to join the conversation.
- jian.kong@vskysoft.com
- Topic Author
- Offline
- Senior Member
- Posts: 5
- Thank you received: 0
Attachments:
Please Log in or Create an account to join the conversation.
- jian.kong@vskysoft.com
- Topic Author
- Offline
- Senior Member
- Posts: 5
- Thank you received: 0
Please see the answer below:
1. You wrote "...cause write to other running server slowly". Do you mean that the WriteMultipleXXXX method call takes longer than normally, or is there anything else that gets "slow"?
---- I have attached two logs. one is OPC_Srv_ConditionChanged, another is writing time we calculated for each writing (Column A).as soon as the reconnect happening, the write spend much more time.
2. Is it my correct understanding that in your WriteMultipleXXXX method call, you combine the nodes from different servers?
Yes, we combine the nodes in WriteMultipleXXXX call, but except the disconnected nodes since we remove that based on the Srv_ConditionChanged event.
3. Can you please elaborate on what have you done when you wrote "Tried isolated client methods". I am asking this because (although I know you do not prefer it) it might be our recommended approach to this.[/color]
----we use multiple client objects, et. var client1 = new EasyUAClient { Isolated = true }; var client2 = new EasyUAClient { Isolated = true }
Please Log in or Create an account to join the conversation.
I need some more info for clarification :
1. You wrote "...cause write to other running server slowly". Do you mean that the WriteMultipleXXXX method call takes longer than normally, or is there anything else that gets "slow"?
2. Is it my correct understanding that in your WriteMultipleXXXX method call, you combine the nodes from different servers?
3. Can you please elaborate on what have you done when you wrote "Tried isolated client methods". I am asking this because (although I know you do not prefer it) it might be our recommended approach to this.
Best regards
Please Log in or Create an account to join the conversation.
- jian.kong@vskysoft.com
- Topic Author
- Offline
- Senior Member
- Posts: 5
- Thank you received: 0
We are using QuickOPC(Revision 5.7)in production environment with 10 machine (OPC UA) connected.
One client connect to 10 OPC UA server. All OPC UA server have subscription and write multiple operation. In normal case, it is working well with fast successful writing less 2 seconds.
But if one of machine shut down for maintenance purpose, there will be reconnection mechanism each 10 seconds to the shutdown OPC UA server by Quickopc internal control , Each reconnect operation that will cause write to other running server slowly, as soon as connecting finished, it will back to normal. It is running periodically.
---We are using single client object.
---Have called OPC Server ConditionChanged methods, it will not write to the disconnected server as soon as the server disconnect detected.
---Tried isolated client methods (it is not preferred), the result is same.[/li]
Would you please advice how to handle this case?
Br Kong Jian
Please Log in or Create an account to join the conversation.
- Forum
- Discussions
- QuickOPC-UA in .NET
- Connections, Reconnections, Certificates
- Quickopc reconnect Problem