Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

How fast can one data point be acquired and sent?

Hi heavily loaded,

Sorry for the confusion.  You stated your loop rate properly, I just misread it.

  1. Loop rates will be system dependent, but the 2000 loops/second seems to be on the higher end for a non-RT OS.
  2. When you do feedback you will need to do that one sample at a time.
  3. The NI Tech is right.  You can make your non-RT OS more deterministic by using a Timed Loop.  However there is a trade-off between speed vs. determinism and you can learn more about that here:
    KnowledgeBase: Why is a Timed Loop Slower Than a Regular While Loop in LabVIEW 7.1?
  4. You may be able to look into a PXI system.  Since the hardware is dedicated you should be able to get the rates you are looking for.  On a PC, the max rate you could ever hope for (even with all of the tricks and no Front Panel updates) is maybe 5000 loops/second. 

    However for PXI, you can get much faster with a RT controller (up to about 40,000 loops/second).
    PID Loop Performance Guidelines for LabVIEW Real-Time on a PXI-8176 Target

    If you wanted to go even faster though, you could get an FPGA and get rates between 100,000 - 200,000 loops/second. 
    http://www.ni.com/fpga/


0 Kudos
Message 11 of 12
(780 Views)
2. When you do feedback you will need to do that one sample at a time.
I'd agree that the most typical implementation of feedback control is one sample at a time using a deterministic OS.  However, there are some other possibilities that can work "good enough", though this also depends very much on the system under control.
 
1. Timed Loops can be set up to use a data acq sampling clock signal as a timing source, and can thus be configured to operate at several kHz.  It still won't be entirely deterministic under Windows, but it'll very likely be more consistent than using a standard While loop.
 
2. You can configure your data acq task for continuous sampling.  One neat trick is that you can specifically request to read the most recent sample(s) already available in the buffer.  Then you are never waiting for new data to arrive.  If you want to get fancier, you can detect when the Timed Loop starts late, and perhaps do something special to try to compensate.  The "right" special thing would again be very system-dependent.
   One example of reading multiple samples:  configure an AI task that samples at 20 kHz.  Use the sample clock as a timing source for a timed loop that runs once per 10 ticks, i.e., 2 kHz.  On each iteration of the loop, read the most recent 10-20 samples and do whatever fancy filtering, weighted averaging, integration, etc. you need to do.  (Derivative calcs for PID control are greately helped by having multiple samples).  Then Calculate and generate an output. 
    A key principle is that it IS possible to use buffered input tasks to capture high-freq sensor info, while updating the output control signal at a lower rate.  The feedback sample rate does not need to be equal to the control signal update rate.
 
3.  The output probably still needs to be created in immediate mode, one sample at a time. 
 
4.  20 kHz output update rate probably won't be achievable on a Windows PC.
 
-Kevin P.
CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 12 of 12
(774 Views)