functional global variable

[gnappo]

I would like to ask to the experts a question about functional global variables. 

In the labview basics 2 course was said that a functional global variable is not reentrant. 

My purpose is to implement a code in such a way.2 main vi's. The first vi deals with some hardware that writes data in an output file with 1 Hz rate (more or less 1Hz, I cannot decide it).

The second vi deals with a different hardware (thermocouples). This works at a different rate (I cannot match exactly the different rates). I would like to write the data from the second hardware in the same output file of the first vi. 

I am thinking to use a functional global variable to pass the information from the second vi to the first vi. In this way I am using the data from the thermocouples at a rate given by the first vi. But at the same time in the global variable the data are written at a rate given by the second vi.

My question is: what exactly happens if the subvi (functional global variable) is called exactly at the same time? As you can understand it's not really important if I read the temperature with an error of 1 second, but I would not like the execution would stop or something like that. 

A functional global variable is a subVI that is not reentrant. This means that when

the subVI is called from multiple locations, the same copy of the subVI is used.

Therefore, only one call to the subVI can occur at a time.functional global variable is a subVI that is not reentrant. This means that whenthe subVI is called from multiple locations, the same copy of the subVI is used.Therefore, only one call to the subVI can occur at a time.

[tbob]

I believe that if the functional global was called by both vi's at the same time, one vi would win the contention and have access to the functional global.  During the time the functional global is running its code, the second vi is on hold.  As soon as the functional global completed its code, the second vi calls the functional global.

But now another problem.  This is a race condition.  What about the data.  Is that data valid if one vi calls the functional global before the other?

[RavensFan]

Only one copy of the subVI can execute at a time.  The second copy will have to wait until the first instance has finished running.  So, yes, the code will wait.

However this should not be a problem in any normal circumstance.  The execution of a functional global variable subVI should appear to be nearly instantaneous.  When you call it, it's while loop will only execute once and either Set the value you put in, into the uninitialized shift register of the variable, or Get the value out of the USR and send it out of the subVI through the indicator and the connector panel.  Either operation should take a very short period of time and would not hold up the execution of other copy of the FGV for more than a couple clock cycles.

Now, the question is the relative execution rates of the two while loops that has each instance of the FGV.  If the reading loop runs twice to every iteration of the while loop, you will get two identical readings.  Is that a problem?  Or if the Write loop runs twice before the while loop reads, you will miss one of the pieces of data.  Is that a problem?  If neither situation is a problem, a FGV should work just fine for you.  If you are worried about duplicated or missing data, then you should really be using a queue to pass data from one loop to the other.

[JÞB]

Well said RF!

And why pass the data between the two data collection vi's at all.  A named queue could be used by both in a multiple producer type of use case and the file writing (consumer) should be able to write any data to the file regardless of where it originated without any missing or duplicated data.

The Queue Message logging.vi example is a great starting point to see this type of architecture

[gnappo]

Thanks to all of you. All your answers were very useful to me. I am evaluating now if to make use of the queues. 

[Yamaeda]

Is there any specific reason for writing to the same file? If the loops don't sync you'll get 2 rows of 1, 1 row of the other every so often. It shouldn't really be a problem, but why not simply write 2 files?

/Y

[JÞB]

---

@gnappo wrote:

Thanks to all of you. All your answers were very useful to me. I am evaluating now if to make use of the queues. 

---

---

@gnappo wrote:

Thanks to all of you. All your answers were very useful to me. I am evaluating now if to make use of the queues. 

---

Excelant!

Glad to help (kudos are nice and RF at least desirves one--- we really do this for fun (and a few other rewards from thnking through other peoples thought processes) , we appreciate yor "thank you's but, Kudos are tracable

[Ben]

A couple of quick comments to add to this thread.

FG's can be involved in Race Conditions if two callers attempt to direct set the same value. An Action Engine (well what do you expect?) can be coded to help with those situations.

Example:

In arecent app I needed to set the heaters to "0" if an over-pressure condition was detected. The Heater set points where driven by a PID. The safety conditions where controlled by a process monitoring the input values.

So how do I keep the PID from setting the heater when the rig is not safe?

A Safety AE !

Actions used by the pressure monitoring set the Safety AE in an "go-safe" state where setting the heaters results in a null op.

This particular pattern (two writters) screams for an AE to coordinate the vaious actions. Do this same thing with queues could get tricky.

So for the Q in this thread we have a pattern of "two source of info, one sink for each" that screams for a queue.

BTW:

The AE Nugget linked above addresses what happens when two callers attempt to call the same non-re-entrant sub-VI.

Have fun,

Ben

[DFGray]

If using the same file, I would recommend using a file type which supports channel based data storage.  Examples are TDMS or HDF5.  Use a queue to pass data.  The data type should be the channel name and the data.  One write loop writes data to the correct channels as it becomes available.  No extra synchronization needed.