1
\$\begingroup\$

I have a PMDC motor which is electronically controlled for speed. And it is a closed loop system. A proximity sensor is there to measure the speed of the motor and there are 12 bolts attached to the shaft of the motor so that when it rotates the proximity sensor produces 12 pulses per revolution. I have written a code to measure the rpm in which I count the pulses in one second and thus calculating the speed. But the problem is I could get a resolution of 5 rpm only. Is there anyway to get a higher resolution like 1 rpm on this system without changing the feedback technology?

\$\endgroup\$
7
  • \$\begingroup\$ Are you open to adding additional external sensors? Is the resolution you are referring to that of the RPM measurement or the change in speed as a result of the RPM measurement? I assume that by "closed loop system" you imply that the current speed of the motor is updated automatically by the measurements from the RPM sensor. What is the speed range of the motor? What is the sampling frequency of the sensor? \$\endgroup\$ May 15, 2013 at 4:32
  • \$\begingroup\$ resolution I meant is of RPM measurement. I could add additional sensor if I have no choice without touching the hardware. Yes,I mentioned I'm checking the pulses every second. \$\endgroup\$
    – raforanz
    May 15, 2013 at 4:38
  • \$\begingroup\$ speed range of the motor is 500RPM@full load \$\endgroup\$
    – raforanz
    May 15, 2013 at 4:39
  • \$\begingroup\$ You say you "count the pulses in one second" but you don't mention how many times per second you check for this pulse... If it is only once per second, you wouldn't be getting results at all since the motor rotates 8.33 times per second, producing 100 pulses per second. I guess a better question is how are you checking for this pulse in code? Is it a HI/LO state? Is it an edge trigger ISR? Also, do you know if there is any "bounce" associated with this sensor as it changes states? That would affect the results as well. \$\endgroup\$ May 15, 2013 at 4:45
  • \$\begingroup\$ It's not clear: are you 1) trying to tie into the existing pulse generator to measure the RPM yourself (and thus not change controller - just use some of its signals) 2) increase the resolution of the existing detection system but then feed the existing controller the signal is needs or 3) install a separate RPM measurement system totally or 4) something else? \$\endgroup\$ May 15, 2013 at 5:21

4 Answers 4

5
\$\begingroup\$

At 500 rpm the shaft rotates 8.3333 times per second therefore, in 1 second you count: -

12 x 8.33333 pulses = 100 pulses

At 505 rpm the shaft rotates 8.416667 times per second therefore, in 1 second you count: -

12 x 8.41667 pulses = 101 pulses

You want greater resolution so you can add more bolts BUT to get a resolution of 1 rpm you'll need 5 x 12 bolts and that sounds impractical.

You could do a rolling count over a 5 seconds and each second throw away the oldest 1 second count and introduce the newest count but you'll still have a sluggish mechanism for measuring rpm - changes in speed won't be seen as dynamically as you might want.

Alternatively you use a high frequency clock and measure the number of counts between pulses. You can average 12 results (one full revolution) to reduce positional errors of the bolts.

How fast can you clock and count?

Answer - you have a clock with period 256usecs - this means it toggles 3906 times in one second. If you count these clock toggles for every 12 pulses on the proximity sensor (aka one revolution of the shaft), at 500 rpm you'll count for 0.12 seconds and accumulate a total of 469 clock cycles. If you accumulated 468 clock cycles, this would be the equivalent of 501 rpm.

You, of course have the option of counting two or more revolutions to give greater resolution at higher speeds. At significantly lower speeds you might want to revert to counting proximity pulses per second OR clock counts for a fractional rotation of the shaft.

\$\endgroup\$
3
  • \$\begingroup\$ i can clock with a period of 256us \$\endgroup\$
    – raforanz
    May 15, 2013 at 8:22
  • \$\begingroup\$ @ Andy aka the last point in your answer(that is counting the clock between pulses) is similar to the built in capture peripheral of a micro-controller ,right? \$\endgroup\$
    – raforanz
    May 17, 2013 at 16:45
  • \$\begingroup\$ I'd set up an internal clock and counter so they run automatically and then I'd set up the input pulse to trigger an interrupt which invokes a routine that checks that 12 pulses have passed which then records the clock counts. I would then reset both the clock & pulse counters to zero for it to start all over. I have no other way of describing it because it's not my skill area. \$\endgroup\$
    – Andy aka
    May 17, 2013 at 20:36
2
\$\begingroup\$

The most accurate approach for speeds in the range you're looking at is to have each incoming pulse increment a counter and latch the value of a timer. Periodically sample the counter and latched-timer values, being certain that the sampled values "go together". For example, if you have hardware pulse-capture counter and pulse-capture circuitry wired to the same input, you might read the counter, then the captured timer value, and then read the counter again. If the two counter-reads yield different values, repeat the process. The time to retry the process is less than the minimum time between input pulses, then on the second try both timer values should match.

Once you have done this, then at your desired update interval, compute your speed in pulses per minute as:

Speed = (NewCount-EarlierCount) * TimerCountsPerMinute / (NewTimer-EarlierTimer)

Except when NewCount equals EarlierCount, this approach will yield a value whose precision is +/- one timer tick. To put it another way, if the input speed is constant, and the timer is itself accurate, the correct reading will be somewhere between

Speed = (NewCount-EarlierCount) * TimerCountsPerMinute / (NewTimer-EarlierTimer-1)

and

Speed = (NewCount-EarlierCount) * TimerCountsPerMinute / (NewTimer-EarlierTimer+1)

Using this approach, if you have a 1MHz timebase, provided your input pulses arrive at 10Hz or faster, you could update your display ten times per second and show a value that was precise to the accuracy of a typical crystal. Depending upon what you're doing, you may want to suppress updates except when the total difference between the displayed and actual readings reaches e.g. three units on the display (so that when values are changing quickly the display numbers change quickly, but if a value is alternating between 123.4 and 123.5, the display would spend enough time showing each value that a person could see it).

\$\endgroup\$
1
\$\begingroup\$

Measure the time between pulse leading or falling edges. You get a time estimate for how long it takes to go 1/12 revolution with every pulse.

\$\endgroup\$
1
\$\begingroup\$

If the minimum speed is 20 RPM then you get one revolution every three seconds, and only four pulses per second. You can't get a resolution (much less accuracy) of 1 RPM by simply counting pulses per second. To get the resolution you want at a very low pulse frequency you are going to need to determine the period between the pulses and then calculating the RPM from that. To determine the period, use the pulses to start/stop a counter. The counter must be clocked fast enough that you can still get at least 500 counts when the pulses are coming at 100 Hz (500 RPM) so you need the counter to run at 50kHz or more.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.