Exec.State and Start Asynchronous Call

[mq17]

Norbert,

that is correct. I thought of some notifier or NSV solution before and will probably implement it because I need information if the VI is "really" running. However I first searched for an easy solution inside the VI propertys only to stumble over the behaviour of the Exec.State property.

Matthias

[Yamaeda]

From your description it starts to sound more like your _dont_ want an asynchronous call. Then you'd only ever have 1 instance running, the same if you dont use 0x80 flag (maybe 0x100 fits better).

If the issue is that the call would pause the state machine it can be solved with the 0x100 or running a "spawner"-vi which you start asynchronously but which runs it's selected vi synchone.

/Y

[mq17]

Y,

I need the asynchronous function because the main application consists only of several buttons that start other parts of the program that can also work standalone. And since some of the other parts, like the measuring module, can only run in one instance the main application has to ensure that. Of course LabVIEW will not open another instance of a non-reentrant VI when I click the appropriate button but as soon as I close the called VI it will reappear because LV has serialized the call. I doubt that 0x100 would anything change in that behaviour. Well, I could check Wait On Asynchronous Call Node with a timeout setting in a loop to detect if the called VI was closed in between, but that is just another workaround.

In prior versions of LV (when the asynchronous call was not yet invented) I used the following construct with success. Asynchronous call seemed to be just a progress in comfort.

Matthias

[Norbert_B]

Matthias,

you can create a continuous running measurement module passing data using queues to all "consumers". So it is valid to think of the module as "internal service", where clients connect, give instructions on desired functions/data and get that back after the service finished handling this.

Norbert

[mq17]

Nobert,

I do that already, but I don't want the measuring module to be a part of the central module. So I need a way to start it from the central module when it is needed, either by an operator action or a program action. That is the reason why I need to know if it is already running. And since the Exec.State property in the typefied version does not provide me with that information I'll stay with my first workaround.

Thanks for all your efforts

Matthias

[drjdpowell]

What we need is an "Async Call with Timeout" function.  Would solve these issues in a much more robust and clean way than testing the reference.