Self-dependency in a non-reentrant VI

[_Y_]

I try to build an executable out of a program that is fully functional under the development environment (LabVIEW 2011, Linux). The executable complains that one of asynchronously launched VIs is bad because one of its components cannot be found. The VI does not invoke any sub-VI dynamically.

To identify the problematic sub-VI, I use the following code:

A new executable was build including this code and the VI under investigation. A run results in the following error:

Possible reason(s):

LabVIEW: File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for the operating system. For example, use \ as path separators on Windows, : on Mac OS X, and / on Linux. Verify that the path is correct using the command prompt or file explorer.

VI Path: /opt/***/Builds/Debugg/Debugg_GetDependencies/SubVIs/*** - Plots & Parameters.vi/0

Built Application or Shared Library (DLL): Make sure all dynamically loaded VIs were properly included in the build specification for the application or shared library.

LabVIEW Real-Time: VIs built into executables cannot be accessed through VI Server calls. Use Source Distributions to dynamically call VIs on Real-Time targets.

/opt/***/Builds/Debugg/Debugg_GetDependencies/SubVIs/*** - Plots & Parameters.vi/0

The same mysterious path is indicated in the indicator "Array" with Execution State “Bad”. The corresponding name in the indicator “Dependency Names” is “*** - Plots & Parameters.vi:Instance:0”.

So, I tried to run the same debugging code under LabVIEW development environment and got the same error (while the program works without any complains under LabVIEW).

What could be the reason? Had any of you solved such a problem?

Thank you

[Mads]

As the error says; the path is not valid, and even if it was fixed, you are not allowed to dynamically call VIs included in the application file this way, so you need to put it in an external folder and generate the path to that location.

However, if you do not need the VI to be replaceable after the build then you could also just load it into memory by including it in a case structure where it will not be called. Put it e.g. in a true-case and wire a boolean control set to false to the case selector (before 2011 you could have used a false constant, but now such unused cases will be stripped out by the compiler, with a control they are not).

With the VI forced into memory like this you can call it dynamically by wiring the name of the VI as a string to the Open VI function.

[Mellroth]

...you could also just load it into memory by including it in a case structure where it will not be called. Put it e.g. in a true-case and wire a boolean control set to false to the case selector...

In recent LabVIEW versions I usually recommend using Static VI references instead.

/J

[_Y_]

Mads, thanks for the reply but I do not get its relevance to my question. The VI itself is found and can be called. But, seems, it try to find something else that is reported in the path list as

VI_path/VI_name.vi/0 and in the list of names as VI_name.vi:Instance:0. The VI is non-reentrant, thus no instances are expected.

By the way, the project contains several VI that are invoked in the same way and have exactly the same settings. All other similar VIs work problem-free.

[Mads]

If it's there as you say; Have you tried to open the front panel of the VI with an invoke node in the built application? If you do that you can hit the broken run-button on it (as long as the front panel was included) - and it will tell you why it cannot run. That's often the quickest way to troubleshoot dynamic VIs that refuse to run in the built app.If nothing else the feedback you get this way is quick and typically verbose.

Have you tried copying the code and saving it in a VI with another name - and calling that one?

Edited November 23, 2012 by Mads

[JamesMc86]

Another thing to look for, are you calling any express VIs? I don't know the reason behind it but when you monitor VIs on an RT target they show as a clone of the main VI, I presume the same must go for the main environment