Sample Clock and DAQmx Read

[nyc_(is_out_of_here)]

Using 9219

Previous programmer sets the Sample Clock with the following parameters

Sample Mode = Continuous Samples

Rate = 100

number of samples = 90000

He starts the Task.

Then in a While loop, he uses DAQmx Read set to the following

number of samples per channel = 100

Questions

1. Is the 9219 continuously reading, and the DAQmx Read reads each channel 100 times?

2. Is there some reason to set the number of samples to 90000 ?

[crossrulz]

From the DAQmx Timing, the "number of samples" is setting the buffer size of the task.

With the DAQmx Read, the number of samples tells the function how many samples to get from the buffer.  If there are not enough samples, it waits until there is or times out.

[Kevin_Price · Accepted solution]

When setting up the sample clock using "DAQmx Timing.vi", the '# samples' input can be used to set the buffer size for the acquisition.  

When reading samples in a loop using "DAQmx Read.vi", the '# samples' input specifies how many samples to retrieve from the buffer.  If that # isn't yet available, the read call will wait (up to the timeout limit) for them to arrive.  If more than that # are available, the read call will immediately retrieve the oldest ones in the buffer to help maintain a lossless stream of data.

To your specific questions:

1. The 9219 is continuously *sampling* and *buffering*.  This happens via hardware and driver.  "Reading* happens through your application software as described above.

2. The 90000 sample buffer size seems unusually large for a 100 Hz task.  That's 900 seconds a.k.a. 15 minutes.  It's possible there's a good reason for it, but it's much more typical for a buffer size to be closer to single digits of seconds.

-Kevin P

[nyc_(is_out_of_here)]

My guess is the 90000 sample buffer size is there so that he never loses any data.

The part in the test program where the reads are occuring is typically 15 minutes in duration.

.

[Kevin_Price]

Just a guess, but there's probably some confusion on the part of the original programmer.  It's kinda understandable given the dual purpose of "# samples" terminology.

A DAQ task that:

1. starts and then enters a loop

2. iterates that loop while reading 100 samples at a time (1 second worth)

3. has no other time delays

would work just fine with a buffer slightly longer than 1 second.  

DAQmx task buffers are circular.  As long as you read enough samples often enough that the driver isn't trying to overwrite data you haven't read yet, you're fine.  Go ahead and try it out -- requesting a 200 sample buffer size should work fine if the other code meets the conditions I described above.   (Note that the auto-sizing I linked before may kick in and give you an actual buffer size of 1000 samples.)

-Kevin P

[nyc_(is_out_of_here)]

The original programmer is confused all right.

The TDMS file that is generated by his code has 50 readings for each iteration in the loop. These 50 readings are all exactly the same value to 9 decimal points!

I haven't figured out yet why if the code is set up for 100 readings that this would be happening.

I will have to dig further.