From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

OPC UA Demo Not Working cRIO-9064

Solved!
Go to solution

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.)

Dimitri

Message 11 of 15
(1,601 Views)

Thank you very much for the extra data point!

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 12 of 15
(1,591 Views)
Solution
Accepted by topic author RVallieu

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

XX.XX.XX.XX     cRIO-Name

 

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.

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
Message 13 of 15
(1,582 Views)

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.

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 14 of 15
(1,567 Views)

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.

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 15 of 15
(1,551 Views)