digital trigger to stop/start analog data acquisition...Need help

[Greg_S-Video]

Hello David

Thank you very much for providing this information for me. To clarify the relationship between "Sampling Rate" and "Samples to Read", the sampling rate is the rate at which your DAQ devices measures data.  This data is placed into your computer memory.  The "samples to read" function is the number of data points that are taken out of your computer memory with each iteration of your loop.  Our general rule of the thumb is to set this value to be a tenth of your sampling rate.  The error you are running into occurs when you try to take out more samples from memory than are available.  If you are sampling at 100 Hz and you want to take out 42000 data points from every loop iteration than LabVIEW will cite an error saying that there isn't data to read.  The solution is to either descrease your samples to read or increase your sampling rate.

More information is provided here for your interest:

DAQmx Timing and Sample Rates
http://digital.ni.com/public.nsf/allkb/3E3D74E26B8A5B83862575CA0053E4B5

Why Do I Have to Specify a Number of Samples to Read When Continuously Acquiring Data?
http://digital.ni.com/public.nsf/allkb/8EF7084B908ABF6686257589007C97DF

I recommend putting your Write to Measurement File express VI inside the loop as you might only be grabbing the samples that are read in the very last iteration.  As well, it prevents you from using up your system memory and instead writes the data to the hard drive.  If you double click the express VI, please select "Append to File".  Can you make these changes as a starting point and let me know of your results?

Thank you very much!

[David T.]

Hello Greg:

Thanks for the recommendations. The vi now is basically working as per my requirements. 

I am now attempting to optimize the vi. I have set my vi to read 7 minutes worth of data and then write data into the file after the STOP is asserted by the Trigger Level vi.

In my test setup, sometimes Stop is asserted sooner than 7 minutes after the start of the acquisition. In this case, I prefer that the data to be written into the file immediately after Stop is asserted.  For this purpose, I followed the instructions in DAQmx Read vi detailed help and set the "number of samples per channel" to -1 but to no avail.    

Is there anyway to modify the vi so that the data can be written into the file immediately after assertion of Stop and not to wait for the whole 7 minutes?

Look forward to your response.

Thanks.

[Greg_S-Video]

Hello David

Can you show me the updates that you can currently made to your VI?  How do you currently have it waiting for seven minutes?  I feel that the VI should write to the file upon pressing stop no matter what the time limit.  I am curious to see how this is set up so that it does not write to a file until waiting seven minutes.  Thank you very much!

[David T.]

Greg:

Attached is my vi. To acquire 7 minutes of data, I have set the vi to following:

Rate (Hz) Samples/Sec = 10

Total Samples to Read = 4200

Input buffer = 4200

Activate "Run Contentiously" button at the top of vi to make the vi ready.

Assert the Start Trigger vi to start data acquisition.

With such settings, the vi acquires 4200 readings at 10 readings per second which gives a total of 420 seconds of data (or 7 minutes). If the Stop trigger is asserted sooner than 7 minutes, the data is written to a file when vi acquires all 4200 readings (or 7 minutes). If Stop trigger is asserted after 7 minutes (or after all 4200 readings are acquired), the readings are written to a file after elapse of another 7 minutes.

I would like to know if there is a way to write the data to the file immediately after Stop is asserted and not to wait to acquire all 4200 readings.

Thanks.

.

[Greg_S-Video]

Hello David

Can you please verify something for me?  I imagine that once you enter that loop that data will begin to be written to that file.  If you press stop while this loop is running, the data should not be removed from that file.  Can you please test this for me to see that data remains in the file?  Please ensure the data acquisition is set to "append to file".

Thank you very much!

[David T.]

Hi Greg:

The reason in Write to Measurement File Config I set the setting to "use next available file name" is because I am running a cycle test on an equipment (which vi will be monitoring a voltage point inside the equipment). The cycle test cycles thru a series of steps contentiously (for 100 times) which takes a few days to cycle thru. During this time, my equipment will trigger start acquisition every few hours and I would like to have the data for each cycle to be written in separate (100) files. 

Setting the config to "append to a file" as you requested and following settings:

Rate (Hz) Samples/Sec = 10

Total Samples to Read = 1200

Input buffer = 1200

Activate "Run Contentiously" button at the top of vi to make the vi ready.

Assert the Start Trigger vi to start data acquisition.

During acquisition, I put the probe on DAQmx Read and it was blank (no data). 

I allowed the vi to run for longer than 120 seconds. The Basic Level Trigger Detection vi inside the loop asserted the Stop after 120 seconds and stopped the acquisition and wrote all 1200 samples into the file. At this time data also appeared in the probe.

I restarted acquisition by reasserting the Start trigger but this time I stopped acquisition manually after 10 seconds by pressing the Stop button. This time also, the vi ran for 120 seconds and added another 1200 readings to the same file rather than writing only 10 seconds worth of data or 100 samples. 

Please discuss this case with your colleagues and advised me if there is any modification I can apply to the vi to cause (force) the vi to write the data into the file as soon as Stop trigger is asserted and not wait for ALL (1200) samples to be aquired.

Thanks.  

[David T.]

Hi Greg:

The reason in Write to Measurement File Config I set the setting to "use next available file name" is because I am running a cycle test on an equipment (which vi will be monitoring a voltage point inside the equipment). The cycle test cycles thru a series of steps contentiously (for 100 times) which takes a few days to cycle thru. During this time, my equipment will trigger start acquisition every few hours and I would like to have the data for each cycle to be written in separate (100) files. 

Setting the config to "append to a file" as you requested and following settings:

Rate (Hz) Samples/Sec = 10

Total Samples to Read = 1200

Input buffer = 1200

Activate "Run Contentiously" button at the top of vi to make the vi ready.

Assert the Start Trigger vi to start data acquisition.

During acquisition, I put the probe on DAQmx Read and it was blank (no data). 

I allowed the vi to run for longer than 120 seconds. The Basic Level Trigger Detection vi inside the loop asserted the Stop after 120 seconds and stopped the acquisition and wrote all 1200 samples into the file. At this time data also appeared in the probe.

I restarted acquisition by reasserting the Start trigger but this time I stopped acquisition manually after 10 seconds by pressing the Stop button. This time also, the vi ran for 120 seconds and added another 1200 readings to the same file rather than writing only 10 seconds worth of data or 100 samples. 

Please discuss this case with your colleagues and advised me if there is any modification I can apply to the vi to cause (force) the vi to write the data into the file as soon as Stop trigger is asserted and not wait for ALL (1200) samples to be aquired. I'd appreciate your (or any other participants) advice on this.

Thanks. 

[A_Donfigulation_Error_Has]

Hi David T,

What I recommend you do is to create a producer/consumer loop instead of using an the 4200 size buffer. You can find a template if you go to File -> New.. -> VI -> From Template -> Framwork -> Producer/Consumer Design Patter (Data).

When you open it up you don't need the case structure in the producer loop. Put your filter and write in the consumer loop. The idea is you take the data and put it into a queue. When there's something in the queue you write it to the file. You produce the data and then you consume it.

Jason L.

[FloatStone]

THX.It helps me a lot.