Synchronizing digital counter frequency input with two analog inputs (accelerometer)

[Schafbo]

I'm trying to add a frequency counter to a data acquisition program that reads analog input data from accelerometers. The frequency counter uses the NI 9402 DIO LVTTL module and the accelerometers are read with two NI 9230 IEPE modules. The analog inputs are read in "Continuous mode" at a sampling frequency. Ideally, I want to read the frequency counter at the same frequency and synchronize the counter and analog inputs. However, the NI example "Counter - Read Pulse Width and Frequency (Continuous)" shows that "Continuous mode" is not quite the same as the analog settings. I'm not able to set the sampling clock to the Onboard Clock like the analog inputs. Is there a way to synchronize them? Or, if this isn't possible, have the Counter Input in continuous output a waveform so I might approximate the frequency at a given time? I'm using the cDAQ-9174 chassis and generating digital signals using the NI 9401 module to test.

[Astromaut]

Hi Schafbo

I found one example that might be useful.

Regards,

Astromaut

[Schafbo]

Thank you for your reply. I looked over using Implicit timing for frequency measurement, and it may not be necessary to synchronize the clocks. If I am able to take time measurement using Implicit timing with Continuous "block sampling" or Reading n samples per loop, how might I record the time for each of the individual samples?

[TylerC1123]

Hi Schafbo,

When you say you're wanting to record the time for each of the individual samples, is this referring to the time at which each sample event occurred (either real world time or time into the acquisition) or duration of a particular sample or event?

[Schafbo]

If I record n samples with DAQmx Read in a loop with where timing is set to "Continuous" mode, I would like to be able to record the time with each of those samples. I am not sure if the DAQmx API is able to do this?

[Kevin_Price · Accepted solution]

No, the DAQmx API won't do that for you.  You'll need to code it up.

Here's the basic idea to get you started -- you need to keep track of the cumulative sum of the interval times represented by each freq measurement.

-Kevin P

[Schafbo]

Thanks! I wasn't sure you could process Continuous acquisition data in the loop fast enough without causing the buffer to fill up. This is exactly what I was hoping to do.

[Kevin_Price]

Note: the code I posted is not a "best practice" for efficiency, just a minimal example that would be clearer than lots of words.

One important part of preventing buffer overflow is to keep the DAQ loop lean and tight.  I'm not at a LabVIEW machine now to show you code, but here's some description and search terms:

1. use a "producer consumer" approach where the only functions in the DAQ loop are DAQmx Read and an Enqueue function where you send all the data.  The DAQ loop is then the producer.  The consumer loop would Dequeue (from the same queue reference) ,then do any processing, array accumulation or display to gui indicators.

2. Specific things that aren't optimal in my earlier code (none of which would affect DAQ buffer issues after moving to the producer consumer approach above):

- concatenating arrays on the output boundary of the outer while loop.  This is probably the worst offense to efficiency.

- writing to gui indicators inside the loop.  This is a medium offense.

- doing the inner For loop processing in the same loop as DAQ.  This is probably a fairly minor offense.  (It would probably be even more minor if you specified a constant # samples to read and fed the same constant to 'N' terminal of the For loop.  This would give LabVIEW some clues that it could use to be more memory efficient and reuse the auto-indexed output array.)

-Kevin P