Hi, I'm currently working on a project where i have to acquire enormous amount of data, up to 2,4E9 samples. The Daqmx task is configured to acquire in continuous, with an external clock and a sample rate up to 900 kS/s on 8 channels, 1channel/ADC of the card PXIe-4309. DAQmx internal logging system is used to retrieve the samples. A PXI 6570 digital card is used to trigger the PXI 4309 acquisition (PXI_Trig0 trigger line). This strategy seems to work up to 245 760 kS per channel. But if i increase that number, i then get the following error on the output of the DAQmx Read VI: Did anyone already faced that issue? Is the strategy chosen appropriate ? The only mathematical operation i can think of is the conversion from raw data format to DBL which is internally done by the logging mechanism. So i tried to change from analog -> multiple channels -> 2D DBL to Raw I32 datatype. But i get another error : Nicolas

Not sure about your errors they seem related to the digital part of your task. Concerning the part acquiring high speed samples and buffer sizes. The procedure I use is a bit byzantine but it seems to work and be stable for acquisition for days to weeks. Use unscaled data. Make the number of points you acquire each update an even multiple of the disk sector size. I also like to make the number of points a multiple of both the disk sector size and the page size. (Not sure if this helps but it does not hurt) Make the buffer size an even multiple of (2). I like to have a buffer that is at least between 2-4 seconds of data. Do not display huge data arrays on the front panel; decimate your data before displaying. mcduff

Have a look at the shipping examples for continuous acquisition. It's normal and expected to use a loop that does a manageable-sized read each iteration when you configure for *continuous* acquisition. Looks like the examples default to a 1000 Hz sampling and reading 1000 samples at a time, so 1 second worth. A more typical rule of thumb is to read 0.1 second worth. This is generally a very manageable rate to keep up with in software, while offering almost-imperceptible 0.1 second latency on data you present to the user. A good place to start for the trade-offs. Like I said before, I'd bet you can set up your ~1 MHz sample rate and then read & process 100k samples per iteration. Also keep in mind that this might just be a real-time convenience operation -- TDMS logging is preserving all your original data so you can always come back to the file to do post processing if needed. -Kevin P

LabVIEW

DAQmx TDMS data logging

Solved!

@henriksandin wrote:

DAQmx logging save the raw data along with scaling. The problem is reading the file. When you to read the file, the data type "says" double. There is not an easy way to read the raw data.

Message 11 of 11

(367 Views)

LabVIEW

DAQmx TDMS data logging

Re: DAQmx TDMS data logging