Hi,
I'd like to clarify a few things about the "blocking" behavior of the Read
vis (the same rules also apply to the rest of DAQmx).
- One of the main problems with the blocking behavior in Traditional DAQ
was that you could not do other operations while you were waiting in the
AI.Read.vi for samples to become available. This was due to the single
threaded model of the Traditional DAQ driver and the fact the Traditional
DAQ used CINs (though they were replaced by DLLs in NI-DAQ 6.x)
DAQmx if fully multithreaded and does not have this limitation. For
example, you can run two versions of your "cont&graph.vi" example
simultaneously (on different devices) w/o problems. Alternately, if you
have two parallel while loops in a VI with a Read.vi in one of them, the
other while loop will not be slowed down while the Read vi is waiting for
samples to become available.
- Scott's "non-blocking AI. Read vi" in Traditional DAQ works by waiting
for the requested number of samples to become available before calling the
Read.vi.
DAQmx supports this feature natively when "-1" is wired into the "number
of samples per channel" parameter on the DAQmx Read vis for continuous
acquisitions. Here is the online documentation for this parameter.
number of samples per channel specifies the number of samples to read. If
you leave this input unwired or set it to -1, NI-DAQmx determines how many
samples to read based on if the task acquires samples continuously or
acquires a finite number of samples.
If the task acquires samples continuously and you set this input to -1,
this VI reads all the samples currently available in the buffer.
If the task acquires a finite number of samples and you set this input to
-1, the VI waits for the task to acquire all requested samples, then reads
those samples. If you set the Read All Available Data property to TRUE,
the VI reads the samples currently available in the buffer and does not
wait for the task to acquire all requested samples.
Regards,
Rajesh Vaidya
Measurements Infrastructure Group
National Instruments
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Subject: Re: DAQmx, etc.
From: "Scott Hannahs" <[EMAIL PROTECTED]>
Date: Tue, 18 May 2004 15:16:16 -0400
At 10:24 -0700 5/18/04, tim wen wrote:
>In LV6 the 'AI read.vi' hogs the CPU waiting for the number of samples
requested to be available.
>someone (sorry for not remembering the name) came up with a 'non-blocking
AI read.vi' which i have
>been using happily.
>i noticed the new DAQmx 'cont&graph.vi' is hogging the CPU also. is there
a cure for it ( i think it makes
>DLL calls)?
One version is at <http://sthmac.magnet.fsu.edu/labview> in the VI library.
I think there are a number of these around. I have not updated it for
DAQmx since it is not available for my development platform. :-(
I don't know if it would be a simple modification to make it work with
DAQmx. It is a fairly simple concept and not too complicated code.
>another question: i've been using LV2 style globals to pass data between
parallel loops
>and am wondering if a queue is a better way to go?
Probably. If you are just passing data in one direction it can work well.
With a LV2 style global you can build in internal processing and value
manipulation to the global (ie intelligent global).
-Scott
