Exec.State and Start Asynchronous Call

[mq17]

In my application I like to start a VI asynchronously by pressing a button control. I just want to have one instance of the VI running so I let the caller test if the VI is already running. Unfortunately there seems to be a bug in the Exec.State property if you use it with a VI reference that has been built with a type specifier. It returns always "Running" as state.

I found a workaround by first openening a "normal" reference to the VI, questioning the Exec.State property, closing the reference and opening the "typed" reference. That works like I think it should.

My question: Is this difference in behaviour of the "VI" property node and the "VI Interface Type 1" property node by design or is this a bug in LV 2012 (I have not tested it with another version) ?

Matthias

[AndreasKr]

Hi Matthias,

i understand your problem. I already tried it at my machine. I could reproduce it. The property node always returns "running". 

He have to look into that in detail. 

Could you please send me all infos of your system. 

Which LabVIEW Version do you use. How is Your machine set up?

XP? Win7? Bit?

Could you please make a post wich all infos. 

When i will look into that with a colleague. 

Thanks a lot

Andreas K

NI Austria. 

[Yamaeda]

Another workaround is to store the VI ref and check if it's valid before opening a new one.

/Y

[Norbert_B]

I just wanted to point out about the very reason of the situation:

These are the options you can read by the Execution State property. As already marked, "Running" indicates that the VI is (at least) reserved for execcution. It does not necessarily mean that the VI is actually executing!

That being said, opening a typified reference to the VI already reserves the VI for running, hence your property node returns this value.

Your workaround seems to be well-thought out and should work in any case. Y already gave another option of handling this situation.

I doubt that there is another, better solution other to these two.

Norbert

[mq17]

Hi all,

thank you for your answers. Norberts explanation seems to be plausible although I cannot find the information in the help file. Maybe NI should put a remark into the help file.

@Y: This solution works only once since the calling VI has no immediate means to detect if the called VI was closed in the meantime. The reference stays valid as long as the calling VI is running.

Thanks

Matthias

[Norbert_B]

Matthias,

Y refers to common architecture where references are hold in uninitialized shift registers. When closing the reference, you should make sure that the shift register is re-initialized to an empty reference.

The you can check with "Not a RefNum" if the VI has already been closed or not.

Remark: "Closed" is a bad term here as it does not necessarily mean "Unloaded".....

Norbert

EDIT: I just made a screenshot of the property "Exec.State" from the LV 2013 help. There is no further detailed information in there other to this box which indicates that reservation is already sufficient for the property to return "running".....

[Yamaeda]

You could check for VI's in memory, although it's a rather slow function.

/Y

[Norbert_B]

---

@Yamaeda wrote:

You could check for VI's in memory, although it's a rather slow function.

/Y

---

This could result in unexpected behavior if working with reentrant VIs and multiple spawns....

Norbert

[mq17]

Norbert,

I did understand Y's approach, but in the case of an asynchronous call the called VI is probably not closed by the caller but by a button in itself. This does not influence the reference in the calling VI. The other way is also true: closing the reference will not stop the called VI. If I close the reference in the calling VI like in example "Call and forget" and put in an empty reference the next attempt to call the VI will not fail and there will be either a parallel (reentrant) or serialized instance.

Matthias

[Norbert_B]

Matthias,

you are correct as call and forget (0x80) passes the reference lifetime to the instance itself.

So it seems you want to ensure that only a single process is spawned. Correct?

What about a workaround keeping a "life" signal in the caller which is reset by the instance itself when shutting down?

Norbert