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

[Blokk]

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!

[crossrulz]

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

[Alexander_Sobolev]

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

[JÞB]

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.

[Kevin_Price · Accepted solution]

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

[Blokk]

---

@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