Assynchronous call and forget Vs Run Vi with auto disconnect

[wideofthemark]

Hi,

I have been working on a project where I have several different GUI windows that are supposed to run all at the same time - along with some 'engine' vis that should run in the background.  Obviously there is a question of how to initiate these runs - and since i started learning labview a few years ago (i think before they were able to do assyc calls properly(?)) I have mostly used run vi with auto disconnect - which gives you a top level vi, which you can of course hide - or make visible - for the two different behaviours. 

I put together some libraries that use the scripting side of labview to check when things are runninng - and whether they are 'top level' or not which are useful for debugging - and for telling whether certain engines are runnning before i communicate with them.

It works quite well for the front panel case - but for background engines one obvious disadvantage is that you end up not being able to pass inputs to the vi in this case - which is a bummer - and to work around it you end up with tones of global variables which need to be set before the vi is run - and you need to have some way of it knowing 'how' it is being started etc.

Then "assynchrourous call and forget" sounds like it should allow easy passing of variables - but I've found that it acts quite differently to run and disconnect....(unless i'm mistaken). 

Basically because you have to have a strictly typed reference to start them off, it seems as far as labview is concerned, the vi that you are runnig assynchronously is 'running' as soon as the top level vi which is running it is running.  - So if you wanted to communicate with it then there would be no way of knowing whether it was ACTUALLY RUNNING, or simply waiting for the assync node to come up - or if it had finished running assynchronously, and was waiting for the top level VI to stop. 

Another odd thing is that although it doesn';t count as a top level vi - it will continue running even after the calling vi has stopped - although again there is no way of knowing from outside whether it is RUNNING or just in memory - untill it drops out of memory.

Another interesting thing is that if you run a vi twice assynchronously then it will queue up the run command - I don't think it does this with run and disconnect....

I made a small project to illustrate my point - attached.

Anyway - I guess i was wondering if anyone had experienced these issues themselves and worked ways around it?  Specifically: 

1 - Is there a way of working out if the assynchronous vi is running?

2 - is there a way of running the assynchonous VI as a top level VI - as in the disconnected case?

[DFGray]

Good object-oriented design of large projects has required the use of independently running VIs for a long time, before LabVIEW had classes.  There are a few things you can do to make your life easier.

1. Communicate to your top level VIs with queues.  This is fast as and much more controllable than using global variables.
2. When you launch a top level VI, set a queue front panel control with the value of a queue reference that it can return a response when it is up and running.  This response should be a queue reference to talk to it.  So the sequence is open the VI, set the queue reference, run it, wait on queue for response.  When done you have both VIs have send and receive queues to each other.
3. When you design your top level VIs, design in a method to stop them.  I usually use either a custom stop event (which broadcasts) or send stop commands to all top level VIs.  Your main VI can wait on a response from the other top-level VIs signalling that they are stopping before it stops.  It can then look for them in memory (you know their names) and abort them, if needed.

Good luck.  Let us know if you have more questions.

[wideofthemark]

Thanks,

I have started using a Queued State Machine type architecture for the engines - though I'm still learning about how to impliment them properly. 

From what you are saying I should use a output queue to work out if a top level VI is running or not - and input queues for communicating to them.  I am doing something like this at the moment although again i;m pretty green with it.

I guess the point i was trying to make is that it would be nice to be able to easily set initialisation data for the engines at start time. - In the queued state machine I guess you would have to start the machine up into a sortof 'standby state', wait till the command queue was available and then queue the initialisation data to it - which I guess is much more versatile than a call and forget - but for simpler scripts it would be nice to have the choice.

JP

[DFGray]

If you have a fixed set of initialization you need to do, you can certainly do this before a queue is available.  Examples would be initializing graph parameters, starting up an attached instrument, or initializing front panel controls.  All of this can be controlled in either fixed code or using initialization files, in addition to sending the data over by message (queue, event, ...).  I have used all of these methods at one time or another, and they can all work well.  You should use what makes sense for your particular application.  However, in all cases, you will have some sort of intialization state.  This could be before your state machine loop starts up or it could be a state in the state machine (recommended).

In your case, it sounds like configuration files may work well.  You will still need to generate queue references for communication, but there is no reason the VI could not read most of its start parameters from an INI file.  INI files are easy to generate and maintain and are well supported by LabVIEW.