prefered execution system

[falkpl]

I have developed a user interface (GUI) which is event driven to control 7-10 autonomous subsystems.  Each system runs in their own thread and are essentially queued state machines with a timeout condition.  The subsystems are launched from the main vi prior to the main going into a a user-event loop.  Each subsystem will run autonomously (next state is self-determined if the queue timeout occurs) unless it receives a command via the shared queue from the toplevel event driven loop.  This works great when I make the subsystem vi run as a reenterant (so it will launch in its own thread (loop).  The problem is that I want to move this launch event inside of the event loop (which will be called from the custom dynamic "initialize all subsystems" or a "reset sub-system" event.  When I do this the vi is no-longer parallel and the event freezes and waits for the subsystem to return.  Do I have to launch the sub-systems dynamically? Can I force a subvi to run in its own thread without dynamic vi calls?  What is the effect of changing the execution system (is this problematic?)

Paul

[davidpcl]

Hi Paul, I would really seriously advise you to kick off your .vi's using the dynamic method - it may seem a bit more complicated than just calling a subvi but it will make you system eminently more scalable, and also will allow you to update the subsystems without interferring with the main vi. NI refers to this kind of architecture as a 'plug-in'.

There should be a decent amount of documentation about how to do this - although from what you've said you probably already know how to, but any extra help on using plug-ins - give me a shout.

Dave C

[falkpl]

I had some trouble with doing the dynamic approach because for some reason the subsystems always loaded in the run state even when I unchecked the run on load.  I wanted to load all the subsystems and then run them from the invoke node, this way a could call them asynchronously, but it didnt work.  I know this can be done since I have done plug-in architecture many times, just couldn't getting it working here, I did get a non dynamic approach to work but it did complicate the diagram unnecessarily.

Paul

[davidpcl]

Major bummer you couldn't get it working. I've just had a crack at doing a dynamic sub vi and it seems to work OK - you've probably used the same method so I'm probably just telling you stuff you already know, but I've attached them anyway. Just put them in the same directory and change the dynamic vi's path.

[shoneill]

I've done this before too,

I used to load the VI via VI server by getting a reference to the VI while entering it's path.  This opens the VI in non-run mode.  You can then set any start values for the process (if needed - my system used a template for 8+ otherwise identical channels) using "Set values" or via Queues if you've programmed the sub-vi this way.  Once all this is done, you can set the VI to run, also via VI server.

I appreciate that you can be more flexible with Queues, and my code tends to move in this direction, but getting the reference via VI server remains my choice because I can choose to run the VI whenever I like.

Hope this helps,

Shane.

[falkpl]

I need it for LV 7.0.  Thanks

[davidpcl]

In Labview 7

[falkpl]

Thanks I see what I am doing, I was using the invoke which was running the vi, I have to use the RUNVI since the subsystems are invoked asynchronously.  To set the values of the subvi I should open a reference, set the values of the input parameters using the set value, then call the the runvi with the wait until done as false to allow for the asynchronous execution in a new thread.  Thanks for all the help.  I will give this modification a try today.

Paul

[falkpl]

OK got it all working great now.  Learn something new each day, the main bug I had is for some reason when I call open vi if I wire the

type specifier input then I get a running vi when it is opened, dont know why.  when I dont wire this input it works fine (loads in an idle state).  Anyone know why this is the case?  I find the flatening to string interface to be a little akward when using strict type def controls.  Why cant I use a call be reference node, pass the vi reference to this node, and specify to call the reference vi asynchronously?  This work around works but is lots of work and the code can be broken by as simple as a control name change (which will alter the set control value nodes in the vi server).

Paul

[shoneill]

Paul, you can also send the values via QUEUE.  This requires a bit more processing on the client side, but is probably more robust.

You can use named queues.  I find using the name of the newly created VI is quite useful.  This information is available to both client and server (Via reference).

You can then implement an initialisation function and a run function via QUEUE.

Thus the names of the controls remain private.

Hope this helps

Shane.