Here is why I strongly recommends against changing the OPC UA-level timeout for achieving what you have described.

The two timeouts - the one for the communication between the OPC UA client and the server, and the other for communication between the OPC server and the PLC - have very different purpose, and one cannot safely stand for the other.

If you shorten the OPC UA-level timeout in order to get "faster response" in case of communication problems, here is what will likely happen: The UA client side will abandon the pending request sooner, but it will not be cancelled on the UA server. The server will continue waiting for the value from the PLC. Further requests to the server, if they come "too soon", will have to wait until the outstanding requests are finished, make them to take even longer(!). And the number of uncompleted requests may start rising inside the server, causing further problems such as memory increase, queue overflows etc.

Suggestions to handle your issue properly depend on the application, but in general they are:
- Whenever possible, use OPC subscriptions instead of repeated Reads.
- Set the timeout for communication between the OPC server and the PLC to the right value.
- If you have to use the Reads, set the MaximumAge in the UAReadParameters (that you can pass to the Read) to a value that would allow the server to provide you the value from its cache in usual case (and, if needed and supported, configure the server to poll the value periodically for you). In fact, default value for MaximumAge already asks the server to give data form the cache anyway, so I am a bit surprised that your calls need to wait for the PLC, but it is possible that either you have changed the MaximumValue, or that the issues arise on the first Read when obviously there is nothing in the cache, or that the server does not interpret the MaximumAge correctly.

Best regards

I will respond in two posts. In this first post, I will try to explain how to do what you have asked for. In the second post, I will explain why you should not really do it.

The timeout value you are looking is most likely the OperationTimeout on the OPC UA service level. There is no configurable property for it in QuickOPC. It is possible to change it but you must go quite deep. To do that, read opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...plication%20Configuration.html . In short, you need to create two XML config file AND change the value of the ConfigurationSources property.

For convenience, I am attaching the configuration file for OPC UA SDK that we are currently using inside QuickOPC. Look for <OperationTimeout> under <TransportQuotas>. Currently it is 120000 milliseconds (2 minutes).




Note that by shortening this timeout too much you can cause some otherwise correctly performing operations to appear failed.

Best regards

Before I answer this in more details, please clarify.

Are you connecting
a) directly to a PLC that has an OPC UA server embedded in it, or
b) are you connecting to an OPC UA server on (your own or) a separate box that is then in turn connecting to the PLC?

Because, certainly in the later case, I would argue that the right place to tune the timeouts would be on the OPC UA server, if the communication is issue is *between the OPC UA Server and the PLC*.

Regards

Hello (I have moved this to a separate topic; I will also answer the original issue separately, later).

For all the hold periods, there is one common equivalent. It is in a (static) EasyUAClient.AdaptableParameters.SessionParameters.HoldPeriod. When a EasyUAClient ahs Isolated=true, then use easyUAClient.IsolatedParameters.SessionParameters.HoldPeriod.

There is no equivalent for UpdateRates.ReadAutomatic, the EasyUAClient doe snot have that behavior at all.

For timeouts, there are multiple settings that get combined together, and you cannot influence them in "one go" as in OPC DA. The most important is probably EasyUAClient.AdaptableParameters.SessionParameters.SessionTimeout .

Regards