LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Analog read rate with daqmx

Solved!
Go to solution

Hi, I have had this problem for a while, I have read tutorials and checked examples, but I am amazed that I cannot figured it out something that seems so simple.

 

I have a series of sensors (AI) and I want to measure data from these sensors at an specific rate (e.g. 20Hz). I thought this would be as simple as setting this rate to the sample clock and the set the number of points I want to read (e.g. 120). But what should take 6s was done in less than one. Now I understand that this sample rate is related with the hardware and yo can only set certain rates, right?

I have seen some examples where the read function is inside a loop with a wait function (e.g. 50ms). Is this the proper way to do it? Then, what are the sample clock rate and number of points for? Any value suggestions for my case?

 

In the end what I want is to measure is an specific number of points at an specific rate. Plot them in a graph/chart while reading and in the end saving them to a file. I am OK with setting up the channels, the loop to plot the data and with appending and collecting the data, but I have the problem in the sample rate and number of points.

 

(In case it is important, I am using a 9239 module and 9172 cDAQ)

 

Thank you

0 Kudos
Message 1 of 8
(3,148 Views)

Hi Igan,

 

In case it is important, I am using a 9239 module and 9172 cDAQ

Yes, that's important!

 

General advice: in case of problems read the manual! (See page 5 and 6…)

 

Solution to your problem: Read at higher sample rate and decimate on your own…

 

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 2 of 8
(3,126 Views)

I feel like what you described as the simple was IS the way you want... Can you attach the VI so people can see if there's some simple mistake? 

 

Edit : Seems I can't delete my post, so please disregard.


GCentral
0 Kudos
Message 3 of 8
(3,118 Views)

With this code I can read at the time I desire as far as the samples per channel are larger than the samples I am gonna save. If it is not, I have jumps in my data when the samples per channel are recorded. It has to be noticed that in any case I have a jump from the first point to the second, but I can live with that.

What I am not sure about is if the data I am saving at each step is the data at that time or a data point that has been recorded earlier.

Download All
0 Kudos
Message 4 of 8
(3,098 Views)

Hi Igan,

 

With this code I can read at the time I desire

I don't think so…

 

With your code you are

- doing NO error handling at all

- requesting just one sample per DAQmxRead: this will be too slow in the long run, especially with a module with minimum 1.6kS/s samplerate!

- collecting data in a shift register without initializing it first: you will get stall data in the second run

- collecting data in a growing array/string which will slow down your loop in the long run leading to errors - which you don't handle at all…

- calling a FOR loop to iterate just once which is plain silly…

 

What I am not sure about is if the data I am saving at each step is the data at that time or a data point that has been recorded earlier.

Because of your bad VI design it will probably be something recorded earlier - see reasons above…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 5 of 8
(3,093 Views)

Hi GerdW, thank you for your comments.

I am new in labview and I am sure that, as any newbie, my codes will be bad designed in the begging. 

You have several good points, but I would appreciate some constructive critique.

 

- requesting just one sample per DAQmxRead: this will be too slow in the long run, especially with a module with minimum 1.6kS/s samplerate!

I think this is the key point of my question. I want to collect at a certain rate, (e.g. 1 point every 50ms). If not like this, how would you set up the sample clock and daqmcRead?

 

- collecting data in a growing array/string which will slow down your loop in the long run leading to errors - which you don't handle at all…

I have to collect the data somehow, right? Would it be faster to write it on the file every step? or is there a more efficient way to store the data?

 

- calling a FOR loop to iterate just once which is plain silly…

Yes, I know it looks silly, but I want the program to ask me about the path to write the file after the previous loop finishes, and if I have it outside it will ask first. 

 

Because of your bad VI design it will probably be something recorded earlier - see reasons above

If it is not doing it it means that the read function will read something that has been previously stored, no? Bu if I set up the samples per channel at a smaller number than the samples I want to record, I have jumps in my data acquisition. Any suggestion?

 

- doing NO error handling at all

- collecting data in a shift register without initializing it first: you will get stall data in the second run

You are right, I just realized and have implemented the changes, thanks.

 

 

 

0 Kudos
Message 6 of 8
(3,086 Views)

Hi Igan,

 

I want to collect at a certain rate, (e.g. 1 point every 50ms). If not like this, how would you set up the sample clock and daqmcRead?

You need to set a clock rate as specified in the manual linked above.

With minimum rate of 1613S/s you need to decimate by 32 to get 50.4S/s (you might try other sample/decimation rates to get closer to your desired 50S/s).

The general recommendation for DAQmxRead is to read ~1/10 of the sample rate, so with 1.6kS/s you would read 160 samples per request.

 

I have to collect the data somehow, right? Would it be faster to write it on the file every step? or is there a more efficient way to store the data?

You should learn/think about producer-consumer scheme to decouple DAQmx from data storage…

 

if I have it outside it will ask first. 

Quick & dirty: use a flat sequence frame.

Or even better: use the error wire to enforce DATAFLOW!

 

it means that the read function will read something that has been previously stored, no?

When you request the samples slower than they are sampled then you will read previous data. Somewhen the internal buffer will overrun and you will get an error message instead…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 7 of 8
(3,079 Views)
Solution
Accepted by topic author Igan

The simple way to decimate a signal in this case would be to use the Continuous Acquisition, read the 32 samples, and only log the first one.  I would also be logging as the data comes in (saves memory growth).  The loop should be limited by the number of samples being read by the DAQ (20ms worth of data), so no waits are needed.  If you find this setup is not fast enough (buffer overflows on the DAQ), then you will want to go with a Producer/Consumer setup to move the logging into another loop.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Download All
Message 8 of 8
(3,067 Views)