Network Shared Variable Breaks rtexe

[SteveMRG]

I've got an cRIO-9063 which I'd like to use for control (PWM digital output signals for pumps) and measurement (temperature and voltage) of a system. In the ideal setup, the cRIO would be able to take measurements and broadcast them to a PC for monitoring and logging. The PC must also be able to change the PWM output digital lines on the cRIO. The cRIO should be able to continue running when the PC is unavailable. To accomplish this, I use Scan interface for DAQ and network shared variables (single writer, no RT FIFO) hosted on the cRIO for communication.

I was able to develop code for the cRIO target as well as for my host PC which meet meet my criteria. However, this code only works in development mode. When I try to build and deploy an rtexe to the cRIO, it doesn't work. I stepped back and made a simple User LED blinking vi, ensuring that I was building and deploying correctly. Slowly adding things to this blinking vi, I discovered that it's the network shared variables which break the vi once it's built into an rtexe. 

After thumbing through other related posts, I'll clarify the following:

- There are no front panel objects on the remote VI. Simply adding a shared variable node is enough to break the vi (when deployed).

- I tried including my shared variable library in the support directory of the build, but from what I seen it doesn't get copied over during building or deployment. I've manually copied the library to the /home/lvuser/natinst/bin/data/ directory on the cRIO, then used an invoke node to deploy the variables from the cRIO when the software first starts up. Even when including a 10 second delay after the invoke node, this has not worked, returning an error of 1043 "The property or method is not supported in this version of LabVIEW."

- NSVs are referenced as Absolute

Some details of my setup:

LabVIEW 2015

cRIO 15.0

NI-RIO 15.0

Communicating via ethernet, static IP

Any help would be GREATLY appreciated. I suspect I'm overlooking some minor step or detail, or else am misunderstanding exactly how and when network shared variables are deployed.

[RVallieu · Accepted solution]

I have found network shared variables to not be worth the trouble over the years.

The RT EXE is not able to use the Deploy Library to deploy the Shared Variables.  See help topic:  http://zone.ni.com/reference/en-XX/help/371361M-01/lvprop/app_libdeploy_library/

Typically SV are deployed once through the project and they persist through reboots of the RT system.  Generally you should have a start-up routine that checks the shared variables and waits for there to be no error out on a SV node and then move on to the rest of the program, setting start-up values and checking that they propagate through the Variable Engine is a typical method.

See the topic here for further information on deploying shared variable in an RT application.  http://digital.ni.com/public.nsf/allkb/990508969805A7C086257619007189E7

The heading Deploying Shared Variables to a Real-Time (RT) Target Running Headlessly is at the bottom.  Since you are connected to an HMI PC you should be able to use the deploy library function on the PC code targeting the cRIO.

Usually it is faster and more scalable solution to replace your Network Shared Variables with a dedicated Network Stream to the HMI and another for HMI-RT EXE commands.  You can send complex structures like a cluster or even define the message type as a cluster of enum and variant to be able to use the Enum to convert the Variant properly based on the Enum Value.

[SteveMRG]

Thanks for the tips, RV.

I had tried the method described in your second link for including the SV library with the Application Builder, but for some reason the library was never actually transferred to the RT target during building or deployment of the application. I checked the file system and didn't see anything. I manually transferred the library to the intended destination and still had the same issue with the executable not working.

I think I'm going to take your advice and stick with Network Streams 🙂

[MarkCG]

I had this problem of a broken RTEXE  when using user-defined IO variables in absolute reference mode inside classes. I changed all my shared variable reference in the program to relative reference and the problem stopped. I sent my code to NI which confirmed the behavior and there is now a CAR out on this, not sure if I can share the CAR number though.

[SteveMRG]

I decided to use network streams, and after some minor software re-archtecting, everything seems to be working. One noticeable hiccup that might be worth sharing: I was able to get network streams working on my development PC (both as a VI, and as a built exe), but couldn't get communication working on another PC. It turned out that Windows Firewall was enabled for the network adapter I was using to communicate with the RT target. This took me a few hours to figure out, so I'm posting here in hopes of saving somebody else the trouble.

Thanks for your help, everybody.