Strict VI ref shows state as "running"?

[TurboPhil]

Apparently, when you use a Static VI reference and then switch it to strict, the VI in question shows its execution state as "running", which means you can't use the Run VI() method for that VI any more (even if you open a separate non-strict) reference. Is that a bug (I'm seeing this in LV2012f3), or is it expected behavior (and, if so, why?).

Background:

I have an application that calls a subvi dynamically. Originally, the subvi was launched via runtime menu option. In that shortcut menu selection user event, I would open a reference to the subvi, check its state, and run it if not already running, then open the front panel (so, if the user tries to re-run before it has stopped, it'll just open the FP). Everything was all fine and dandy with that setup until I recently added another possibility:

I added a separate subvi in the initialization states of the parent VI that would call the same subvi via Asynchronous Call By Reference Node (ACBRN) if there were specific command line arguments specified. I used the ACBRN so that I could pass the command line arguments on the connector pane. All was well and good with the new feature, until I tried doing it the old way--via the runtime menu. The existing code stopped working because it always showed the subvi with and exec.state as "Running".

What makes things more interesting is that the strict VI reference stuff is buried in a case structure, checking the commandline arguments. So, during testing, it's not even being called. But apparently, the compiler is aware of the fact that it might need to get a strict reference to the subvi, so it goes ahead and reserves it.

As far as i can tell, the only way around this particular situation is to move away from the strict reference/ACBRN entirely, and go back to the old-school way of passing in inputs via the (more brittle) control value.set() method. Since I can't seem to determine if the VI is actually running or not once I obtain (or potentially obtain) a reference to it, there's no way to do my "Don't try to run this VI if it's already running" checks otherwise. If I use ACBRN in the runtime menu event case, it will basically queue up another run of the subvi which will kick off as soon as the current run stops...

Has anybody else seen this behavior before? Any known issues/workarounds?

The attached files show a really stripped-down version of the behavior. Saved in LV2012.

[Alexander_Sobolev]

The Strict VI reference loads the VI almost as a subVI (the caller's Names property is not modified). SubVI of a running VI is considered to be a running VI even if not executing, nothing strange. 

I would advise to load into strict VI reference a blank VI - just to determine connector pane, the main VI will not be loaded until it is really loaded.

[TurboPhil]

---

@Alexander_Sobolev wrote:

The Strict VI reference loads the VI almost as a subVI (the caller's Names property is not modified). SubVI of a running VI is considered to be a running VI even if not executing, nothing strange. 

I would advise to load into strict VI reference a blank VI - just to determine connector pane, the main VI will not be loaded until it is really loaded.

---

Interesting. Not sure I understand why a strict reference would be loaded "almost as a subvi", nor do I understand your suggestion. The point of the strict VI reference (in my case, anway) is to ensure the connector pane matches. If you use a blank VI, then you don't get that benefit.

This smells more like a bug to me. Or at least a poorly documented "feature".

[CQ_Li]

Here is from the help file: 

....Use a strictly typed VI reference if you want to call the referenced VI with the Call By Reference node or the Start Asynchronous Call node. When you create a strictly typed VI reference, you cannot wire vi reference to the Run VI method. You cannot use the Run VI method to run a VI that is already reserved for execution by another VI. A strictly typed static VI reference also reserves any subVIs when a top-level VI is reserved, thus making it ineligible for the Run VI method. Refer to the Run VI method for more information...

I think that's why you get a erro says the vi is running in you test. 

[mikeporter]

I agree with you about th8s being a bug, but NI is doing all their usual handwaving trying to justify the behavior.

Mike...

[Alexander_Sobolev]

I could not open your code (I am at LV 2011), now I understand you loaded VI references only statically. When you create reference dynamically (with Open VI reference using its path or name), VI is loaded only when you call this function (or a reference is created if the VI is already loaded). When you specify type with another strict VI reference, it makes the output reference look "strict" - with determined connector pane. This type specifier VI can be blank, just with a matching connector pane. 

[mikeporter]

What you say is true, but the basic error remains. Once you load the VI (statically or dynamically) you can't just ask LV is this VI is running, because it always says yes - even when its not running. The solution is simple really: have an execution state called "Reserved for Execution".

Despite all the talk about reserved for execution and strict this and that, the behavior now is simply wrong because it returns incorrect information.

Mike...

[Alexander_Sobolev]

I do not think it is an error.

SubVIs behave similarly to Strict static referenced VIs. And monitoring each call to a subVI is a bad idea. And, after taking into account inlining, monitoring every structure is extremely bad. 

The problem can be solved.

Check state.vi monitors the state of the Called.vi

RunStrict.vi runs "Called.vi" using asynchronous call, the call moment is reflected in Check state.vi.

Edit: LV 2011 

[alex_bauer]

I know this thread is quite old, but I wanted to add something because I came across the same problem.

If you have to keep the reference in memory for some reason, the proposed Check State solution does not work. Even if the called VI is finished executing, it is reported as "Running" as long as the reference is not closed....

[mikeporter]

My but this is an old thread... The problem is that this bug is over 4 years old and I am not aware that NI has even acknowledged it. 

NI talks a lot about "A Better LabVIEW". What would really make LabVIEW "better" would be for them to fix all the stupid and obvious bugs like this one.

Mike...