simultaneous data acquisition and storage on 16 channels

[krivan]

Hi,

I am trying to acquire data and store them simultaneously on multiple channels simultaneously. I have a PXIe-6358 and I am acquiring the analog input data on 16 channels. While I'm doing that I need to store the data of the different channels into the respective files. I tried to do that using a for loop and a spreadsheet VI, it creates the files and starts filling up them with data but it stops after couple of seconds saying that "Attempted to read samples that are no longer available.".

I attached my VI and the error message. Can somebody please advise what is wrong?

Thanks,

Krivan

[Liam_A]

Hi Krivan,

There are a couple of issues that may be causing a problem.

Because of the write to spreadsheet vi, the while loop could be taking too much time to complete, causing the buffer to exceed. This could be combatted by the use of a Producer Consumer loop and queuing data to be read. The write to spreadsheet vi, being put in the bottom consumer loop.

A relevant example can be found http://decibel.ni.com/content/docs/DOC-2239

Also, from your code the default values from the front panel could mean that the sample rate for the card is being exceeded, meaning the read data could be invalid.

The card specs can be found here http://sine.ni.com/ds/app/doc/p/id/ds-163/lang/en

I hope this helps

[krivan]

Hi Liam,

thanks for the idea, I'll have a look shortly! Regarding the sample rate I don't think I exceeded it because the card is able to sample at max 1.25 MS/s per channel and it is set to only 10 kHz.

[krivan]

Liam,

thinking about it: if I set the sampling rate say to 1MHz, wouldn't the problem of an expanding queue arise? I mean that say I store the data in a separate while loop but the file opening/closing has a fixed time which sets a limit for the data processing time that results in a expanding queue and I produce the data faster than I can actually store it. 

Is there a possibility in Labview  to keep a file constantly open and just stream in the data?

Thanks!

[Timmar]

You have 2 forces and 1 potential race condition working against you:

F1. Updating a graph on every pass through the loop can be CPU intensive and will be executed in the lower priority user inteface thread.

F2. Open-Append-close functionality that you are using with the write to spreadsheet file.vi

R1. In contradiction to my above comments, what happens if the loop is running too quickly (you have no time delay) perhaps the next chunck of acquired data is not in the buffer yet and you are trying to access an empty buffer.

Ths from the daqmx help file:

-----------------

number of samples per channel specifies the number of samples to read. If you leave this input unwired or set it to -1, NI-DAQmx determines how many samples to read based on if the task acquires samples continuously or acquires a finite number of samples.

If the task acquires samples continuously and you set this input to -1, this VI reads all the samples currently available in the buffer.

If the task acquires a finite number of samples and you set this input to -1, the VI waits for the task to acquire all requested samples, then reads those samples. If you set the Read All Available Data property to TRUE, the VI reads the samples currently available in the buffer and does not wait for the task to acquire all requested samples

-----------------

As far as answers are concerned

Use Liam's Producer-Consumer solution

Wire "AI samples per chanel" to the read vi (this should moderate your loop to 100msec Execution)

Or put a wait next milisecond multiple into the loop, set it to say 100msec to get you 1000 ish samples at a time

For data storage, it sounds like you need to look into tdms as a solution.

My limited understanding is that it has been designed to hande the data streaming activities.

If this is a bit intimidating, use file open - File write1 (mulitple times), file close. Unfortunately You will have to format your own strings

Hope this helps,

Tim L.

[krivan]

Thanks for the advices! Actually I haven't thought about the timing conditions this way so far...

However in the meantime I found a suitable solution that is the Configure Logging functionality [DAQ-mx] that streams the data into files and makes easier to handle the TDMS streaming as well.

Information can be found here:

http://zone.ni.com/devzone/cda/tut/p/id/9574

The usage of the -1 is a good idea, thanks!

Krivan

[AndrewMc]

I'm not sure what you mean by using -1, but this will not help performance; it will actually hurt performance.  When calling DAQmx Read, it is best to read a specific amount of samples; otherwise, the call will return almost immediately with samples (typically a small amount).  In this setup, the overhead when calling DAQmx Read is exacerbated by calling DAQmx Read more frequently for the same number of samples.  Additionally, specifically with respect to TDMS streaming, if you use a constant sample size each read, we do not need to write a new header to disk.  Therefore, the streaming performance will be better and the file will be a lot smaller.

Long story short, I do not recommend reading for -1, especially with respect to the TDMS streaming feature.

[Timmar]

Thanks andrew,

My -1 posting was meant as a warning - do not, not as a suggested solution.

THe VI uses -1 as default.

[AndrewMc]

Cool.  Just clarifying in case someone misread this: "The usage of the -1 is a good idea, thanks!"