Re-entrant VI with Front Panel

[jgcode]

I was trolling through NI's code documents when I saw this post and it got me thinking:

Which is the better way and why, to have multiple instances of a VI's front panel in memory at the same time.

1) Spawn (and specify re-entrancy on open ref node: 8) a re-entrant VI and invoke open front panel method OR

2) Spawn .VIT template

I was under the impression the later is the way to do it. The user mentions in the post a problem with loading, and the need for a wait in the for loop.

How does LabVIEW handle each approach (with respect to memory allocation?)

Cheers

[Kurt Friday]

I prefer method 1

What I do instead of waiting in a loop is to pass an occurrence ref into it and then when the spawned vi is loaded it sets the occurrence which is the signal to the launcher that it can continue.

Another advantage I like about method 1 is that you can include your vi within your code but have it cased out, so if it's broken you know about it at top level also you don't need to include it as a support file when you build, its already there.

One trick you need to be aware of is that LabVIEW will strip the front panel of any vi unless you have the vi property "Show Front Panel When Called" set to true or you have a property node of a control in the code.

I don't know the performance advantages of each method though.

[jgcode]

One trick you need to be aware of is that LabVIEW will strip the front panel of any vi unless you have the vi property "Show Front Panel When Called" set to true or you have a property node of a control in the code.

Hi Kurt - thanks for your reply.

I have noticed the "do not delete" comment for a property node for a control whilst trolling through some of your old code here

[Kurt Friday]

Hi Kurt - thanks for your reply.

I have noticed the "do not delete" comment for a property node for a control whilst trolling through some of your old code here

Ha, cool, didn't recognize you Jon without your Bee Avatar.

[Black Pearl]

2) Spawn .VIT template

As far as I remember: In LV 7.1 only method 2 works.

Dealing with reentrant vi's with improved during the 8.x.

Felix

[jgcode]

One trick you need to be aware of is that LabVIEW will strip the front panel of any vi unless you have the vi property "Show Front Panel When Called" set to true or you have a property node of a control in the code.

Hi Kurt - I tried the above but no luck - do you have any examples?

I still cannot seem to get two FP in memory at the same time. Lets say I spawn two re-enetrant VI's and open their front panels with Show Front Panel:Property Node. If both are instantiated at the ~same time (i.e. using For Loop) the FPs open but th VIs don't run (observing run arrow). If I use a delay, the first runs correctly, then the second runs correctly, but the second one stops when the first spawned VI completes execution.

As far as I remember: In LV 7.1 only method 2 works.

This is the only way I can get it to go in LV 8.6.1 as well. In order to create two independent FP in memory.

Seems re-entrant VIs share the same FP memory (mentioned in below post).

I did find some more info from searching here, here, here & here

[Kurt Friday]

Hi Kurt - I tried the above but no luck - do you have any examples?

I still cannot seem to get two FP in memory at the same time. Lets say I spawn two re-enetrant VI's and open their front panels with Show Front Panel:Property Node. If both are instantiated at the ~same time (i.e. using For Loop) the FPs open but th VIs don't run (observing run arrow). If I use a delay, the first runs correctly, then the second runs correctly, but the second one stops when the first spawned VI completes execution.

This is the only way I can get it to go in LV 8.6.1 as well. In order to create two independent FP in memory.

Seems re-entrant VIs share the same FP memory (mentioned in below post).

I did find some more info from searching here, here, here & here

No prob mate

Just having a beer waiting for a curry, I can squeeze one out.

Have a play with this.

SpawnFP.zip

[jgcode]

No prob mate

Just having a beer waiting for a curry, I can squeeze one out.

Have a play with this.

SpawnFP.zip

Sweet, got it to go - I had a bug, dammit (amateur mistake of releasing a ref) so the observation I made above can be ignored.

Thanks heaps for the post, really like the way you case out the VI.

Better than using a static ref because the VI will be in the build AND as you mentioned the Top Level will become broken.

Also playing with the build in LV8.6.1

Running the build errors when Spawn button is pressed complaining the VI is not in memory.

I figured this may be from the constant folding of the casing out and LabVIEW being smart - so I changed the constant to a control defaulted as false, re-built and it works. I guess this has changed from the version you are using and thought it may be of interest if you didn't already know?

Enjoy the curry! (is it homemade?) - for brunch yesterday I had takeout Dosa Masala and Purri's with potatoes. :YumYum:

Cheers mate

JG

Edited July 19, 2009 by jgcode

[Kurt Friday]

Also playing with the build in LV8.6.1

Running the build errors when Spawn button is pressed complaining the VI is not in memory.

I figured this may be from the constant folding of the casing out and LabVIEW being smart - so I changed the constant to a control defaulted as false, re-built and it works. I guess this has changed from the version you are using and thought it may be of interest if you didn't already know?

JG

Ah, yeah forgot about that. I've updated the code and included a build.

SpawnFP_2.zip

Enjoy the curry! (is it homemade?) - for brunch yesterday I had takeout Dosa Masala and Purri's with potatoes. :YumYum:

Curry was OK, nothing special just some takeaway from the local, could have been a bit spicier. I made Beef Rendang the other day that was damn good, poked me right between the eyes.

Edited July 20, 2009 by SciWare

[jgcode]

Curry was OK, nothing special just some takeaway from the local, could have been a bit spicier. I made Beef Rendang the other day that was damn good, poked me right between the eyes.

My wife makes a mean curry, her Father is a genius at them.

His special is a bacon bone curry that literally blows your head off.

I did not eat heat/spicy food growing up so I am easing myself in

I also do not understand why someone would want to eat something like that!

Although I think the bacon bone is coming up for me, if I make it through that then I am really considered family

Edited July 20, 2009 by jgcode

[jgcode]

Ah, yeah forgot about that. I've updated the code and included a build.

Seems in LabVIEW 2009 VIs will not be remove due to constant folding.

E.g. this VI will be included in a 2009 build, it was not in 8.6.1

[Kurt Friday]

Seems in LabVIEW 2009 VIs will not be remove due to constant folding.

E.g. this VI will be included in a 2009 build, it was not in 8.6.1

I can't think of any reason why. Perhaps it breaks some new feature of LV2009.

[Rolf Kalbermatter]

I prefer method 1

What I do instead of waiting in a loop is to pass an occurrence ref into it and then when the spawned vi is loaded it sets the occurrence which is the signal to the launcher that it can continue.

What I do in this case, is wait in the caller until the subVI has opened its FP. The reason to this is that the VI is kept alive by either a VI refnum to it or its FP being open. So after the FP is open, closing the VI refnum used to spawn it is safe.

Another advantage I like about method 1 is that you can include your vi within your code but have it cased out, so if it's broken you know about it at top level also you don't need to include it as a support file when you build, its already there.

You can do that with .vit too although I usually have those dynamic VIs rather in a "all VIs" top level VI that I have open when developing (and add to the build as explicitedly added VI). To put a VI Template on a diagram instead of its instantiated VI you need to drag the icon from an open VI Template (file->open) or or dragging it from the explorer into the diagram, rather than using the "Menu Palette->File Browser" method.

One trick you need to be aware of is that LabVIEW will strip the front panel of any vi unless you have the vi property "Show Front Panel When Called" set to true or you have a property node of a control in the code.

You can also change the setting of the according VI in the build settings in your project but I admit that this is something that can easily be forgotten and the FP frontpanel property is a nice trick to make sure things work always as expected.

I don't know the performance advantages of each method though.

Instantiation from a VIT is a lot more costly in terms of time needed to open it and most likely also same or worse in memory footprint than a reentrant VI. But the option to have a front panel for reentrant VIs was not there before LabVIEw 8.2 I think.

Rolf Kalbermatter

[Kurt Friday]

Hi Rolf

Some nice tips.

You can do that with.vit too although I usually have those dynamic VIs rather in a "allVIs" top level VI that I have open when developing (and add to thebuild as explicitedly added VI). To put a VI Template on a diagraminstead of its instantiated VI you need to drag the icon from an openVI Template (file->open) or or dragging it from the explorer intothe diagram, rather than using the "Menu Palette->File Browser"method.

Rolf Kalbermatter

I was trying to do something like this when I was developing the popup menu toolkit. It was built in LV 7.0 and I had to use vit's because each recursively spawned submenu needed its own unique FP. I remember experimenting by placing the vit in the BD as you mention but there was an issue that I'll have to take another look at, I'd say it's been resolved in later versions of LV. So as part of the user documentation I tell the developer that they need to include PopupMenu.MenuSelector.vit into their build.

[PJM_labview]

I skimmed through the thread quickly so I apologize if this has already been said.

• Instantiating a reentrant VI is way faster than instantiating a vit.
• There are some things (UI wize) that you can not do with reentrant instances. For example, each reentrant instance share the same tip strips (or documentation) for their controls (this could be problematic depending on your use case).

PJM

[Kurt Friday]

I'm just revisiting the bad old days of vits and playing with Rolf's suggestion that you can place a vit on the BD in a similar way as the reentrantly called vi is done in my posted example SpawnFP_2. I can get it to work in dev environment but not as a built exe. Here is a shot of my code.

The trick to get it to work in the dev environment was casting the spawned vit name to a path, this must request LV to open the vit and rename it as a new instance. If you just wire the vit name into the Open VI as a string it complains that "Cannot instantiate template VI because it is already in memory" So OK that makes sense.

But When I build it and run it it just complains that "Cannot instantiate template VI because it is already in memory"

I'm just playing with it for intrest sake to see if there was something I missed when I was playing with vit's back in the late Jurassic with the Popup Menu.

[Rolf Kalbermatter]

I'm just revisiting the bad old days of vits and playing with Rolf's suggestion that you can place a vit on the BD in a similar way as the reentrantly called vi is done in my posted example SpawnFP_2. I can get it to work in dev environment but not as a built exe. Here is a shot of my code.

The trick to get it to work in the dev environment was casting the spawned vit name to a path, this must request LV to open the vit and rename it as a new instance. If you just wire the vit name into the Open VI as a string it complains that "Cannot instantiate template VI because it is already in memory" So OK that makes sense.

But When I build it and run it it just complains that "Cannot instantiate template VI because it is already in memory"

I'm just playing with it for intrest sake to see if there was something I missed when I was playing with vit's back in the late Jurassic with the Popup Menu.

Probably you were not missing anything. The applications where I used that never required to be build into an executable so I never came across that limit and therefore never tried to tackle that problem.

Although I did intend to leave the VITs and their subVis external to the exe for the case we ever would attempt to do the build. But not sure if that would make a difference.

Rolf Kalbermatter

[Kurt Friday]

Probably you were not missing anything. The applications were I used that never required to be build into an executable so I never came across that limit and therefore never tried to tackle that problem.

Although I did intend to leave the VITs and their subVis external to the exe for the case we ever would attempt to do the build. But not sure if that would make a difference.

Rolf Kalbermatter

Ahhh, cool. I'm a little more wiser now.