We have no such benchmarks.

Subscription should be better than a cyclic reading. If the server supports it, you can even enable "queuing" on the subscription, so that multiple subsequent changes can be transferred at once if needed.

Regards

Hello.
You are really stretching it out far - in good sense

I understand what you are asking for. Currently, the answer is negative - QuickOPC does the heavy lifting of encoding/decoding custom data types from/to UAGenericObject, but it is up to you write code that handles it.

We have considered several approaches to improve upon the current UAGenericObject, such as
1) use 'dynamic' types
2) "map" existing classes to UAGenericObject (this is what you suggested)
3) allow the software to generate the classes for (2) automatically, too.

All these have their advantages and disadvantages. They are on list for some possible enhancement, but are not currently in any concrete short- or mid-term plan. The fact is, only a limited number of users need OPC UA Complex Data, and for them the, existing UAGenericObject is already a big helper. I understand what you need, and the more interest in this feature we spot, the more likely it is it gets implemented soon; but I cannot give any promise.

Best regards

Thank you for the details.
You are confusing two things here.

One is the fact that the variable might be a two-dimensional array "as configured in the server", and the fact that besides the variable for the array itself (StateCumulativeTime), the server provides separate nodes for each element of the array, and the nodes have two indexes - such as StateCumulativeTime[0, 0]. This is completely server-specific behavior. From the point of OPC UA specification the extra nodes have no relation to the base node, and they do not "form" any array. They are just a bunch of separate nodes with names that "happen to look like" a two-dimensional array. These nodes, as I understand it, show correctly in all clients (including QuickOPC), and when you read them, you get a scalar value of the chosen single element - and, that also works in QuickOPC.

The other thing is the actual value provided by the server for the "base" array node, i.e. StateCumulativeTime. You show that you get a one-dimensional array in QuickOPC. You do *not* show what value you get for it in any other OPC UA client. You even wrote "I couldn't read its value" - what did you mean - using which client? And what was the error you got? And have you tried yet another other client?

If you cannot read the thing in other OPC UA clients, and you get one-dimensional array in QuickOPC, what leads you to believe it should be two-dimensional then? It is quite possible that server ships out the value as one-dimensional array. So I am looking for your argument to the contrary. Maybe you have a UA client when you have received it as two-dimensional? - if so, please post a screenshot.

If the thing can be reproduced with KepServer configuration not requiring an external hardware or software, please provide the configuration and we will have a look at the case here. I tend to think, however, that there is nothing wrong in QuickOPC. Have you asked Kepware whether the node is supposed to provide on- or two-dimensional value?

Regards

OK, I was hoping that the variable has a fixed number of dimensions. But it has not - ValueRank == 0 means that it can be either a scalar, or an array with any numbed of dimensions.

The questions is then, whether the server is truly sending it out as one-dimensional array, or whether it sends a two-dimensional array value and it somehow gets interpreted as on-dimensional in QuickOPC.

Have you tried with some other OPC UA client (not OPC DA Classic!), and if so - with which client, and what was the observed value?

Thank you

Good.

Can you please read out (using EasyDAClient.Read) the ValueRank and ArrayDimensions attributes of the same node? (passing the corresponding attribute IDs to the Read; www.opclabs.com/files/onlinedocs/QuickOpc/Latest/User%27s%20....EasyOpc.UA.UAAttributeId.html ).

Thank you