Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

error 200279 - USB-6353 being used to sample at 10 kHz

Hello all,

 

I need some help with continous sampling on a USB-6353.  I am sampling 28 analog channels and 32 digital channels at 10 kHz.  I have attached some code to look at.  Please start with Main.vi.

 

I get an error (200279) that appears to be random.  Sometimes the error never happens and the code runs smoothly, other times it happens shortly after I start sampling.

 

I've tried reading all samples (by setting the DAQmx read function "number of samples per channel" to -1), and increasing the buffer size in the task for sample clock.  Currently I am using the buffer size suggestion found here.

 

I can't make the change to reading a fixed number of samples.  The program has to remain flexible enough to run as long as anyone needs it.  Could be 30 seconds, could be 30 hours.

 

I'm not running anywhere near as fast as the USB-6353 is spec'd to operate, so I'm sure that can't be the problem.  Can this be an issue with how fast the PC is able to read samples?  If so, how could you ever use this device at its performance limits?

 

Any input will be appreciated.  Thanks!

0 Kudos
Message 1 of 6
(3,262 Views)

Lucas,

 

Sometimes this type of problem can arise if the device is used through a USB hub or with other USB devices.  I would recommend trying a different USB port that is on a different controller (i.e. use a USB port on the back of your computer rather than a front USB port). 

 

Also, have you tried temporarily fixing the number of samples to read for debugging purposes?  

James K.
National Instruments
Applications Engineer
0 Kudos
Message 2 of 6
(3,242 Views)

Thanks for the response.

 

I double checked the USB connection.  It is plugged in the back of the PC at the mother board.

 

I'm not sure exactly what you mean by fixing the number of samples to read.  I have tried setting it to -1, which reads all available samples.  Currently, I have it "fixed" to read 10,000 samples each time through the loop.  I have not tried anything less than 10,000 samples.

0 Kudos
Message 3 of 6
(3,236 Views)

I think the issue here might be the buffer size (this is configured by the 'samples per channel' input to the timing VI).  You have it set to 10,000 which is the number of samples you're trying to read.  I think what is happening is that when your first task is waiting for the 10,000 samples (read won't return until this is done), samples are collecting in the 2nd task's buffer.  Once the first task reads 10,000 samples read is called on your 2nd task.  However, it's buffer size is also 10,000.  Since read can't be done until there is already 10,000 samples acquired (two tasks are synchronized and running at same rate), you're almost certain to overflow the buffer on your 2nd task.

 

Hope that helps,

Dan

0 Kudos
Message 4 of 6
(3,230 Views)

Thanks for input.  I'll be sure to try inceasing the buffer size on both tasks as soon as I can get my hands back on the hardware.  Hopefully it's that simple!

 

I initially chose the buffer size based on this.

 

It recommends a 10 k-sample buffer for sample rate of 10 khz.

 

If anyone else has other suggestions in the meantime, I'm all ears.

0 Kudos
Message 5 of 6
(3,215 Views)

In isolation the linked suggestion is just fine.  However, because you serialize your calls to DAQmx Read and attempt to read a full buffer's worth of samples you're seeing issues.  In this scenario, I would expect you would see problems any time your buffer size and number of samples to read were the same.

 

Hope that helps,

Dan

0 Kudos
Message 6 of 6
(3,208 Views)