OPC UA Demo Not Working cRIO-9064

[RVallieu]

I had a working OPC UA LV 2016 program - upgraded to 2017 - trying to get everything upgraded to match.

Ran into problems with Client on PC not being able to connect to Server on the 9064.

Went back to basics - ran the OPC UA Demo example from NI - same behavior, Client on PC can not access the Server.  

Can someone else with 2017 try the OPC UA Demo.lvproj Data Access Server and Data Access Client VIs with a cRIO?

When on the same machine they work fine (i.e. both run on PC).  Currently using None as the Security Protocol.

I have a SR open, just looking for other eyes and tries. 

[RVallieu]

The error w are recovering when using the wireless to connect is -356653 The Status of the OPC UA Server is uncertain.

We also tried a physical connection to the cRIO and the Error code was then -356612 A communication problem occurred. Ensure that the OPC UA Server that you specify in the Server Endpoint URL is running and the network between the OPC Server and the opc client is connectable.

After that we ran a 2016 created OPCUA Browser Client that I wrote as a tool and were able to connect to the Server and see the tag values and see them updating live. This worked wireless and wired.

We also downloaded the ProSys Client app and were able to connect to the 2017 cRIO server.

[Jacobson-ni]

I actually did run the demo a while ago for the 17.0.1 toolkit version on a 9035 and 9038 with the server VI running on the cRIO and client VI on my W7 computer and was able to get that to work. I can try to run it on a 906x target tomorrow but as a result of me running the example I filed CAR 654055 because the OPC UA Client Connect.vi would throw error -356610: The certificate is not trusted if you have none chosen as the security option and you don't use a certificate.

You're getting a different error but it might still be worthwhile adding certificates because I was seeing the exact same behavior of it working if client and server were running both on the cRIO or my Windows computer. If you haven't already, I would also update to 17.0.1 because it fixes a separate CAR which would case locally generated certificates for client (server) or server (client) to be invalid which could couple with the above CAR to cause all sorts of nonsense.

[RVallieu]

Hmm.

Well that would be the issue - we were trying to run with no certs and None set for Security.

Will we have to select an encryption level other than none to force it to use certs or are you saying that using Certs with None selected is still required?

I just downloaded and installed the toolkit and the installer did not indicate that there was any update when it checked.  I will verify the version information.

[Jacobson-ni]

---

@RVallieu wrote:

Well that would be the issue - we were trying to run with no certs and None set for Security.

---

So are you saying that it's working when you use a different security policy? I just want to make sure because I'll add that error to the CAR.

Will we have to select an encryption level other than none to force it to use certs or are you saying that using Certs with None selected is still required?

---

In the original escalation I wrote that "You are able to connect if you exchange certificates, even if the security policy is set to none.." although I don't remember testing if the server has no trusted certificates and the client was just given one or if the certificates of the server and client even had to match.

[RVallieu]

We did not try with certificates and leaving None set or picking another Security type.  That will be the next step.

[RVallieu]

Trying certifcates today.

File Access through Explorer does not allow loading the HMI Client cert to the var/local/opcua/certstore so I put it in the lvuser folder hierarchy.

[RVallieu]

-356653

The status of the OPC UA server is uncertain.

This is the error we get.  Server is up and running with no errors indicated.

For Client Connect - Username and Password - is that for the cRIO accounts in general?  I put in the admin account username and password thinking that might work since the Help seemed to indicate that this would be required.

[RVallieu]

Moved back to using the DEMO and added Certifcates and the same issue is occuring.

We Start the server with no issues listed.

Try to connect from the PC to the cRIO Server and get -356653 with all certs in place.

[RVallieu]

The error happens regardless of what Security mode we select.  None or Sign with Basic 

[dfousek]

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

[RVallieu]

Thank you very much for the extra data point!

[RVallieu · Accepted solution]

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.

[RVallieu]

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.

[RVallieu]

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.