Embed Size (px)
Citation preview
Getting Shaft Speed without Getting the ShaftDave Wilson
Kappa Electronics
The word “sensor” has become a dirty word for many motor control engineers today. With the advent of modern sensorless control techniques, the poor motor shaft sensor has been relegated to the same social status as the 8-track tape player. But before you join the crusade to rid the universe of these pesky little devices, consider the benefit of using a shaft sensor in your design, especially for low-cost motor control applications. When speed regulation is critical (especially at low speeds), or large torque perturbations can unexpectedly occur, the lowly shaft sensor may be just what you need to save your design.
A very affordable sensor design is shown in Figure 1, where a magnetic ring is pressed onto a motor’s shaft, and the alternating North-South poles are detected via a single Hall-effect sensor.
Figure 1. Digital Tachometer Feedback
Such topologies are common in many household appliances, such as washers and countertop mixers. In fact, Figure 2 shows a motor shaft with such a speed sensor taken from a kitchen mixer. But trying to obtain accurate speed information from a digital tachometer may result in some new, colorful phrases appearing in your vocabulary. Simply counting the number of pulses that occur over a given sampling period is easy, but it results in a low-resolution velocity signal, especially at low speeds. If the width of each pulse is measured with a high frequency timer, the resolution is improved. But you need to perform a multi-precision divide operation, which takes a lot of time on most small, fixed-point processors.
Hall
Hall
Hall
Figure 2. Magnetic Ring on the Shaft of a Universal Motor Used in a Kitchen Mixer
Before raising the white flag of surrender, consider the solution shown in Figure 3. This technique requires very little processor bandwidth, and can generate velocity signals with remarkable resolution and accuracy.
Figure 3. Timer Based Speed Measurement Structure
The only hardware required is a two channel 16-bit timer, where one channel is programmed to capture both tachometer edges, and the other is used as an output compare to detect timer overflow conditions. As each new hall edge is captured, it pushes the previous captured values down the FIFO. Once the FIFO is full, velocity measurements can commence, and will be updated every time a new input edge is captured. Notice that Capture(n) and Capture(n-2) always correspond to the same edge (high-to-low or low-to-high). Performing the velocity calculation from similar edges of a digital shaft sensor usually produces much more consistent results. By performing a simple subtraction of Capture(n-2) from Capture(n), we obtain a value which turns out to be inversely proportional to the motor speed. The exact equation to calculate the motor’s speed is given below:
Equation 1.
Unfortunately, the difference between captured edge values (X) is in the denominator, and must be represented as a 16-bit value for a 16-bit timer. This can be a very time-consuming calculation, especially on an 8-bit architecture. To avoid having to calculate the above expression in real time for every new Hall-effect signal edge, the calculations are performed a priori on a PC for every possible value of X. A Look-Up-Table (LUT) of RPM values is created, which is then linked with the code. For a 16-bit capture timer, there are 65536 possible values of X. If each corresponding RPM value calculated from equation 1 is stored as 16-bit value, then the resulting LUT will be 128K bytes long! To improve memory efficiency, we must obviously compress the LUT.
As a first attempt at compression, let’s only use every 256th point (i.e., only the MSByte of X as shown in Figure 3) to create the LUT. The LSByte of X is then used to linearly interpolate between the table entries. The effectiveness of this technique is illustrated in Figure 4, where the calculated RPM value using interpolation is compared to the true results of equation 1 for every possible value of X.
0
0
0.5
1
1.5
2
error%
65536Capture(n) – Capture(n-2)0
0
0.5
1
1.5
2
error%
65536Capture(n) – Capture(n-2)
Figure 4. Error Resulting from Linear Interpolation with a Single LUT.
As can be seen, for low values of X, the error is quite large, exceeding 2% worst case! This is because the slope of the “1/x” curve being interpolated is very steep in this region. For many applications, 2% error is not acceptable.
To mitigate this problem, a larger LUT could be used, which would result in a finer increment and less error. But a more effective compression strategy can be achieved by realizing that a finer increment is only required for lower values of X, where the error function is higher. This suggests that multiple LUTs could be used to span the entire range of X values, with different sampling increments for each LUT. For example, a LUT constructed from every 16th point could be used for 0 ≤ X ≤ 4096, and the original LUT constructed from every 256 th point could be used for the rest of the X range. This strategy results in the error plot shown in Figure 5.
-0.1
-0.05
0
0.05
0.1
0 65536Capture(n) – Capture(n-2)
error%
LUT1 LUT2
-0.1
-0.05
0
0.05
0.1
0 65536Capture(n) – Capture(n-2)
error%
LUT1 LUT2
Figure 5. Error Resulting From Linear Interpolation, Dual LUTs.
As can be seen, worst case error is now bounded to less than ± 0.1%, or an improvement of more than 20x. The growing error envelop as you move to the right of the graph is the result of quantization error caused by limiting the RPM entries to 16-bit values. For higher values of X, the table entries get numerically smaller and smaller, and the quantization error as a percentage of numerical value becomes more pronounced. The total memory required for both LUTs is about 1K bytes, which is a compression factor of 128 times compared to the original uncompressed LUT. MathCad® was used to generate the two LUTs shown in Figure 5, and also evaluate the resulting errors.
From the description above, larger values of X correspond to slower speeds. But what happens when the motor is moving so slowly that it causes X to overflow its 16-bit range? In these cases, the timer will actually wrap around, resulting in chaotic velocity measurements. To prevent this from happening, one of the timer channels is programmed to act as an output compare, which serves as a watchdog to detect input pulse periods that are too long. Each time a new input edge is captured, a count value corresponding to the maximum allowable tachometer signal period (lowest possible speed) is added to the captured time from the previous edge (Capture(n-1)), and the result is stored in the output compare register. If the output compare interrupt ever fires, it is because the motor speed has dropped below the minimum speed that we can measure. When this happens, the OC ISR sets the measured velocity to zero, flushes the capture FIFO, and disables velocity calculations until the FIFO is full again. Figure 6 shows an example timeline illustrating this process. The C code responsible for processing the Hall sensor signal edges is also listed below.
Figure 6. Example Tachometer Signal Processing for Lower Speeds
CONCLUSION
calc
ulat
e v 1
set O
C to
t 1
v1 t1
v2 t2
v3 t3
v4t5
OC
tim
eout
, flu
sh b
uffe
r
OC
tim
eout
, flu
sh b
uffe
r
velocity set to 0
t4 t6 t7
v8 t8
v9 t9
v10 t10
v11 t11
calc
ulat
e v 2
set O
C to
t 2
calc
ulat
e v 3
set O
C to
t 3
calc
ulat
e v 8
set O
C to
t 8
set O
C to
t 5
set O
C to
t 6
set O
C to
t 7
calc
ulat
e v 4
set O
C to
t 4
OC
tim
eout
, flu
sh b
uffe
r
calc
ulat
e v 9
set O
C to
t 9
calc
ulat
e v 1
0se
t OC
to t 1
0
calc
ulat
e v 1
1se
t OC
to t 1
1
Hall Sensor Signal
Velocity measurement = vnOC timeout = tn
calc
ulat
e v 1
set O
C to
t 1
v1v1 t1t1
v2v2 t2t2
v3v3 t3t3
v4v4t5t5
OC
tim
eout
, flu
sh b
uffe
r
OC
tim
eout
, flu
sh b
uffe
r
velocity set to 0
t4t4 t6t6 t7t7
v8v8 t8t8
v9v9 t9t9
v10v10 t10t10
v11v11 t11t11
calc
ulat
e v 2
set O
C to
t 2
calc
ulat
e v 3
set O
C to
t 3
calc
ulat
e v 8
set O
C to
t 8
set O
C to
t 5
set O
C to
t 6
set O
C to
t 7
calc
ulat
e v 4
set O
C to
t 4
OC
tim
eout
, flu
sh b
uffe
rO
C ti
meo
ut, f
lush
buf
fer
calc
ulat
e v 9
set O
C to
t 9
calc
ulat
e v 1
0se
t OC
to t 1
0
calc
ulat
e v 1
1se
t OC
to t 1
1
Hall Sensor Signal
Velocity measurement = vnOC timeout = tn
Obtaining motor velocity information is one of the most important (and difficult) measurements you can make in a motor control system. The “1/X” period measurement technique is very popular, but the multi-precision divide associated with this can eat up lots of CPU code space and bandwidth. The technique presented in this article can measure motor velocity very accurately without requiring a divide operation. All you need is a processor with a two channel timer, and multiple LUTs occupying roughly 1K of total code space.
This technique was successfully implemented on the MC68HC9S08AWxx processor family from NXP to control a universal motor in a countertop mixer application (Figure 2). The speed sensor consisted of a six pole magnetic ring mounted on the motor shaft, resulting in three waveform periods per revolution when detected by a single Hall-effect sensor. A PID control loop was used to regulate motor speed between 2000 RPM to over 13000 RPM, in ten speed increments selectable by the user. Motor speed sensing using this technique was found to be very accurate and extremely fast over the entire speed range.
So you really can have your cake, and eat it too!
Dave [email protected]
Tachometer Signal Processing C-Code Listing:
interrupt void hall_ic (void) { word hall_period; static word measured_velocity; static word hall_0; static word hall_1; static word hall_2; hall_2 = hall_1; hall_1 = hall_0; hall_0 = HALL_CAPTURE_VAL; HALL_CHAN_FLAG = CLEAR;
if (edge_cnt == 0) /* No previous edges buffered up */ { edge_cnt ++; HALL_OVERFLOW_VAL = hall_0 + MAX_IC_COUNTS; HALL_OVERFLOW_CHAN_FLAG = CLEAR;
} else if (edge_cnt == 1) /* One previous edge buffered up */ { edge_cnt ++; }
else /* We have at least two edges buffered up, which means we can now do a period measurement */
{ velocity_OK = YES; HALL_OVERFLOW_VAL = hall_1 + MAX_IC_COUNTS; hall_period = hall_0 - hall_2; measured_velocity = v_calc (hall_period); /* Fetch velocity from LUTs and interpolate */ } }
/* OVERFLOW CODE *//*********************************************************/
interrupt void overflow (void) {
edge_cnt = 0;
HALL_OVERFLOW_CHAN_FLAG = CLEAR; HALL_OVERFLOW_VAL += MAX_IC_COUNTS; velocity_OK = NO; measured_velocity = 0; }
