Best practice for timer during measurement?

[Basjong53]

Hi, I have a DAQmx read vi that is measuring for several seconds. I would like to have a front panel indicator to show the user the remaining time. This requires a parallel loop that handles the timing. I made something that works using notifiers (don't worry about the DAQmx part for now):

So the DAQmx read and the timing loop start at the same time. The loop waits for a notification for 500ms, updates the indicator and runs again if no notification is sent, which is the case while the measurement is running. Once the measurement is finished it sends a notification to the timing loop and after a maximum of 500ms the loop ends. The loop also ends if the timeout of the DAQmx is reached (I simply set this to be 2 times the measurement duration, this can be any factor).

Though this works quite well, I'm still learning LabVIEW and I would like to know if there are other, better or more common solutions to this.

Thank you very much in advance.

[winterishere8]

Typically I have the read DAQmx in a while loop that stops either on user stop or Error. I have an elapsed timer inside that while loop and display to user. That is one approach.

[crossrulz]

So it sounds like you have a finite sample task.  I would probably just put the read in a loop and read ~100ms worth of data at a time.  Or use a Wait and use -1 for the number of samples to read everything in the buffer.  You can then keep track of how many samples have been taken vs how many the task is set up to do and use a progress bar to show this ratio.  Of course, you would need to do something to combine all of your data correctly.

[Kevin_Price]

---

@crossrulz wrote:

So it sounds like you have a finite sample task.  I would probably just put the read in a loop and read ~100ms worth of data at a time.  Or use a Wait and use -1 for the number of samples to read everything in the buffer.

---

A little correction for the sake of the OP.  Setting # samples to read = -1 for a *Finite Sampling* task will not just return the samples already available in the buffer at the moment, it'll wait to try to accumulate *all* the samples that were specified in the original call to DAQmx Timing.  (Under *Continuous Sampling*, setting # samples to read = -1 would indeed immediately return with the samples already available in the buffer.)

Confusing?  No argument.  Consider kudos to this idea on the Data Acq Idea Exchange.

To avoid a 2nd loop, I'd probably do the 1st thing crossrulz said -- request ~100 msec worth of samples each iteration and accumulate them.  But having the 2nd parallel timing loop isn't so bad either.  I typically advocate keeping the DAQmx Read loop as lean as possible so deferring other processing for a parallel loop is a decent habit to get comfortable with.

-Kevin P

[crossrulz]

---

@Kevin_Price wrote:

---

@crossrulz wrote:

So it sounds like you have a finite sample task.  I would probably just put the read in a loop and read ~100ms worth of data at a time.  Or use a Wait and use -1 for the number of samples to read everything in the buffer.

---

A little correction for the sake of the OP.  Setting # samples to read = -1 for a *Finite Sampling* task will not just return the samples already available in the buffer at the moment, it'll wait to try to accumulate *all* the samples that were specified in the original call to DAQmx Timing.  (Under *Continuous Sampling*, setting # samples to read = -1 would indeed immediately return with the samples already available in the buffer.)

---

Good job catching my Monday morning brain fart.  I very rarely deal with Finite Samples tasks, so the caveat did not enter my brain.

[Basjong53]

@Kevin_Price wrote:

So it sounds like you have a finite sample task.  I would probably just put the read in a loop and read ~100ms worth of data at a time.  Or use a Wait and use -1 for the number of samples to read everything in the buffer.  You can then keep track of how many samples have been taken vs how many the task is set up to do and use a progress bar to show this ratio.  Of course, you would need to do something to combine all of your data correctly.

---

That seems like a good idea to read in chunks of data. It also allows me to update a graph showing the measured data during the measurement in stead of only after everything is done. This will be very useful for the user!

---

@crossrulz  wrote:

To avoid a 2nd loop, I'd probably do the 1st thing crossrulz said -- request ~100 msec worth of samples each iteration and accumulate them.  But having the 2nd parallel timing loop isn't so bad either.  I typically advocate keeping the DAQmx Read loop as lean as possible so deferring other processing for a parallel loop is a decent habit to get comfortable with.

---

I can do both. Have the reading done in chunks to live update the front panel graphs etc. And the parallel loop to leave the Read task alone.

Thanks for the replies!