Hello,
thanks for clarification.

To #1: There are two rates in play, One is the sampling rate - how often the server is supposed to collect the data. The second one is the publishing rate - how fast the server is allowed to send the data to the client. Normally, you specify the sampling rate with QuickOPC, and the publishing rate is set to be twice as fast. But there are some limits, and the server may modify the rate requested by the client.

So, the first thing is that the server actually must collect the data fast enough. I suppose you already specified the sampling rate fast enough? Because, if the serer does not even collect the data, they of course won't be delivered to the client either.

Second, the data changes must be delivered to the client. And here is where it gets tricky. The default setting of the publishing rate (twice as fast as sampling) should assure that each data change makes it to the server, but there is no absolute guarantee. For example, if the network communication is slow, or even the client response is slow (because the client needs to ask for new data), data changes can get lost.

A solution for this is queuing. This is specified in the OPC UA standard. QuickOPC has the client-side support for it, but not all servers support it (for data; the queuing is necessary for events but that is a different story). For more about it, see reference.opcfoundation.org/v104/Core/docs/Part4/5.12.1/#5.12.1.5 . If you server supports queuing, then turning it on on the client side might help - or at least improve the situation.I do not know, however, if your server supports it. Can you find out? If it does, then what you need to do is to set the QueueSize in UAMonitoringParameters passed to the subscription - see opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...itoringParameters_members.html .


To #2: If your server exposes the array *only* as a node per each element, then the only improvement you can do is to use WriteMultipleValues instead of repeatedly calling WriteValue.

If your server exposes the array (also) in a single node, then it is possible to read/write the whole array at once, or read/write parts of it (ranges), if the server supports it. See opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...tml#Index%20Range%20Lists.html .

Best regards

Hello,
let me have some additional before I answer:

To #1: What do you mean by "last change"? I can imagine that some changes are not always "seen" by the client - and I can provide some explanation and hints to that. But, why "last"? Did you mean "I lose some changes"? Or was that simply an example that out of the two changes, the second one is lost?

To #2: Does your OPC server expose the array as a) a single node with value as itself is an array, or b) multiple nodes, in which each node corresponds to a single element of an array, or c) a combination of both approaches? And, what do you mean by "insert" ? - that is not normally used to describe an operation in which a new element is entered into a middle of the array and the elements with higher indexes are shifted towards higher indexes - is that what you meant? Or did you mean simple "setting" of elements while *keeping* their indexes?

Thank you