LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Dynamically calling a subvi does not work in executable

Solved!
Go to solution

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).

0 Kudos
Message 1 of 11
(378 Views)

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

 

Bob Schor

0 Kudos
Message 2 of 11
(371 Views)

Oh, sorry. Let me try again...

Download All
0 Kudos
Message 3 of 11
(367 Views)

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

0 Kudos
Message 4 of 11
(363 Views)
Solution
Accepted by Matthisc

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!

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO
Message 5 of 11
(348 Views)

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

0 Kudos
Message 6 of 11
(333 Views)

@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.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 7 of 11
(280 Views)

@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.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 8 of 11
(260 Views)

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!

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO
0 Kudos
Message 9 of 11
(204 Views)

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 🙂

 

 

0 Kudos
Message 10 of 11
(186 Views)