There are some defaults but as this is an internal UA SDK stuff, I am not sure whether you can leave entries out; I suggest that you start with the "default" configuration file and modify the parts that you need.

The configuration that QuickOPC uses when no custom config is in effect: I posted it already - in this forum thread, see post #3952 from March 23: It is the last file attachment there.

Best regards

This particular error message is related to the SessionConnectTimeout. IF it is the only kind of timeout error your are getting, I would just modify the SessionConnectTimeout value to suit your needs.

And, there is one more related thing you should consider. After a session-level error (such as the timeout error we are talking about) occurs, the expected EasyUAClient behavior is as follows: For certain duration following the error, all calls that reference the same server will fail *immediately* (without waiting). This should be the case with your subsequent "browse" calls as well. This behavior is intended to 1) reduce the load on the resources (client, network, server) by limiting the number of reconnection attempts, and 2) prevent repeated lengthy blocking on the client side. The length of this time period is controlled by the RetrialDelay property in EasyUAClient.AdaptableParameters.Session, can defaults to 10000 (10 seconds).

Regarding the XML config file: It's a bit complicated, but I believe it is described satisfactorily in the doc I mentioned: Concepts document, section Advanced Topics, chapter Application Configuration. What is not clear there please?

Best regards

Hello.

Tables in the following documents list the various timeouts, and where to configure them:




Most parameters can be set directly from the code. The OperationTimeout - which you may not need to change - depends on which one(s) you are getting - is a lower-level parameter that needs a more complicated approach. Please read the Concepts document, section Advanced Topics, chapter Application Configuration. For convenience, below is the "built-in" configuration used; you can use that one and just modify the item(s) that you want change.



Best regards

I will give an answer in two parts. This first part is what I can answer quickly.

Yes, EasyUAClient.BrowseNodes(...) performs synchronously.

Detection: In case of timeout and any other error, it should throw an exception (UAException). Depending on the error/timeout cause, there will be different messages and InnerException-s in it. I would be interested to know whether you have received any exception, and if so, what are the details of it. Or is it still the exception listed under www.opclabs.com/forum/ua-reading-writing-subscriptions/1781-...-than-1-minute/reply/3942#3827 ?

Communication problems should *not* be a cause for incomplete results returned by BrowseNodes(...). That it, the method call should either return all correct results, or nothing at all (when it throws an exception). Let me know if it behaves as described. If, of course, you are making repeated calls to BrowseNodes(...), some of them may succeed and some may fail. In such case, your "total" results would be incomplete, of course.

With regard to instructions on how to change the timeouts, I will assemble the information and post it here, later.

Best regards

Methods other than SubscribeXXXX/UnsubscribeXXXX perform synchronously and are therefore OK to block under error conditions until their timeouts expire - but obviously not forever. There are, however, many of them (mostly configurable), and they are quite long - up to 10 minutes.

I have looked through our earlier conversation. It is my understanding that you have now removed the code that attempts to unsubscribe/resubscribe in case of errors, is that correct? - please confirm.

Assuming that the answer to the above is Yes, can you please describe in more details, setp by step, what is happening? Is it, for example, like this?

1. Network is somehow disconnected.
2. Your app calls SubscribeMultiple.
3. After cca 1 minute, the event handler for MonitoredItemChanged receives a notification with the .Exception property set to the error in your last post.
4. At about the same time, the SubscribeMultiple call finally returns?

Or is the sequence or the timing different?

Thank you.

We have not made any changes in this area so far. With the above describe sequence of steps, the only improper/unexpected behavior would be that the SubscribeMultiple call waits for 1 minute (until Step 4), instead of returning quickly after Step 2 - which we do not consider a major problem. But I need to be sure that I understand the observed behavior correctly first.

Best regards