LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Spawning processes from an executable

I have a LV2012 program that needs to run a number of subVIs as separate, standone processes in the background. The "Start Asyncronous Call" function works great for this.

 

However, I need to build an executable that has the same functionality, to be run on a machine that just has the RunTime Engine.  How do I do this?

 

The Start Asyncronous Call function is expecting a VI, so that that can't be used in the executable. If I build the subVIs as DLLs and call them with Call Library Function Node, it's not clear to me how to run the DLLs as a separate processes. If I build the subVIs as EXEs and call them with System Exec, the subVI front panel pops up; I have many of these so it gets ugly.

 

Do I need to build the subVI as a dll, then put that dll in a vi wrapper, build the wrapper as an EXE, then call that with System Exec? Surely there is a cleaner way to do this.

 

Thank you in advance for any advice you can offer.

 

0 Kudos
Message 1 of 7
(2,672 Views)

Instead of using that "type specifier refnum" I prefer to drop a static VI reference on the diagram. Drag and drop the subVI you want to launch into the static VI reference. It will then link it to that VI. Right click the static VI reference and select strictly typed reference. This VI will then be compiled into your code when you build the executable automatically. 

 

 

Message 2 of 7
(2,660 Views)

@Chris_12345 wrote:

 

The Start Asyncronous Call function is expecting a VI, so that that can't be used in the executable.

 


Hi Chris, if I remember correctly from your main EXE you can call a VI file.

Simply remember to include it  in the release and specify the correct path.

In other words: the run-time engine can execute VIs.

What it can't do is recompile them, so they must be "ready" for the correct version of Labview RTE.

 

Marco

 

 

 

 

 

 

 

0 Kudos
Message 3 of 7
(2,640 Views)

Chris,

     Here's how I do it.  The following code will work in both Development and Run Time environments.  The VI I'm trying to spawn is UTIL Save Project Name.  As you can see, I've built a Static VI Reference, browsed to this VI on my disk, and also checked the box to make it a Strictly Typed VI Reference.  I wire it to a Property Node and get its name, which I then wire to a Get VI Reference.  You might ask, why, if I start with a (Static) VI Reference, am I going to all this trouble to get a(nother) Reference?  Well, I have to set the Start Async options, in this case, "Call-and-Forget" (x80).  I also need to wire the (strict) VI Reference into the Type input of the Get VI Reference in order to get the required Strict VI Reference that the Start Asynchronous Call requires.

 

Try this, and let us know if this works for you.

 

Bob Schor

 

Start Async Example.png 

0 Kudos
Message 4 of 7
(2,615 Views)

Hi Marco,

Thank you, this works (sort of). What I mean by that is calling *small* VIs does just what it should do. However, for larger VIs, a window opens up that shows LV finding and loading the various components, then it suddenly closes and reports Error 1003 (subVI is not executable). Yet, I can run it on my development machine. It does have OOP, and some of the non-referenced children can't run on Windows, so maybe that is causing a problem, even though it shouldn't. Do you think this might be what is happening? I suppose a work-around is tio put in a bunch of Conditional Disable structures, but I would prefer not having to do that.

Chris

 

0 Kudos
Message 5 of 7
(2,579 Views)

@Chris_12345 wrote:

Hi Marco,

Thank you, this works (sort of). What I mean by that is calling *small* VIs does just what it should do. However, for larger VIs, a window opens up that shows LV finding and loading the various components, then it suddenly closes and reports Error 1003 (subVI is not executable). Yet, I can run it on my development machine. It does have OOP, and some of the non-referenced children can't run on Windows, so maybe that is causing a problem, even though it shouldn't. Do you think this might be what is happening? I suppose a work-around is tio put in a bunch of Conditional Disable structures, but I would prefer not having to do that.

Chris

 


Who's Marco?  Are you responding to my post?

 

When you get Error 1003, does it say what subVI is not executable?  Have you set any "Execution Properties" (like reentrancy) on any of your VIs?

 

I've used this technique to spawn 24 copies of a video capture routine, monitoring (and recording from) 24 cameras simultaneously.  Needless to say, there were a lot of VIs inside the single VI whose Static VI Reference I used ...

 

BS

0 Kudos
Message 6 of 7
(2,574 Views)

Hi, I'm Marco 🙂

 

@Chris: you could try disabling portions of code in the dynamically loaded VI, until you find which one is causing the error.

Moreover: the child class should not be loaded in memory unless at least one of its vi is called by the parent class.

 

I wonder if there is a Labview RTE log file with more details about what happened....

 

Marco

 

 

 

0 Kudos
Message 7 of 7
(2,542 Views)