LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

A (should be) simple DAQmx question - take finite samples in software timed loop

Solved!
Go to solution

Usually I use separate DAQmx loops exclusively for the task, and send the data via a Queue. In such cases I simply use continuous sampling, very simple solution.

However, I wonder what is the "official" procedure when we want to take finite samples iteratively in a loop, which is software timed and contains other (RS232, etc) tasks. So simply I want to sample like 100 values per channel per iteration, and keep the loop iterating at a certain speed (for example 1000 msec, 1-10 msec jitters are ok in this case). I know that the other tasks will not take more than 400-500 msec to execute. So it is convenient to keep a 1000 msec iteration speed.

Please have a look the (non finished code) snippet below, is it ok to setup it this way? I always realize my DAQmx knowledge is just way too limited 🙂

Thanks!

 

daqmxq.png

0 Kudos
Message 1 of 16
(6,659 Views)

You don't actually need the Start Task and Stop Task.  Otherwise, I don't see anything actually wrong.


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
0 Kudos
Message 2 of 16
(6,623 Views)

I usually set Commit state with Control task.vi before the loop. It moves some task initialization steps outside the loop. 

Message 3 of 16
(6,608 Views)

I'd definitely get rid of the wait inside the loop.  The DAQ Task waits until samples to read are acquired and throttles the loop perfectly.  Adding a second clock source is just asking for trouble.  The words of Ben Franklin come to mind.  A man with one watch knows what time it is, a man with two is never quite sure.  

 

You know you should just do it my way.Smiley LOL


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 16
(6,587 Views)
Solution
Accepted by topic author Blokk

I tend to go with a different approach which is a little more flexibile in a particular way.  It can be really useful sometimes, but can also be unimportant or even detrimental.  It just depends.

 

When I need snapshots of discontinuous data, I configure for continuous sampling and for allowing overwrite.  I also configure to read relative to the sample being taken *right now* instead of relative to wherever my last read left off.  When set up this way, I can immediately retrieve a fixed # of samples representing the most recent stuff that was happening at the sensor.  And during the times I'm not peeking at the data, the task will happily overwrite the buffer in the background without throwing errors.

 

I've never had a problem with this approach being a noticeable detriment, but can imagine how continuous streaming could waste resources in apps where data peeks are relatively rare.

 

Below is a code snippet to illustrate how to do what I'm talking about:

 

 

-Kevin P

  

Config AI to read recent.png

 

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 5 of 16
(6,585 Views)

@JÞB wrote:

I'd definitely get rid of the wait inside the loop.  The DAQ Task waits until samples to read are acquired and throttles the loop perfectly.  Adding a second clock source is just asking for trouble.  The words of Ben Franklin come to mind.  A man with one watch knows what time it is, a man with two is never quite sure.  

 

You know you should just do it my way.Smiley LOL


I agree and also disagree with you. I understand your problem with that extra timing ("Wait Until Next ms Multiple"), but it is required. Why? Because the execution time of the non-DAQmx code part might vary with up to ~100 msec, or even more (serial and other tasks). Probably most of the time it has a very self-similar execution time, but I cannot be sure. So you are right that the DAQmx part executes always with the same speed, but I cannot exactly fix the execution time of the non-DAQmx part, thus the loop time might vary too much occasionally.

Therefore, I need to "round up" the total loop execution time to 1000 msec using that "Wait Until Next ms Multiple"...

0 Kudos
Message 6 of 16
(6,555 Views)

Kevin, I really like your solution:

  1. It teaches me how the DAQmx driver handles the buffer "behind the curtain"
  2. I can just simply use the continuous sampling, but only take the most recent portions from the sensor(s) as I just need in this particular application
  3. The code avoids the two most common errors thrown by DAQmx: when I do not read the buffer enough fast, or when I try to read data which is not there yet

Thanks very much, I learned some new stuff today! 🙂

0 Kudos
Message 7 of 16
(6,552 Views)

Hmm, I see some very strange behaviour: i set the rate to 1000, and the packet size to 100. I set up the code as your example exactly. Surprisingly, the DAQmx Read function outputs the very same values for 14-16 iterations, then i see some new values. The code should give me always the latest 100 values sampled with 1kHz, so i have no idea what is wrong 🙂 Why the DAQmx Read reads the very same values??

 

Edit: my hardware is a USB-6009.

0 Kudos
Message 8 of 16
(6,531 Views)

I believe DAQmx is MAGIC!!! Smiley Surprised

 

daqmx___.png

0 Kudos
Message 9 of 16
(6,523 Views)

Question: can we consider the above behavior as a DAQmx bug?

0 Kudos
Message 10 of 16
(6,516 Views)