Nidaq mx ConfigureInputBuffer Size to Small

[SuperWolfi]

We have a 6025 E, where we would like to read the last 20 Values from one Channel. Our idea was to Configure the Task like this.

this.KraftT.Timing.ConfigureSampleClock("",200,SampleClockActiveEdge.Rising,
SampleQuantityMode.ContinuousSamples);

But when we used the function
this.KraftC.ReadMultiSample(20)

the values were to old, so we decided to reduce the ConfigureInputBuffer - Size.

But we haven't found the correct Buffer size.

Attempted to read samples that are no longer available. The requested sample was previously available, but has since been overwritten.

Increasing the buffer size or reading the data more frequently may correct the problem.


What is the right value when only the last 20 values
should be in the buffer. (To try 20 is indeed a good idea but when i start the task the library answer with an exception that 33 is the minimum.

[Chris_W1]

SuperWolfi:

I'm not entirely sure I understand what you're doing. You first approach seems reasonable to me if you want a specific sampling rate, but you say that the values were too old. What makes you say this? Do you mean you're receiving the error "Attempted to read samples that are no longer available. The requested sample was previously available, but has since been overwritten."? This error means that you're not reading data fast enough to keep up with the rate that you specified to ConfigureSampleClock. Reading more often, or increasing the buffer size should fix this problem.

Also, DAQmx can also do "on-demand timing", which means that the driver reads the requested number of samples as fast as possible with the given hardware. On-demand tim
ing is the default if you don't call ConfigureSampleClock.

Does this help? If not, can you attach a project or give me some more details about your application?

Thanks,

Chris W
NI DAQmx .NET Team

[SuperWolfi]

We wrote a function (getrowkraft()), which replies the value of this.KraftC.ReadMultiSample(20).
We use this function only a few times, because we need just one single data.

One included parameter is:
this.KraftT.Timing.ConfigureSampleClock("",this.konfig.abtastfrequenz_kraft,SampleClockActiveEdge.Rising,SampleQuantityMode.ContinuousSamples);

If we call the function getrowKraft(), we get one single value back, and this value is to old, because if the input voltage were 5V for example, and we measure one voltage, the next time we reduce the 5V to zero, so we still measure with the function 50times the 5V, long after we have zero volts.
So we thought, that the buffer has to be reduced:
this.KraftT.Stream.ConfigureInputBuffer(20);
It doe
sn't work...

We do only need 20Samples with the actual voltage.
I attached a file for you.
In the init() function, we just make the initialization.
I put my necessary comment in english next to the taks, which do not work.
Please just look over, maybe you can find my mistake!
Thanks a lot!

[Chris_W1]

SuperWolfi:

Thanks for the code; I now think I understand what's going on. I think that the problem is that you are using the wrong type of timing; It sounds like what you want is Finite Sample Clock Timing.

I'm attaching a program I wrote that uses all the different timing types I'm going to describe in a minute. Hopefully this program will help you decide which timing type is best for your application.

On Demand Timing means that the data is acquired from the NI hardware as quickly as possible. This is most often useful for writes or reading a single point. The main drawback to On Demand timing is that you don't get to specify the sample clock rate for the acquisition. For applications where you need data acquired or written at a specific rate, use one of the next two timing types.

Finite Sample Clock Timing means that you do specify a rate, but you only want to acquire a finite set of data. From looking at your code, I believe this is what you want. When you use this type of timing, every time you call ReadMultiSample(20) the driver will acquire 20 brand new samples at the rate you specified. This means the call to ReadMultiSample will block for a short time until these samples are read.

Continuous Sample Clock Timing means that you specify a rate, but that the board is acquiring data into it's onboard memory continuously, starting when you call KraftT.Start() or issue the first call to ReadMultiSample. This is happening in the background while your program is running. Generally, you must transfer data out of the board's buffer into your own buffer periodically by calling ReadMultiSample, or the board's buffer will overflow and you'll get the exception you mentioned earlier (that says "Attempted to read samples that are no longer available. ..."). Because the driver is constantly reading from the board and filling it's buffer, it's possible that any given call to ReadMultiSample() is returning old data from the driver's buffer rather and new data that was immediately acquired. I think this was causing the problem you were seeing.

The NI-DAQmx documentation has some good information on timing and other DAQ topics. You can find an overview of the different timing types for instance, by launching the NI-DAQmx documentation from the Start Menu at Programs >> National Instruments >> NI-DAQ >> NI-DAQmx Help, then from the contents navigating to Key NI-DAQmx Concepts >> Timing and Triggering >> Timing/Clocks >> Sample Timing Types.

I hope this helps,

Chris W
NI .NET DAQmx Team