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

Are there any more thoughts or suggestions on how to troubleshoot this?  I really just don't understand why one project's executable works while the other projects doesn't.  

0 Kudos
Message 11 of 15
(1,103 Views)

With that Static VI ref it really should be included automatically, but try to add it as Always Include and see if it changes anything. You can also add some popup vi's that shows the effective Path as a debug tool to see if there's anything strange.

/Y

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

Qestit Systems
Certified-LabVIEW-Developer
Message 12 of 15
(1,071 Views)
Solution
Accepted by topic author S.Gronstal

I had a look at your project and made the following change and it built/compiled:

 

2014-11-24_09-49-31.png

 

I suspected the problem might have been that because you used the VI Name to open the VI reference that this became incorrect when built into the executable. The method I've shown above is how I usually use Static VI calls and this means that the VI is automatically included in the build specification, the paths just work and the VI type specifier always matches the connector pane.

 

I then went back and tried to make the smallest change possible - changing VI Name to Path but leaving both references, relinking to the SubVI but none of these worked. I wonder if it has something to do with having both references to the same VI? VI Name and VI Path both worked as soon as I made both VI references static.

 

This is obviously only suitable when you're launching one or more instances of the same VI rather than launching different VIs (that have the same connector pane / interface).

 

Anyway, the solution I have shown above should work but I'm unsure of exactly what it didn't like about having both (static and non-static) references to the same VI.

 

 


LabVIEW Champion, CLA, CLED, CTD
(blog)
Message 13 of 15
(1,062 Views)

Could it be that non-strict isn't included automatically? Still, if the other is, it shouldn't really make a difference.

/Y

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

Qestit Systems
Certified-LabVIEW-Developer
Message 14 of 15
(1,052 Views)

Sam Sharp's solution resolved my broken executable issues, and my executables all function properly now. 

 

I was looking for the reference material from which I pulled my original asynchronous call method from, with the goal of writing the author to see it corrected.  Unfortunately, my search only found this example in a LabVIEW R&D video (https://www.youtube.com/watch?v=JBYs5UPBVQs#t=15).  I know there are more, and I hope other programers don't struggle with this issue too.  

 

Thank you everyone!  

 

0 Kudos
Message 15 of 15
(1,034 Views)