Relationship between sampling rate and timeout?

[labviewtasks]

I'm having difficulty in understanding the relationship between sampling rate and timeout. From my understanding, you have to balance the collection and writing of data into the buffer and reading data out of the buffer. I don't understand why the chart is updated at different rates depending on the settings. For example, if my samples per channel is 5000 and both sampling rate and number of samples per channel are 500, why is there a (what seems to be) a second delay? Why does it flow much faster when number of samples per channel is much smaller at 50? I initially thought number of samples per channel divided by rate gave the reading rate and samples per channel divided by sampling rate gave writing rate, but and if the former is faster than the latter, there would be no issue. This is an example VI provided in class

[altenbach]

Your loop cannot go to the next iteration until everything it it has competed. If the reading is very fast, the lower limit is given by the 5ms wait. If the DAQ takes longer, it is the time limiting step. You can calculate from first principles how long it takes to read the requested  5000 samples if the rate is 500 samples/second.

It seems silly to read 5000 samples per iteration if your chart can only display the last 1024 points and most data is irreversibly lost.

(Maybe you can explain what you mean by "buffer", "timeout", "writing rate", etc.  they are nowhere to be found in your VI.)

[labviewtasks]

Timeout is an input to DAQmx Read and LabVIEW context help says it is in seconds, not milliseconds. "Buffer" is referring to DAQmx PC Buffer. "Writing rate" is an error. I meant sampling rate. 

I know in one second that 500 samples are acquired, but why is there a second delay in displaying data. The chart updates only every second. If the timeout tells DAQmx Read to wait 50 seconds, then wouldn't it refresh every 50 seconds and not one second?

[altenbach · Accepted solution]

A timeout defines how long to wait if no data ever arrives before giving up and returning a timeout error. In your case data is always available so the timeout is irrelevant.

If reading takes one second, the loop rate is one second and the chart is only updated once per second. The chart cannot display anything new unless the 500 samples have been read. Basic dataflow principle.

[labviewtasks]

Ah, ok. Your description is so much better than the context help. When it said, "timeout specifies the amount of time in seconds to wait for samples to become available," I interpreted that as, the VI hold off on reading data for those few seconds. I didn't know it was like a deadline to receive data

[labviewtasks]

Also, since DAQmx Read is in the while loop, are the initial samples read over and over again? Can new data be read?

[altenbach]

It always only reads new data.

[Kevin_Price]

Just trying to help with some further descriptions:

timeout - yes, it's a deadline not a delay

sample rate - the rate at which the device and the DAQmx driver will push data into your task buffer.  With multi-channel tasks, every channel will be converted and delivered at the sample rate.  (Note that some devices spec an "aggregate" sample rate such that the max you can achieve gets divided by the # channels in the task.)

read rate - the rate at which your software read loop iterates.  A typical rule of thumb is to read 1/10 sec worth of data per iteration for a 10 Hz loop rate.   It's achieved by requesting # samples = (sample rate / 10) from DAQmx Read while making sure there's no other time-consuming operations in the loop.

circular buffer - it's important to realize that the task buffer is treated as a circular buffer.  The device and driver keep trying to push data in, and when they reach the end of the buffer they just wrap around back to the beginning again.   Your calls to DAQmx Read also keep track of your reading progress in a similar way.   It's a bit of a race where the reads always trail the writes, but must not fall so far behind as to get "lapped".

contiguous data - as the device keeps pushing data into the buffer, DAQmx keeps track of  which data you've already read and which you haven't.  Each successive call to DAQmx Read will start from where your previous call left off to make sure you get a contiguous stream of data.   One implication of this is that you must read enough data often enough to keep making room in the buffer for new data to be pushed.   If DAQmx sees that it's about to overwrite data you haven't yet read, it'll throw a non-recoverable task error.  The earlier rule of thumb about reading 1/10 sec tends to work out well over a wide range of sample rates and program complexities.

-Kevin P