Frequency measurement accuracy

[ScottC.]

Hey All,

I have attached a stripped down version of a VI (StrippedVI) that I am working on. This program is an interface with  dc and induction motor drives. The user is to command a certain speed or torque from the machines and the VI writes those values to the appropriate drive register. The wiring for the system also runs through a

meter box, and you will see the DAQ functions for bringing in this data.

One of the things we want the user to be able to do is put a load on the induction machine via a torque command from the dc machine. As they step up the torque, we want them to record a rise in frequency and current demanded by the machine to keep pace. The problem is that the changes are small, and as of now the frequency measurement is not stable enough to see a change. Basically, it gives valid results to only the first decimal place.

To  measure the frequency, I have utilized a subVI found here and changed it slightly to measure the current waveform (since it is more clean). I have tried to simply up the number of samples taken to get more zero crossings, but even at 5000 the measurement isn't that great and the program slows down considerably.

I have been through this code many times hoping there was a coding issue I would find that woud resolve this, and that it wasn't simply a built-in problem with how we are getting the measurement. So you know, the frequency expected is 0-60 Hz. Anybody that could give it a quick look over would be appreciated.

Thanks,

Scott

[ScottC.]

As an update, I have tried switching the indicator to a waveform chart, so that I would have a longer history of the data. I also changed the frequency measurement VI back to where it looks at the chart itself and not the data to mimic this change. This doesn't seem to be helping either. Right now the only thing that has gotten a more stable measurement is taking more samples, which slows the VI down enough as to become not worth doing.

[ScottC.]

And with the changes in samples, I seem to get about 4 good values then one or two pretty low values (the good ones will be within 0.05 and then I'll get one that drops by >.1), so I am still thinking there might be something wrong more in the approach than the data itself.

[egraham]

Hi Scott. I'm looking at your program and I'm unclear on a couple of things. It sounds like you are trying to continuously acquire analog signals, but on your VI it shows you have the sample clock set up to acquire finite samples. Then on every loop iteration you start that task to acquire your samples. Why not just set up the sample clock to acquire continuous samples?

Also, you've got a Wait ms Multiple timer in there set to 50 ms. That isn't setting the loop rate. Your event structure that is in the same loop as the acquisition will timeout every 100 ms. Your loop can't run any faster than that with the event structure in there. Typically you woud have that event structure in a second loop outside of your DAQ loop.

LabVIEW has several built in functions for continuously measuring frequency. Under waveform measurements try Extract Single Tone Information and see if that works.

Eric

[johnsold]

Scott,

1. Measuring low frequencies always takes a long time.  Measuring a frequency of 0 Hz takes infinite time. So you must decide on some lower limit of frequency (>0) that will be acceptable to your process.

2. If the number of zero crossings varies from one data set to another, I would expect some jumps in frequency resolution.  The Meas Freq of Visible

Waveform VI measures the half periods between zero crossing and then averages by dividing by the number of zero crossings.  Since your sampling and reading the DAQ buffer is not synchronized with the signal frequency, the number of half cycles per data set will change. *

3. Can you post some typical data?  Just the current waveform you are analyzing is sufficient.  Run your VI. Open the  Meas Freq of Visible Waveform VI and Edit >> Make Current Values Default.  Save (under a different name if you do not want the data in your working VI) and post the saved VI.

4. As a general rule period measurements are better at low frequencies and direct frequency measurements work better at high frequencies.  Techniques using Fourier transforms usually need at least 3 cycles (10 is better) for good results.  So they tend not to be good choices at low frequencies as well.

Lynn

* Example: Let the frequency be 32 Hz. Sampling rate is 10000 Hz. Number of samples per reading is 4000.  The period is 31.25 ms.  You will have 12.8 cycles in 400 ms.  So some data sets will have 25 half cycles = 25 zero crossings while others will have 2. In a noise free situation the zero crossings would be 312 or 313 samples apart.  312/25 = 12.48.  312/24 = 13.00.  313/25 = 12.52.  313/24 = 13.04.  Same frequency. Same algorithm.  Different results. All "wrong".  An appropriately weighted average will get the right answer.  Unfortunately you cannot tell what the appropriate weighting should be from the measured data.

[ScottC.]

Thanks for the help guys.

Eric:

THanks for pointing out the wait timer problem, silly little mistake I probably would've kept on missing. Since my last post I had actually switched to using the Single Tone Measurement. I ran through it a couple of times and it gives me the save value. As far as the DAQ settings, to be honest I had just assumed I had missed something in the code I had added. The DAQ settings were done previously, and I had hoped not to change them because the measurements were designed with them in mind. If it is the solution, however, I don't mind the work.

Lynn:

I have attached what I hope you were looking for. It was run at an IM speed of 50%, which should be ~30Hz. Obviously we won't be measuring the frequency at 0Hz, because that would correspond to no speed and we wouldn't be gaining anything. I would guess that we could easily specify one frequency these tests should be run at, most likely 50% (30 Hz) or 75% (45 Hz).

I did see the problem with losing a zero crossing, but just wasn't able to get around it besides making the data set bigger. That is why I tried switching to the chart, so that there would be a running record of data and hopefully dropping one crossing wouldn't have much effect. Unfortunately that doesn't seem to be the case.

[johnsold]

ScottC,

Thank you.  What you sent works fine.

I put a graph on the input data to see what your signal looks like.  It seems to be quite clean.  That is important for a zero crossing detector. I also put indicators on the zero crossings and differences of zero crossings arrays.  The differences range from 165 to 169.

I added the Mean and Standard Deviation VI from the Math palette in parallel with your average calculation.  It gets the same result but also calculates the standard deviation which give an indication of the error.  The standard deviation is 1.24.  This means that the calculated frequency of 29.98 Hz is an approximation.  The "real" value has a 63% chance of being between 29.76 Hz and 30.20 Hz.

Given the variability of your data and the limitations of time and sampling, you may not be able to do much better.

Lynn

[egraham]

Scott,

Is it true you're trying to measure frequency accurate to two decimal places?

Lynn,

Why not suggest performing the measurement on a data set acquired over a longer period? He could use an action engine or a shift register on his existing loop to maintain a specified period of data. Currently the measurement is on 0.4 seconds of data which is about 12 cycles at 30 Hz. What if he ran the calc on a larger set of data? Shouldn't his resolution increase as the array of data he uses increases?

Eric

[ScottC.]

That was the hope. I have done some work with the DAQ and added some averaging to the values read in, as well as looking at a longer data history, and I now have the measurement stable to the second decimal place. Unfortunately, I'm still not seeing any change like we were hoping to. I thought at the beginning that it may just not be possible to see the change but was hoping I was missing something. Thank you both for your help.

[johnsold]

Eric,

I thought of that after I left work yesterday.  I have done exactly that when needing to measure low frequencies quickly.

Here is how it works.  Take sample sets 400 ms long.  Append the new samples to the previous samples. Analyze frequency of longer set.

Details: Decide how long the long set needs to be. This will be dependent on how much averaging you need to do to get the accuracy and resolution you need and how long the frequency is stable.  In your motor/generator setup you should be able to operate at one setting long enough to get good data then change to another setting.  The rotational inertia of the machines should be enough to keep the frequency fairly stable at any given setting.

Details 2: You will need to implement a circular buffer.  Suppose you decide to keep 4 seconds of data for analysis.  That would be ten blocks of the 400 ms acquisitions. Each time a new acquisition comes in you dispose of the oldest 400 ms of data and append the newest 400 ms of data.  Circular buffers can be implemented with queues or Action Engines.

With this approach you get a new frequency reading every 400 ms but the reading is based on the last 4 seconds of data.  Of course you can change the numbers to match your needs.

Lynn