convert signal encoder to rpm using USB 6251.vi

[Z00m]

Concerning increasing the precision

Hi John P,

I am having the same issues, encoder pulses to rpm with mw PCIe 6321

At first, as you are also using two counters, I took one for reading the pulses and the other one for reading the pulses' frequency. But I didn't succeed in routing the PFI of the first counter CTR0 to the second one, always got an error.

I took your example, but I changed the counter input to the counter input for angular encoders. It all works fine, still I am not satisfied by the precision of the velocity. I want to build a velocity and position control, so I need the measurements as fast and precise as possible. At a freauency of 100 Hz I get a velocity which differs from 60 rpm at slow (1000rpm) and fast revolutions (3000rpm). May be, the loop's period isn't constant enough? I haven't figured it out yet. Can you help me to reduce the error?

[John_P1]

Hi Z00m,

Based on your front panel, you have a 100 ppr encoder connected to a shaft that rotates at ~3000 RPM.  So, the resulting frequency in terms of pulses per second would be:

    100 pulses/rev * 3000 rev/min * 1 min / 60 seconds = 5000 pulses/sec

You are sampling the data at 100 Hz (every 10 ms), which means every consecutive sample should in theory increase by 50 pulses (5000 pulses/sec * 10 ms).

However, the phase of the encoder is not synchronized with the phase of the counter's sample clock.  So, depending on the exact frequency and relative phase of your encoder to the counter sample clock, you could get an error of either +1 or -1 encoder tick.  This is sometimes referred to as quantization error.  50 pulses between consecutive samples could become 49 or 51.

Converting 51 and 49 pulses per sample into RPM gives the following results:

    (51 pulses / .01 seconds) * (60 seconds / min) * (1 rev / 100 pulses) = 3060 RPM

    (49 pulses / .01 seconds) * (60 seconds / min) * (1 rev / 100 pulses) = 2940 RPM

Another way to think about it is that the resolution of your measurement with the given parameters is 60 RPM:

    (1 pulse / .01 seconds) * (60 seconds / min) * (1 rev / 100 pulses) = 60 RPM

There are two ways to increase the resolution of this particular system:

    1)  Decrease the frequency of the measurement (probably not an option given that you said that you want to receive measurements as fast as possible).

    2)  Use an encoder with a higher number of PPR.  For example, using 1000 PPR but keeping everything else the same would give a resolution of 6 RPM.

You could also technically average a number of consecutive measurements together to get a more reliable result, but this is equivalent to #1 above and doesn't seem to be suited for your application.

In summary, your existing encoder does not pulse quickly enough to be able to rapidly give you accurate measurements.  I would recommend using an encoder with a higher number of Pulses per Revolution (you can calculate the minimal PPR that you need based on your accuracy and sample requirements).

Best Regards,

[Z00m]

Hi John P,

thanks for the quick and good reply. I will try to make the best with the cheap 100 ppr encoder...and I think, this is one is helping a lot: changing the encoding type to X4 instead of X2: four times more counter incrementations and then deviding the result by four, this expectingly enhancing the resolution to 15 RPM (instead of 40) and reducing this quantizatio error; sometimes 30 RPM, but I can live with that.

Unfortunately, this is throwing after some time a buffer error.

Greetings from France

[John_P1]

Hi Z00m,

Great idea--changing the counter to x4 would give you 4 times the resolution (and 1/4 of the quantization error).

-200279 is the error that indicates that your DAQmx Buffer is overflowing.  You are sampling data at 100 Hz (once every 10 ms), but the loop is not keeping up with this data.  From your front panel screenshot, it looks like the loop is executing about once every 16 ms (62.5 Hz).  You have a few options to fix the problem:

    1.  Lower your sample clock so that the loop can keep up.  Based on the screenshot, anything 62.5 Hz or less should be OK.

    2.  Read more than one sample per loop iteration (but this is probably not ideal for a control application).

    3.  Try to speed up the performance of your loop.  Taking out the waveform chart should help.  If you can get the loop execution time down to 10 ms you should be OK sampling at 100 Hz.

Best Regards,

[Z00m]

Hi,

thanks, I did method 3. speed up performance

To increase the sampling rate of this VI, you have to delete this block "tâche fini" respectively "wait(terminate) task". This caused always the buffer error

And another issue:

This motor evaluation board I am using has also a DC load generator connected to the motor shaft. So, consider we are using a static friction right a the beginning (command voltage almost 0) and the motor is jittering a bit, we receive encoder pulses. The derivation used to obtain the RPM from these pulses results in unrealistig high velocities...or am I wrong and this board has only some EMC problems ?

Regards

[Z00m]

I have to correct me: this is also happening without any load and/or motor jittering. The counter has from the beginning on a value of 1,07374E+9

Of course, I can limit suppress these values, but I am curious to know where they come from.

[iq66]

Hi;

I am using NI 621 M series to calculate RPM.  I am not sure how to wire all the channels. I think your example use 2 counters and I followed that from Labview manual.  Can you tell me how to generate external clock and feed in to PFI channel?  That is the only problem I have.

Thank you.

[Sean_F]

Hi Zoom. How are you calculating the angular velocity? Here's an example that does this on two counters. 

Hi IQ66: You can find the counter output pin by looking at the device in MAX or in the device manual. Select the device, right click and select Device Pinouts. You'll see what pin and PFI line correspond to counter x output. For this application, you can avoid physically wiring the counter x output to be the sample clock for the second counter by making its sample clock (first counter) internal output. This KB outlines how to access internal channels. 

Hope this helps!