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.

Connecting to many OPC-servers using multiple threads gives Timeouts

More
24 Sep 2020 15:26 #8944 by support
Oh, that's great to know. Thank you.
We should either document it somewhere, or think of how to actually automate this in the software itself.

Best regards

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

More
24 Sep 2020 14:30 #8941 by zaglerp
Hello,

when I call ThreadPool.SetMinThreads(60, 60) before reading all the nodes, the operation takes only 5 seconds now.
Thank you, I will set this value in our application as well.

KInd regards
Peter

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

More
23 Sep 2020 05:59 #8931 by admin
Thank you.

One more thing to look at is the .NET thread pool. QuickOPC uses threads from the pool for various things internally. I can imagine that a problem can arise when the demand for threads is significantly higher than the number of threads being provided from the pool. Many threads will then have to wait, and if there are timeouts on the waits, corresponding errors would be returned.

I suggest that you have a look at docs.microsoft.com/en-us/dotnet/api/system.threading.threadpool?view=netframework-4.7.1 , and examine what GetAvailableThreads, GetMaxThreads and GetMinThreads return, and experiment with increasing the value through SetMaxThreads, SetMinThreads.

Best regards

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

More
21 Sep 2020 11:05 #8924 by zaglerp
Hello,

one target server per host.
Please have a look at the sample code attached:

UAAttributeDataResult[] attributeDataResultArray = client.ReadMultiple(new[]
{
new UAReadArguments("opc.tcp://10.199.12.51:4840", node),
new UAReadArguments("opc.tcp://10.199.12.52:4840", node),
new UAReadArguments("opc.tcp://10.199.12.53:4840", node),
new UAReadArguments("opc.tcp://10.199.12.60:4840", node),
new UAReadArguments("opc.tcp://10.199.12.61:4840", node),
new UAReadArguments("opc.tcp://10.199.12.62:4840", node),
and so on ...


Kind regards
Peter

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

More
21 Sep 2020 11:01 #8923 by admin
Hello,
thank you for update.

One more additional question please:

4. Are the target servers always on separate computers (hosts) = one per computer, or are they all on the same host, or how roughly are the servers "distributed" among computers?

Best regards

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

More
21 Sep 2020 09:21 #8922 by zaglerp
Sorry for using the wrong forum thread. Is it possible to move it?

Regarding your questions:

1) The exception thrown:
OpcLabs.EasyOpc.UA.UAServiceException: OPC-UA service result - Error establishing a connection: BadRequestTimeout = BadRequestTimeout.
---- SERVICE RESULT ----
Status Code: {BadRequestTimeout} = 0x80850000 (2156199936)
Description: Error establishing a connection: BadRequestTimeout
Status Code: {BadRequestTimeout} = 0x80850000 (2156199936)
Description: BadRequestTimeout
Additional Info: <ExceptionTrace>
---- REMARKS ----
If this error happens during connection to a server: Is the server running and fully operational?

+ The SDK action called was "DiscoveryClient.GetEndpoints".
+ Following (26) events were gathered during the action on activity ID [38], in the order of first occurrence:
SDK trace: GetEndpoints Called. RequestHandle=1, PendingRequestCount=1
SDK trace: Channel 0 in Connecting state.
[57] SDK trace: Channel 0: SendHelloMessage()
3*[59] SDK trace: Channel 0: ProcessAcknowledgeMessage()
3*[59] SDK trace: Channel 0 in Opening state.
[59] SDK trace: Token #0 created. CreatedAt = 09:13:19.490 . Lifetime = 3600000
2*[59] SDK trace: Channel 0: ProcessOpenSecureChannelResponse()
[59] SDK trace: Security Policy: opcfoundation.org/UA/SecurityPolicy#None
[59] SDK trace: Sender Certificate: (none)
[59] SDK trace: Token #1 activated. CreatedAt = 09:13:19.490 . Lifetime = 3600000
[59] SDK trace: Channel 1441275268 in Open state.
[35] SDK trace: Channel 1441275268: Close
[35] SDK trace: Channel 1441275268 in Closing state.
[35] SDK trace: Channel 1441275268: SendCloseSecureChannelRequest()
[58] SDK trace: Channel 0 in Closed state.
[58] SDK trace: CLIENTCHANNEL SOCKET CLOSED: 03A0AAD1, ChannelId=1441275268
[58] SDK trace: Channel 0: SendHelloMessage()
[59] SDK trace: Channel 0: SendHelloMessage()
[59] SDK trace: Token #0 created. CreatedAt = 09:13:21.436 . Lifetime = 3600000
[59] SDK trace: Token #0 created. CreatedAt = 09:13:21.449 . Lifetime = 3600000
[59] *Event list length limit exceeded*
+ Events starting with activity ID in [] may not necessarily be related to the current action.
+ The error occurred when preselecting the endpoint for discovery URL "opc.tcp://10.199.12.78:4840".
+ The client method called was 'ReadMultiple'.

2) It is always the same error

3) For testing I always do a restart of the program. I will try to modify the hold period in my sample.

Kind regards
Peter

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

More
04 Sep 2020 07:50 #8858 by support
Oops. This forum thread is under "QuickOPC-Classic ..." category, not QuickOPC-UA, and therefore I thought we were dealing with OPC "Classic" (I have not looked at your code yet).

No, the "automatic subscriptions" does not exist in/apply to EasyUAClient.

But I need to ask additional questions now.

1. Can you please provide the precise text of the "timeout" error you are referring to, and the associated call stack in the Exception object? And, if there non-null InnerException in it, its message text and call stack, and so on.
2. Is it always the same error, or are there more?
3. As you know, QuickOPC handles connections/disconnection invisibly to the developer. But they still need to be made, and therefore the "first" read on a particular target server is always more demanding than subsequent ones. Is your problem/your test done after a fresh start of the program, or does it behave the same upon subsequent reads? Also note that the default setting is to disconnect in several seconds after last use, if there are no subscriptions, so after that period elapses, QuickOPC disconnects and a new connection is needed again; it might be wise to increase this "hold period" in heavily loaded systems, where operations themselves take long, to prevent unwanted disconnections/reconnection which further contribute to the load.

Regards

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

More
03 Sep 2020 15:09 #8852 by zaglerp
Hello,

we are using UA - is it the same for the UA client?

Kind regards
Peter

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

More
03 Sep 2020 13:42 #8847 by support
Hello,
I admit that we have not tested with such large numbers of servers. The recommendations I gave were based on the knowledge of internal design and implementation.

Looking at the results of your tests, I think that there is a possibility that additional functionality inside EasyDAClient (so-called automatic subscriptions) is responsible for (at least parts) of it. Can you please do the steps described here and re-test?:

www.opclabs.com/forum/reading-writing-subscriptions-property...scriptions-made-with-opc-reads

Also note that if the problem was the timeout error, but not the long time by itself, the timeout values can be configured to be longer.

Best regards

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

More
03 Sep 2020 12:30 #8844 by zaglerp
Hello!

In our case we have to communicate with more than 100 servers and the startup time of the client now exceeds 6 minutes, when using MultipleRead().
We also experience Timeouts, although al servers are up and running.
Can you please explain, what we can do to reduce it and how to avoid the Timeout situations?

I have attached a simplified sample showing the results using different approaches for initiating the communication:

Test1: (Main1)
Accessing 28 servers with one call to ReadMultiple()
Duration: 51 sec. 2 Timeouts

Test2: (Main2)
Accessing 28 servers with subsequent calls to single Read()
Duration: 22 sec. No timeouts

Test3: (Main3)
Accessing 28 servers with subsequent calls to single Read() having a delay of 100ms:
Duration: 5 sec, No timeouts

Thank you for your support.
Peter
Attachments:

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

Moderators: support
Time to create page: 0.070 seconds