04-18-2020 02:37 PM
Sorry to jump in (mcduff should get credit for the solution). I made a few minor (but important) changes to your code, shown below as a Snippet (you should easily be able to change them yourself on your version).
Other than straightening some wires and making things more compact (and in order of importance):
The second point is (probably) the one McDuff would suggest you learn first.
Bob Schor
04-18-2020 03:10 PM
@Bob_Schor wrote:
The second point is (probably) the one McDuff would suggest you learn first.
As would I. I think the first point is often not particularly important. For continuous acquisition, DAQmx autosizes up to a larger buffer size when you request one it considers too small. Do you find this surprising or non-intuitive? Consider up-voting my complaint/suggestion about it on the Data Acq Idea Exchange.
I'd also amend the second point a bit. With a high sample rate, I would make my buffer at least 2x as big as the # samples I was going to Read each loop iteration. I would for sure not make it exactly the same size. You need to allow a little breathing room for the driver to be transferring new samples into the buffer while your Read call is retrieving the ones you want, else you risk an unrecoverable buffer overflow error.
-Kevin P
04-18-2020 03:20 PM
@Kevin_Price
I'd also amend the second point a bit. With a high sample rate, I would make my buffer at least 2x as big as the # samples I was going to Read each loop iteration. I would for sure not make it exactly the same size. You need to allow a little breathing room for the driver to be transferring new samples into the buffer while your Read call is retrieving the ones you want, else you risk an unrecoverable buffer overflow error.
Depending on the memory in my system I like making the buffer 4-8x the sample rate. Be careful if using the log only mode of DAQmx then buffer needs to be a multiple of the disk sector size.
mcduff
04-19-2020 08:10 AM
Kevin and McDuff,
Thanks for the clarification and correction! I've probably never "pushed" the limits of my DAQ devices ...
Bob Schor