broken VI, but is good when opened

[Jessica.Badowski]

I have some VI's that I call from a Teststand sequence. When I try to run the test sequence I get an error about a broken VI.

When I open the VI, it does not appear as broken. How do I track down the cause of this error? I am attaching the log file.

[paul_cardinale]

Sometimes TestStand is finicky about things in Diagram Disable structures.  A broken or missing VI inside a disabled case won't break the VI, but TS might not like it.

[Gregory]

Are you using multiple LabVIEW runtime engines?
Do you have the VI set to separate compiled from source code?

[JÞB]

Attach the vi

Inspect it for VI Properties>>General>>Source Version. What is the value? 

[Jessica.Badowski]

Nothing broken inside a diagram disable.

My runtime is set to autodetect, which should be 2020 as that's the only version I use.

I don't separate the compiled from source.

Source Version is 20.

I noticed my PC was using 2020 SP1 and the deploy system had just 2020, so I tried installing 2020 on my PC, recompiled, same problem.

I'll attach the file TestCurrentPulse.vi and the subVI, GraphImageString.vi. All the other subVIs should be in standard libraries.

It takes an array of waveforms, picks out the one of interest, triggers on a threshold, trims to specified length, measures peak and mean of waveform and returns those along with the base64 PNG of the graph to include in report. nothing too complex I think.

Since the error claims the VI is broken, I expected to see the run button reflect that when I opened the VI, however it shows the normal run icon. 

I can mass-compile my whole project folder and the error goes away, but when I deploy a new version of my test project, the error will come back and will require compile again. I don't want the end user to have to start mass-compiles so I need to find the root cause.

[XM43]

Hi Jessica,

Something similar happened to me but on a Real Time VI that I had. It was a small VI all looked good when opened but still had a broken arrow in it which would show up randomly. I tried the following and it temporarily fixed the issue:

1) CTRL + A

2) CTRL + U

and the broken arrow went away. It happened to me a handful times on random days until I replaced the VI with its content on the block diagram. But for the meanwhile, this was my fix.

[rwunderl]

I had a similar error when trying to dynamically run a vi inside a Packed Project Library from a compiled executable launcher. The launcher threw an error saying the vi was broken and to use the development environment to debug the vi. Trouble was that when opening the very same vi from the PPL using the development environment, the vi was not broken!

Turns out these two situations were actually quite different. Yes, the vi was not broken and compiled into a PPL from the development environment just fine. However, when dynamically loaded from an executable, the vi must now run using resources from the run-time engine and not from the development environment.

The fix was to enable support for the Datalogging and Supervisory Control (DSC) module in the executable’s build specification. This added the required dependencies to the exe that were not included in base LabVIEW (since DSC is an addon with a separate license).

I realize this may not be your exact issue, but it is a thought that perhaps when TestStand (an executable) calls your vi that there may be some dependencies that are missing from the run-time engine that are present in the development environment. Check to see if you are using any special toolkits that require deployment licenses or run-time support.

[Jessica.Badowski]

Interesting. I'm not using PPLs, just a directory of VIs. I'm also not using any toolkits.

I did get a list of all the subVIs and verified that all the dependencies exist and are in the same location on the destination computer. I don't see how the runtime engine would have trouble finding them.

I think I had trouble with libraries in the past but I can't remember what it was. It may be worth trying again to ensure all the dependencies included with my program.

[JÞB]

One more trick.  Look at the callees of the offending VIs. Do any of them have a non-default load option?  Load with callers is the right thing to do for TestStand but, if something is set to Load when called or Load and retain on first call, you might see TestStand getting confused because the callee is not in memory when the caller is first loaded and idle.

You could script a quick test for the load option settings of all project items.

[Matti_Zimmer]

I have had issues using maleable VIs (vim, the red ones): Placing one of these in my VIs worked fine in development environment, but building an executable led to a not working VI. Took me some time to find this. Everything works fine building an executable from VIs in a lvlib, my case not working uses the vim in a VI which is part of a lvclass (which itself inherits from a class in a PPL).

My conclusion is to avoid using vims.