VI state indicates VIis broken when it is not

[J_Bangasser]

I have an executable that loads other VI’s (which are not were not built into the executable) using the vi.lib/Utility/victl.llb/Preload Instrument.vi.  Then immediately after that, I use the vi.lib/Utility/victl.llb/Get Instrument State.vi to determine that the state of the VI that was just loaded.  My problem occurs when the VI state indicates that the VI is broken.  When I bring the VI up using the development version of LabVIEW, the only thing that is bad is that the VI shows the asterisk (*) at the top indicating that it wants to be saved.

 When we used LabVIEW 4.0.1 this did not occur.  My executable did not care if the VI needed to be saved, it only cared if the VI was actually broken, like missing a sub VI.

Is there anything that I can set in my .labviewrc file that would tell my executable to ignore the VI’s that just need to be saved and only yell if the VI’s are actually broken?  In my case, having a need to be saved does not truly indicate that the VI's is broken.

Please keep in mind that I am running in a Solaris 5.8 world and cannot build all my VI’s into my executable.

 Thanks,

Julia

[Dynamik]

Hi Julia,
There are a number of things that can cause the VI to be broken when loaded by the EXE, here are a few of them:
1) changed (differing) typedef used by both EXE and "plug-in"
2) changed (differing) sub-vi connector-pane of sub-vi used by both EXE and "plug-in"
3) missing dependencies (a dll might be missing on the run-time station)

For some types of errors, the broken VI will provide a detailed description of the problem. As soon as the EXE determines the VI is broken, have it open the VI's front-panel. Click on the broken-arrow and hope for a non-vague description. ;^)

Cheers.

[J_Bangasser]

Thanks for the idea about loading the "broken" VI's panel.  I tried this, but when I clicked on the broken-arrow, the dialog box reads:

"The VI is not executable.  The Full development version of LabVIEW is required."

Gee, I already know that!  It did not give me anymore information.

Another quirk to the problem is that it appears to be intermittent.  One time I pre-load a VI and it says that it is broken.  So I unload the VI and reload it, and then it is executable.  What could have changed?  It used the same VI search paths, because these are called out in our .labviewrc file.  What could be different from one run to the other?

In regards to your other reasons what can cause a VI to be broken, we do a mass compile on all our VI’s (Oh and did I mentioned that we have over 1500 of them!) on a system that has an identical operating system and setup are the one that runs the software.  This includes both the executable VI’s and the “plug-in” VI’s.  We have gone through great pains to remove any links or mounts and shield these systems from the rest of the world.  I have a good feeling the LabVIEW should know where all its sub-vi’s are and have already been saved with this information.  Finding sub-vi’s in location different from when it was compiled is the only reason that I can think of that would cause a VI to be “broken”.  I would really just like the executable to ignore the fact that a VI may need to be saved and still load it into memory.

[Dynamik]

Hi Julie,
> "The Full development version of LabVIEW is required."
> Gee, I already know that!
Doh! - sorry, well it _can_ list specific (missing) items (typedefs, dlls) which can be helpful.

> One time I pre-load a VI and it says that it is broken. > So I unload the VI and reload it, and then it is
> executable. What could have changed?

Maybe this is related to that funny-bit with type-defs where when one changes, others that contain it are "broken" until opened/saved.

I think that among all those files you may have a couple with the same name - the exe is using one, the plug-in another.

Things I'd probably try (but don't get your hopes up) are:
1) Load everything in memory then "Save with Options"\Development Distribution.
... though you're probably doing a "Mass Compile" instead of "Save With Options" because there are too many VIs to load at once or you need to maintain some complicated directory structure? Too bad, save with options would weed-out any duplicates.

2) Find a utility here on the forum that will help you list ALL the filenames in your project. Use it to list, sort, and check the hierarchy for duplicates.

3) After you've done a Mass Compile that includes the problem VI, it should open without wanting to be saved again (does it?). If so, NOW load the Main VI (the one that will become the EXE) and see if it wants to be saved. By loading the problem VI _first_, the Main VI will be forced to use VIs already in memory. If the Main VI wants to be saved, find out why.

4) Go home early.

Cheers!

[Dynamik]

Hi Julia.

      There's another LV forum-participant whos motto is (something like) "don't explain it - show it".  Good advice, I think.  In that spirit, here's a VI to search for duplicate file-names.  It's name is YARDL for "Yet Another Recursive-Descent Lister".  It includes the sort and compare logic mentioned previously.

Specify every directory-root in the Array of paths, then Run.

When/if you've discovered the answer, please post again with the solution - your experience may help many others.

Cheers.

Message Edited by Dynamik on 06-07-2006 12:00 AM