Inconsistent LabVIEW Real Time Behavior With Control Property Nodes

[billtrib]

LabVIEW 2014 no service pack

cRIO 9068 (Linux) with dual processor

I wrote a vi that interacts with the CVT to pass values between the CVT and a pile of front panel controls that are accessed by reference. My project supports a front panel, if one is connected then you can use this panel to interact with the system. All the controls are located in a tabbed pane on the main vi running on the RT module, all functionality is contained in a sub-vi that accepts as input an array of control references.

It works perfectly in developer mode. Then when I deployed the controls were completely isolated: nothing was loaded and initialized from the CVT, changing control values had no impact on the system.

For debugging I had provided a string array of all the control labels so I could see what controls got picked up by the panel. So, I figured that the first step in troubleshooting would be to see if the RT standalone execution populated any of the controls. After building and running this, everything lights up and works perfectly.

It appears that in order to enable front panel communication with a RT sub-vi some control connected to that VI must appear on the front panel. If this is not the case, the sub-vi will not interact with the controls at all.

In my opinion this is a bug. Comments or clarifications, anyone?

[natasftw]

While the 9068 runs on the Linux RT OS, it doesn't have an embedded UI.  That's exclusive to the cRIO-903x series.  When you're running on the RT, you don't actually have a front panel.  As a result, you're going to see some strange behavior if you're working with Front Panel controls.  I would expect this is a big part of what you're running into.

[crossrulz]

I didn't think the cRIO-9068 supported having front panels in deployed code.  I think you have to have a 903X series cRIO for that.

[billtrib · Accepted solution]

Thanks for all of your answers. For the record, while the 9068 has no embedded panel it supports remote front panels. I am using that feature successfully. The core of the code runs headless, I just didn't want the hassle of setting up a fully independent panel on an external PC.

My initial analysis and statement of the problem was incorrect. I thought I was running in RT with the panel working, but was actually running from the developer. Even with controls and indicators brought out from the sub-vi the panel was still catatonic.

Then I re-read the NI documentation on front panels. They clearly state that if a RT application IS CONNECTED to a front panel then property nodes etc. will work. If it is not, the program will still run but indicate errors for property node operations. Typically error management is not done for information-only panel stuff, so I did not see the error.

It turns out I was collecting the set of controls at the beginning of execution. In development mode the front panel is always there, so it worked. However, when the RT target boots and starts it is impossible to have a remote front panel connected, so my set of controls was empty.

Moving the control set initialization code (just get an array of references to all controls in the pane of interest) into the area of the code that is executed after the mouse click that activates the panel did the trick. If there is no remote front panel then no one can click on it, but if there is a front panel then all the controls are there.

Thanks again for ruminating with me.

Bill