OK, there seems to be basic misunderstandings which we need to clarify first.

The equivalent of OPC DA "Read" in OPC UA is "Read" again. In QuickOPC, this is invoked using various methods whose name starts with "Read", such as ReadMultiple and so. QuickOPC, in addition, takes care of connections (sessions) - there is no need to explicitly connect.

So, in order to read something, you just need to call the Read.

What makes you believe that this is not enough, and that you need to subscribe as well?

Best regards

Hello,
thanks for the numbers.

What I plan to do is to set up a similar test here and measure the usage, to understand what is happening. Please give me some time. I will post here then again.
I would not be surprised if reading 300 variables once per second would be relatively demanding, but subscriptions should be less demanding than that.

But, I am afraid there might be some profound misunderstanding in play. I have not found any processing of the subscribed items in your code. That is, the part that in our example (opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...es%20for%20data%20changes.html ) is initiated by the statement

But you have no such statement in your code. There is no point in making subscriptions but not using their results. Can you please explain why are you doing that? I can imagine only one reason (to keep the client connected to the server) - but in this case, it would be perfectly sufficient to subscribe to just one item (and even better, that can be done without any subscription, by prolonging the disconnection timeout).

But that's not the whole story. If you actually wanted to have the data of these variables available to you for extended periods of time and not just once, the *highly preferred* approach is to use subscription only. So, in that case, you would keep the subscription call, add an event handler to process the incoming data, but completely remove the periodic calls to Read.

Regards

Hello,
thank you for the code.

Can you please clarify:
1. Are you calling the procedures you listed just once, or in some kind of loop? If in loop, how often (frequency)?
2. Are we talking about a temporary "spike" in the CPU usage, or does it - after one call to the procedure - go high and remain that way?
2b. If so, is that even the case after calling the procedure with the "Read"?

Thank you

If you are subscribing to data, you should have an event handler for the event which actually brings you data. In the example I pointed out before, it was this method:

In the example, the method just displays the incoming data. In your application, I would expect the method to do the actual processing you need with the data. So, I wanted to keep the procedure but leave it basically empty - no executable code inside it, everything commented out.

Regards

Thank you, but I think you have misunderstood what I asked you to do. I was not asking you to remove *all* code related to QuickOPC - leading to, as you wrote, to not subscribing to any changes. I was asking you to keep the code that does the subscription, but comment out the internals of the event handler for the DataChangeNotification event. This way, there will still be subscription, but depending on the CPU usage, I would be able to tell whether the CPU load came from the processing inside the event handler, or elsewhere.