You are right. There actually is a bug in current QuickOPC, the first of code should work as well. It will be fixed in the upcoming QuickOPC version (2019.1). Thank you for reporting it.

Just for clarity, the expected behavior does not *directly* set the PublishingInterval in UASubscriptionParameters to half of the SamplingInterval in UAMonitoringParameters. It should set it to zero. The zero has a special meaning, and at the moment QuickOPC actually creates the subscription, it will interpret the zero and use the half of SamplingInterval instead. This is done so that the parameters do not have to modify themselves mutually.

Best regards

I probably know what has happened. It is not that the rate was revised by the server. The issue was likely in the parameters passed in from your code. The PublishingInterval is set to 0 in the parameters (and then automatically determined by QuickOPC from the SamplingInterval) only in certain overloads of the constructors used to make the EasyUAMonitoredArguments. In other cases, the PublishingInterval has the default of 1000 ms. I would have to see the precise code to determine what has happened, but this is the likely cause.

I admit that this may not be quite clear to the developer from the current documentation.

Best regards

I understand that sometimes there might be a need for "seeing" the physical grouping of the values, but hiding them is a deliberate design decision that has to do with the very principles of QuickOPC, and it is not going to change. Different toolkits will work differently in this respect.

If you have set the SamplingInterval to 200 ms, QuickOPC will set the PublishingInterval to 100 ms, and request these from the server. if the server does not adjust the values, you should then be getting new values at around 100 ms rate (and their time "resolution" will be 200 ms in principle). The server can modify the requested rates. If you can get values faster with OPC Scout, it's weird. Firs thing to do is that I suggest to attach a handler to the static EasyUACLient.LogEntry event, and observe what happens when the subscription is being set up - to check whether the rates are as expected (you may post the log here).

Regards

Just to be sure: Be aware that there are two "rates" to be set/considered, between the OPC UA server and the client.

In QuickOPC, one is called SamplingInterval. That is the logical rate. And the other is PublishingInterval. That is the physical rate. The physical rate should be set to suit the needs of the logical rate, but it is the logical rate (SamplingInterval) that matters.

The PublishingInterval is typically faster than SamplingInterval (QuickOPC makes it half the SamplingInterval normally), but can also be different, you can change that from the code as well. It can even be longer than SamplingInterval, which typically only makes sense with Queuing enabled (not all servers support it), otherwise sampled data might get lost.

This does not directly concern your question, but indirectly it does.

Regards

Hello.

There is no such event in QuickOPC.

With some simplification, in the situation you have described, the OPC server will send the 50 values (in one message) each 200 ms to the client.
QuickOPC will deliver this to you each 200 ms as 50 separate DataChange events or callbacks.

The fact that the 50 values come together from the server to the client is purely a physical, transport concept, that has no (= should not have) semantics/meaning to the client. You cannot rely on it anyway, as it won't always be the case. If you have written your program in such a way that it requires those 50 variables come together at the same time, you would be doing it wrong already.

The "grouping" of values makes sense between the server and the client, because the connection is, in comparison to the internal processing inside your program, uncomparably slower. The grouping achieves efficiency. On the other hand, if you were to process the incoming message "as a group", at some some early or late point you will have to write a loop inside your code to process them one by one anyway. QuickOPC does this "ungrouping" already, but as you can see, the performance impact is not big in this case, because it does not differ much from you doing it in your code.

If you need to interpret the incoming values as a group, you should have some other information that glues them together. Typically that is a timestamp. Reassembling the values using this extra information complicates the code, but is the right way to do it.

If you want to "group" values you send over your websocket API, but do no care about how precisely the values are "grouped", you can have a logic that ships out the values always after a certain number of events accumulate, or after a certain delay.

Best regards