Using Timer functions in parallel with VISA functions

[Mike_S.]

I have an application using two VISA sessions operating
in parallel controlling a LeCroy oscilloscope and a Pacific
Power Source through GPIB.

In a sub-VI, I setup the scope and put it in single acquistion
mode. Then, in the top level VI, I am reading a global variable
that detects when the scope is armed - when this flag is set, I am
using the second VISA session to control the power to the circuit
under test.

I have a while loop with a small delay (100ms) to poll the
global variable, (I also use the global value to exit the loop.)

This technique does work, although there is a 10 second delay
between the time the scope is armed for acquisition and the time
the command is recieved to turn on th
e power source.

If I take the Wait(mS) function out of the while loop, the command is
sent immediately following when the scope is armed, with no delay,
and even though I don't seem to be missing the trigger, I would prefer
just a small delay, to ensure that the scope is ready every time. Also,
from what I've read, it's not good practice to run loops without even
some small delay.

Is there a better approach to this? I hope I have expained the
problem sufficiently - any help or insight would be appreciated.

thanks,

Mike Selecky

[mikeporter]

I guess my first question would be why are you using two loops? You have a two-step process that has a natural data dependency between the steps. Why not just have it all in one process and lose the extra loop and global?Mike...

[Mike_S.]

Mike, thanks for your response.

Actually in the top level VI, I have two sub-VIs - one that handles the scope communication,
and one that handles the power source control. These are not in any loop together; rather
they both operate in parallel. The dependency that exists is from the flag from the scope
sub-VI that is transferred to the global that is read in the top level VI - this signals
when to start the power source VI in order to apply power. The VISA session for the scope
communication is still open; after the scope is triggered, I read the channel data etc.

In order to read the global in the top level VI, I have to place it in its own while loop
until it changes state - this exits the loop and signals when to apply power. The problem
I am
having, and trying to understand, is the wait(mS) function that controls the loop cycle
interval seems to be causing an excessive delay in the communication to the power source -
if the wait function is not used, and the loop is allowed to run freely, the command to the
power source is sent immediately when the global changes state - if the wait function is used
the delay is far more that the 100ms that I used - about ten seconds till the command is
finally received by the power source.

[mikeporter]

I understand the structure you're talking about, but I don't understand why they have to be in seperate loops. The flag from the scope (actually the error cluster output from the scope command function) is the data that establishes the sequentiality between the two steps. If errors are handled properly in the scope and power supply subVIs all you have to do is string the teo routines together using the error clusters and you're done.

What you want in the subVIs is to create them such that the first time they run they initialize the VISA session and store the reference to it in an uninitialized shift register. Every time after that (or until an error is detected after the command operation) the part of the code that reads or writes the instrum
ent uses the cached reference. To allow the code to stop cleanly, you might also want to include a front panel control that tells the subVI that the system is shutting down and to close the VISA session when it's done with it.

Errors propegated into a subVI containing VISA calls will essentially bypass those calls as long as all the error clusters are connected together. What actually happens is that the low-level functions abort as soon as they see the error input and simply pass the error in to their error output.

Mike...

[Jeremy Braden]

The reason for putting a wait in a loop is make the process pause every iteration to allow other processes execute. LabVIEW automatically multithreads parallel process, so a loop without a wait will even starve sister threads in the VI. To minimize the delay, you can wait zero ms.

Look in the LabVIEW help for more information about multithreading.


Jeremy Braden
National Insturments