Voltage-over-frequency (V/f) open loop control is based on three assumptions:

1) Motor impedance increases as the frequency increases.
2) A fixed amount of current is most desirable.
3) Motor speed can be increased easily by increasing the frequency and related voltage.

Typical V/f control is run from table-based values of for voltage (the tqdat variable in our code) and frequency (delta theta variable in our code), as illustrated in Figure 39, below. Notice that low frequency values require lower voltage values. 

Figure 39. V/f open loop control with current behavior and operational points.

When the commanded frequency increases beyond the Wops value, the only possible control is to increase the applied synchronous frequency while holding the voltage level steady at 100 %. Table values from Wmin to Wops, as plotted on the chart in Figure 39 above, are determined in the laboratory by observing the current, which is generally kept constant.

When the frequency increases beyond the Wops value, the current value decreases. Most of this decrease in current comes from the generation of back-EMF current by the rotating magnetic field. At Wmax speed, current becomes minimal. Generally we do not drive the motor beyond this maximum speed.

Figure 40. Firmware flow for open loop V/f control without any speed feedback.

V/f open-loop control, illustrated in Figure 40 above, starts with a desired motor speed. Firmware looks up the table values to set the command frequency and pre-determined voltage level. The timer is initialized and three sine waves are generated at the commanded frequency and voltage level.

An interrupt routine handles the sine wave generation using PWM values. No feedback is given regarding the motor speed; we assume that the motor is running at the speed desired. This type of control is known as open-loop control - no closed loops whatsoever are used. Generally, Wmin and Wmax depend on the motor plus load and Wops is determined by the system configuration.

This control method has two main advantages. First, it requires no measurement of current or speed. Second, it uses a simple algorithm that is easy to implement. With some experimentation, we can rotate any BLDC motor without knowing the details of its parameters. This simplicity, however, also has its disadvantages. Without feedback, we do not know at what speed the motor is running. If the load is variable, the motor speed will be variable also. If the system requires some form of speed control, a speed sensor can be added.

However, this moves us to a closed-loop control system. The open-loop method provides no reading of the current, so an overcurrent condition is possible. To protect against this condition, a shunt current resistor can be used to measure the steady-state current. This technique gives some feedback regarding speed as well as overcurrent. It may also give some feedback about the load on the motor. Adding a shunt current resistor is relatively easy and again moves us to a form of closed-loop control.

Open-loop implementation example
In Figure 41 below we have implemented open-loop control to show a profile with three-speed motor operation. We start the speed profile at 5 seconds by commanding a low speed of 2400 RPM. We use a ramp in speed, shown in Figure 42 below, to reach the commanded speed and we also use a ramp in voltage. We begin generating a sine wave with a commanded value of 1200 RPM (20Hz) and voltage (torq) value of 50% (32), because voltage is scaled 100% using a 2^6 format.

During the interrupt processing, we create a "near zero" flag when the angle (or sin_pt) is near zero. In the main routine, when the near zero flag is true, firmware changes the commanded speed by a small amount (for example, 120 RPM) and also increases the torq value by 1. Based on the speed and torq start and stop values, different ramp profiles will be generated.

Figure 41. Speed profile with three different speed values as a function of time.

Figure 42. Speed ramp from 40 to 100 Hz as a function of time

The motor is run at low speed for 60 seconds and then the speed is increased to a medium value of 3000 RPM. The motor reaches medium speed using the same ramp module. Then the motor is run for an additional 60 seconds and the commanded speed is increased to its high speed value of 3600 RPM.

We run the motor for 60 seconds at high speed, then slow it down to 1200 RPM and stop it. We wait for 5 seconds, change the index offset, and start the motor again. This time we run the motor in reverse—an important step, because we want to be sure that the motor has this ability.

Within the interrupt code, we use a port pin to output high (1) and low(0) state. When we enter the interrupt processing module, we output high (1) state on this port pin. When the interrupt processing is complete, we output low (0) state on the pin. In this way we can measure the CPU bandwidth, as Figure 43 below shows. The rising-edge to rising-edge time is our carrier-frequency time period, and the rising-edge to falling-edge time is the time it takes the firmware to execute the interrupt-processing routine.

Figure 43. CPU bandwidth measurement for open loop sinewave.

At a 16kHz carrier frequency, the measured interrupt time is 62.60 microseconds, whereas the calculated value is 62.50 microseconds. Our result is within the measurement error. The execution time is measured as 33.56 microseconds, which gives us a CPU bandwidth usage over 50%. Thus more than half of the available CPU processing time is used in this interrupt.

However, interrupt processing is the only time-critical task that the CPU has to do in this open loop implementation. Although not ideal, our open loop implementation is reasonable because it leaves about 50% of the CPU's time for performing other non-critical tasks. For closed loop, we will need to add other time critical tasks that will require us to reduce the CPU bandwidth for sine wave generation task.

Optimizing the sine code
Our next step is to optimize the code for sine wave PWM execution time for three reasons:
(1) If we want to increase the carrier frequency from 16kHz to 20 or 25kHz, then, the interrupt time is 50 and 40 ?s respectively. In this case, the CPU bandwidth usage will be 66% and 80% which is generally not acceptable.
(2) We want to add time-critical speed and current measurement tasks, and
(3) We want to add interrupt driven closed loop control code, which is a time-critical task also.

Therefore, it is better to reduce the Sine wave PWM execution time early. To improve performance, we'd like to reduce the CPU bandwidth usage from its current level of over 50%. First we measure individual times for each PWM computation, including table lookup and long multiplication. We are looking for ways to avoid table lookups because they take a lot of time. A significant amount of time is also being spent in MAX-MIN checking. If we can avoid some of this computation, we will save more CPU bandwidth. After detailed analysis, we implement the following changes in our code:

Change #1. Instead of computing the sine value for W index, we simply use the sum of the U and V sine values. This is true for one case only: when all three sine waves are 120 degrees apart. If the index difference between U, V, and W is not 120 degrees, then such replacement cannot be made. Since this technique is applicable to our implementation, we now save the time required for table lookup, long multiplication, and scaling.

Change #2. We study the upper and lower bounds of the table as well as the torq voltage variable in our code and guarantee by design that the PWM values generated by our equations will not require MAX-MIN checking. Then we eliminate these checks. This process saves more CPU bandwidth but requires that we spend time reviewing the entire code for such a guarantee.

Change #3. Finally, after making sure that we have generated a proper sine wave, we turn on the compiler optimization flag.

Listing 2

The optimized code is shown in Listing 2, above. Running this optimized code, we measure the CPU bandwidth again for comparison. As Figure 44 below shows, the CPU interrupt-processing time is now 14.31ms, down from 33.56ms required for the original code. This is a reduction of more than 50% and thus CPU bandwidth usage is significantly lower. For a 16kHz carrier frequency, interrupt time is now 62.5ms, which translates into 22.9% CPU bandwidth usage versus 53.7% with the original code. These improvements give firmware designers the freedom to add time-critical sensor measurement and closed loop control tasks that are useful in motor control.

Figure 44. CPU bandwidth for optimized code

Closed-loop scalar control
Since we have optimized the sine-wave implementation, let's now investigate closed-loop control using a scalar formulation. Closed-loop control requires some type of position sensor that can measure speed, as shown in Figure 45 below.

Figure 45. Closed loop speed control using position sensor and input capture timer.

We can get the required position feedback from a single Hall-sensor that gives one pulse per mechanical rotation, a tachometer sensor that outputs eight pulses per mechanical rotation, or from a Hall commutator that gives six signals per electrical rotation.

An input-capture function coupled with the proper counter provides two measurements: elapsed time from one input capture to a second input capture, and change in rotor position. Both measurements together provide the speed measurement. As we can infer from Figure 45 above,  the rotor position can be detected at every input capture, and using the previous input capture data, the speed of the rotation can be computed.

Since we obtain the desired speed or speed command from a pre-set profile, it is easy to implement a proportional-integral (PI) speed regulator as shown below.

A similar algorithm is deployed for the new voltage value of the sine wave. Thus, two parameters are computed for each speed measurement: a new sine frequency and a new sine voltage. In many designs, voltage calculations are not implemented because the motor at that point is already running at the operational voltage and there is no need to change it. In such cases, eliminating the voltage calculations saves CPU bandwidth.

Another form of control is based on the proportional-integral-derivative (PID) algorithm. In this method, a derivative term is added to the equation using the change in the error term.

Other terms remain the same. This method offers excellent control of acceleration and braking and is preferred by many experts. Disadvantages of PID, however, are convergence time and stability of the control. Depending on the gain values, the PID algorithm may react to small changes and continually perturb the system performance. Based on his experience, the author prefers to implement PI type control.

Hall processing
Let's take a look at the sensor processing steps and CPU time necessary to implement closed-loop scalar control. We use a single-pulse-per-rotation Hall-sensor for this implementation. A free-running, downcounting timer is started during initialization.

Then, at every Hall interrupt, this timer is stopped and the counts are moved into a variable called New_Meas. The timer is reset or reloaded and started again. A flag called new_data is set for the next task.

When the new_data flag is set, the process_hall module computes the speed. The module checks for conditions such as underflow or overflow and then calculates speed, based on one pulse per rotation. If we have implemented the type of Hall-sensor generally used for commutation signals, then speed is computed based on 60 degrees of electrical rotation. Next, the speed computation is converted into mechanical speed using proper transformation based on the number of pole pairs.

The new_data flag is cleared for the measurement task and a flag is set for the speed regulator, which we call the velocity regulator. Once the new flag has been set, the velocity regulator processes the new speed measurement and creates new values for frequency and voltage using one of the formulas previously described.

Running closed-loop control of our BLDC motor using Hall sensors and other sensors gives preliminary measurement results such as those shown in Figure 46 below. The execution times for the two tasks are as follows:

Process_halls              16 µs every Hall interrupt
Velocity_regulator     10 µs every speed measurement to every Hall interrupt

Figure 46. CPU bandwidth measurements for sensor and closed loop speed control

Now we'll analyze CPU bandwidth usage for this closed-loop control. Sine wave PWM interrupt processing time is 15 microseconds. At a 16kHz carrier frequency, this time is 16000*15, which gives an interrupt-processing time of 240000 µs.

This time period, which is required to generate a proper sine wave at a given frequency, represents nearly 24% of the CPU bandwidth at the 16kHz carrier frequency. Note that the sine wave PWM interrupt-processing execution time is not dependent on the speed. This is good news, because firmware designers will not have to calculate CPU loading every time the speed changes. The CPU usage turns out to be nearly constant at every speed.

Our execution time for speed measurement or Hall process is 16 µs. Let's use the case in which one Hall signal is sensed and processed per rotation. Because the number of times Hall processing must be performed depends on the speed of the motor, the processor bandwidth required for speed measurement will also be speed dependent.

We will create a table, called Table 4, below, for two different speeds. Note that velocity- or speed-regulator execution time is 10 µs, and is also speed dependent. This measurement also has an entry in our table. We compute the CPU bandwidth for two speed values -100Hz and 200Hz (indicating that each task must be processed 100 and 200 times). As shown in the last column of Table IV, the CPU bandwidth increases very slightly, from 24% to 24.2% and 24.5%. That is not much of an increase at all.

Table 4. CPU Bandwidth calculations for one sensor measurement and one control processing per mechanical rotation

We also want to calculate the CPU bandwidth for a case in which typical Hall commutation signals are used for speed measurements. Our motor has four pole pairs, and thus four electrical rotations per one mechanical rotation. Since there are six commutation signals per electrical rotation, the number of Hall processes has now increased by a factor of 24. We average the speed measurements for one electrical rotation and apply the velocity regulator once per electrical rotation or four times per mechanical rotation. The corresponding CPU bandwidth calculations are summarized in Table 5, below.

In this case, sine-wave generation requires the same bandwidth as before, while speed measurement and speed control is done more often and therefore require more bandwidth. However, the increase in CPU bandwidth is still not much: bandwidth usage increases from 24% to 28% and 32 %, which is an increase of only about 4% for every 6000 RPM increase.

It's important to point out that we made our calculations to show how the CPU bandwidth usage increases. The designer must still decide how to set the speed measurements and control-loop timings. If other tasks will be impacted by the 4% bandwidth increase, perhaps they can be scaled back. This kind of tweaking may have an impact on speed accuracy, but that is what optimization is all about. As we saw previously in Table 4, we can always perform speed measurement and speed control tasks only once per mechanical rotation to reduce the CPU bandwidth.

Table 5. CPU Bandwidth calculations for 4-pole-pair motor. (24 times sensor measurement and 4 times control processing per rotation.)

V/f open-loop control vs closed-loop scalar control We have discussed in detail the methods for V/f open-loop and closed-loop-scalar control and evaluated the CPU bandwidth requirements for each. Now let's compare features and benefits of each type of control method.

As the name implies, V/f open-loop provides no feedback regarding speed, while closed-loop control performs speed measurement using some sort of position sensor—for example, commutation Hall-sensors; a single Hall-sensor; an encoder with A, B quadrature and Z zero synch pulses; or a tachometer with multiple pulses per rotation.

In both the open- and closed-loop methods, the MCU generates sinusoidal modulation to the inverter drivers. However, speed-control accuracy differs significantly. Because the open-loop method does not provide either feedback correction or control of the speed, the accuracy is poor.

With closed-loop scalar control, on the other hand, the feedback on actual speed and the corrections made to the frequency and voltage generation result in highly accurate speed control. The motor rotates very close to the commanded speed in scalar control. No such expectation is possible in open-loop control, though, which cannot even tell us at what speed the motor is running.

In scalar control, however, the MCU must have an additional timer to measure the time between two position pulses, as well as input capture with interrupts. The V/f open-loop control method is relatively easy to implement at minimal cost, while the need for sensors makes scalar control somewhat more expensive.

Yashvant Jani is director of application engineering for the system LSI business unit at Renesas Technology America.

References
1. Power Electronics and Variable Frequency Drives Technology and Applications, Edited by Bimal K. Bose, IEEE Press, ISBN 0-7803-1084-5, 1997
2. Motor Control Electronics Handbook, By Richard Valentine, McGraw-Hill, ISBN 0-07-066810-8, 1998
3. FIRST Course On Power Electronics and Drives, By Ned Mohan, MNPERE, ISBN 0-9715292-2-1, 2003
4. Electric Drives, By Ned Mohan, MNPERE, ISBN 0-9715292-5-6, 2003
5. Advanced Electric Drives, Analysis, Control and Modeling using Simulink, By Ned Mohan, MNPERE, ISBN 0-9715292-0-5, 2001
6. DC Motors Speed Controls Servo Systems including Optical Encoders, The Electro-craft Engineering Handbook by Reliance Motion Control, Inc.
7. Modern Control System Theory and Application, By Stanley M. Shinners, Addison-Wesley, ISBN 0-201-07494-X, 1978
8. The Industrial Electronics Handbook, Editor-in-Chief J. David Irwin, CRC Press and IEEE Press, ISBN 0-8493-8343-9, 1997

This article is excerpted from a paper of the same name presented at the Embedded Systems Conference Boston 2006.