Hi Jim,

Searching a node id with the specified string ”Leitsystem”.”IST”.”TEYH_UB_0001-EFB” should work fine. There’s no problematic special characters in this string.

You don’t also need to do any escaping. It should enough just to input the string directly with the non-escaped quotation marks.

So, there’s either a bug in the client or some other issue which prevents the node from being found. Based on this information alone, I’d say there’s a chance that the node id indeed is not available in the server even though it should be.

Could you double check that the node id indeed exists and the node id was copied without error to the search dialog?

If the issue persists, please send us a screenshot showing the node id in the Attributes and References view, the input to the Search for NodeId dialog and the resulting error message. Also, please mention what is the version of the Prosys OPC UA Client that you’re using. These files cannot be attached here on the forum, so you’ll need to send them by email to us at uajava-support prosysopc.com.

As for the “reg exp or wildcards” question: this would be a very nice feature, but I’m afraid it’s not in our roadmap currently. Furthermore, this would be a big technical change. Nowadays, the search functionality can directly read the attributes and browse for references when the node id has been supplied. To provide this kind of advanced search, the client should in practice browse through the whole OPC UA server address space. If the address space is large, then this can add considerable overhead.

Hi Jim,

Yes, screenshots cannot be attached here on the forum. You’ll need to send them by email to us at uajava-support prosysopc.com as instructed in the previous post. Let me know if there’s a problem to send these by email.

Hello,

Thank you for the screenshots, they arrived successfully.

In this case, the issue is that there’s no inverse references available from the searched node. One of the main points of the current search functionality of Prosys OPC UA Client is that users can find out the browse path to the specified node. With the current implementation, this is not possible if there’s no inverse references to follow from the node.

The most obvious and easily fixable issue is that the error message should be clearer. Now the error message states “The node id refers to a node that does not exist in the server address space”. But the node does exist, the issue is that it doesn’t have the needed references. We’ll mark this into our issue tracker and fix the error message in a coming release.

On a longer timeline, the logic could also be reworked to make the search work without inverse references. But the rework would probably require a large amount of work and this is not in the immediate roadmap. And if this feature is reworked, it could similarly add more intelligent filtering such as regular expressions and wildcards such as proposed in your original forum post.