OPC UA Read Single Element of Array Node

[jacobson]

For a little background, I am working on an OPC UA client plugin for DCAF (http://forums.ni.com/t5/Distributed-Control-Automation/gp-p/5235) and ran into an annoying bug in LabVIEW API. The client API has a polymorphic read function with one instance for each data type. What I found was that if you have a valid NodePath input but chose the wrong data type for that item, you won't receive any warnings or errors and the function outputs some default value. This means that there isn't really a way to tell whether the read returned a valid value, so to get around this, I am planning on using the Get Node Attribute function to manually confirm that the user's configuration is correct at program start. What I am unsure about is the case where a user wants to read a single element of an array so I'm hoping someone has done something like this in the path and would be able to tell me:

1. Does OPC UA allow for clients to read a single element of an array item? LabVIEWs implementation does not (from what I could find) but from some google searches it seems like this is allowed.

2. If this is valid, is there a standard way of addressing a single element in an array? 

3. Does anyone know of a free OPC UA server or one that has a trial where you are able to address a single element in an array? If anyone has something like this set up (or tried this in the past) I would also be interested to know what data type the Get Node Attribute returns if the node path is referencing a single item in an array.

[JKSH]

1. Yes, apparently. According to https://opcfoundation.org/forum/opc-ua-standard/clarification-for-index-range-handling-of-readwrite/ the ability to read an array subset (including a single element) is required by the standard. The ability to write is optional, however.
2. I believe it's called "Index Ranges". My previous link shows an example. Here's another: http://forum.unified-automation.com/topic1386.html
3. I don't know of one, sorry

 

7 hours ago, jacobson said:

if you have a valid NodePath input but chose the wrong data type for that item, you won't receive any warnings or errors and the function outputs some default value.

This sounds like a recipe for hard-to-detect bugs... Is there any chance of getting NI R&D to change this behaviour (or at the very least provide a way to enable stronger checks)?

[jacobson]

Thanks for the reply. Having the write being optional makes this very problematic because even if I confirm that the datatype is correctly configured I may not be able to check whether the write really worked. If I can't guarantee my checks, it may be best to just not allow it and put some bookmarks in the code so people could change that behavior for their deployment. Still not 100% sure what I'll do but I have more to think about now.

9 hours ago, JKSH said:

This sounds like a recipe for hard-to-detect bugs... Is there any chance of getting NI R&D to change this behaviour (or at the very least provide a way to enable stronger checks)?

It's definitely bad and I filed a CAR but in the meantime I'll have to manually check this.

[smithd]

On 2/18/2017 at 4:57 PM, jacobson said:

1. Does OPC UA allow for clients to read a single element of an array item? LabVIEWs implementation does not (from what I could find) but from some google searches it seems like this is allowed.

2. If this is valid, is there a standard way of addressing a single element in an array? 

3. Does anyone know of a free OPC UA server or one that has a trial where you are able to address a single element in an array? If anyone has something like this set up (or tried this in the past) I would also be interested to know what data type the Get Node Attribute returns if the node path is referencing a single item in an array.

1/2. Just don't support that. I suppose someone could make a huge array, but if we're (I would assume) talking to something as powerful as or significantly less powerful than a cRIO, I wouldn't expect an array size greater than 1-2k elements, which is a grand total of 8-16 kB. Its a decent amount but not disturbing...plus this module is going to have run async anyway since UA is a req-resp protocol. Just pull the whole array and split it apart inside the module code. If you look at the modbus module it does something similar (at least I think we decided to group writes in that one, might be thinking of a different project).

3. I saw this a few weeks ago and thought "what an absurd thing who would ever need this"...it sounds like it might be a handy tool for you to test with
http://node-opcua.github.io/

and of course since its just a protocol you could also use the c# lib I pointed out in the other thread: https://github.com/OPCFoundation/UA-.NET/tree/master/Dashboard

Edited February 21, 2017 by smithd