LabVIEW
Dynamic call VIs biuld
We need to see the code. I'm guessing you have paths setup to open a reference to a VI but the path in the EXE isn't the same as from source. The solution to this is to not use the VI path at all and to reference it by name, and ensure it is in memory using a static VI reference. Here is an example that was posted a while ago as a way to get away from the VI Templates method, which was popular in the 7.x era of LabVIEW when trying to do this type of thing.
@pawhan11 wrote:What is the diffrence between using static reference and add vi to always included during build?
Well one is better, and the other is always include 
After re-reading your issue I think the static VI reference is not the solution for you. Still here is my explaination on what the usage of the static VI reference is, then I'll mention why it isn't right for you. The last paragraph where I mentione debugging an EXE is probably what you need to try.
To me having to remember to add the always include is an extra step that I (or someone who is going to replace me) might not know is required. Using the static VI reference you are telling LabVIEW this VI is a dependencies, and needs to be included, just like all other VIs in the application. Then using that you can read the VI name (or path) and use that instead of having another link to code that might not be obvious. If I were to rename the VI, move it on disk, or add another VI to be included, then other things need to be changed. That could be updating text for the VI name as a string constant somewhere, updating the path to the VI (which can be semi-arbitrary and change between versions of LabVIEW), and need to add the always include. If you use the static VI reference there is far less issues that could come up which make it just not work. If I rename the VI, change the path, or add new VIs to include the only thing I need to do is have a static VI reference to it, where the VI name is returned as a property node. No need to update string/path constants, and no need to add the always include. It's more modular, and more simple.
@pawhan11 wrote:Path to vi is correct both in development and in exe.
This is the most common mistake when this type of error comes up, how do you know the path is correct? It isn't working so it is possible the path isn't correct.
@pawhan11 wrote:
As I understand static call will place this dynamic vi in memory during build. So when I edit this dynamic vi on disk what will exe do?
Oh, okay that wasn't clear before. With the technique I describe LabVIEW will include a copy of the VI specified in the static VI reference, and it won't use the one from disk. In these types of situations I usually turn the code into an EXE but enable debugging so I can probe around and see why it is breaking.
http://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/debug_apps_dlls/
thanks for fast reply.
Path is correct because I checked that in debugging. I get error 1003 that says that this vi is broken ( no more details in error) so I think something from inside is missing.
Static reference works but after that my vi is no longer dynamic... It is the same as placing this vi in false case structure that never executes and then just calling it by name. So after I make changes in dynamic vi on disk it will run according to that one compiled in exe?
AIf I understand correctly dynamic vi will run if all its components and functions are known to EXE. If i edit and make small changes to dynamic vi like changing constant and so on EXE will still run it.
