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.

The client appears to have stopped running

More
06 Aug 2024 17:23 #12996 by support
This is good news, thank you for letting us know.

Regards

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

More
06 Aug 2024 09:18 #12994 by xpycy001
Modified the following parameter values
EasyUAClient.AdaptableParameters.SessionParameters.ServerShutdownRetrialDelay = 5minutes

EasyUAClient.AdaptableParameters.SessionParameters.EndpointSelectionTimeout
EasyUAClient.AdaptableParameters.SessionParameters.SessionConnectTimeout
EasyUAClient.AdaptableParameters.SessionParameters.OperationTimeout
EasyUAClient.AdaptableParameters.SessionParameters.CloseTimeout

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

More
06 Aug 2024 09:16 #12993 by xpycy001
Close the final reply to the current article

1) After 2-3 months of actual operation observation, the problem has been basically solved at present
2) The reason is basically determined to be caused by the default connection parameter of QuickOpc's driver (EasyUaClient)
3) Scenario: The client connects to more than 10 machines normally, completes subscribing to multiple locations, and then the ServerConditionChange shows as disconnected. When EasyUaClient is reconnected, the organic rate thread count slowly increases. When multiple machines and locations are disconnected at the same time, after about 2-4 hours, the thread count reaches the 2000 limit
4) Solution: Modified the reconnection interval control
5) At present, such anomalies have not occurred again
6) Regarding this issue, it first appeared after December 27, 2023, when another problem was modified (the issue of delayed issuance from other machines caused by disconnection and reconnection)
www.opclabs.com/forum/ua-connections/3667-quickopc-reconnect-problem#12495
7) So far, QuickOpc has basically solved several major problems in my project practice.

Thanks
2024.8.6 17:17
The following user(s) said Thank You: support

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

More
08 Jul 2024 07:46 #12926 by support
Hello.

The reconnection settings you are doing appear correct. I have tested them, by modifying the basic subscription examples we have, and they worked for me. So, it looks like that there must be something else different in your program that causes the reconnections to behave differently. The recommendation is to start with a simple program like did, test the reconnections, and then gradually look for what is done differently in the real program.

However, there are some changes and fixes in the current version that may affect you, and I would highly recommend that you switch to the current QuickOPC version (5.80.278 or later). There was nothing made to address specifically your problem, but there were changes and fixes in the related areas. For example, we fixed a problem in which the faulted connection was not reported through DataChangeNotification quickly enough (it could take up to the reconnection delay before it was reported).

Regards

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

More
05 Jul 2024 08:11 #12919 by xpycy001

Hi ,support:

Review current issues
1) During the operation of the client, when the machine is disconnected, there is a connection exception that causes the thread to become larger, ultimately reaching the maximum thread pool limit ( ThreadPool Max Count: 2000)
2) has manually set the time interval for retry connections. For example, I set the interval to 5 minutes, but in reality, the connection is reconnected after 20 seconds. Please refer to the attached screenshot
3) I now want OpcUAclient to try reconnecting every five minutes for disconnected machines. How do I configure the parameters ?

current setting:
"RetryConnectDelay": 300,
"EndpointSelectionTimeout": 15000,
"SessionConnectTimeout": 60000,
"OperationTimeout": 120000,
"CloseTimeout": 5000,

easyUAClient.IsolatedParameters.SessionParameters.RetrialDelay = 300 * 1000;
EasyUAClient.AdaptableParameters.SessionParameters.RetrialDelay = 300 * 1000;


Simon
2024.7.5 16:03

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

More
05 Jul 2024 08:05 #12918 by xpycy001
Hi ,support:

Review current issues
1) During the operation of the client, when the machine is disconnected, there is a connection exception that causes the thread to become larger, ultimately reaching the maximum thread pool limit ( ThreadPool Max Count: 2000)
2) has manually set the time interval for retry connections. For example, I set the interval to 5 minutes, but in reality, the connection is reconnected after 20 seconds. Please refer to the attached screenshot
3) I now want OpcUAclient to try reconnecting every five minutes for disconnected machines. How do I configure the parameters ?

current setting:
"RetryConnectDelay": 300,
"EndpointSelectionTimeout": 15000,
"SessionConnectTimeout": 60000,
"OperationTimeout": 120000,
"CloseTimeout": 5000,

easyUAClient.IsolatedParameters.SessionParameters.RetrialDelay = 300 * 1000;
EasyUAClient.AdaptableParameters.SessionParameters.RetrialDelay = 300 * 1000;


Simon
2024.7.5 16:03
Attachments:

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

More
19 Jun 2024 07:09 #12878 by support
Hello.

While I do not know the concrete cause of your issues, it should be said that in case of *excessive* network problems, there are scenarios that are effectively impossible to handle gracefully. QuickOPC tries to reestablish the connections (which is ultimately what users want) when a problem is detected on the OPC UA level. But at the same time, there can still be TCP connection "leftovers" (such as unclosed connections) that take long time to close and clean up (and we depend on the system and the UA stack in this respect). If the network problem occurs rarely, this is OK - eventually the "leftovers" will be cleaned up. But if the network problem repeats, a buildup of the "leftovers" can occur.

Regards

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

More
16 Jun 2024 12:06 #12876 by xpycy001
After a long period of observation, it has been preliminarily determined that this reconnection is caused by network anomalies. The only misunderstanding is that individual machines or points should be arranged in order, rather than reconnecting multiple tasks in parallel at the same point. The above is just personal speculation, so in order to solve the problem, the timeout parameter has been modified. If an exception occurs and the thread exceeds its maximum value and the time period becomes larger, it indicates that modifying the timeout parameter can help solve the problem

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

More
16 Jun 2024 11:55 #12875 by xpycy001
Hi , support:
The following information is recently collected
Part A :
Regarding the issue of stopping production in this specific situation, a lot of tests have been conducted recently, and the environment is as follows:
1.1 We used 5 physical machines and simulated 12 VM virtual machines. Each virtual machine was templated with an opcServer (Kepserver) and imported 300 points,
1.2 There are a total of 12000 point configurations, of which 30 points are written back per second. Finally, a client. exe (EaseyUaClient) is used to connect simultaneously
1.3 Using unplugging the network cable, modifying the point path (simulating batch point not saving), and shutting down the virtual machine, after repeated attempts, the problem could not be reproduced, and finally abandoned this simulation.
Part B:
1) Has been on the actual project site recently, with more than 30 clients in total, and a few of them have encountered anomalies again. I have conducted corresponding information collection
2) I have monitored the number of threads on each client. exe (EasyUAClient) end, and there is a slow growth of client threads, ranging from exceptions to reaching the upper limit, which takes about 1-4 hours before and after;
3) I extracted the dump document and opened and analyzed it using VS2022, with clear exception prompts
4) There are more than 1920 threads queuing, all waiting for another thread. I will delay taking a screenshot of the code location
5) The code for the most internal waiting;
dump debugger:
[24256] NET ThreadPool Worker =>
UaSCUaBinaryClientChannel. cs=> line 265
1==>writeOperation End (int. MaxValue);==>// here....
Opc.Ua.Core.dll Opc.Ua.Bindings.ChannelAsyncOperation at line 185
2=>if (! M event. WaitOne (timeout)&&throwOnError) //here: WaitOne (timeout)
at same time : 1,978 Threads blocked at same code line
I Think , may be timeout too largue,retry interval too small
I noticed the target m event Set() is related to timeout, I am trying to adjust the parameters
EndpointSelectionTimeout = 15* 1000
SessionConnectTimeout=15 * 1000
OperationTimeout=10 * 1000
CloseTimeout=5 * 1000
RetryConnectDelay=60*1000
Attachments:

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

More
12 Jun 2024 17:28 #12867 by support
Hello.
It might not even be possible to resolve problem without having a reproducible scenario in our lab. That would require you to put together a VM/VMs for the repro, which we can then run here and put on them our debug versions and debug tools.

Aside from that, we can try to figure out something using remotely collected information, but that is a long shot. First thing needed is the one I described in my last post, i.e. obtain the stack traces from the blocked application.

Regards

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

Moderators: support
Time to create page: 0.101 seconds