Saving data during continuous acquisitioni

[Oleks]

Hello all,

I am having troubles with something really basic. I am monitoring voltage signals from three channels and would like to record X(ms) of current signals when I feel like it(hopefully without any delay caused by Windows). I thought by creating case structure and by inserting a flat sequence into it I can achieve this. Apparently not, I set a value to wait to 5000ms but I did not even get 1 second of data.

Would really appreciate any help

Oleks

[johnsold]

What you want is the Producer/Consumer architecture.  This uses separate parallel loops for acquisition and for saving. The data is passed from the Producer to the Consumer via a queue. Look at the Design Patterns or examples which come with LV.

In the Consumer (save to file loop) you would dequeue the data and put it into a shift register. When the save boolean is activated, the consumer begins accumulating the 5 seconds of data. When the data is accumulated it saves to the file and begins accumulating the next batch or waiting for the next save command.  When not saving you can simply discard the data from the queue or save a few seconds worth and discard older data, depending on your requirements.

Lynn

[Oleks]

Hi Lynn,

Thank you very much for the tip! I have to read about this feature as I am not famillilar with it. I already found a pdf presentation of somebody from NI, I see if I can digest the methodology 😉

Oleks

[Oleks]

Hi Lynn,

I think I was able to get some progress with the architecture that you suggested. I was wandering if I can cross-connect Boolean lines between two loops? 

[johnsold · Accepted solution]

Oleks,

No. As soon as you make that connection with the boolean you no longer have parallel loops.  With that connection the consumer loop cannot start until the producer loop stops. And it is possible that the Release Queue could execute before the consumer loop Dequeues the data.  If that happens, you would lose all the data.

You do not need to do anything to tell the consumer loop when you want to record. The queue takes care of that for you. Here is how it works: In the producer you only Enqueue data when the Enable Recording boolean is True. In the consumer (assuming that you have removed the boolean wire) the Dequeue has an infinite timeout (default).  So it will wait forever for data to show up in the queue.  When it dequeues the data, it saves the data to file.  The Wait does nothing useful. The way you have the program set now, the consumer loop will dequeue exactly one reading, save it to the file, and exit.

Since you have set the Recording Time to 5000 ms, I assume that you typically want to save 5 seconds of data each time the Enable switch is set to True.  With the Sample Rate = 10 kHz and Samples to Read = 1000 you will need to read 50 times to get 5 seconds of data.

There are several ways you can handle this.  One way is to keep track of how many samples you have read with another shift register in the producer. When Enable Recording switches from False to True, you start counting samples and sending the data via the queue to the consumer. When you reach the time or number of samples limit, stop enqueuing.  Only stop the consumer loop on the error from releasing the queue.

This will permit several recording "sessions" within one run.  I do not have DAQmx so I did not test this.

Lynn

[Oleks]

Hi Lynn,

Thank you very much for clarifications! The approach you suggested is exactly what I needed. There is one question I was wandering about. If I set number of sumples to -1, it will imply that all available samples will be read. Does it mean that by enablinng recording I will be logging current data stream into file. I guess with 5s recording length (10kHz sampling rate), it will take me 5 times to write all that data into text file, but the samples will start counting from the moment I enamble recording? 

Thanks again!

Oleks

[johnsold]

Oleks,

If you set Samples to Read = -1, then each time the producer loop iterates it will grab all the samples which are in the DAQ buffer. The number of samples can vary from iteration to iteration. With this method you can no longer calculate the number of iterations which will be required to collect a specified amount of data.

You can do one of two things with that method:

1. Examine each waveform returned by the DAQmx Read to determine how many samples it contains.  Add up the numbers of samples from each read. Compare to the total number desired. Stop recording when the number is reached.

2. Keep track of elapsed time during each recording session.  When the elapsed time exceeds Recording Time, stop recording.

Either method will work. Both may give a total number of samples or recording time slightly greater than the Recording Time input unless you trim the data. (But my method will do the same thing if the number of cycles calculated from (Recording Time)*fs/(Samples to Read)  is not an exact integer).

Lynn