compute buffer size

[faustina]

I’m trying to modify a DAQ System that runs on a PC controlling multiple types of hardware (PXI/PXIe, SCXI, cDAQ, cRIO, etc.).  These are not necessarily connected to the PC via Ethernet.  The original System was created for only SCXI hardware.  Now it needs to run with combinations of multiple types of hardware with multiple sampling rates.  Using state machine architecture, I create states for each step in the DAQ process.  I’ve created a single task for each device.  For example all the channels on a module of a cDAQ chassis are in a single task.  Each module in the chassis will have its own task.  DAQmx Timing function uses the Sample Clock and is always continuous mode with 3 samples per channel.  I don’t understand why 3 samples per channel were chosen except the users want to see the data in real-time.  The sampling rate can vary.  How can I compute the buffer size (aka PC buffer) for the DAQmx Configure Input Buffer function so that I don’t overflow my buffer.  I’m sure I will have to compute buffer size for each task because of multiple types of hardware and sampling rates.

[Kevin_Price]

You may not *need* to explicitly configure the various buffer sizes as DAQmx will automatically bump them up to a generally reasonable size.   That said, I often still *do* configure explicitly to give myself a 5 or 10 second buffer -- these days, RAM is both cheap and plentiful enough to not quibble too much over a little bit of excess buffer size.

There's still a duty to read from the buffers in a way that can, at least on average, keep up with the hardware sample rate.  A typical rule of thumb is to iterate at about 10 Hz while reading 100 msec worth of samples.  Be sure you don't *overconstrain* the timing.  Either let DAQmx Read handle it by requesting a fixed # of samples, OR use your own 100 msec wait timer and always read "all available" samples (using the special value of -1, which is also the default).

With a state machine architecture and many different devices and tasks, you should probably use your own wait timer function and then retrieve "all available" samples from each task.   So you'll read a somewhat varying # of samples each iteration and your downstream processing will need to be robust that.   I'd also advise something like TDMS as a file format - it's well suited to logging many distinct channels that were sampled at different rates.

-Kevin P

[faustina]

This is what I find interesting given the following configuration:

PXIe-1065 chassis

• PXI-6133; sampling rate = 100000 => buffer size = 100000
• PXI-6133; sampling rate = 1000000 => buffer size = 100000
• PXI-6133; sampling rate = 100000 => buffer size = 100000
• PXI-6133; sampling rate = 10000 => buffer size = 10000

SCXI-1001 chassis; sampling rate = 1000 => buffer size = 10000

• SCXI-1102C
• SCXI-1102C

• I create 5 tasks; one for each 6133 card and one for SCXI chassis. 
• Setup time with DAQmx Timing VI.
• LabVIEW automatically assigns buffer size.  I get warning 200011 for the SCXI chassis.
• Start the acquisition with DAQmx Start Task VI.  I get error 200222 for the second 6133 card.

Then

• I stop the acquisition with DAQmx Stop Task VI
• Clear the tasks with DAQmx Clear Task VI
• Re-create the 5 tasks
• LabVIEW automatically assigns buffer size.  Again I get warning 200011 for the SCXI chassis.
• Start the acquisition with DAQmx Start Task VI and no errors are generated!

Why does the error occur the first time but not the second?  I run the DAQmx Read VI with "all available" samples from each task.  I don’t think I have a timer issue.  I’ve got 8GB of RAM for my 64-bit processor running at 3.4 GHz. 

[Kevin_Price]

Your 2nd 6133 has a 0.1 seconds worth of buffer size.  Once you start the task, there can never be more than 0.1 seconds between reads or you'll get that error.

This could happen right at startup if you start lots of other tasks after the 2nd 6133 and before doing your first read.  Task starts have a little extra overhead time and a bunch of them could add up to that 100 msec.

I'd recommend doing what I often do (as mentioned before).  Explicitly set the buffers to be sized for several seconds worth of samples.  That should help avoid the error in the presence of any reasonable set of code execution timing anomalies.

-Kevin P