Calculate frequency from pulse counting

[MalteR]

Hi,

I want to calculate the frequency of a time based signal, which looks like a TTL signal for most of the time. The main goal is to calculate the flow rate of a turbine through the obtained frequency. The frequency of the turbine ranges from 0 to 2000 Hz. I tried to calculate the frequency with a "Tone measurement" block, but this gave me bad results when there is no flow occurring. From my understanding, the input voltage signal should be kind of constant when using this block, which isn't the case for my application, since there's a lot of noise when there is no flow through the turbine.

I'm using a NI 9178 chassis and a NI 9205 card. 

I've attached a picture of the TTL signal (20240529_TTL signal), which I measure with a different LabVIEW program. From my understanding, the signal looks fine. Afterwards I did rebuild the example used in this thread to count the pulses. When I run the program (attached, 20240523_MR_LabVIEW Counter simple) the counter isn't counting anything. Some help would be appreciated!

Thank you

[ZYOng]

You are using NI-9205 which is an Analog Input module, but the code you attach is running a Counter Input task, which requires a DIO module. Do you have any DIO modules?

[Kevin_Price]

Though a bit unconventional, the example you linked from John Passiak does indeed show a valid way to use a chassis counter to count pulses of an internal signal known as the "AnalogComparisonEvent" that will fire repeatedly according to the Analog Input task you have set up for the 9205.  (Aside: I haven't seen him around here in quite some years, but I would recommend you treat *all* his posts as pure gold.  Excellent stuff!)

Did you modify the example at all?  What happens when you revert to the original?  Can you confirm whether the AI task gets triggered and returns samples?  If not, you may need to explore your trigger conditions (level, hysteresis).

Having said all that, if you *have* a compatible digital module available, take ZYOng's advice and use it to take a counter-based frequency measurement directly.

-Kevin P

[MalteR]

@ZYOng:

Unfortunately, no, I haven't. That's why is used the workaround in the linked thread. I thought the solution would work with an analog module.

@Kevin_Price:

At first, I used the second example, where no trigger is needed. This one doesn't work for me, so I tried the first, more complex example with the "AnalogComparisonEvent". And this is the next point, where I have some trouble. Because I want to measure a frequency of 2k Hz at max, I'm taking 4k samples because of the Nyquist-Theorem. But I'm not really sure, which values I need to enter for "Level" and "Hysteresis", because I'm not sure what those values are telling me in this case. Do you have some advice, what kind of combination of values could give me a result?

[Kevin_Price]

Huh, I never even scrolled down to see the 2nd example.  That's a much simpler starting point -- it may be worth some extra time trying to get that method to work for you before resorting to the Analog Comparison Event workaround.  On the other hand, the footnote at the bottom of pg 7 of the spec sheet suggests that DIO access to the PFI0 pin is only available when using the module on a CRIO chassis in FPGA mode.

So we're probably back to the A.C.E. after all.  With your nominal TTL signal toggling between ~0 and ~5 volts, I would set the level at something like 2V and hysteresis at maybe 0.5V.

I'm not sure if I've explored the following and don't have hardware to do it with now.  So take this with a little grain of salt and do your own experimenting.

    I would *suspect* that the time resolution available for the A.C.E would be dependent on the sample rate of the AI task.  If you sample at 4 kHz, you'd then be stuck with a quantized time resolution of 250 usec.  In the realm of counting operations, it's pretty typical to have to deal with a minimum of +/- 1 count error in each measurement for a variety of reasons I don't have time to fully describe right now.  But the result could be when you are expecting a 2*250 usec = 500 usec interval to correspond to a 2 kHz frequency, you might instead measure 1*250 usec or 3*250 usec instead, producing apparent frequencies of 4 kHz or 1.333 kHz instead.

    So you may find that you want to sample at a much higher rate.  For example, to get 1% quantization error, you'd need time resolution that's 1/100th of your 2 kHz interval.  That means you'd need to sample at 200 kHz.

Let's pause here.  There will be more things to get into (avoiding buffer overflow errors from AI, continuous frequency sampling methods for your CTR task) down the road, but let's start by getting a basic proof of concept working by simply *counting* the total # of Analog Comparison Events as shown in the example.

-Kevin P

[MalteR]

I now tried different values for the "threshold level" as well as "hysteresis", but still no results, the "Count of Triggers" still displays 0. Sometimes it's jumping to 1, but still, the number of pulses should be a lot higher. I set the "Sample Rate" to 200k and the "Number of samples" to 50k too. 

When I display the voltage with the help of another VI I'm getting perfect pulses, as expected. So it has to be a problem with the code.

[Kevin_Price]

It'll be helpful if you'd save back your code to LV 2020 or so (from menu File->Save for Previous Version...) and post it here.

The tinkering I've done with the A.C.E. was probably with a desktop X-series device.  As I recall (and I can't vouch 100% for my memory), even when the AI task was configured for a single start trigger, the A.C.E. would react repeatedly as long as the task was running and the triggering criteria were met.  A fuzzier memory was that a level trigger would cause a pulse while an analog window was more of a toggle -- the state of the A.C.E. signal let you know if you're inside or outside the window, the edges let you know if you were entering or leaving the window.

I can't speak with any authority about the A.C.E. behavior on a cDAQ system, but start with the presumption that it would be similar until demonstrated otherwise.

-Kevin P

[MalteR]

Attached you can find the current VI for LV 2020. 

Best regards

Malte

[Kevin_Price]

I don't see a problem in the code.  Without your equipment and DAQ setup, I can only try some general nibbling around the edges to try to help troubleshoot.  First let's try to figure out whether the A.C.E. pulse only fires once on your DAQ hardware for a triggered continuous acquisition, but would fire multiple times during a sequence of triggered finite acquisitions.

Attached is a slight mod to your code.  It should now loop over a series of brief triggered finite acquisitions instead of running continuously.  See whether this helps your counter to increment its trigger count with each iteration.  Note: I added dataflow to make sure the trigger count value isn't read until *after* the AI task was successfully triggered.   I also reduced the # samples per loop to make the loop iterate faster while also being kind to the waveform graph I added.

Another thing to consider trying is to go back to continuous acquisition, but configure an "analog window" start trigger.  Perhaps *that* would cause the A.C.E. to fire multiple times within a single continuous acquisition?

It may simply turn out that your cDAQ devices behave differently than the desktop MIO device I tinkered on previously.  Or I don't remember the details of my tinkering correctly.

-Kevin P