Dynamically calling a subvi does not work in executable

[Matthisc]

Hello,

I am trying to calling a VI dynamically in a program. It all works fine in Labview, but once I compile an executable, the dynamically called VI complains that it cannot find any of its subvis. 

I have seen this post https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019QDcSAM&l=en-NO which describes my problem very well, but the suggested solution is not working for me (I don't understand point D.ii) though, the default support directory is a folder named "data" in the main folder... 

Any feedback is welcome, best if it is an idiot-proof step-by-step explanation 🙂 . I am attaching a simple example of the structure I am trying to run (with a single subsubvi the subvi calls (which itself consists of several vi's, all from the file.llb library).

[Bob_Schor]

I also have a habit of saying "I'm attaching ...", and then, like you, I Post before I remember to Attach ...

Bob Schor

[Matthisc]

Oh, sorry. Let me try again...

[Bob_Schor]

After reading the article you cited, I can suggest a simpler way to accomplish your task.  Create a Folder in your Project called something like "Code from Project ABC", and put copies of the VIs (and TypeDefs, and sub-VIs that they call) in there.  To see if you've got all the "pieces", take your Project to another computer with LabVIEW, but without Project ABC, and see if you can run it from Development mode.  If so, you're done, and the Build should work.  Otherwise, it will show you the missing VIs you need to add.

This is something of a kludge.  If you are going to be using the code from Project ABC more than once, extracting that code and making it a Library, or using VIPM to make it a VI Package that will be found at Build time, is a more robust method.

Bob Schor

[GerdW · Accepted solution]

Hi Matthisc,

use a static VI reference and your problems are gone:

You don't even need to include the subVI as "Always included" when you build an executable anymore!

[Bob_Schor]

Bravo, @GerdW!  Of course that's the "better" method, one I use all the time.  I must have had my brain turned off ...

Bob Schor

[paul_cardinale]

---

@GerdW wrote:

Hi Matthisc,

use a static VI reference and your problems are gone:

You don't even need to include the subVI as "Always included" when you build an executable anymore!

---

That's worse than just running the sub VI directly.

[rolfk]

---

@paul_cardinale wrote:

---

@GerdW wrote:

Hi Matthisc,

use a static VI reference and your problems are gone:

You don't even need to include the subVI as "Always included" when you build an executable anymore!

---

That's worse than just running the sub VI directly.

---

Actually it's not the same! A subVI runs once when called. This starts the VI and lets it run as its own top level VI until it decides to close. However I would nowadays use Start Asynchonous Call for that! And let the VI open itself when it deems that necessary, not before it is started.

[GerdW]

Hi Rolf,

---

@rolfk wrote:

---

Actually it's not the same! A subVI runs once when called. This starts the VI and lets it run as its own top level VI until it decides to close. However I would nowadays use Start Asynchonous Call for that! And let the VI open itself when it deems that necessary, not before it is started.

---

I also use StartAsync nowadays, often as Fire&Forget. You additionally get simple access to the ConnPane…

The main point for the OP was the usage of StaticVIReferences with all their advantages, when compared to building a VI path using filepath functions!

[Matthisc]

thank you everyone for your help! the static VI reference does the job and that's enough to get my program running the way I want it - not so obsessed with performance, it's a simple data logger... 

for curiosity, I am still interested, why the packed library solution did not work for me and how I should use it in the future. But again, thats optional help 🙂