Rif.: buffer size and timing problems with cDAQ 9188 and Visual Basic

[roberto_ficarella]

Hi everybody, I have a cDAQ-9188 with a 9235 module for quarter bridge straing gage acquisition.

I would appreciate some help to understand how timing and buffer works.

I don't use LabView: I develop in Visual Basic on Visual Studio 2010.

I have developed my app from the NI AcqStrainSample example. What I have found in the order is:

- CreateStrainGageChannel

- ConfigureSampleClock

- create an AnalogMultiChannelReader

and

- start the task

Than there is a timer in the VB app, once the task has started, that triggers the reading function. This function uses:

- AnalogMultiChannelReader.ReadWaveform(-1)

I have no problem with CreateStrainGageChannel, I set 8 channels and other parameters.

As regards the ConfigureSampleClock I have some doubts. I want a continuous acquisition, so I set signal source internal, rate 1000, sample mode continuous, than I have to set the buffer size using the "sample per channel" parameter.

What I wonder is:

1) can I set any kind of buffer size? What's the hardware limit of the module (9235) or DAQ (9188)?

2) can I read the buffer, let's say, once a second, and read all the stored samples in it?

3) Have I to implement my own buffer for reading from the DAQ or it's not needed?

4) Since I don't want to lose packets: is there a timestamp or packet index I can use to check this?

Thank you so much for the help

[roberto_ficarella]

Any help would be really welcome!

[Tom_W_[DE] · Accepted solution]

Hi Roberto-

I will address each of your questions:

1) can I set any kind of buffer size? What's the hardware limit of the module (9235) or DAQ (9188)?

This samplesPerChannel parameter has different functionality depending on the timing mode you choose.  If you choose Finite Samples then the samplesPerChannel parameter determines how many sample clocks to generate and also determines the exact buffer size to use.  But if you are using Continuous Samples mode, the samplesPerChannel and Rate parameters are used in conjunction to determine the buffer size, according to this excerpt from the DAQmx C Reference Help:

Note that this buffer is a host-side software buffer.  It does not have any implications on the hardware buffers available on the cDAQ-9188 or NI 9235.  Those devices each have relatively small hardware buffers, and their firmware and the NI-DAQmx driver software transfer data from device to host automatically and in the most efficient manner possible.  The host-side buffer then holds the data until you call DAQmx Read or otherwise service the input stream.

2) can I read the buffer, let's say, once a second, and read all the stored samples in it?

Yes.  You would accomplish this by choosing a DAQmx Read size equal to the reciprocal of the sampling rate (for 1 second's worth of data) or some multiple of that for other Read durations.

3) Have I to implement my own buffer for reading from the DAQ or it's not needed?

No, you should not need to implement your own buffer.  The host-side DAQmx buffer will hold data until you call the DAQmx Read function.  If you want to Read from that buffer less frequently you should consider increasing its size to avoid overrunning that buffer.  Which brings me to your next question...

4) Since I don't want to lose packets: is there a timestamp or packet index I can use to check this?

DAQmx will report to you if any packets are lost.  The default behavior is to stop the stream and present an error if the DAQmx host-side buffer overflows (if, for example, your application does not retrieve samples from that buffer at an equal to or faster rate than they are acquired, on average). 

If, for any reason, you would like to allow DAQmx to ignore overrun conditions (perhaps, for example, if you want to continuously sample at a high rate but are only interested in retrieving the most recent subset of samples), you can use the DAQmxSetReadOverWrite property and set it to DAQmx_Val_OverwriteUnreadSamps.

Hopefully this helps-

[roberto_ficarella]

Thank you so much Tom, it is much clearer now and it seems easier than I used to believe.

So, if I want to acquire at 10ksamples, and read the buffer 10 times a second, 2000 samples (2x the number of samples to read) would be ok, right?

I will always read the latest data even if the buffer has older values too, right?
Thank you again. 

[Tom_W_[DE]]

Hi Roberto-

If you are acquiring at 10kS/sec and you would like to be able to Read 10 times per second, you should call DAQmx Read with numberOfSamples = 1000.  All of the values are expressed in number of samples per channel, regardless of the numbers of channel in use or the raw sample width.

The default setting is to Read all samples chronologically.  This means that if you are acquiring data at some rate and reading periodically you will always get the samples in the order they were acquired.  This may mean that your data is somewhat stale, depending on the frequency with which you call DAQmx Read.

If you instead want to always read the most recent sample(s) acquired, you can use these properties to adjust the starting read position for each Read operation:

DAQmxSetReadRelativeTo: DAQmx_Val_MostRecentSamp, DAQmx_Val_CurrReadPos, etc

DAQmxSetReadOffset: where the 'data' parameter represents an offset from the current read position.  It is an int32, so you can specific it as positive/forward or negative/backward in the buffer from the current relative read position.

[roberto_ficarella]

I can call the DAQmx Read on a time based interval, not on a sample-based interval.

So I would call the Read every 100ms, but that doesn't ensure I have 1000 new samples in the buffer!

Do you think this could be a problem? I don't mind reading always the newst sample, I prefear to read ALL the samples, even with some delay...

[Tom_W_[DE]]

Hi Roberto-

DAQmx Read will block until the requested number of samples are available (or until the timeout expires).  You can use it as a way to throttle the loop rate of your application to the hardware acquisition rate and correlate those two operations.

If you want to read all available you can take two approaches:

1. Call DAQmx Read with a larger number of samples than you know to be available at the time the Read is called.  For example, attempt to read many times per second with a read size larger than the reciprocal of your acquisition rate.  This would effectively give you all available samples at some interval determined by the relationship of your read size and acqusition rate; or
2. Call DAQmx Read with "-1" samples to read.  Throttle the calls to DAQmx Read using software delays or some other means in your application.  This way, you will always get all samples available when you call DAQmx Read.  The disadvantage is that the sample size might vary because of the software-timed nature of this approach.

[roberto_ficarella]

Hi Tom, you say:

2. Call DAQmx Read with "-1" samples to read.  Throttle the calls to DAQmx Read using software delays or some other means in your application.  This way, you will always get all samples available when you call DAQmx Read. 

It is what I do. Is there the risk of reading twice some samples?

[Tom_W_[DE]]

Hi Roberto-

No, DAQmx will not return the same samples twice unless you use the functions I mentioned previously to modify the read pointers.  If you leave those as they are and just call DAQmx Read, as long as there are no throughput or buffer overflow issues, you will always get sequential data and no repeated or dropped readings.

[roberto_ficarella]

Thank you so much Tom,

which document in the help could I study just to take a look at all the things you told me?