VI Launcher & Global Variables

[gmhgmh]

Hello, I've inherited VI code that gets compiled as an EXE. This EXE uses the VI Launcher function to launch sub VIs.

The EXE has a global variable structure that gets used by the launched VIs.

I think the vi that defines the global variable gets found by the launched VIs; the VIs for both are in the same directory. I'm not sure how the launched VI knows to look for its sub VIs - there are no project files and they don't get compiled to an EXE. Just cause they're in the same directory?

So my questions

1) how do the launched VI's know where to find their sub VIs?

2) what about the global variables? I presume they maintain their own copy in their own memory? They can't possibly be shared between the programs can they?

3) how do I go about communitcating between the EXE and the launched VIs? Is there an easy way?

A side question would be - what type of performance hit am I getting by launching the VIs rather than compiling them into the EXE?

Thanks for everyone's help again,

Gunter

[gmhgmh]

Just a ping! to see if anyone can help.

(Best I can tell the globals are shared between the exe and Vi's launched by the VI launcher VI.)

Thanks again!

Gunter

[PeanutButterOven]

I searched VI Launcher on the web and it is not a native LabVIEW toolkit so I can only speculate as to how it was coded. But it seems it would dynamically call by reference and possible scan a file path until the appropriate front panel was detected and then load/call the vi. As for communicating between the executable and the VIs called, global variables are an option but not the preferred method. Using Shard Variables is a much better solution for passing data between VIs/EXEs. I have provided some links for you to familiarize yourself with Shared Variables and their implementation.

http://www.ni.com/white-paper/4679/en/

http://zone.ni.com/reference/en-XX/help/371361J-01/lvconcepts/ni_psp/

http://digital.ni.com/public.nsf/allkb/04D9A85B6967EE87862571140065EEC6

[Bob_Schor]

---

@gmhgmh wrote:

Hello, I've inherited VI code that gets compiled as an EXE. This EXE uses the VI Launcher function to launch sub VIs.

The EXE has a global variable structure that gets used by the launched VIs.

I think the vi that defines the global variable gets found by the launched VIs; the VIs for both are in the same directory. I'm not sure how the launched VI knows to look for its sub VIs - there are no project files and they don't get compiled to an EXE. Just cause they're in the same directory?

So my questions

1) how do the launched VI's know where to find their sub VIs?

2) what about the global variables? I presume they maintain their own copy in their own memory? They can't possibly be shared between the programs can they?

3) how do I go about communitcating between the EXE and the launched VIs? Is there an easy way?

A side question would be - what type of performance hit am I getting by launching the VIs rather than compiling them into the EXE? 

---

First, an assumption:  I assume when you say "VI Launcher function" you are talking about VI Server.

As far as I know, there are three ways to "launch" VIs in LabVIEW -- use the Run VI Method with a VI reference (VI Server), call a VIT to spawn a clone (I don't do this, normally, so I'm fuzzy on the details), and use the Start Asynchronous Call functions.

Let's ignore what happens when you build an EXE, for now.  When you open a VI in Development Mode, it has to "touch" all of its sub-VIs in order for there to be no broken wires.  This means that they all are in memory, and "know" where each other is located.  This basically answers Question 1 (in Development mode).  Global Variables are simply locations in memory where a Variable is stored "globally", meaning everyone can get to it.  So again, it simply appears to all the VIs that use it as a known memory location, hence answering question 2.  Question 3 is of a different nature -- we'll come back to it.  As for the side question, in Development mode, launching VIs instead of calling them directly has more of an impact on how they share CPU resources (if launched, they necessarily run "in parallel", so they'll run independently of the main routine and might be able to share resources more efficiently.

I'm not really sure what happens when you build an executable, but part of the process is taking the VI (which looks to us like pretty pictures on the screen), getting rid of the pictures, and boiling it down to the underlying code that needs to be executed.  I suspect the difference between the EXE and the VI is like the difference between Compiled and Interpreted code -- in the latter case (e.g Development mode), an "interpreter" needs to be running to "interpret" the code ("pictures") and do whatever the code implies.  One benefit, of course, is you can "Watch" the code being executed.

In order to compile the code, the compiler needs to know where everything is, just as the interpreter does.  In building the executable, it puts the various pieces "to be run" in the file, then brings them into pre-determined (or figured-out-on-the-fly) memory locations, and starts them going.  This includes the detached (spawned, launched) tasks, as well -- they live in memory, and the Run Time System "knows" where the loader put them, so it can reference them.

[Someone who really knows how this works can probably say it better, but I'm pretty sure that I got the Big Picture at least 75% correct ...].

Question 3, how to communicate with a Detached Process -- you can use a number of techniques.  Global variables, Action Engines, Functional Global Variables (or VIGs) are one method.  If your detached process periodically "reads" its front panel, you can "push its button" by using the Set Control Value method using a reference to the detached VI.  They can share a Queue (though you need to be a little careful here). 

[gmhgmh]

Thanks BP & Bob - I'l try to digest what you both said.

Thanks again,

(where's the kudos button so I can thank you?)

Gunter

[Bob_Schor]

---

(where's the kudos button so I can thank you?)

---

I really have no idea!  I hope someone answers, as there are some responses I think deserve a Kudo ...

[Bob_Schor]

... and, of course, I found it just as I posted.  See the yellow Star?  Mouse over it ...

BS