DAQmx continuous acquisition

[gmonjo]

Hello there,

I'm having some trouble with data acquisition from module NI 9236 in cDAQ 9188 chassis. Problems are:

- Noise filtering

- Saving data

I want to acquire 4 channels with a 20-25 Hz sampling rate. However, since I have noise issues, I acquire with a 1000 Hz frequency and then average the last 50 values. I also change Strain into MicroStrain.

This program also saves the zero value and uses them to substract all further readings. The whole program runs in a while loop with a 20ms wait.

When i simulate the module everythings works right and i get a nice sine wave from the four inputs. However, when working with the real hardware I get something like this:

20:59:59.00   NaN   NaN   NaN   NaN
16:18:06.13  2302  1727  2326  1734
16:18:06.32  2304  1728  2329  1735
20:59:59.00   NaN   NaN   NaN   NaN
... x10

where two readings are followed by 10 "NaN". Could this be a buffer issue?

I appreciate your help.

PS. Sorry of the unnecessary formatting code.

NI Software : LabVIEW 2010

NI Hardware : cDAQ 9188, NI 9236
Driver Version : latest
OS : Windows XP

[Schneiater]

Hi gmonjo,

The problem you are facing can be an issue with loop timing.

In the DAQmx Read you didn't connect the input "number of samples per channel". When you don't connect anything, it uses the default value that is -1. With -1, it reads everything that is in the buffer at the moment.

Probably your NaN come from this configuration. It is possible that you try to read when there is no data at the buffer, so it return an empty waveform data. When you divide this data by the data size (0), it returns a NaN.

You can try to take the wait function off and input 50 to the "number of samples per channel". The DAQmx read will time your loop and you will get 50 samples each iteration.

This will probably solve your problem.

Another recommendation to your program is related to the File IO functions. You should close the file after you stop using it (probably at the end of the VI) and you don't need to open it inside of your loop because you opened it out of the loop. You can just use the same reference.

I hope this helps.

If you need more information, feel free to ask.

Best Regards,

[Schneiater]

Hi gmonjo,

Antything new on this issue?

Regards,

[gmonjo]

Hi Rodrigo,

Thank you for your answer.

I changed the "number of samples per channel" input to set the buffer size and this solved the "NaN" problem. Hower I did leave the wait function. It seemed to work only in this fashion.

I followed your recommendations on the IO functions.

The filtering problem was solved by adding a "low pass filter" instead of the previous "averaging". This gave much better results. However, I think it takes much more processing time, which influences the maximum frequency we can achieve. Luckly I need to measure frequencies in the 1-4 Hz range, so this was not a problem.

The program worked fine with:

   Sampling freq: 1000Hz

   Buffer size: 100

   Wait time: 100ms (10Hz)

Which gives a saving frequency of 10Hz

When changing the waiting and buffer size:

   Sampling freq: 1000Hz

   Buffer size: 50

   Wait time: 50ms (20Hz)

I got the following problem:

I guess the waiting period is too small. However this frequency could be achieved with the following inputs:

   Sampling freq: 2000Hz

   Buffer size: 100

   Wait time: 50ms (20Hz)

I found this to be rather odd.

Anyways, I'm using these last settings for my 20Hz acquisition.

[Schneiater]

Hi gmonjo,

Actually, this error you are receiving happens on the filter you are using. It is related to the high and low frequency inputs. You must check the sampling info of the signal you input to the filter and the frequencies you use as low and high frequency for the filter must not be higher than half of the signal sampling frequency (Nyquist).

The configuration that worked for you uses double sampling frequency, so it is something to check out.

I hope this helps.

Best regards,

[gmonjo]

Hi Rodrigo,

Yes, I'm aware of this. I'm using a Lowpass filter with a cutoff frequency of 10Hz, much much lower than the 1000Hz or 2000Hz sampling frequency.

That's why i find it strange.

Regards.

[Schneiater]

Hi gmonjo, Can you post your code with the filter? I would like to see what are your inputs. It could be a picture of this part of the block diagram. Thanks,

[gmonjo]

Sure. This is the code of the DAQ vi with the filter subvi.

One more thing. There is a difference with the simulated DAQ and the real acquisition. I don't know why this happens.

For instance, with the simultated acquisition I didn't have the NaN problem I posted before.

Regrads.

[Schneiater · Accepted solution]

Hi gmonjo,

Actually, in the code you sent me, you didn't set the number of samples to read. It is possible that you are facing the same problem with a different error.

Below you can see the input where you should set the number of samples.

Please, test your VI configuring it to acquire a constant number of samples each iteration.

Regards,

[JÞB]

---

@gmonjo wrote:

Sure. This is the code of the DAQ vi with the filter subvi.

One more thing. There is a difference with the simulated DAQ and the real acquisition. I don't know why this happens.

For instance, with the simultated acquisition I didn't have the NaN problem I posted before.

Regrads.

---

Got it-  The default for the simulated signal is to run as fast as possible- (simulates time) where as your DAQ does take time to acquire samples.  You have miss-interperated how to set the DAQ timing.  Buffer size is the amount of samples to store in the device onboard buffer.  when its full its full and may stop acquiring or overwrite the buffer (resulting in an error) 

In your application it looks like you want to process "chunks of data" with a known length.  Use Nchanell Nsample reads not continuous acquisition.  replace the Start task vi with Control task to commit the task outside the loop each loop iteration the task will "autostart" wait for all data requested and give you all the data and iterate starting the task again without missing a beat. 

Although, its probably best to pass the data out of your loop in a queue to another loop that chews on the numbers to get the acquisition loop cycle time down to just data acqusition time - (look at the Queued Producer Consumer examples)