take periodic samples with daqmx (record time, sample duration (averaged) and number of samples)

[NI-hilator]

I have what I think should be a straightforward application (i.e. I'm sure somone has done this before) but I can't seem to get the right terms to enter into the  NI search box to turn up an example. In short, I need to allow the user to set the record time, sample duration (averaged) and the number of samples to take during the record time. 

To elaborate:

In my application the user will record a voltage signal over a specified length of time - the Record Time (i.e. how long to measure) which can be 25ms to 5 minutes.  The user will also be able to enter how many points they wish to sample during that total record time and the length of the sample window (25ms to 1 sec), or in other words "the sample time" which are in turn averaged out to produce one point.  I think I understand the basic terminology for the Daqmx timer and read functions, Sample Mode, Samples Per Channel, Rate and Number of Samples Per Channel. The DAQ Sample rate will be fixed at 10Khz.  I have some basic code that will do one sample and can put this all in a timed loop but it I am trying to leverage the DAQmx library.  To give proper credit, this code was snagged from another post with some minor modifications: http://forums.ni.com/t5/LabVIEW/Integrated-signal-from-a-photodiode-with-an-NI-USB-6009/m-p/2936044/...

For example: take 20 points over 60 seconds, each for 25ms.  In my attached example I can achieve the single sample by setting the Rate to 10Khz and Samples/Channel to 250 (equalling 25ms).  What is the best approach to repeat this N number of time (number of samples desired) at some periodic rate (Total Record Time / Number of Samples)? A producer-consumer queued state machine with a timed loop around my existing loop seems like a lot of work when I'm think there might be a way to leverage the DAQMX settings and other VIs to do this in a cleaner way.  BTW, I am not hung up on the user terminology, if there is a better way to describe and ask for the parameters please comment. Again, this seems like it would be common...  If I am going about this the wrong/long way please chime in.  Working example that you can point me to elsewhere that would be great too!

Thanks in advance for any feedback!

[NI-hilator]

I should probably point out that I am not actually using the daqmx library. The library I am using is similar to daqmx but without the all of the daqmx features.  When I created the post, I thought they were essentially the same and used term daqmx becuase I thought more people would be familiar with it.  Essentially the library has the same virtual channel concepts and is set up the same.  The library has equivalent vis with equivalent connectors for  Create Virtual Channel, Read, Write, Timing, Trigger, Start Task, Stop Task, Clear Task, Is Task Done, Wait Until Done and a Property Node although not all of the objects of a daqmx property node.  I understand I may lose some potential contributors but consider that the above stated example originally used daqmx vis and I did a simple replace and with a few reconnections and changed the channel control and all worked ok. Thanks again!

[Dennis_Knutson]

A for loop would control the number of iterations and an elapsed time function inside would control the time between iterations. This could connect to a case statement that has your DAQ code. A bit more flexible approach would be a simple state machine.

[NI-hilator]

Thanks Dennis.  The user can ask for a Record Time as small as 25ms.  It seems that using an elapsed timer and for loop may would work ok for long record times but that it might contribute to sampling delays in a record time this short?  What if they ask for 25ms record time and 5ms sample windows of 5ms and 5 samples? or even 4 samples? 4 samples x 5ms each is 20ms, leaving 5ms or approximately 1 ms second between samples to run through the rest of the loop doing calculations & logging. I could queue up the reads using a producer consumer to remove the latter part from the acquisition loop. 

I considered continuously acquiring and buffering the reads and periodically pull off the most recent N number of samples when with timed loop (or elapsed timer?)  It seems this would unnecessarily thrash the DAQ hardware but I don't know of another way to capture such a relative large range of record times, 25ms to 5 minutes, and not run into software delays at the shorter end.  Does this make any sense? Am I being overly concerned about the software delays?  Thanks again.

[mikerophone]

NI-hilator,

In general, it's a good idea to hardware-time all of your data acquisition measurements to ensure that it is deterministic.  If you want the user to define the sampling window, then create a control for the record time and create a constant for the sampling rate.  If you multiply these two together, you will get the number of samples which you can wire into your input for "samples per channel"

Can you redefine your problem statement? Your previous post was a little unclear.

-Michael

[NI-hilator]

Thank Michael.  I guess the timing is the concern and my question is one of style and common/best practice when it come to achieving that. I can certainly make it work, but was looking for feedback on pros/cons of various approaches.... Elapsed time Express VI vs a Timed Loop etc. How to hardware time vs using software Elapsed Time vi or Timed Loop. I've attached an updated VI that should illustrate what I want to do.  Any comments on: using a Elapsed Time vs comparing Get Date/Time or Timed Loop, updating a calling VIs graph via a control reference vs using a Queue. Thanks!

[Dennis_Knutson]

A timed loop does not provide anything unless you are running on rt. The suggestion to use an elapsed time function would be accurate to perhaps 10s of milliseconds. There is basic arithmetic correlation between sample rate, number of samples, and time to acquire. Your image shows finite acquisition so you don't care about gaps in the data. The issue with Michael's solution is that increasing the number of samples to something much greater than the sample rate will make the VI seem unresponsive.

[NI-hilator]

Thanks Dennis.  Good points about the timed loop and the gaps in data.