LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Asynchronous VISA Reads ?

Hi!

So. I developed two drivers, one using serial
communication, and the other using GPIB. The GPIB
device doesn't support SRQ.

I did this using VISA, which looked promising and
NI is recommending.

Both these drivers are needed together with a DAQ-
card (PCI-6031E). The card reads single scans and
feeds a bunch of PID regulators. The different
instruments are called from separate loops to
enable optimized and independend aquisition
speeds.

The problem is that whenever my VISA-drivers are
called, they will effectively kill the
performance of the system. Looking through the
VISA-manuals, my guess is that the LabVIEW VISA
Read and Write are not asynchronous?

So there's nothing to do about it? It also seems
like the "instrument-
IO events" are not supported
in LabVIEW.

To check if it could be correct, I made one of
the drivers work with the regular serial VIs. It
worked just fine.

So, should I garbage my neat VISA drivers and use
the traditional serial- and GPIB-VIs instead ???


Please tell me this can't be true. I can't have
the slow instrument control the rate of the DAQ-
card, and I need the readings from the card
continously to regulate the system.


I use NT4, single PIII, LV5.1.1, NI-DAQ 6.6, NI-
VISA 2.1. There's no "Synchronous=True" in my
labview.ini.

Best regards,
Johan Gustafsson


Sent via Deja.com http://www.deja.com/
Before you buy.
0 Kudos
Message 1 of 5
(3,578 Views)
Johan:

In article <88md0h$r31$1@nnrp1.deja.com>,
garboinindia@my-deja.com wrote:

> The problem is that whenever my VISA-drivers are
> called, they will effectively kill the
> performance of the system. Looking through the
> VISA-manuals, my guess is that the LabVIEW VISA
> Read and Write are not asynchronous?
>
> So, should I garbage my neat VISA drivers and use
> the traditional serial- and GPIB-VIs instead ???

There is a known bug in the NI-VISA 2.01 driver for Win32 that causes
excessive CPU usage on serial I/O. The new NI-VISA 2.5 driver is in
beta and should fix the problem you have seen. The particular problem
was with serial reads, which although they were async, they polled
rather than sleeping when data was not available. If you are will
ing
to try the beta, go to ftp.ni.com/support/visa/drivers/win32 and let me
know whether that works better for you. Sorry for the inconvenience,
but we are dedicated to continuously improving our VISA drivers - and I
recommend that you not "garbage" your VISA-based app.

Dan Mondrik
Senior Software Engineer, VISA
National Instruments


Sent via Deja.com http://www.deja.com/
Before you buy.
0 Kudos
Message 2 of 5
(3,579 Views)
> > The problem is that whenever my VISA-drivers are
> > called, they will effectively kill the
> > performance of the system.

> There is a known bug in the NI-VISA 2.01 driver for Win32 that causes
> excessive CPU usage on serial I/O. The new NI-VISA 2.5 driver is in
> beta and should fix the problem you have seen. The particular problem
> was with serial reads, which although they were async, they polled
> rather than sleeping when data was not available. If you are willing
> to try the beta, go to ftp.ni.com/support/visa/drivers/win32 and let
me
> know whether that works better for you. Sorry for the inconvenience,
> but we are dedicated to continuously improving our VISA drivers - and


Thank's for your fast reply.

I've tried to install the NI-VISA 2
.5 beta, but I'm not sure I was
fully successful. I still got a "National Instrument VISA" in the
Install/Uninstall (won't run an uninstall shield.

How do I find out what version of VISA that is installed?

So far I have seen no improvement in performance at all with the new
install. Putting a "syncVisa=True" in the .ini doesn't seem to have
much effect either. Multithreading is turned on

Using the old fashioned serial VIs gives just a tiny performance
decrease compared to running the DAQ loop alone. (about 20Hz)

Running the VISA read loop, pretty much stops the DAQ loop. 5 Hz, with
clear delays (stops?) when the VISA driver is executed.

I'm very confused. Is this possible, or is there something I've missed?
The driver, after initialized, flushes the serial buffer, writes a
string to the instrument, and then reads back the reply.

Best regards,
Johan Gustafsson
FFA Sweden
www.ffa.se


Sent via Deja.com http://www.deja.com/
Before you buy.
0 Kudos
Message 3 of 5
(3,566 Views)
On Mon, 21 Feb 2000 17:05:24 GMT, gnj@ffa.se wrote:

>
>> > The problem is that whenever my VISA-drivers are
>> > called, they will effectively kill the
>> > performance of the system.
>
>> There is a known bug in the NI-VISA 2.01 driver for Win32 that causes
>> excessive CPU usage on serial I/O. The new NI-VISA 2.5 driver is in
>> beta and should fix the problem you have seen. The particular problem
>> was with serial reads, which although they were async, they polled
>> rather than sleeping when data was not available. If you are willing
>> to try the beta, go to ftp.ni.com/support/visa/drivers/win32 and let
>me
>> know whether that works better for you. Sorry for the inconvenience,
>> but we are dedicated to continuously improving our VISA drivers - and
>
>
>Thank's for your fast reply.
>
>I've tried to install the NI-VISA 2.5 beta, but I'm not sure I was
>fully successful. I still got a "National Instrument VISA" in the
>Install/Uninstall (won't run an uninstall shield.
>
>How do I find out what version of VISA that is installed?
>
>So far I have seen no improvement in performance at all with the new
>install. Putting a "syncVisa=True" in the .ini doesn't seem to have
>much effect either. Multithreading is turned on
>
>Using the old fashioned serial VIs gives just a tiny performance
>decrease compared to running the DAQ loop alone. (about 20Hz)
>
>Running the VISA read loop, pretty much stops the DAQ loop. 5 Hz, with
>clear delays (stops?) when the VISA driver is executed.
>
>I'm very confused. Is this possible, or is there something I've missed?
>The driver, after initialized, flushes the serial buffer, writes a
>string to the instrument, and then reads back the reply.
I have made one experience with VISA serial reads which perhaps will
help you. If you open the VISA session each time you want to read from
the serial port and close it afterwards it will take much more time
than keeping the VISA session open for the whole program.
If you open the session at the beginning of your program and use it
for all serial reads you can speed up your program.
Perhaps this is the problem you have, I hope this will help you.
0 Kudos
Message 4 of 5
(3,566 Views)
dan.mondrik@natinst.com wrote:
>
> There is a known bug in the NI-VISA 2.01 driver for Win32 that causes
> excessive CPU usage on serial I/O. The new NI-VISA 2.5 driver is in
> beta and should fix the problem you have seen. The particular problem
> was with serial reads, which although they were async, they polled
> rather than sleeping when data was not available. If you are willing
> to try the beta, go to ftp.ni.com/support/visa/drivers/win32 and let me
> know whether that works better for you.

Good morning, Dan,

I downloaded and installed the VISA 2.5b, got the message that things
were installed successfully, but this leads to two questions:

1) Do I now find a new set of VISA vi's and replace my old ones with
them?

2) a) If so, where would th
ey be/what would they be named?

2) b) If the answer to 1) is "no" how could I confirm that the vi's have
been changed? All information I can pull up from Explorer says that I am
still working with a 2/11/99 file, whereas the files unzipped from the
zip file for 2.5b are dated 12/16/99. Also, when opening/closing a vi
using the VISA vi's, I don't get the "do you want to save this" message
which comes up every time I make the slightest change in a vi, sometimes
even when I didn't make any.

Thank you for your help

Cameron

--
Cameron Dorey
Associate Professor of Chemistry
University of Central Arkansas
Phone: 501-450-5938
camerond@mail.uca.edu
0 Kudos
Message 5 of 5
(3,566 Views)