Thanks for letting me know. BTW, ReadItem (as opposed to ReadItemValue) also does not wait for a "Good" quality.

Alright, I think I have now a better understanding of what is happening. It is a combination of two things, and both of them have to do with the initial connection to the server. Unfortunately, you have initially written that the problem does *not* happen with the ReadItem method, which I think, after reading your last post, was not correct. I believe that without being connected upfront, the time to execute an *initial* ReadItem would be around 8-10 seconds as well.

Here is what I think is happening:

Step 1. An initial connection to the server requires 8-10 seconds (taken by the server)
Step 2. A time from the moment of the initial connection to the first "good" quality takes additional 8-10 seconds (taken by the server).

QuickOPC maintains the connections automatically. If not connected, the connection has to be made first. Therefore both methods (ReadItem and ReadItemValue) require at least the Step 1 delay; the ReadItemValue then also requires the Step 2 delay.

The initial delays are cause by the server and therefore *must* happen at some time. The only optimization that can be done is to avoid disconnections from the server, so that they are not required over and over.

One way to go is to enforce the connection - which is what you have done by using the Subscribe. Note that you have not really avoided the initial delay - that is impossible, you now have it between the SubscribeItem call and the first DataChange notification - but made it more suitable for your app. You do not need three EasyDAClient objects for this - it can be done with just one.

Other method (probably not so good in your case) is to significantly increase the HoldPeriod, which is for how long the client keeps the connection to the server open after it has been used. Normally it is just a couple of seconds, but you can make it e.g. 1 day or so or even more. This will get rid of the delay in case of second and third etc. Reads, but the first Read will still require the delay as before.

For some applications, it is also possible to *shorten* the timeout for Read methods (possibly combined with the previous method). Then, the first Read will simply timeout very quickly, but still initiate a connection. You can set the timeout e.g. to 1 second only. If you can handle the timeout by ignoring it or showing that the value is momentarily unavailable, and then come to do the same thing later, you would prevent what you call "freeze". The Read method won't take more than the configured timeout.

Best regards

Yes. As I explained, the ReadItemValue method waits until the value becomes "Good", by using a subscription. The subscription is initially relatively slow (10 seconds). Try to make it faster e.g. like this:
Best regards

In order to change the data source, modify your last line to read e.g.:

And, try a .CacheSource as well.

Please post the piece of your code that does the read, and I will respond with a corresponding modification.

Best regards