Jump to content
_Y_

Self-dependency in a non-reentrant VI

Recommended Posts

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:

P4fSxmPU.gif

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

...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

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Mads

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.