Actually, looking now at the relation between the OPC-DA item ID and its corresponding OPC UA node Id in your particular server, I can see that what they have done is that they have taken the item ID in OPC DA (which is always a string), and represented it as a string-type OPC UA node ID in a custom namespace, preserving the actual string value.

So, this is probably the most straightforward way of doing it, quite easy and logical. Nothing to be surprised by or complain about. They have preserved the identifier value, and added a namespace - which is necessary, because there always is *some* namespace in OPC UA node Id.

Best regards

I forgot to address the other two points:

Ad 1. Not sure why the double click is not enabled. Will raise with the developer of this part.
Ad 2. No we don't have filters here yet.

Best regards

As to the difference between OPC DA and OPC UA item/node IDs, you need to direct that question to the server vendor. But in principle, they are absolutely free to do them any way they like, so there is nothing to complain about. Nowhere in the OPC specs there is a prescribed mapping between OPC DA item IDs and OPC UA node IDs.

Regarding the difference between UaExpert and QuickOPC: What matters is the actual node ID, and not how it is represented as a string. In this sense, UaExpert has chosen a format different from QuickOPC, but they both represent the same node. The node Id consists of the namespace, and the identifier (which can be one of 4 types). In both cases, you are told that :

- The namespace index is 2. This is the "NS2" part in UaExpert, and "ns=2" in QuickOPC.
- The identifier is string type. This is the '"[string]" in UaExpert, and "s=" in QuickOPC
- The identifier (string) is "11/Server 1/DateTime.Value" - in both cases.
- In addition, QuickOPC tell you the namespace URI (the "nsu=" part). This is important for persistance of node IDs, because the namespace index may change between sessions - but the URI will remain the same. UaExpert does not have to persist the node IDs so they don't care, but we have to...

Our format is the one used in the OPC UA specifications. In fact, at other places in UaExpert, you will see it used as well (except for the URI part) - see the image below. I am not sure why they use two formats, it is probably for historical reasons.




More reading:
- opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...tml#OPC%20UA%20Node%20IDs.html
- opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...indices%20in%20Node%20Ids.html


Best regards

Regarding the original issue (about the Signal nodes) - which may be no issue at all, because you might have chosen the Signal nodes by accident, and you true issue was with selecting *any* leaf nodes:

I have received somewhat unhelpful answer to the effect that the proper browse filter is "a decision for client developers and their customers." - while, at the same time, a wider default filter, and "toggle" switch to show more than the default, were recommended.

So I am taking that into account and it may get done in a future version.

As to the issue you are still fighting, I have provided a reply as well, and I believe that once you understand that the left side for branches and only the right side is for leaf selection, you will hopefully get it working.

Best regards

Please read my previous post carefully. You have not done what I have told you.

Best regards

This is a different issue.

Referring to your picture labeled "OPC UA client": In the tree view on the left hand side, select the "Server ..." node. You shoudl then see the nodes on the right side (in the list view), and when you select one of them, the node information pane should be filled in.

It's only the right-hand side (list view) that's for the actual "leaf" selection. It's the same as in the OPC DA dialog.

The reason why the nodes also appear in the tree (left side) is because in some circumstances they may act as "branches" too (and have leaves below them).

Best regards

This works as designed.

The QuickOPC UA browsing dialogs and controls are for browsing "data nodes" - that is, they are specialized for the purpose of displaying the view of the server's address space that is limited to hierarchy of nodes that are meant for generic data reads/writes/subscriptions. The UaExpert, on the contrary, shows everything that is in the address space/information model of the server. Your expectations might be skewed by the fact that if you encounter UaExpert first, and it shows more, it appears "better". But UaExpert is not a real application for production usage. UA client applications are normally specialized to some extent. UaExpert isn't. If, for example, you wanted to write an application that is an OPC UA client for Alarms&Conditions and needed to subscribe to alarm nodes, the subset of nodes you want to view would be different again. And so on.

When browsing for nodes, the QuickOPC UA browsing dialogs and controls, with some simplification, differ from the "show everything" approach in following aspects:
1. The browsing starts in the Objects folder, and not in the Root.
2. The only node classes displayed are Objects and Variables (Variables may include UA properties).
3. The reference types followed are only: a) "Organizes" and its subtypes, and b) "HasComponent" and its subtypes, c) HasProperty and its subtypes (optionally).

The first two aspects are obvious and I am totally confident that they are correct.
The third aspect is the one that causes the difference here. In the ProSys simulation server, taking one node as an example, the "Signal" node (that you are missing in QuickOPC) is related to the "Counter" node by a custom HasSignal reference:



But, the HasSignal reference type is a subtype of neither Organizes nor HasComponent nor HasProperty:



Basically, the server vendor has created a "custom link" in the address space, which is however not meant to be seen by clients that are doing things like HMI, logging etc. If they wanted that to be seen as such, they could have made it a subtype of HasComponent, for example.

I tried to locate an authoritative answer to this in UA specs, but could not - the information is spread among multiple parts, and is more or less implied. Although I think I am correct in what I have just explained, I will ask my friends in OPC UA working group (over the public forum first) what is their opinion on this, to get "approval" - or (unlikely...) a correction of my opinion. I will post a reply here when I know more.

In addition, I have made a note for possible future improvement in which the user might be at least given an option to turn off the "filter" - even if it was not fully correct, it could be deemed useful.

Note that in the API on EasyUAClient (BrowseXXXX methods), you *can* specify filters so that you retrieve any nodes you want - even all of them. But this functionality is not currently in the UI browsing dialogs and controls.

Best regards