Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

How does the DAQmxBase Analog 2D DBL NChan NSamp VI work?

I have a BNC-2110 DAQ board and I'm trying to read data from multiple input channels as real-time as possible. I'm using the DAQmxBase Analog 2D DBL NChan NSamp VI, which seems to collect the data extremely fast when I enter multiple channel names into the VISA input control. I have a couple of questions:
1. How does the DAQmxBase VI work? Does it acquire the given number of samples from one channel and then move to the next? Does it alternate taking samples between the 2 channels? Does it sample all the channels simultaneously?
2. Is there a better method for acquiring data from multiple channels?
3. When I give it a # of samples (e.g. 10000 at a sample rate 10^5 Hz), it only returns some (~7000) of the samples. What am I doing wrong?

Thanks,
Stefano
0 Kudos
Message 1 of 15
(5,753 Views)
Hi Stefano-

The BNC-2110 is just a breakout accessory. Which actual DAQ board are you using? Which O/S?

The DAQmx Base example you seem to be working with is Cont Acq&Graph Voltage-Analog SW Trigger.vi. This example continuously buffers data in the background from all channels you specify in the Physical Channel control. This hardware-timed operation samples all channels in a "round robin" pattern; this means that you take one sample from each channel in the list in the specified order and at the specified rate so there is correlation between the samples taken on different channels.

The "DAQmxBaseAnalog2DDBLNChanNSamp" VI then reads samples from the buffer in a 2D array format. This is the absolute best and most reliable method to acquire samples from multiple channels because it is hardware-timed and offers correlated readings between multiple channels.

The reason you're probably receiving only 7000 samples is that your trigger is not occurring until ~3000 samples have been acquired. As you can see from the program structure samples are only written to the Waveform Graph after a trigger condition has been met. If you would like to acquire samples continuously and display the full requested sample count with each iteration I would suggest the example "Cont Acq&Graph Voltage-Int Clk.vi" found in the "C:\Program Files\National Instruments\LabVIEW 7.1\examples\daqmxbase\Dynamic\ai" folder of your hard drive.

Please let us know if you have any additional questions.


Thanks-
Tom W
National Instruments
0 Kudos
Message 2 of 15
(5,737 Views)
I'm not sure I understand exactly what you mean by the "round-robin". Let's say I have a sample rate of 1000 Hz and I take 100 samples from 2 channels. This is how I understand it: The trigger hits at t=0 and I get my first sample from CH1. A thousandth of a second later I get a sample from CH2. At t=.002 I get my second sample from CH1 and so on... So if my trigger hits at t=0 I should end up with 200 samples in total ending at time t=0.2 sec, right?

Thanks for the help,
Stefano
0 Kudos
Message 3 of 15
(5,734 Views)
Hi Stefano-

Actually that is not how sampling is performed. Without getting too involved in the tedious details of operation I will explain the basics.

First, there are actually two clocks for your device. In DAQmx (and presumably DAQmx Base) these are referred to as the sample clock and convert clock.

When you specify the sampling rate for a multi-channel acquisition you are specifying the sample clock rate. This clock initiates a train of convert clock pulses that sample the individual channels on the board. So each cycle of the sample clock runs at the requested rate and comprises multiple pulses of the convert clock.

In other words, when you request 1000 Hz and 100 samples in a multi-channel operation you will find that the operation takes 0.1s regardless of the number of channels in the task. This means that the convert clock may potentially run much faster than the sample clock in order to grab the necessary samples from multiple channels in a single sampling cycle. This also explains why adding multiple channels to your task divides the maximum sampling rate per channel of your board roughly by the number of channels in the task.

Please let me know if this doesn't clear up your questions. You can find more information about these concepts in this KnowledgeBase

Thanks-
Tom W
National Instruments
0 Kudos
Message 4 of 15
(5,716 Views)
Tom,
First of all, thanks so much for your help thus far. I'm starting to make some serious progress on my measurement. Before I leave you in peace, I have a couple more (hopefully quick) questions:

- One of the application notes said that the convert clock using the maximum interchannel delay in DAQmx. How can I calculate the interchannel delay based on the sample rate I apply to the DAQ board?

- I'm on a Mac running OS 10.3.9 with LabVIEW 7.1. When I take data from the DAQ board, it causes LabView to "unexpectedly quit" pretty often. I thought it might have something to do with how I configure the acquisition, but I can seem to find a pattern that causes the program to crash. Any ideas?

Thanks again for your valuable time,
Stefano
0 Kudos
Message 5 of 15
(5,708 Views)

Hi Stefano-

I am awaiting information from our R&D representative regarding clock behavior in DAQmx Base to verify if the behavior is device-specific or not.  I will update you as soon as I get word back.

As for the LabVIEW crashing, there could be a number of causes that may relate to memory utilization issues or a problem that might even be unrelated to your DAQ operations.  Are you able to successfully run any DAQmx Base shipping examples?  I would suggest running a few example programs of the same type of operation that your program performs to see if you are able to replicate the crash with those.  Do you see any error codes when LabVIEW crashes?  If not it will be difficult to troubleshoot the problem, but if the examples run well then I would suggest looking at them as references for structuring your own programs.

Thanks-

Tom W
National Instruments
0 Kudos
Message 6 of 15
(5,689 Views)

Hi Stefano-

I am awaiting information from our R&D representative regarding clock behavior in DAQmx Base to verify if the behavior is device-specific or not.  I will update you as soon as I get word back.

As for the LabVIEW crashing, there could be a number of causes that may relate to memory utilization issues or a problem that might even be unrelated to your DAQ operations.  Are you able to successfully run any DAQmx Base shipping examples?  I would suggest running a few example programs of the same type of operation that your program performs to see if you are able to replicate the crash with those.  Do you see any error codes when LabVIEW crashes?  If not it will be difficult to troubleshoot the problem, but if the examples run well then I would suggest looking at them as references for structuring your own programs.

Thanks-

Tom W
National Instruments
0 Kudos
Message 7 of 15
(5,691 Views)
"Error 42 occurred at RLP Invoke Node

Possible reason(s):
The DMA buffer overflowed because data was not read from the buffer as fast as the DMA channel wrote to the buffer."

I get this error at higher sampling rates, and I also see this error after saving the incoming data to a file. My goal is to be able to display a continuous acquisition and save a snapshot of the data whenever I press the "Write File?" button.
0 Kudos
Message 8 of 15
(5,677 Views)

Hi Stefano-

It sounds like the error you're running into is a DMA buffer error that results from a hardware overrun on the buffer.  This makes sense at higher rates and in situations when you temporarily stop removing data from the buffer during file writes because the hardware DMA buffer is being filled faster than you are reading it out with the DAQmx Read VI.

The best solution to avoid this problem is to read more points from the buffer at a time or to read more frequently.  The first option is perhaps more useful in your situation because the file writing portion will delay the subsequent read operation significantly.  By reading more points at a time you will ensure that there is space to buffer more incoming data at faster rates.

Please verify which DAQ board you are using- it seems the sampling schemes are in fact very device-specific in DAQmx Base.

Thanks-

 

Tom W
National Instruments
0 Kudos
Message 9 of 15
(5,658 Views)
Sorry for the delayed response.

I'm using a 6034E DAQ card on a Mac running OS X and Labview 7.1. How does this card perform its sampling? What is the fastest DAQ card on the market today?

Thanks,
Stefano
0 Kudos
Message 10 of 15
(5,613 Views)