Error 20003: while reading data through more than 5 Analog input channels at Sampling rate of 100Khz. (all at same time)

[sabintimsina]

I am using NI USB 6216, 16 bit device with 400ks/s. Using the same device, I was trying to read data from 6 sensors (creating 6 channels) at sampling rate of 100Khz, but it gave me error 20003 saying " the number of samples should be >0". Whenever only 5 channels are created instead of 6, every thing perfectly works. Also, if I decrease the sampling rate to 83Khz, it works perfectly even with 6 channels. I am not sure if I am exceeding device max sampling rate ? 

[aputman]

Please post a code snippet or the actual VI.  We can't debug a partial image of a block diagram.

Read this blurb about the DAQmx Timing VI.  Make sure you understand how the buffer works for Continuous Samples.  You'll need to make sure to read samples fast enough to keep the buffer from overflowing. 

[Kevin_Price]

ALSO,

The 6216 is a multiplexing device.  The 400 kHz rating in the spec sheet  is an *aggregate* total.  This is the total # of A/D *conversions* per second.   This will be divided among all the channels in your task, such that your task as a whole will be limited to a sample rate of 400/N kHz where N is the # channels in the task.

The spec sheet terminology is different than what's used in the DAQmx API, and this can be confusing until you learn the secret code.

That said, your observations that you can collect from 5 channels at 100 kHz or 6 channels at 83 kHz seem to point to a device capable of 500 kHz aggregate sample rate.  Are you sure you have a USB-6216?

-Kevin P

[sabintimsina]

Thanks Aputman,

I am not quite sure about the buffer size. I have attached full snippet of vi file.

[sabintimsina]

Thanks Kevin_Price,

I am confused too but I am sure I am using USB 6216. Here I have attached full snippet of my VI file.

[sabintimsina]

@Kevin_price and @ Aputman,

Correction on Labview. I have listed  Sample clock to 85KHz so that it could run 6 Channels. But the actual sample rate to process is 100KHz. With 100Khz, and 6 channels it shows an error 2003.

[aputman]

There is a lot wrong with this VI but the elephant in the room is that your BD is the size of an elephant.  It's no wonder you are confused.  If you are using the navigation window to view different parts of your program, something is wrong.  

Regarding your original question, I'm guessing your issue stems from the fact that you have set the device to acquire 85k S/ch/s into a buffer but you are only reading 2500 samples per channel from that buffer to analyze.  Your read loop would have to execute 34 times per second to keep up with the device. 

I'm not entirely sure how the multiplexing works for a continuous acquisition mode but it could also be related to this.  It could be that not all of the channels have been "multiplexed" when the request for samples is being made.  This is just a guess.  

[Kevin_Price]

I couldn't turn your snippet into code as it's from LV 2017 and my most recent version here is 2016.  

Exactly *where* does that error occur?  The error text you described doesn't *sound* like a DAQmx error to me, and I wonder whether it might be a automatic error dialog popping up from down in your filtering code.

Otherwise, I think aputman is on the right track for the most part.  (Exception: the guesses about multiplexing.  It works the same way for finite or continuous mode, and the board/driver will never try to return a set of data that includes an incomplete round of multitasking.  It won't throw an error if asked for data in the middle of multiplexing either.)

My guess is that you get a DAQmx error at some point, and then DAQmx Read returns you a waveform with 0 samples.  Then this empty array is sent to your filtering code and *that's* where the *visible* error occurs.

But the real root cause is back at the DAQmx stuff.  And I'm not yet ruling out my previous suspicions about your "6 channels at 83/85 kHz" on a device spec'ed for a max of 400 kHz aggregate A/D conversion rate.  I would expect an immediate error when you try to start the task, but the *visible* symptom of the error doesn't come until you read back 0 samples and make the filter code choke.

Put a debug probe on the error wire right after starting your AI task.  Find out for sure whether your combos of # channels & sample rate are *really* allowed.

-Kevin P

[mcduff]

---

@Kevin_Price wrote:

Put a debug probe on the error wire right after starting your AI task.  Find out for sure whether your combos of # channels & sample rate are *really* allowed.

-Kevin P

---

I have found that some of the multiplexing devices allow "oversampling", that is, the max rate supported by 1 channel may larger than the max rate supported by multiple channels. I have found that multiple channels can sometimes reach the higher rate BUT it is extremely unstable and the task will usually fail quite soon after it has started. But you can get a short burst.

Anyway use the following to find your max allowed sampling rate.

Make sure you wire your task with ALL of the channels you want to the node. It will spit out the max sample rate.

I usually use this for a "dummy" task, that is a task I never start. After the user has set up all of their channels, I create a dummy task, input it to this node, and see what is the maximum allowed sampling rate. I will adjust my sampling rate control as needed.

mcduff

[aputman]

---

@Kevin_Price wrote:

(Exception: the guesses about multiplexing.  It works the same way for finite or continuous mode, and the board/driver will never try to return a set of data that includes an incomplete round of multitasking.  It won't throw an error if asked for data in the middle of multiplexing either.)

---

Good to know. Thanks.

I'm somewhat of a noob when it comes to DAQmx.  The OP did not wire the Samples/Channel on the timing VI and it threw me off.  I was confusing that with the "Read" samples/channel.