There is no change, and no change is or was planned.

If you need to do other operations while the OPC call is in progress, there is nothing that prevents you from using a separate thread or task to perform the OPC call.

Best regards

Please let us distinguish between making some operation asynchronously in your app, and having asynchronous OPC UA calls. And, "async" is not quite the same as "parallel".

QuickOPC does *not* allow you to make asynchronous OPC UA calls on a single OPC UA connection (session). That is, every Read or Write operation you make runs to a completion, and only then a new operation begins - they are all serialized. The only other thing that runs "in parallel" on the same session are subscription notifications - they are received independently of the Read-s and Write-s (and other operations). The only way to have two Read-s/Write-s in parallel is to use a separate session to the same server, which is normally not recommended (can be achieved by using multiple EasyUAClient instances with .Isolated property set to 'true').

The issue we were working on was that the Write performed from inside the data change handler has delayed the processing of other incoming data changes. That can be resolved by starting a thread for the Write, yes. But when you spin off, say, ten threads like this, the Write-s that they make will be performed in a serialized way, one after another.

The problem may be simply in the server performance. If the server is only capable of doing, say, 10 write operations per second, no amount of client-side tweaking is going to stuff the server with more changes per second.

I should note, however, that it is common for OPC operations to take some "constant", relatively long time, but be not so much dependent on the amount of nodes addressed. So, for example, if writing one node takes 100 milliseconds, it is possible (depends on the server), that writing ten nodes *in one call* will only take e.g. 110 milliseconds, and not 1000 milliseconds. You should experiment/measure these things, and if the server behaves like that and you want to improve the performance, your app should (if the logic allows) accumulate certain amount of "Write-s", and then send them to the server in "batches".

Best regards

As I wrote:

You may, for example, run the Write in a separate working thread as well.

It's as easy as one or two lines of code. But you need to think of the consequences - for example, what happens when the number of these threads, unfinished, increases. This is, by the way, the same case if the calls were truly asynchronous: What happens if you add them faster that they can be processed - as you do in your code? This is precisely the reason why we have not included the async calls - because these situations are complex and do not have a "one size fits all" solution that we can provide, and we want the developer to think about them and handle them the way that's right for the project.

Best regards

In UA client in general, the answer is Yes, you can do async write.

With the current API of EasyUAClient, we do not give you a way of doing reads or writes that would appear as asynchronous to you. But you can emulate that.

Best regards

Hello,
what you describe seems to me the correct behavior, per design.

With respect to your calling thread, the EasyUAClient.ReadXXXX and WriteXXXX methods are always synchronous. That's also clear from the way they return their results (through exceptions and return values, and not through some callback or event).

And, read this: opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...20or%20callback%20methods.html .

So, what is happening is that you call the Write, and it is being executed, and your code in the DataChangeNotification handler is blocked (no matter whether you use the same or different EasyUAClient instance or whether they are isolated or not). Apparently the Write is not particularly fast - it is slower than the rate of incoming notifications. So, after every Write, *one* new notification can be processed, Write blocks again, and the other incoming notifications keep queuing. When you "uncheck" the Write, your processing becomes much faster, and the notifications that were queued so far and did not have a chance to be processed are then delivered and quickly processed by you.

If this is not what you want, you need to re-think the approach. You may, for example, run the Write in a separate working thread as well.

Best regards