LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Does a subVI retain output (indicator) values between multiple calls?

Solved!
Go to solution

Hello,

 

This is probably a silly question. But in the back of my mind, I had always assumed this, but I would like confirmation:

 

A subVI will always retain output/indicator values in memory after each call, until LabVIEW is closed.

 

Is this correct?

 

So if I had called the subVI once inside VI #1, and then I called it again inside VI #2, the output/indicator values from the VI #1 call are still available to be used when called inside VI #2. 

 

There doesn't seem to be any documentation about this, unless it's deeply embedded somewhere and I haven't found it.

 

Thanks!

0 Kudos
Message 1 of 16
(3,700 Views)

The indicator is an output, so it's returned value typically depends on calculations based on the subVI inputs.

Indicators update whenever they receive new data.

 

Can you be a bit more specific about your application of this, maybe attach a simple example.

 

(Also note that there is a "Clear indicators when called" VI option).

Message 2 of 16
(3,686 Views)

The basic answer to your question is that you don't quite understand the Principle of Data Flow.  Let's call the sub-VI "SubVI", and let's call its output "Out1".  VI1 calls it, and connects a wire to Out1.  When SubVI runs, it puts some value on Out1 (or maybe doesn't put any value on the Indicator, so the Default Value is returned).  Until SubVI returns, there is essentially no value on the Wire.

 

Now VI2 calls it, connecting another wire to Out1.  Before SubVI runs, there is no value on the wire.  When SubVI runs and exits, whatever value that SubVI puts on Out1 will be available to VI2.  

 

So to ask if a subVI "retains" its indicator value between calls makes no sense -- when the subVI is called, whatever value is on the Indicator when it exits is passed to whatever is wired to it.  If it is called again, it will run again and do whatever it has been programmed to do, and will again place a value on Out1.  Depending on what subVI does, the value may be the same (for example, if a constant is wired to the indicator), but the general expectation is each call returns its own value.

 

I hope I understood your question correctly ...

 

Bob Schor

0 Kudos
Message 3 of 16
(3,668 Views)

I'm thinking of it this way Bob, and perhaps I should try a sample VI.  But if a value gets put into the indicator on the first call, does the value persist that you could read its value in the subVI using a property node or local variable early in the subVI before you write to that terminal again.  My guess is yes.  But I don't see any advantage to it as I would just use an uninitialized shift register or feedback node for any values I want to retain between subVI calls.

Message 4 of 16
(3,666 Views)

@RavensFan -- well, it is entirely possible that some of the talented readers of this Forum can figure out how to sneak a value out of a subVI (I, myself, would try Channel Wires, but I'll wager a dime that I'm right, and am even more sure that I'm "in principle" right).

 

Bob Schor

0 Kudos
Message 5 of 16
(3,663 Views)

@Bob_Schor wrote:

I hope I understood your question correctly ...

 

Bob Schor


 

It is possible that the indicator terminal is in a case structure case that is not always active, it might not always get new data with each call. Probably need to do some tests.

0 Kudos
Message 6 of 16
(3,659 Views)

Here is the proof that the indicators remain the previous value from the last call.

This doesn't get into the subject of indicators that are in case structures.

 

LV17

Download All
0 Kudos
Message 7 of 16
(3,642 Views)

Nice shooting y'all.   Plenty of ways to get a race condition with stale data on indicators.   

Unfortunately,  there really is no reason to write code that has no output!  (If you have an awesome example,  I'll bet a dime that its bug free)

 

Clearing indicators or using a clone instance can avoid some problems.   We need to see code to find out what race conditions you are getting into  


"Should be" isn't "Is" -Jay
0 Kudos
Message 8 of 16
(3,635 Views)

Oy veh!  I've learned the lessons about the problems of Local Variables that I overlooked this "mis-use" of them!  [Is that a Good Thing or a Bad Thing?  Needless to say, when I see local variables, I immediately look for ways to eliminate them ...].

 

Bob "Always Learning" Schor

0 Kudos
Message 9 of 16
(3,629 Views)

@altenbach wrote:

@Bob_Schor wrote:

I hope I understood your question correctly ...

 

Bob Schor


 

It is possible that the indicator terminal is in a case structure case that is not always active, it might not always get new data with each call. Probably need to do some tests.


(OK, test was done and confirmed my suspicion. Last post was via phone, so I could not test but vaguely remembered some things)

 

So: The value is not retained if the indicator gets stale data AND is connected on the connector pane.

(OTOH, If the indicator is not connected on the connector pane, the subVI panel (when open) shows the last written value, 20 in this case).

 

RetentionTest.png

 

 

Ravens example is just a plain race condition, because the terminal actually gets written on both calls.

0 Kudos
Message 10 of 16
(3,621 Views)