Showing results for 
Search instead for 
Did you mean: 

Reentrant top level vi

I have a fairly large top level application vi which contains a number of non-reentrant Functional Globals.  It is a cRIO RT application.  The product which this LV application supports is modular.  That is, the end product is being expanded by integrating a duplicate set of the hardware.  From a software control standpoint, the same LV application could be used to support the expansion.  Thus, on the cRIO a second instance of the top level application vi running from a parallel loop would do the job.  However, because of the non-reentrant Function Globals this will not work because state needs to be maintained.  I see two options for a solution:

1) Duplicate the top level vi hierarchy with unique file names for all functional global vi's.  This would be very inefficient.

2) Change the functional global vi's to re-entrant, pre-allocated.  This may be the best, but has it's issues because the application calls these vi's in different places.


Any other suggestions to manage a modular architecture like this?

0 Kudos
Message 1 of 16

Hi meg57,

You could make a functional global reentrant, open it once with VI server at startup, and pass the VI reference to every location where the functional-global is used - replacing the non-reentrant VI instance with a call-by-reference.



0 Kudos
Message 2 of 16
I cant remember the details exactly but i think if you make the reentrant vi a vi template (vit) and launch it, each will get its own functional global instance. Give it a try and see if im remembering correctly. You could do it quickly with a simple top level VI and a functional global that just increments a number at different rates.
0 Kudos
Message 3 of 16

Global resources are global to an application instance. There's nothing you can do to change that. Assuming you don't want to do what 550nm (should we just call you Green?) suggested, because that would require you to do this for every single global FGV call that you have, you will have to create separate application instances.


The easiest way to do this is to simply launch a second copy of the executable (either by actually copying it or by adding the AllowMultipleInstance=True line to the INI file), but I don't know if RT allows that or how it will behave in such a case. Likewise, you could try creating a second project (basically just a copy of the first) and launching the app through there. Again, I don't know how the RT target will behave.


The third option would be to get another cRIO, but I'm assuming that's something you would prefer not to do.

Try to take over the world!
Message 4 of 16

Unless I'm misunderstanding, I think this thread on LAVA shows the contrary (althought I haven't tested it yet). I was a bit off base, it's the functional global you need to make a template. 


Edit: testing now and it doesn't seem to be working as expected, but I could have sworn I did use this method in the past and got it to work.



0 Kudos
Message 5 of 16

Here, I got it to work.


You make your functional global a non-reentrant template and you make your top level vit a reentrant vi template. Then when you launch the top level vit dynamically you will get two independent instances of the functional global. I used VI server methods but you could most likely use start async call if you are using LabVIEW 2012.


Run the and you will see that each launched template VI increments its counter independent of the counter in the other vit.

Message 6 of 16

I don't know about the OP, but the VIT solution will be very helpful to me.

Nice solution Greg! 



It's my favorite color! Smiley Wink

0 Kudos
Message 7 of 16

One thing to note about the VIT solution - it looks like it works fine if you have multiple copies of the VIT in the same VI, but you will need to check how this behaves when you call the template in subVIs, particularly if those subVIs are non-reentrant. Also, the rules on RT might be different. I would suggest looking for some documentation on this behavior, as it's certainly non-obvious.

Try to take over the world!
0 Kudos
Message 8 of 16

Watch me surprise a few of the regulars.


In this case a FGV is not the best data storage mechanism.  The FGVs refer to singlton private data instances and expanding them to have multiple copies in memory means the caller must know which instance of the FGV contains "MyData" 


Scaleing a singlton to a multiple is a lot easier by replacing the FGVs with Classes.  Each caller then needs only know which collection of class instances contain the collection of "MyData."


Or As TST said, Global resources are global.  Limiting the scope means chosing some method to: A) create copies and B) let the caller distinguish between copies.  Spawning VITs is one way to get there but you can make your debug and integration a heck of a lot less burdensome if you spawn One VIT (FGV) that holds references to your "MyData" class instances.

"Should be" isn't "Is" -Jay
0 Kudos
Message 9 of 16

Jeff·Þ·Bohrer wrote:


Scaleing a singlton to a multiple is a lot easier by replacing the FGVs with Classes.  Each caller then needs only know which collection of class instances contain the collection of "MyData."

Ugh, but now you have to pass that wire around! Smiley Very Happy

0 Kudos
Message 10 of 16