Thank you for the information.

I think that the most likely answer is that the server is simply sending values in this order. If you want to verify that, we would need to employ some deeper analysis - for example, make a Wireshark capture of the communication between the client and the server, and then determine where the issue comes from (server side, or client side).

Regarding your code: In general, it is preferable to use the SubscribeMultipleMonitoredItems methods (as opposed to just SubscribeMonitoredItem). The reason for that is that each call requires a roundtrip to the server and making many calls is thus inefficient, The reason why you received "worse" results with SubscribeMultipleMonitoredItems might be in this:

SubscribeMonitoredItem takes as an input the SamplingInterval (which is how often the underlying data source should provide values to the server), and automatically determines the PublishingInterval (which is how often the server should provide values to the client), usually as one half of the SamplingInterval.

SubscribeMultipleMonitoredItems, on the other hand, by default, does not automatically determine the PublishingInterval - it uses whatever value it finds in the parameters, and the default is 1000 ms. This is probably no good if your SamplingRate is e.g. 1000 ms as well. I suggest that you use the SubscribeMultipleMonitoredItems, but in addition, set the monitoredItemArguments.SubscriptionParameters.PublishingInterval to one half of the SamplingInterval or less.


Best regards

And here the values for point 3:

14.52.17.256 : ns=2;s=User.Float999 : 490 {System.Double} @09.11.2015 13:52:15 @@09.11.2015 13:52:16; Good
14.52.17.632 : ns=2;s=User.Float999 : 488 {System.Double} @09.11.2015 13:52:14 @@09.11.2015 13:52:14; Good
14.52.18.721 : ns=2;s=User.Float999 : 489 {System.Double} @09.11.2015 13:52:15 @@09.11.2015 13:52:15; Good

Hello

1. I use sampling-rate. This s set to the same value for all items

2.
3. I will test and post the values in a view minutes

4. I have tried
this code

and also this code

The second code produced more problems tha the first one.

I have tried saplig rate 1, 500 and 1000

Hello. Some additional questions:

1. Do you use the same parameters (such as sampling rate etc.) for the items? (Background: Different parameters can cause the items be placed on separate subscriptions, which could be a cause for inconsistent order).

2. Can you post here the piece of code that handles the event notifications? Specifically, I am interested in whether you would catch an unsuccessful notification indicating some kind of a problem.

3. When the values come in "wrong" order: Please obtain their ServerTimestamp and SourceTimestamp, and check their order as well, and let me know the result.

4. What sampling rate (and/or publishing rate) do you specify for the items? Ideally, can you also post the piece of code that does the Subscribe?

Thank you
Best regards

From: D.
Sent: Monday, November 09, 2015 9:20 AM
To: Z.
Subject: ...

Hello,

during Testing i got a new problem:

The setting for my test :
a OPCUA Server with 1000 Float Variables (Float1 to Float1000)
a Delphi Client with your Components where all Variables are subscribed in the same way like your example, but in a vcl Form instead of a console app

If i change all variables every second ( I send 1, next second 2 then 3 ……) i have the following problem:
Some of the changed values are completely missing (the on change event didn’t fire) and some values are not in right order for example if get Value 1 then 3 then 2 then 4.

I have testes with your example Server and another server from sw toolbox with the same effect.

Is there a limit how much variables can be received via subscribing or are there some settings that can cause these problems?


With kind regards

D.