Yes, have a look at this example: opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...%20of%20a%20single%20node.html . You need to read the DataType attribute of the node.

The returned UA type is represented by a Node ID. This is where it gets a bit complex.It can be one of the types defined in the standard, in which case you can test it against constants that can be found in UADataTypeIds class, such as UADataTypeIds.Int16. Less frequently, it can refer to a node describing a type derived from some of the standard, or a custom (complex) data type. Fully describing how these more complicated cases work isn't realistic or even reasonable to make here - for that, I refer you to the OPC UA specs.

Best regards

I am glad that it works. You may want to consider reporting it to Red Lion (with reference to analysis in this thread), because the server's behavior is not conformant with OPC UA spec in this respect.

The node you want to browse is in the second argument, where you now have the UAObjectIds.Server .
- If you want to browse from some other predefined node, simply change it to that node's name.
- If it's not a predefined node but you somehow know the NodeID, you can construct UANodeId (or UABrowsePath or UANodeDescriptor) object and use it as that 2nd argument.
- Or, if you want to browse recursively, results from one Browse can be used as inputs to subsequent Browse.

Best regards

Thank you. I have found following main differences between what QuickOPC calls and what the other client calls:

1) QuickOPC browses for References and subtypes (as specified in your code), the other client browses for HierarchicalReferences and subtypes.
This probably isn't causing the problem and we will leave it for later.

2) QuickOPC uses zero for requestedMaxReferencesPerNode parameter, the other client uses 16384. According to the UA spec, "The value 0 indicates that the Client is imposing no limitation".
We are doing it right, but I can imagine a bug in the client in which they might have forgotten to include code for "zero" case. I will therefore propose to test out a modified setting on our side - see further below.

3) QuickOPC explicitly lists all wanted node class in the nodeClassMask, the other client uses 0. According to the UA spec, "If set to zero, then all NodeClasses are returned.".
In my view both clients are doing it right, but at least in theory there might be a bug in the server in which causes it to have problem with our value.

Because changing the QuickOPC behavior for case (2) is the easiest, can you please add the following line to your code, before any actual OPC operation is called?(assuming they you are not setting the Isolated property of EasyUAClient to 'true').

... and then repeat the test, to see if you now get some nodes from the browse?

Thank you

Thank you for the Wireshark traces. I am, however, puzzled by what I see in them. In your report, you wrote that your browse call looks like this:
In the Wireshark trace, however, I see something completely different. I see two browse operations at once,
- first on node BaseObjectType, for reference type Organizes and subtypes, and NodeClass = Object,
- second on node ObjectsFolder, for reference type HasComponent and subtypes, and NodeClass = Object

It looks like that you are running something different from what was in the original report? If so, can you change it back and make Wireshark trace with it?

Regards

Hello.

Doing a TeamViewer wouldn't normally be of much value, as I need to debug the communication using tools that I have on my development machine only. I therefore suggest to collect the Wireshark traces. Please have a look at this: kb.opclabs.com/Collecting_information_for_troubleshooting , and the two external links in that article that relate to Wireshark (under "Learning material"). You can, at least for now, ignore the instructions about extended tracing, instrumenting using the LogEntry event, etc. We can start with simply two Wireshark, one with QuickOPC, and one with the tool that works.

Best regards