≡ Menu

06 VISV Avoiding broken executables when using dynamic VIs


As we've learned back in VISV Episode 003. When building executables that use dynamic VIs, you must make sure to specify the dynamic VI name in the ‘always include' section of the LabVIEW Application Builder specification. Not doing this will cause problems that manifest themselves as a LabVIEW application that won't be able to load your dynamic VI and will either raise various errors or cause the application to fail completely. It depends on how critical your dynamic VI is to the overall application.

Making special considerations for dynamic VIs during the build process is an extra step you have to do which can lead to a point of failure. If you create a new dynamic VI in your code then you must remember to update the build spec. Even with the best intentions, this step can still be missed.

Sometimes you are not in control of the build process. For example, your code may be distributed as a toolkit that others use to build their own applications. Informing end users of your code to include the dynamic VIs is a challenge.

In this video tutorial, I will show you a simple way to avoid these problems by following two simple code modifications.

Download Code Used in this Tutorial: (LabVIEW 2009)


In the video, you'll see me use the path from the VI path property wired into the Open VI Reference function. It's slightly more efficient to use the VI Name property and wire that instead. Since the VI's already in memory. Using the VI name should work just fine.


Hey, this is Michael Aivaliotis! Thanks for reading my post, listening to the podcast or watching the video on this page. When I’m not posting content on this site, I help companies develop automation powered by LabVIEW. If you want to find out how I can help you succeed with your next LabVIEW project – Contact Me.

  • Thanks Micheal, it’s a great tip! Especially when you have more than one exe built in your project, saves the pain of updating all the specs.

  • Bob Schor

    Question — you wired the Static VI Reference to a property node to get the path, then wired the path to Open VI Reference to get the VI Reference.  Not knowing any better, I’ve been doing much the same, but using the Static VI Reference directly, eliminating the property node + Open VI Reference.  Any downsides to this “shortcut”?  [Answer to my own question — you used the “Option” input of Open VI Reference to specify “Prepare for Reentrant Run”, something my shortcut doesn’t permit.  Is there a way to “bundle” this behavior with the VI itself, i.e. set its Execution property to Reentrant?]

    • Bob, thanks for commenting. :)

      As far as I know. Setting the VI as reentrant is not enough. You must use the Open VI reference function. You actually have to do both. Set the VI as reentrant and also use the Open VI reference function with the x8 option. Not sure why it’s setup this way.

      The Run VI method assumes the VI is already in memory, and this can be done with the static VI reference. However, the static VI reference does not have a switch for allocating a separate dataspace for the VI and cloning it, which is required for reentrant VIs. The Open VI reference function with the x8 option achieves this.

  • Lamsalli

    how to add some controls in control box for arduino, how to download?

  • Charles

    Is this still needed when using the async VI calls that appeared in LV 2011?