Showing results for 
Search instead for 
Did you mean: 

Reset front panel boolean control if new value is rejected by the program



In my setup I have a number of valves connected to multiple NI 9217 modules (24V on/off output), but there is not enough power supply to power all the valves simultaneously (not that i would ever need to) and a power overdraw will damage the power supplies. I have set up a check to ensure the number of active valves never exceeded "X" (a queue with "X" elements available) and if a valve attempts to turn on and there is not an element available in the queue, a warning is generated and displayed to the user.


What I would like to happen is that if a valve 'activation' is rejected, the front panel control for that valve (a boolean) is reset back to the default  value. I currently have this implemented in sub vi's by sending through a reference to the control and using the value property to over-write the control with the default value. However I am in the process of shifting a lot of the control code onto a cRIO and am unable to send a control reference through a shared variable to a vi running on the cRIO.


So what would be the best way to implement this? One way would be to use global variables to send through the reference, but is there a better way?

0 Kudos
Message 1 of 6

So where is the value you are trying to adjust now located?  On a Windows GUI that is connected to your cRIO?  On the cRIO itself?  Where are the commands to turn on an output originating?

There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 6

If you're using the main GUI to enqueue the valves to turn on, you could handle the number of valve buttons allowed to be set like this:




The hidden case contains:



The other Event structure event is Panel Close?

You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

0 Kudos
Message 3 of 6

The target value is a shared variable located on the cRIO. The command comes from the GUI on the computer (when in manual mode) or from a configuration file (when in automatic mode). I would like to shift all of the underlying code onto the cRIO so when it is in automatic mode, it could run without any connection to the computer. Currently the code is all contained within sub-vi's in the main GUI, and backwards comunication (sub-vi's controlling the main vi) is handled by control references and property nodes, but this wont work through shared variables.


I guess to put the question simple, is there an easy way to have two way comunication between two separate vi's (that can be running at different rates), in reference to a single variable. One way that i have just through of is to use the shared variable timestamp. The main vi can store the time it wrote to the shared variable, and then read the shared variable a until more recent value is read. The second vi will read the shared variable and then write the output value back into the shared variable for the main vi to read (as it has a later timestamp). But this approach will probably have issues with timing.

0 Kudos
Message 4 of 6

Is your problem you're having trouble using a shared variable in communication between your GUI and CRIO? If that's the case it seems that that issue would be cleared up when you move all of your code onto the CRIO. Have you tried using a global variable already?  What is the issue with using your queues to send information?


Collin D.
Software Product Manager
0 Kudos
Message 5 of 6



I would be very careful about developing an application that utilizes property nodes that reference a front panel on your Real-Time target. You may already know that, I just want to be sure to save you any trouble in the future. Property nodes that reference front panel controls or indicators are simply not supported on real-time because front panels are stripped in Real-Time executables.


As for the variable communication question, is there a reason that you can't  just use two single process shared variables? Furthermore you could use the variable timeout output to avoid reading stale data when one VI has stopped writing to it's variable. Some more information on avoiding stale variable data can be found here:



Rob B
FlexRIO Product Manager
0 Kudos
Message 6 of 6