LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

reentrant VI that uses a functional global

Hello,

 

I currently have an issue with a top-level VI that is reentrant and is using FG's within it. My goal is to create the top-level application and once completed to have a "Launcher" utility that will open N instances of my top-level VI. Unfortunately, I've run into a situation where I am using FG's to tell subVI's that the top-level application is closing and when I close one instance it closes them all. I'm also using a circular buffer action engine (AE) within the top-level VI to store historical data for a waterfall intensity graph and I believe that this will also suffer from different top-level VI instances cross-talking data when I don't want them to. Does anyone have suggestions on how to keep same name FG's in separate top-level VI's from communicating with one another? The picture below shows what I'm trying to do at a high level. The MAST display is my top-level VI and I want to be able to run it N times with different configurations.

 

MastLauncher.PNG

 

I've read most of Ben's April 8, 2007 community nugget on Action engines and I recall that there was some back and forth between the LVOOP camp on a way to implement AE's in object-oriented architecture that may work for my case. I haven't touched LVOOP though so I was wondering if anyone has other examples to get around my issue or if LVOOP really is the best way to solve it.

 

Regards,

 

Tim



Tim Sileo
RF Applications Engineer
National Instruments



You don’t stop running because you get old. You get old because you stop running. -Jack Kirk, From "Born to Run" by Christopher McDougall.
Message 1 of 3
(2,548 Views)

@tsileo wrote:

Hello,

 

I currently have an issue with a top-level VI that is reentrant and is using FG's within it. My goal is to create the top-level application and once completed to have a "Launcher" utility that will open N instances of my top-level VI. Unfortunately, I've run into a situation where I am using FG's to tell subVI's that the top-level application is closing and when I close one instance it closes them all. I'm also using a circular buffer action engine (AE) within the top-level VI to store historical data for a waterfall intensity graph and I believe that this will also suffer from different top-level VI instances cross-talking data when I don't want them to. Does anyone have suggestions on how to keep same name FG's in separate top-level VI's from communicating with one another? The picture below shows what I'm trying to do at a high level. The MAST display is my top-level VI and I want to be able to run it N times with different configurations.

 

MastLauncher.PNG

 

I've read most of Ben's April 8, 2007 community nugget on Action engines and I recall that there was some back and forth between the LVOOP camp on a way to implement AE's in object-oriented architecture that may work for my case. I haven't touched LVOOP though so I was wondering if anyone has other examples to get around my issue or if LVOOP really is the best way to solve it.

 

Regards,

 

Tim

 


 

 

Thank you for reading! I get a fresh round of energy everytime I learn that a Nugget was helping out.

 

Spoiler

I am still accepting Kudos for those Nuggets.

Smiley Wink

 

Setting LVOOP to the side...

 

I'll speak to both use cases.

 

You can use dynamic events inside the cloned sub-VI to register for the close event and a ref to the top level to poll if it is still running.

 

THe round robin-buffer.... a queue created in the top level and a ref to same passed to the sub-VIs will create a virtual pipe for each top level that the sub-VIs can fill.

 

Re: Uisng an Action Engine...

 

YOu could use VI server to create a new instance and pass that ref to the sub-VI that in-turn use Call by Ref nodes to invoke teh AE actions. This is a more complicaed appracoh but should work.

 

I avoided that constrct in favor of storing the data that is unique to each "tree" inside the clones themselves and pass a cluser with that data to the AE to operate on and then the Ae returns the sate. Looking back this was a form of "poor man's LVOOP". So before you go this route concider LVOOP and let LV do the work instead of you.

 

Ben

 

PS: Wow! begging does work. Thank you!!!!

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

Hi Ben, First off thank you for the very quick response.

 

regarding the Nugget: Kudos Given Smiley Happy

 

Re: Dynamic Events...I haven't really used these before but I've seen a few brief examples and they don't seem overly complex. I am having trouble wrapping my head around the concept of using them between my Launcher and Display VI's though. I've attached my launcher to show how it actually launches the displays. I'd prefer to not have to pass any ref's from the Launcher to MAST Display or from MAST Display to it's subVI's if at all possible. That was one reason I used FG's and AE's in the first place Smiley Wink

 

Re: Round-Robin buffer...I was originally using uninitialized shift registers (USR's) to store 5000 rows of display updates that are 1024 DBL's each row. Are you suggesting that maybe a 5000 element queue may be a better approach? One thing I actually did think of with a queue approach is that I could call "VI clone name" to initiallize each buffer with a unique name based on the MAST Display clone number. I haven't implemented that yet since my buffer design is complete but the code is not. It also forces me to pass the clone name to all calls to the buffer which I was hoping to avoid if possible.

 

Any links to examples would be great so that I can try to visualize what you were trying to explain. I haven't been using LV long enough yet to daydream my block diagram layout but I'm getting there Smiley Tongue



Tim Sileo
RF Applications Engineer
National Instruments



You don’t stop running because you get old. You get old because you stop running. -Jack Kirk, From "Born to Run" by Christopher McDougall.
Download All
0 Kudos
Message 3 of 3
(2,522 Views)