1. Home
  2. Electronics Design
  3. Measuring motor RPM with micro.

Measuring motor RPM with micro.

Hi all. I am trying to measure the RPM of a motor and have a few questions. The motor is turning slowly(about 132RPM after gearing). There is an "optical encoder" on the shaft that gives me 8 pulses / rev.This gives me a pulse every

56ms or so. How can I calculate the RPM of the motor WITHOUT using floating point routines and in a fairly fast time. I could wait 1 second , count the number of pulses / 8 * 60 to get RPM , but this takes far to long(1s) :0( I can measure fewer pulses , but the time is still to long. I could measure the period of 1 pulse , invert / 8 * 60 to give RPM. This is much quicker , but involves floating point routines. I can gate a timer in the micro with the pulses from the encoder to give me a count in the micro , but this will also involve floating point routines to get back to rpm. Is there a simple solution to this problem(probably) and I've missed the boat completely or am I stuck with the options I have described:0( Cheers Rob
Reply to
seegoon99
Loading thread data ...

Hi all. I am trying to measure the RPM of a motor and have a few questions. The motor is turning slowly(about 132RPM after gearing). There is an "optical encoder" on the shaft that gives me 8 pulses / rev.This gives me a pulse every

56ms or so. How can I calculate the RPM of the motor WITHOUT using floating point routines and in a fairly fast time. I could wait 1 second , count the number of pulses / 8 * 60 to get RPM , but this takes far to long(1s) :0( I can measure fewer pulses , but the time is still to long. I could measure the period of 1 pulse , invert / 8 * 60 to give RPM. This is much quicker , but involves floating point routines. I can gate a timer in the micro with the pulses from the encoder to give me a count in the micro , but this will also involve floating point routines to get back to rpm. Is there a simple solution to this problem(probably) and I've missed the boat completely or am I stuck with the options I have described:0( Cheers Rob
Reply to
seegoon99

More information needed. What range of RPM, what resolution required?

You might be able to use a lookup table for the inversion, perhaps with interpolation to increase the resolution.

Paul Burke

Reply to
Paul Burke

The 'key' is to choose your values carefully. If (for instance), you have a master clock at 2323200 Hz, and you count pulses on this between the edges of the optical encoder, then this directly gives RPM*1000. If you instead use a more readily available clock, like perhaps 8MHz, then the result needs division by 3.443, to give the RPM in the same '*1000' form. Though it sounds as if you would need FP for this, if you multiply by 74, and then right shift the result 8 times to give /256, you get division by

3.46, which may well be acceptable. This would give 131350 for the 132RPM example given. Generally if you use integers, and select a scale like this, you can achieve the same results, without needing FP maths.

Best Wishes

Reply to
Roger Hamlett

Hi there. Thanks for the reply. The rpm range is about 130 to say 700. Lookup table is a possibility.Not exactly sure how to impliment it yet. Something to look at though. Cheers Rob

Reply to
seegoon99

If you want a fast answer the best you can do is measure the period between pulses. Be aware though that the resolution with this method is better at low rpm values and worse at high values. You first step is therefore to decide what resolution you need.

If you can wait one second and count pulses then the opposite is true - resolution is better at higher rpm and vive versa.

Assuming speed is what you require the fastest method will be a look up table. You need to scale the pulse period count then check against boundaries (max and min allowed values) then subtract the minimum. Use this value as an offset into your look up table which contains the (previously calculated) rpm values.

If you micro has a 16 bit divider there may be an alternative. RPM =

60000/Tp where Tp is the period between pulses in mS. If you count is not in mS (highly likely) then some scaling will be necessary but with some thought you can usually limit it to simple shifts and a change of the divisor.

By the way, this is just the sort of problem that typifies many embedded applications and demonstrates why it is important to know your micro architecture and not to blindly code in C. Well done for thinking about the problem first.

Ian

Reply to
Ian Bell

Oi. Kids these days.

You need revolution/minute, and you have clock ticks/revolution, right?

So do the math:

revolution/minute = (clock ticks/minute)/(clock ticks/revolution)

Let's say that you have 1us clock ticks. That means you have

(60000000 clock tick/minute)/(clock ticks/rev)

That'll fit into 32 bit integers, no problem.

Want RPM in tenths? Use

(clock ticks/(minute/10))/(clock ticks/revolution)

That'll _still_ fit in 32 bit integers.

Granted, going higher will require some fancy footwork, but you should see where I'm going.

Dig through the archives of the Embedded Systems Programming magazine -- the have had more than one on doing this kind of stuff with integer math.

formatting link 

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
Reply to
Tim Wescott

I saw a guy do this in hardware with two or three banks of counters. He used the first to count, say, milliseconds in one period, then took that result and preloaded another counter which divided some fixed clock by it, giving 1/t * some factor, which he then displayed, or counted again, I don't remember exactly. but it _can_ be done. :-)

Good Luck! Rich

Reply to
Rich Grise

Divide by eight and feed it to a frequency counter. The counter can be nothing more than a software routine on a microprocessor.

--
Service to my country? Been there, Done that, and I\'ve got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida
Reply to
Michael A. Terrell

Or for a different approach, let a pulse begin an exponential discharge, and at the next pulse read the v of the discharge: pulse v = rpm. A key question here is how accurate you need it, and not how accurate at all times but how accurate where. To explain this, you might for example need it accurate at one speed, but could tolerate increaseing inaccuracy at speeds further afield..

NT

Reply to
meow2222 

--
Build a little integrator?

use the one-shot to make all the pulses one width and then use them
to charge a cap:

              +----------+
PULSES IN>----| ONE SHOT |--+--[DIODE>]--+-->OUT TO µC ADC  
              +----------+  |            |   
                            +----[R]-----+
                                         |
                                        [C]
                                         |
                                        GND
Reply to
John Fields 

--
Oops...

              +----------+
PULSES IN>----| ONE SHOT |--+--[DIODE>]--[R]--+-->OUT TO µC ADC  
              +----------+  |                 |   
                            +-------[R]-------+
                                              |
                                             [C]
                                              |
                                             GND
Reply to
John Fields

Oops! Why not just a single R/C to average the output of the one-shot?

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
|  Analog/Mixed-Signal ASIC\'s and Discrete Systems  |    manus    |
|  Phoenix, Arizona            Voice:(480)460-2350  |             |
|  E-mail Address at Website     Fax:(480)460-2142  |  Brass Rat  |
|       http://www.analog-innovations.com           |    1962     |
             
I love to cook with wine.      Sometimes I even put it in the food.
Reply to
Jim Thompson

If you drop the diode and one resistor, this nonlinear circuit turns out to be linear and cheaper.

Reply to
Mochuelo

This old thread in s.e.d might be useful......

From: Tony Williams Newsgroups: sci.electronics.design Subject: PIC; Fast frequency measurement? Date: Tue, 20 Jun 2000 10:25:57 +0100 Message-ID:

--
Tony Williams.
Reply to
Tony Williams 

--
Why not, indeed!
Reply to
John Fields 

--
Yup! Thanks.
Reply to
John Fields

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.