DAQmx continuous sampling problem

[venky_in]

Hi,

I am experiencing similar kind of problem. I am using PXI 6225(M Series) with PXI 8106 controller and LabVIEW RT 8.2 with Daqmx 8.5 driver. I am trying to develop single VI which can continuously acquire data from DAQ card every 1ms. Sampling rate is 10K and I am trying to read 10 samples at a time in a while loop. There is no delay inside loop, so loop should run exactly at 1KHz rate but actually it is not. Loop time is varying from 0 ms to 2000ms. This is real time system so I need exactly 1000ms loop rate.

I want to achieve the loop timing based on DAQ device and dont want to use timed loop to implement this.

I have changed the "dataXfer" property option to "OnBoardMemoryNot empty" but still not seeing any difference. (Please refer attached VI). Please let me know if I am missing anything.

Thanks,

Venky

[venky_in]

Hi,

Sorry, forgot to attach the VI

Thanks,

Venky

[Jonathan_Brumley]

Hi Venky,

Continuous sample mode in NI-DAQmx is optimized for throughput, not jitter.  With Continuous, since you do NOT set the buffer size explicitly, NI-DAQmx will choose a buffer size based on your sample rate.  You can use the Buffer property mode to see what NI-DAQmx is choosing, or you can use that property mode to override the value.  Also, since your rate is reasonably fast, the driver will program the device to burst samples over in large blocks to maximize throughput.  As a side effect, this will cause relatively high latency and jitter compared with what you want.  Setting the FIFO interrupt mode to Not Empty doesn't help because that attribute only makes a difference if you are using interrupt-driven transfer.  By default, NI-DAQmx chooses DMA based transfer.

You will get much less jitter if you change the sample mode to Hardware-Timed Single Point.

You will also want to remove the call to "AvailSampPerChan", because that property will not work in HWTSP mode.  If you need to know if you are keeping up, you can instead use the "Wait for Next Sample Clock" VI after your call to Read.  That VI will tell you if your loop is running behind.  Whether or not you can keep up will depend on the speed of your RT target. 

Hope this helps,
Jonathan

[Jonathan_Brumley]

Hi Venky,

I just looked at your VI again and I have three (3) more comments (!)

1.  First of all, I noticed you are trying to update indicators inside your loop.  ("data" and "AvailSampPerChan").  With LabVIEW RT, updating indicators is not a real-time operation.  You will get all kinds of jitter if you try to do this inside your time critical loop.  If you really need to display data from every loop iteration, then you will want to us an RT FIFO to shuffle the data over to a separate non-time-critical loop that runs in the background.  For performance testing purposes, you should simply remove these indicator updates from your loop.  Doing this is MORE important than my original suggestion of switching to hardware timed single point.  However, you probably want to switch to HWTSP also.

2. With RT control loops using DAQ there is the concept of a "warmup" state.  The warmup state is usually considered to be the first N iterations of a loop (1, 10, 100, etc.) You will need your system to be able to handle some jitter while the loop is warming up.  The first iteration of the loop will be especially longer than other iterations, because DAQmx will need to allocate the output array for the Read VI.  During subsequent iterations, DAQmx will use the same array.  If you use HWTSP with Wait For Next Sample Clock, NI-DAQmx will choose a number of warmup iterations and only tell you if you are late after those warmup iterations are complete.

3. After talking with some DMA experts here in the office, I need to clarify my point about setting the FIFO (On-board memory) request condition.  When using DMA, setting the request condition DOES affect how the data is transferred to the computer.  However, setting that property does not necessarily affect how often the device will interrupt the computer to indicate progress.  Anyways, if you use Hardware-Timed Single Point, the driver should do what you want (which is to minimize latency), so you will not need to worry about this property.  If you decide to stick with Continuous instead of HWTSP, then you may want to switch to interrupts and THEN set the FIFO request condition. 

Message Edited by Jonathan Brumley on 08-16-2007 02:58 PM

[venky_in]

Hi,

Thanks for the quick reply.

Interrupt Mode : If I am changing property to "interrupt mode" than RT just hangs and nothing works.

HW timed Single point read : It is not able to transfer requested samples because sampling rate is quite high

Continuous Acq Mode : I changed DAQmx Read -> Advanced -> Wait mode property to "Poll". After this I can see data every 1ms from DAQmx Read VI. Now problem is loop jitter; 100 micro sec in every 1ms. Loop time is between 0.9 ms to 1.1 ms and not exactly 1ms.

VI has Time Critical priority with no front panel indicators update job. In controller BIOS USB and things are disabled. But still I am not able to eleminate this problem.

Please let me know if I have to do any other thing to achieve deterministic 1ms loop rate.

Thanks,

Venky

[Jonathan_Brumley]

Hi Venky,

I was able to get the attached loop to run at 1 kHz with very low jitter.  It is using Hardware Timed Single Point.  The trick was to read 1 sample (16 channels) at a time and bundle up every 10 samples into an array for further processing.  The problem with my last suggestion is that if you try to read multiple samples at a time using HW Timed Single Point, you will get a late warning when you call Wait for Next Sample Clock.  The moral of this story is that HW Timed Single Point is single point only.

Assuming it takes 30-50us to read one sample for 16 channels (using my 8176 PXI controller), all the processing of the 10 sample/16 channel 2D array will need to fit within 50-60us, so that you can loop back around and read the next sample on time.

Depending on what device and system you are using, this approach may or may not work for you.  If you are using a multiplexed data acquisition architecture like with M or E series, then you will want to consider the convert clock rate.  The convert clock rate is a tradeoff between getting a fast scan of all channels and getting adequate settling time between channels so no ghosting occurs.  You can read what DAQmx is choosing for the convert clock rate using the DAQmx Timing property node.  16/(convertClkRate) will give you the total time for your scan.  If you need the scan to be faster, you can set a faster convert clock rate, but check this out with your device hardware manual so that you ensure adequate settling time for your application.

[maxwellb]

Hi,

I think I'm experiencing a slightly different but related issue.

I'm running LabVIEW 2010 on Windows with a PCIe-6251 DAQ card. I have a control loop running at 400 Hz. I'm using Continuous timing mode. I'm using the NChan 1Samp DAQmx read to pull out a single sample at a time, which I use to time the control loop. The problem is that when I measure the execution time of DAQmx read, it sometimes reaches up to almost 4 ms when there should be a 2.5 ms sample period. I think what I'm experiencing is DAQmx optimizing throughput, not jitter, and transferring multiple samples at a time from the DAQ card's onboard memory to Windows RAM.

I realize that this application seems better suited for Hardware Timed Single Point. In fact, when I switch the timing mode of this application to HTSP, I start measuring an impressively constant (for Windows) execution time of 1.8 ms on the DAQmx read, which is more reasonable for the 2.5 ms sample period minus all of the other stuff the loop is doing.

I like Continuous mode because users occasionally ask this application to do things that it isn't quite fast enough for. In those cases, I like to be able to buffer a few samples without losing the continuity of my 400 Hz data set. Control jitter is somewhat less important than data integrity. However, I'd like to see if I can improve the jitter here.

Can anyone advise me on which of these advanced properties of DAQmx I should use in order to minimize jitter with a Continuous timing single-point acquisition on Windows? I assume that the FIFO/DMA/Interrupt properties are Real-Time only... What about that DAQmx Read -> Advanced -> Wait?

Thanks!

[crossrulz]

What is the buffer size you setup?  I'm guessing it is 1.  So what it sounds like to me is that you are hitting the DAQmx Read when the card is trying to overwrite the buffer.  In other words, you lost a sample.  That tells me that you need to work on speeding up your loop and/or increase you buffer size.  The buffer size is set with the DAQmx Timing VI.  If you set to Continuous Acquisistion, the Samples to Read is actually the buffer size.

[maxwellb]

Sorry I took forever to respond to this, been wrapped up in some other things. Anyhow, just ran in to this issue again and was able to characterize it a little better. I've attached a simple VI that I can demonstrate it with. This was with slightly different hardware. LabVIEW 2010 on Windows with a PXIe-6361 DAQ card.

I can see my problem by checking the AvailSampPerChan immediately after calling DAQmx read. At a 400 S/s rate with up to 320 channels, this value stays at 0. But if I bump up the channel count to 352, I start getting AvailSampPerChan readings jumping between 0 and 1. This indicates to me that the DAQmx driver has decided to start transferring two samples at a time instead of 1. That makes sense, but I would like to tell it not to do that somehow if possible.

Regarding buffer, I've tried using the DAQmx Buffer property node to set Input.BufSize as low as 2 (won't let me do 1) and as high as 1000 and haven't seen that affect anything.

I realize that the most straightforward solution to my problem (minimizing jitter with a single sample loop) seems like switching to Hardware Timed Single Point. However, there are some aspects of HSTP that worry me. I am able to demonstrate using this same VI that if I am running this task in HSTP mode and I fail to call DAQmx read for 30 ms, the onboard DAQ card memory gets filled up and I am forced to reinitialize my task. This worries me because I am running on Windows here and if something weird goes on in the background and holds up my DAQmx read servicing loop for 30 ms, I'd much rather just buffer up a few samples and recover (as continuous mode does) rather than have to implement something to automatically reinitialize the task with as yet unknown consequences.

[maxwellb]

I've also found out that it is very tough to get continuous sample mode to behave like this at 350 S/s. I used all of the available hardware I had to bump up the channel count to 640 and AvailSampPerChan stayed flat at 0 for a 350 S/s task.