LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to stop instances of a subvi from sharing data?

Solved!
Go to solution

My first experience with a subvi that I created myself has failed :smileysad: . The first instance works fine. But when I use a second instance of the subvi they interact with each other. They appear to be sharing data somehow.  That is, when I probe a wire inside one of the subvi instances I see values that should only be present in the other instance.

 

I created the subvi in literally "textbook" fashion. Everything falls into place just like the examples in "LabVIEW 8 Student Edition". 

 

The code works fine when not used in a subvi. That is, when I "cut-and-paste" the code multiple times it works correctly. But when I encapsulate  the code in a subvi I get interaction between instances. Has anyone else ever had this problem? What did you do about it?

 

thanks

0 Kudos
Message 1 of 14
(3,248 Views)
I'm not sure what you are trying to do with your subVI.  But it sounds like you want to set the VI to be re-entrant.  That causes each call of the subVI to be its own instance.
0 Kudos
Message 2 of 14
(3,238 Views)

Thanks Ravens Fan,

 

I'll investigate how to make a subVI "re-entrant" when I'm back at work tomorrow. But I'm confused. Are you saying that a subVI can only be used once in a program without special preparation?  Seems like my LabVIEW text book would have mentioned that.

 

Isn't a subVI like a C subroutine under the hood? In C you call a subroutine as many times as you want without interference between instances. Each instance has it's own memory to work with.  You have to use global variables if you want to share data between instances.  I gather LabVIEW doesn't work that way.

 

thanks 

0 Kudos
Message 3 of 14
(3,225 Views)

Hi Ravens Fan,

 

It's me again.

 

Thanks for providing the key word "re-entrant". I'm finding lots of info about it using google. Here's an example.

 

I'm anxious to give your suggestion a try. I've spent hours trying to find out what I was doing wrong in my seemingly very simple program.  I'm not using the subVI recursively or anything like that. But as surprising as it seems (to me at least) LabVIEW really doesn't allow a VI to be used more than once in the same program without special handling. 

 

Thanks again for providing that tip.

 

0 Kudos
Message 4 of 14
(3,219 Views)

There are a lot of things that make little sense. Is you entire observation based on "probing" or are you actually getting unexpected results? You can NOT probe a specific instance of a non-reentrant VI, because there is only one subVI.

 

Typically, the code of a VI can be re-used for multiple instances and there is nothing wrong with this, so the default of VIs being non-re-entrant is fine. You can use subVIs as many times as you want in a program and there is no "special handling" needed at all. There is no need to create N copies of the subVI in memory, that would be wasteful.

 

There are two cases where you want to make a VI re-entrant:

  1. The VI instances retain data (e.g. in uninitialized shift registers) AND you want each instance to retains only local data and not share it globally. (typically, one wants to share the data, e.g. in an action engine, so in this case the subVI cannot be reentrant, of course).
  2. The VI instances need to execute in parallel and at the same time (again, typically it is OK if the execute serially, especially if you only have a single CPU).

These cases are rare under normal use, so "reetrant" is NOT the default setting. Makes sense.

 

It seems to me that you have some basic misunderstanding. Could you attach your example VIs so we can be sure what you are actually talking about?

 

Message Edited by altenbach on 10-27-2008 12:39 AM
0 Kudos
Message 5 of 14
(3,203 Views)

altenbach wrote:

... You can NOT probe a specific instance of a non-reentrant VI, because there is only one subVI.

...


You CAN probe with specific instances of a non-reetrant sbu-VI, but you have to indicate which instance you are after.

 

If you single step the caller of a non-reentrant sub-VI and "step into" the sub-VI call, you will open the instance used by that caller. You can then probe away.

 

Another method woudl to set a break-point that is fired by AN istance of the sub-VI. The caller drop-down (what is normally the font drop-down) should show the call chain.

 

Original Q thread:

 

Yes sub-VI can act like functional calls, including those that use "Static Local"s that retain their value from call to call. In LV these are typically shift registers but also apply to controls and indicators that are NOT on the icon connector.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 14
(3,186 Views)

Setting the re-entrant execution properties on the main VI didn't make any difference. 

 

I've attached my program.  I've been staring at this for hours. I hope someone can see something I don't.

 

The first file is the working model. It doesn't contain the problem subVI.

 

The second file is the same program with the subVI included.

 

The third file is the sub VI itself.

 

The problem is that when either of the two boolean switches ("latch until released") are held down the same value appears in both of the "zero load" display boxes. A value should only appear in one. This behavior doesn't appear when subVI's are not used.

 

The wire feeding data to the two subVI's is "Scaled Data". Context help says its a 1-D array of doubles.

 

Thanks for taking the time to look.

 

 

0 Kudos
Message 7 of 14
(3,175 Views)
Solution
Accepted by topic author km4hr

You have several problems.

 

1.  Your main VI that calls a subVI calls USC_SG_subVI, but you posted USC_strain_subvi.

2.  USC_strain-subvi, is NOT set up for reentrant execution.  Look at File/VI properties then Execution.

3.  You are using a feedback node within the subVI.  (Which is another variation of an uninitialized shift registers).  I would recommend keeping the feedback out of the subVI and make it a part of the master while loop in you main VI.

Message Edited by Ravens Fan on 10-27-2008 11:15 AM
Message 8 of 14
(3,168 Views)

You have uninitialized feedback nodes in your program.  You move those to the subVI.  I don't have the DAQ subVIs or any hardware so I cannot run it, but I think the feedback nodes may be your problem.  They retain the data from the previous run.

 

The "Zero Load mV 2" indicator is connected to the "fed back" signal and will be one iteration of the loop or one call of the subVI late.  I converted your working program to use shift registers rather than feedback nodes and it makes the data linkage more clear(at least to me).  Cleaning up the wiring  (right to left) also helps to see what is going on.

 

Watch the program run with execution highlighting on.

 

Lynn 

0 Kudos
Message 9 of 14
(3,163 Views)

Ravens,

 

Sorry I posted the wrong subVI file. But the one I posted has the same content as the correct one I believe. For the sake of completeness I'm attaching the correct file also.

 

Looks like your diagnosis is the same as johnsold. The feedback node must be the problem. Unfortunately no documentation I've seen warns that some "nodes" are off limits for use in subVI's. Proves again that there's no substitute for experience and detailed understanding.

 

I'll have to do some more studying about un-initialized data (?).

 

Thanks again for all you help. Without people like you and johnsold I'd never learn LabVIEW!

 

 

0 Kudos
Message 10 of 14
(3,145 Views)