"I thought when the call back is triggered, the available number of data in the buffer should be exactly the same as I set."
Ideally this would be true, however the device is continuously sending data to the buffer, so it will never be exactly what you set. Additionally, if the callback function you provide takes a long period of time, you may end up missing events and have data in the buffer from those as well.
"That's what I am experiencing now. I am asking for suggestions to avoid it. Is the only way to increase buffer size?"
There are several things which can help.
1) Make your buffer bigger. To me, this is kind of a band-aid approach. The root problem, I believe is that the callback function is taking too long. Creating a bigger buffer will prolong the amount of time it takes to receive this error. If you know that all you'll ever need is 80 seconds of data, then you can probably just create a buffer that is big enough for that.
2) Use DAQmxSetReadOverwrite to set the overwrite mode to DAQmx_Val_DoNotOverwriteUnreadSamples. Because the 6133 has a large amount of onboard memory, this will allow DAQmx to pause the data transfer when the buffer is full, and store samples in the device's memory until more space is available in the buffer. This is effectively doing the same thing as the first point, only the additional buffering occurs on the device rather than host buffer.
3) Understand the following:
- Execution time of your callback function
- Frequency of your callback function.
The symptoms we've been talking about lend themselves to the assumption that your callback function is taking longer than the every N sample interval to complete. I think it would be a good idea to do some timestamping in your code to prove or disprove this notion. If we see that the callback function takes longer than 0.5 seconds, then we can be certain that it cannot keep up with the acquisition. In this case, the best approach would be to figure out what portion of this code is taking the bulk of the time, and find a way to optimize it. If you find that the callback is not taking too much time, then something else is going on and I'll try to do more debugging on my side.
Hope that helps,
Dan
