LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why would an asynchronous call result in "The VI is not executable. The full development version..."

Solved!
Go to solution

 

I've built a moderately complex labview program to communicate with a new analyzer I'm building.  To describe the application briefly, the main VI is a user interface that, in an initialization step, asynchronously calls a dozen other VIs.  Each called VI is a state machine that handles communication with a specific component of my analyzer, be it Heat Controllers, Flow Controllers, NI DAQmx channels, a SQL database, etc.  I use GFV's and/or AE's to communicate information between the main VI and each component. The system works well when running it through NI Labview 2012 SP1 (Full Development Version).  I can build the project successfully, but when I run the build (on the same development machine),  I encounter the "The VI is not executable.  The full development version of LabVIEW is required to fix the errors" message. 

 

My first step in troubleshooting this was to isolate the issue.  I removed all the asynchronous calls, rebuilt it, and the program runs without errors (granted, none of the state machines that handle intrument I/O are running). This gave me the impression my user interface VIs aren't the problem. 

 

The next step I took was to create a test project with a simplified user interface to asynchronously call and control a single component.  The first component I tried controls a Heater, and it works perfectly.  I build it, and run it without errors or problems. 

 

Thinking that component must not be an issue, I add the asynchronous call for that component back into my main VI, to test it there.  It works well in the Labview Development environment, builds without errors, but alas, I get the same message that the "VI is not executable" when I attempt to run the build. 

 

I'm at a loss as to how to trouble shoot this, or what might be causing the problem.  Why would an asynchronous call to the same VI break one project's build executable, but not cause problems in a secondary projects executable? 

 

 

0 Kudos
Message 1 of 15
(3,814 Views)

Generally when we design the software and run it through the development system, the asynchronously called VI are located at specific locations, so it won't  trouble us, but when we build the executable the VI path changes, make sure the called VI's have proper paths.

 

Also while building the executable include the VI in always include section.

With Regards

Miraz
Kudos is better option to thank somebody on this forum
------------------------------------------------------------------------------
Message 2 of 15
(3,788 Views)

The message "VI is not executable" generally happens when you try to execute a VI which is already running/in error state. How are you making sure that the VI is running? Do you have a UI for the dynamically called VIs?

It is always safe to check the state of the VI before executing it using the VI method. 

Check the code where you are launching and executing different VIs, I suspect there might be some error. 

-----

The best solution is the one you find it by yourself
Message 3 of 15
(3,770 Views)

How are you loading the plugins? Are you using Static VI references or are you loading them dynamically from disk and if so, are you just referencing the VIs or using packed project libraries (.lvlibp)?

 

If it's the latter, are there type definitions / subvi's that are shared between the plugins and the caller? When the application is compiled, all of those SubVIs will get compiled into the .exe and the plugin will have a hard time to find them or will reference it's own version from a different path.


LabVIEW Champion, CLA, CLED, CTD
(blog)
Message 4 of 15
(3,749 Views)

If you're using Static VI ref it shouldn't be a problem, if you're using Path you must make sure they're included in the build as "always include".

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 5 of 15
(3,729 Views)

 

I use the VI Name Property to call VI's by name rather than absolute path.  The result is the called VI appears under the list of dependencies.  This removes the option to include the file within the "Source File" -> "Always Include" build option (probably because it is a dependency, and is thereby automatically included). 

Furthermore, this method works when building and running an executable with the attached test project, but causes a broken executable with the main project using the exact same calling method. 

 

*fake edit*  I've attempted your solution, directly adding the Asynchronously Called VI to the list of top level VI's, and then added its as "always included" under the source files.  This did not change the outcome, where the executable has a broken arrow. 

0 Kudos
Message 6 of 15
(3,716 Views)

 

When using the functioning Test Program, which has the exact same asynchrounous call, to the same file, in the same location, everything is running smoothly.  I can determine the state of the Asynchronously called State Machine using Global Functional Variables (GFV's).  These relay information between my State Machine and the Main UI, including the current state the SM is in.  Additionally, for testing purposes, I have a popup dialog box that reports the number of iterations the state machine ran through right before it exits that VI. 

 

Most of the state machines, and the state machine I'm testing with, don't have a UI.  Some do for debugging purposes, but not one I plan to display for my future users. 

 

I've attached a zip file of the test program I'm using.  It builds and operates on my machine.  When I use the same asynchronous call on my main program's UI, and rebuild, the previously executable build becomes broken.

0 Kudos
Message 7 of 15
(3,714 Views)

 

How are you loading the plugins? Are you using Static VI references or are you loading them dynamically from disk and if so, are you just referencing the VIs or using packed project libraries (.lvlibp)?

 

I'm not certain what your question is asking.  I added a GIF of my calling code. 

 

If it's the latter, are there type definitions / subvi's that are shared between the plugins and the caller? When the application is compiled, all of those SubVIs will get compiled into the .exe and the plugin will have a hard time to find them or will reference it's own version from a different path.

 

 

Assuming "Plugin" refers the the Asynchronously called VI, there are Typedefs and SubVI's that are shared between the caller and the plugins.  If the plugin has trouble finding and referencing the typedefs and subvi's (some of which I use as GFV's), then why does it work with my test project (attached above), but causes my main project to malfunction? 

 

0 Kudos
Message 8 of 15
(3,711 Views)

 

I believe I am using a Static VI reference. 

0 Kudos
Message 9 of 15
(3,706 Views)

 

Here, I've attached 2 Project files. 

 

One is a husk of my full application. 

---  It includes an Asynchronous call to SM_OxygenatorOvenTest, which is a the husk of the original state machine with all DLL calls removed.  It runs find in the development window, but when I build it, the exectuable gives the "This VI is not executable error". 

---  If I remove the Asynchronous call, and rebuild it, the executable runs without errors.  (granted, the husk program doesn't do much). 

 

The second attached project is AsyncStateMachine. 

---  It includes the same Asynchronous call to the SM_OxygenatorOvenTest.  The attached version below has the DLL calls removed.  It runs in the develpment environment, and I can build and run the executable without issues.  It successfully communicates with the SM from the main program through the AE_OxygenatorOven VI. 

 

Why would the asynchronous call break one build, but not the other? 

Download All
0 Kudos
Message 10 of 15
(3,694 Views)