Why is my VI Bad?

[SteveChandler]

I open a VI with VI Server and the execution state is "bad". Is there any way to find out why it is bad? I can open this VI directly and it is ok and will run fine.

[Yair]

The only thing I know of which can cause that state is if the VI is broken (although it's quite possible there are other causes). My guess would be a missing subVI or typedef. If you have a reference to the VI then you can presumably use that to open its FP or BD to get a more detailed message (if it's an EXE then presumably you would need to make sure these aren't stripped).

[SteveChandler]

Some more details: I have a main application that loads one of several VIs into a subpanel. Everything works if I run the main application from the development environment. If I build the main application standalone then the application state of the VI I want to load is bad. That VI is built as a source distribution and I can open it without errors either directly from LabVIEW or from my main application if the main application is not running standalone.

Instead of loading it into a subpanel I took your advice and just called FP open. Sure enough there is a broken run arrow. But if I click on the run arrow I get a dialog that says "VI has an error of type 302208. The full development version of LabVIEW is required to fix the errors." But there are no errors in the full development version.

I am in the process of elimination right now. Fortunately the VI is simple enough that I can recreate it in stages to find out what is breaking it. Once I find the problem it will likely be obvious and I will tell myself "Duh! You can't do that!". But surely there must be a more efficient troubleshooting method for these situations.

[iwire]

Hi Steve,

In order to help troubleshoot these kinds of dependency-issues with dynamic calls, it can be useful to open the FP of all a VI's broken sub_VIs. I typically check for errors when loading the dynamic VI, and if the open throws an error, then call an "OpenBroken.vi" (passing it the VI path) which does a recursive traversal of the broken VI and its dependencies - opening only the broken dependencies. The deepest (broken) VI is the last opened - just click on the broken-arrow...

This method doesn't necessarily yield a better/good/more-helpful error message - in fact it's success rate is probably less than 50%. But when it does work, it saves so much debug time as to be well worth the investment!

I'm at home and didn't have access to this tool, so built&tested it again. (in other words, i think it will work...)

Luck/Cheers.

Util.VI.OpenBroken.vi

[jgcode]

Are you using Classes and/or X-Controls?

[ShaunR]

Try unchecking "Remove Polymorphic Instances" and verify that you have no broken VIs in disabled structures.

[jgcode]

Are u using DSC?

[SteveChandler]

I am using classes - no XControls. I tried unchecking Remove Polymorphic Instances and that did not help. I don't have any disable structures. Also I am not using DSC.

Why is everyone's avatar all messed up? Is it just my eyes after writing LabVIEW all day?

[ShaunR]

Why is everyone's avatar all messed up? Is it just my eyes after writing LabVIEW all day?

JG always looks like that

[jgcode]

JG always looks like that

A fridge fell on my head when I was a kid - cut me some slack!!

[Yair]

That VI is built as a source distribution

My guess would be a vi.lib or user.lib VI, as those don't get included automatically in a source distribution. I would start by unchecking the exclusion boxes in the build spec. Of course, then you will probably get some conflicts, because you will have the same VI more than once, but you can either ignore that or use a library to wrap everything in the distribution in its own namespace.

[jgcode]

I am using classes

I have had issues with Classes before and the way I debugged the build was by doing the following:

Create a new VI and drop a class constant on the BD.

Create a new build spec for this VI.

Cycle through checking all Classes until you find an issue.

Sometimes it's been a 'dirty' VI I just cut and pasted into a new one that fixed it, other times it's been some run time environment issue (e.g. with X control). Sometimes with I have gotten a better error message from LabVIEW too using this method.

If you have hierarchy of Classes (e.g. composition) you can find the issue and work down.

Either way, if you track down the issue please post it.

[Tim_S]

Have you tried setting the "Enable Debugging" flag in the build specification? This lets you put breakpoints and lets you watch code execution in the executable or DLL (using the Operate->Debug Application or Shared Library menu option). Your executable won't run quite like it will without the option turned on, but it helps with the kind of thing you're describing.

Tim

[jgcode]

Have you tried setting the "Enable Debugging" flag

I have found that this setting can 'fix' the issue I.e. Broken VIs are not longer broken. As it must be different to the Run Time Environment.

[Mark Smith]

One common problem that can cause this sort of thing is that a VI that is loaded dynamically might need its front panel (like when you need to set the control value thru VI Server). If you enable debugging for the built app and all of a sudden it works, this might be the problem since the debug build will retain the FP's where the standard build removes all except the Top Level VIs. Wait - I see you load the subVI as a source distribution - that makes this unlikely.

Probably, this is because the dynamically called VI can't find one of it's dependencies. Sometimes I just give up and include everything but the kitchen sink in the build dependencies just to get it to run and then start removing components until it fails. Not very much fun but it usually works.

But I feel your pain - this is one of the biggest PITAs that I encounter. You get a broken app and absolutely no help from the error message.

Mark

[Tim_S]

I have found that this setting can 'fix' the issue I.e. Broken VIs are not longer broken. As it must be different to the Run Time Environment.

I have to agree with Mark: have you put the offending subVI in "always include" section? Another thought is to go into the Source File Settings and navigate to your subVI; from there you can change if the block diagrams get stripped, window appearance, execution, etc.

Tim

[Jon Kokott]

You are opening a VI using VI server, so the VI must not be reserved in the hierarchy allready. Make sure that you do not have a strictly typed VI reference (of the VI you are trying to load.) in any vi within the application space.

~Jon

edit:

I think that this also means that you cannot have the VI in the hierarchy set to "Reload for each Call" or "Load and retain on first Call" I believe that those will reserve the VI as well. for some reason I don't think that Load with callers reserves it but I'd have to double check that.

Edited August 16, 2011 by Jon Kokott

[Aristos Queue]

I can think of one difference: When you open a VI in the dev environment, LV will automatically search for any missing subVIs. When you open using VI Server, by default, LV will not search for missing subVIs. You have to put a specific flag on the Open VI Reference to make it search. If LV started the search and found the missing VI almost instantaneously, you might not ever see that in the load progress dialog.

That's my contribution for today. Others have given you other good ideas to try.

[SteveChandler]

Thanks everyone for the replies. It is working now.

I am kind of frustrated because I don't know what the problem was. I rebuilt the VI from scratch and tested it in steps. I completed that and it still worked. I then cut and pasted the block diagram from the old VI into a new one and that worked as well. Unfortunately I saved the old VI and no longer have a broken one to investigate. This means I will be left with the icky feeling of never knowing what the problem was.