As I explained, leave AllowAsynchronousMethod at the default (true). Only set it to 'false' if reads are not working at all, and return an error indicating that the asynchronous method is not functional.

As a note, I do not understand this part of your post: "there is no synchronization between OPC Client nad OPC server." The synchronous and asynchronous OPC operations have nothing to do with "synchronization" between the server and the client. Synchronous means that the OPC client makes a call and waits for the result. Asynchronous means that the OPC client makes a call and can proceed doing something else, and the OPC Server sends the result later. Asynchronous method is preferred in OPC, and that's why it is a default. QuickOPC hides the differences from you, and the ReadXXXX and WriteXXXX methods of EasyDAClient object always appear as synchronous to the developer, independent of whether internally the OPC call is synchronous or asynchronous.

Regards

The 'Isolated' setting causes each instance of EasyDAClient to maintain its own connection to the target server. Normally you can leave it at default ('false'), which means that only one connection will be kept to any target OPC server, and it will be shared by all EasyDAClient instances.

Only set 'Isolated' to 'true' if you need multiple separated connections to the server, e.g. if you need to set some parameters differently for each connection, or if you need to make operations in parallel (on each connection, operations are serialized). So far I have no indication that you have such needs, so I see no need to set 'Isolated' to 'true'.

Note: If you have just one instance of EasyDAClient, then, it does not matter whether it is set to 'true' or 'false'.

Similarly with the sync/async settings. Recommendation is to leave them at default unless there is a specific reason to change them. The default is that both sync and async are allowed, and async is preferred. If, for example, the server had a bug in the async implementation, it would be advisable to disable the async method. But if it works, there is no need to change it.

Regards

We have tried to reproduce this as you indicated, with a local connection to Matrikon simulation server, and with 1000 items. We used one quite fast computer, and in a second test, an old, relatively slow notebook.

We were not able to reproduce the issue under normal circumstances. Reading 1000 items typically took considerably less than 1 second, practically always below 2 seconds, and never gave the error ("read not completed"). Longer time was always needed for the first read operation, as it involves setup operations which are not necessary for subsequent reads.

In one test, accidentally, we have run into situation where the read times started growing higher than stated above. But that was with a coding error: We have created and used more and more instances of EasyDAClient type with Isolated property set to 'true'. Each of these then maintains its own connection to the server and consumes relatively high amount of resources. So this was a coding bu: When using "Isolated = true", the developer is responsible for keeping the amount of such (active) instances low enough, as to not cause any problem. I want to mention that, so that you can check your code and make sure you have not done the same mistake.

Apart from that, the problem was not reproducible, and therefore we cannot proceed further on the issue.

Regards

I suppose Matrikon simulation server with local connection should be relatively fast. It is weird that it would not be possible to read 1000 items in 30 seconds or so.

We will try to reproduce the issue here with the simplest achievable configuration, i.e. local connection to Matrikon simulation server. I will let you know the results.

Regards

It is very unlikely that this is caused by the queue overflow, mentioned in the text. Almost certainly it is what it what is says at the beginning: "Read not completed" - that is, a timeout error, indicating that the OPC operations were not completed during the timeout you used (30 seconds).

What makes you believe that this is not caused by the OPC server or network?
I have made a test, and we are able to consistently read 1000 items over the local network from or simulation server in approximately one second.

Hello,
I have separated this into a forum thread of its own. Each forum thread should be dedicated to one issue.

What makes you believe that the slow read is not caused by the OPC server or network?
I have just made a test, and we are able to consistently read 1000 items over the local network from or simulation server in approximately one second.

Best regards