LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Calling a vi from exe

Solved!
Go to solution

I am developing a project in which I need to call a particular VI from calling VI. I have done it in development. Next, I have created an application for a calling VI. It calls a required VI from where I have saved it and works fine. My doubt is Do I need to keep that called vi as a vi even if I distribute an application to my customer? Hope I have told my doubt correctly.

Best Regards,
Dhans 😉
Kudos are welcome 😉
Aspirant Labview Programmer (Labview 14) 😉
0 Kudos
Message 1 of 9
(2,645 Views)

All VI's that are ever called are particular VI's... And you always call it from a caller, by definition. I know you try to be explicit and that it's hard to do this without knowing the lingo. It makes giving an answer hard as well. So you'll get general answer that might not apply to your situation. Here's one...

 

If the VI your calling is called as a normal VI then it's included in the executable automatically.

 

If you use a static VI reference, it's automatically included. But not if the static VI reference is in a dynamically called VI (even if a static VI reference is used).

 

If you call the VI by name or path, it's not included automatically. You can use a static reference (recommended) so it will be included. Or you can add it explicitly to the build specification, in the always include list.

 

If you want to call it dynamically and it can't be in the executable (because it can change and you can't recompile the executable), you need to ship the VI (and all subvi's, including vi.lib used, that are not in the executable) separately. This can be done with a PPL or manually (, or with a source distribution I guess).

 

Of course a simple test would have made all this clear as well. Seems you're running into a problem. Maybe you can explain the problem.

Message 2 of 9
(2,634 Views)

As the previous post describes, if you are calling the vi dynamically from an exe you will need to do either a source distribution or put it in a PPL (Packed Project Library). Read about PPLs first, there are some "risks" the predominant being that you overwrite an existing library with the PPL, which is not editable.

Here is a thread that describes my recent experience with dynamically calling a vi from an exe. My problems derived from deploying it on another machine (it may work fine on your development machine, then fail on a target machine, for reasons unrelated to your actual program, more the target computer's installed drivers and LabVIEW Runtime)

Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5


LabVIEW Champion



Message 3 of 9
(2,607 Views)

Hi all,

 

    Thanks for the reply. I didn't call it dynamically. Only one call in a caller VI. I have created an application of caller VI only and run it on the other computer and it works fine. Seems there is no need to add called Vi there. Only static reference is enough. If I am wrong, tell me what to do. 

Best Regards,
Dhans 😉
Kudos are welcome 😉
Aspirant Labview Programmer (Labview 14) 😉
0 Kudos
Message 4 of 9
(2,602 Views)

It depends on what you are trying to accomplish. If it is only that your main VI calls a sub-vi, then if you use a static reference, then it will be "compiled in" to the exe when the exe is built, which appears to be what you want and are doing. My, and part of the other's comments, were if you were trying to load a vi at runtime, that hadn't been present when the exe was built. A somewhat different goal.

Good luck, and have fun with LabVIEW!

Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5


LabVIEW Champion



Message 5 of 9
(2,586 Views)

@dhans wrote:

 

    Thanks for the reply. I didn't call it dynamically. Only one call in a caller VI. I have created an application of caller VI only and run it on the other computer and it works fine. Seems there is no need to add called Vi there. Only static reference is enough. If I am wrong, tell me what to do. 


Your not wrong. If you don't do anything dynamically, building an exe is as simple as adding the top level VI, and pressing build.

Message 6 of 9
(2,582 Views)

Hi all, 

Thanks for the reply. I have understood the concept between static VI reference and dynamic VI reference ostensibly. Can someone tell me the concept of these two type reference in depth?

Best Regards,
Dhans 😉
Kudos are welcome 😉
Aspirant Labview Programmer (Labview 14) 😉
0 Kudos
Message 7 of 9
(2,552 Views)
Solution
Accepted by topic author dhans

@dhans wrote:

Thanks for the reply. I have understood the concept between static VI reference and dynamic VI reference ostensibly. Can someone tell me the concept of these two type reference in depth?


You can call a VI statically (just use it as a subVI) or by reference (dynamically).

 

The static VI reference obtains a reference, but the call is still dynamic (you could switch the references, so the call is not fixed at compile time).

 

So you can:

+ Do a normal VI call

+ Call the VI by reference (dynamically)

    + with a static VI reference

    + by getting a reference by name\path

 

There are other ways to get VI references, but for a "normal" (not scripting) application those are mostly irrelevant.

 

Dynamically calling a VI with a static VI reference has benefits (over getting a reference by name\path). For instance, you can use find all instances and the VI will be in the executable.

 

Getting reference by name\path simply means you're on your own regarding the VI as a resource. It (and it's dependencies) will not be taken into account for anything... There are still use cases for this, for instance plug-in structures where names are not known (extendable) during compile time. Or when a name is given from e.g. a configuration file.

Message 8 of 9
(2,543 Views)

Hi wiebe,

 

    Thanks for the explanation. 

Best Regards,
Dhans 😉
Kudos are welcome 😉
Aspirant Labview Programmer (Labview 14) 😉
0 Kudos
Message 9 of 9
(2,539 Views)