VI Server Asynchronous VI Problems

[IEC]

Hey everyone!

I've attached some example VIs that I've been playing with, trying to understand how VI server works.  Could someone please take a quick look at them?  It's 3 counters, running at different rates, which write to global vars, these global vars are then monitored by another VI.  All of these VIs are loaded from a different VI through VI server, but I can't get them to run right.

The main "loader" VI which makes all the VI server calls is called Main, the VI which monitors the counters, and the only VI which should be seen is called CountMain.

Thanks for the help, and the extended labview development of my brain!

Jonathan

[Darren]

Hi Jonathan,

I found a few problems with your VI.  The first is that all the paths to the VIs you're calling dynamically need the ".vi" extension on them...remember that when opening a VI reference, the path you specify needs to be the exact file path (including the file extension) to the VI on disk.  Next, I noticed that you have "Wait Until Done" on the "Main" VI set to True.  With this option set, you will never get to the FP.Open property, because the "Run VI" method will be waiting until the VI is finished, which will never happen if you don't have the panel showing so you can click the stop button.  Here are a few other general suggestions to help you along:

1.  I would recommend using error IO on the nodes to dictate the program flow instead of a Sequence Structure.  In this way, your code is more readable, and you can find out about any errors that occur on your nodes when debugging problems.

2.  You could have diagnosed the original problem by using Execution Highlighting on your VI...it would have shown you that there were errors on the Open VI Reference nodes because you had the paths specified incorrectly...you would have also seen that the VI was stuck on the Run VI method in the final sequence frame.

I hope these suggestions help.  Good luck with your application!

-D

[IEC]

Darren,

Thanks for the reply... it definately helped.  One question though about your reply, you said to use the error wiring to dictate the program flow...  though the error wiring is useful, won't it actually eat up more system resources and slow down the program?

I working on optimizing the speed of an imaging application I have developed, speed is everything.  This little program was just a tester to get my feet wet in VI server, but when it comes to the final product I need to do everything I can to make the application run faster.  The basic idea is I want to use VI server to have a data acq. subVI running in the background which will do nothing but read and write to gpib (pulling float values off two sr830 lockin amplifiers), then the values it gets are put into globals, another subVI telling an rs232 device to perform a function, etc... the main user interface will read these globals and display them in some fashion or another. 

Any general ideas on how to speed up a program which does such?

Thanks,

Jonathan

[Darren]

Hi Jonathan,

Using the error terminals of subVIs and functions is an extremely common way to enforce dataflow in LabVIEW.  There are no "performance issues" associated with this technique.  Perhaps you are thinking of situations where you might want to run code in parallel...obviously you can't have parallel code linked by error wires, but in your example VI, the code certainly was not running in parallel, since you were using a Sequence Structure.  Nor does your code have any real need to run in parallel, at least the way it is currently written.

Hope this helps,

-D