From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx read and data log at different rates

Solved!
Go to solution

Hey guys!

 

I am using DAQmx to do some analog input reading.  I would like for the data to be datalogged via TDMS at 1000 Hz.  However, I only want to read the data at 10 Hz.  Is there a preferred method of doing this?  The picture below shows what I have so far.  (Note that this image is a simplification of the DAQmx routine I'm using)

 

daqmx question.png

As you can see, I set the sample clock to 1000 Hz.  This forces TDMS datalogging at 1000 Hz.  I then have a while-loop that runs at 10 Hz with a DAQmx read operation in it.  At the moment, I am forced to read ALL data on the buffer during each loop iteration.  However, I am only interested in reading 1 sample from each channel during each loop iteration.  (I ultimately take this 1 sample/channel at 10Hz and push it into a plot for the viewer.)

 

Is there a way to only read the newest data for each channel and then to clear the buffer such that I don't get a buffer overflow error when DAQmx see that I haven't been reading all of the data?  It seems inefficient for me to be reading all of this data and then only indexing out the first column.  Am I missing something, or is this method fine?

 

Thanks for the thoughts!

0 Kudos
Message 1 of 9
(4,347 Views)
Solution
Accepted by topic author brentjustice

I would probably just take out the wait function, read 100 samples per loop explicitly, and index out the last sample to show on your display (or average the 100 samples).

 

Alternatively, setting the following read properties before starting the task should work for most devices (if not, please let us know which you are using):

 

Untitled 3 Block Diagram _2015-01-26_14-43-34.png

 

 

Best Regards,

John Passiak
Message 2 of 9
(4,321 Views)

Ditto John.

 

The wait is unnecessary sine the DAQmx read will wait up until timeout for 100 samples to be available.  If you have any other wait based on anything other than the DAQmx sample clock you run into issues of differences in the two timing sources.  That is what leads to the buffer filling up and your "Latest Sample" isn't since the latest sample gets left in the buffer and won't be read till some future time.


"Should be" isn't "Is" -Jay
0 Kudos
Message 3 of 9
(4,304 Views)

Ok, I tried the following 3 solutions:

 

1) read 100 samples per loop iteration and index out the last column

2) read 100 samples per loop iteration and average the values

3) read 1 sample per loop iteration and use software timing to dictate loop speed

 

Here are the 3 codes, in order:

 

read all2.png

read avg2.png

read one line 2.png

Here are the resulting loop speeds, again, in the same order:

 

read all.png

read avg.png

read one line.png

 

The bottom line is that all of these methods work.  It appears that the read-one-line method results in a tighter loop time.  (Any thoughts on how to properly and fairly compare performance other than looking at loop speed?)

 

Thank you both for the information.  John, you've helped me before.  Thanks alot!

0 Kudos
Message 4 of 9
(4,298 Views)

Watch also for any samples left in a buffer.  with a 1D array of wfm. you could also watch the T0 delta


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 9
(4,285 Views)

Apologies, but I'm not sure that I understand this comment.  What is "T0 Delta"?

0 Kudos
Message 6 of 9
(4,282 Views)

Are you using a USB device by chance?

 

The loop timing should average out to 100 ms in all three cases, but there would be some inconsistency in loop time in the first two since you are always reading 100 new samples and there will be variable latency in when the data is available to the software buffer.  In the third case, you are always reading the most recent sample that is already in the software buffer and so the variable bus latency wouldn't affect the loop timing.

 

What Jeff is talking about is that you don't want to read N samples per loop AND have a loop delay, which could result in a backlog of samples if the cpu clock is slightly slower than the clock on the DAQ device.  Reading N samples without a loop delay (as we suggested and as you have implemented in the first two examples of your second post) guarantees a fixed number of samples read per loop and will result in a "fairly" consistent loop time.  Reading -1 samples with a loop delay (as the code in your very first post) will result in a variable number of samples read (possibly 0) but will have more consistent timing (especially if using a bus with variable latency).

 

Reading relative to the most recent might actually be what you want... but be aware that the data you are reading is only the most recent sample which has already been transferred to the DAQmx software buffer and there are likely samples still in the hardware buffer which have not yet become available.

 

Using loop speed (or rather, consistency) to characterize the application's performance is only relevant if your application depends on this parameter.  If the loop's purpose is to just inform the user of the voltage then it probably doesn't matter.

 

 

Best Regards,

John Passiak
Message 7 of 9
(4,272 Views)
I could not have said it better myself John

"Should be" isn't "Is" -Jay
0 Kudos
Message 8 of 9
(4,233 Views)

Yes, I am using an NI-USB-6343

 

That clears things right up!  Once again, I appreciate the explanation.

 

I'm going to go with the averaging solution.  This seems to be the solution that makes the most sense.  The only purpose of the DAQmx read is to populate a pretty plot for the user, nothing time-sensitive is going on.

 

Thank you for your help!

0 Kudos
Message 9 of 9
(4,204 Views)