It's also regardless of cRIO-9064.
It's happening also between 2 PCs running Labview2017 and OPC-UA, while it's working ok with Labview 2015 and DSC.
(No security levels used; just experimenting with OPC communications and demo versions.)
OK - NI worked with us to figure out what the issue was - and how to fix it on the systems in question. We were directly connecting to the cRIO from the PC through a switch - thus there was no DNS Server involved. We even tried direct connection to the cRIO (but this does not involve a DNS server). That is the source of the issue - with no DNS Server involved there was a problem with the Windows OPC UA Client connecting with the cRIO OPC UA Server.
The cRIO hosts file located under root/etc/hosts was modified to include
The Windows machine hosts file also needed to have the same line added to it before the OPC UA Client could connect. it is typically located in C:\Windows\System32\drivers\etc
XX.XX.XX.XX is the IP address we assigned in MAX. cRIO-Name is the alias assigned in MAX. Usually it is auto generated to be something like NI-cRIO-9064-NNNNNNNN where NNNNNNNN is the Serial Number of the device.
Just an update - the code in our project built around the OPC UA Toolkit connected perfectly fine after this fix. So other code than the DEMO from NI has been verified to work in 2017 with this workaround.
I will say that allowing the Client to use Node ID without the NameSpace identifier is just a bad idea. I understand you wanted that for "backwards" compatibility, but you ruined that already with any reads from the OPC UA client VIs that return Node ID, as they now include "ns=#,s=<Tag>" - this also is what is returned when you register for Value Change Detection Events and the Event information returns Node ID. Also all the Write subVIs for individual were replaced with the Array version - another rework required, much more invasive than the Node ID change.
I think it would be better to force the developer to get the ns information from the Server upon connection and cache it for later use in building Node IDs to compare/send to the OPC UA VIs - as more than one client can be connected on the same system to a different Server and use the same Tag schema.
Thinking about it - I suppose since we open the Client Reference individually and store them, the reference wire would contain the information of which NS connection is in the Reference.