the ten commandments of digital control

Motor Drive & Control RSS for posts RSS for comments

The Ten Commandments of Digital Control (part 1)

Dave (Wisconsin) Wilson Dec 19 2011 15:09 PM 1

Dave Wilson, Motion Products Evangelist, Texas Instruments

Despite the fact that I now work for the Microcontroller Division of Texas Instruments; deep down, I still consider myself to be an analog engineer. I must confess that I didn’t always respect digital designers, as I used to believe their ranks were filled with slacker engineering students who flunked their Laplace Transform classes. After all, how difficult could it be to do a digital design? With an LS7400 NAND gate, there are a thousand ways to hook up the inputs and output, but only one way is correct. With an LM324 op-amp, there are also a thousand ways to hook up the inputs and output, and they are ALL correct! So I concluded that analog design was where the REAL engineers were!

Having said that, you can imagine my dismay as I watched the digital juggernaut begin devouring my analog motor control playground. One bastion after another of analog design expertise fell to the relentless onslaught of the ubiquitous microprocessor. I was inevitably dragged kicking and screaming into the digital age. But somewhere along the way, I began to see the microprocessor as a friend rather than an enemy. I soon realized that digital system design wasn’t just a copout for engineers who couldn’t solve differential equations. In fact, when viewed through the prism of the z-transform, designing digital control systems is just as challenging (if not more so) as designing an analog controller. Today it’s hard to imagine motor control without the microcontroller, as some technologies such as Field-Oriented-Control would not even be economically possible.

The process of dropping a microcontroller into the heart of a motor control system is a fairly common practice today. However, there are some

http://e2e.ti.com/members/1452723/default.aspx

subtleties that are worth mentioning, which I refer to as my “Ten Commandments of Digital Control”. I plan to write 5 blogs this week, each containing two commandments. So without further ado, here they are, counting down from commandment number 10:

10. Be prepared…Model-based code generation is coming!

While this is technically not a commandment, it is certainly a phenomenon! It won’t be long before we will be relying on computers themselves to write the actual motor control code. Today we use software drivers to abstract the hardware details of a peripheral from the rest of the software. Soon, simulation tools will be able to abstract the entire motor control software effort! Just as I was forced to embrace a different design methodology for motor control hardware, I predict we will see the same effect play out with many software engineers who have grown comfortable with writing their own motor control code. You can read more of my thoughts about this topic in a previous blog here.

9. Be skeptical…Garbage in, garbage out!

You’ve probably heard the adage that “you can put lipstick on a pig, but it’s still a pig.” The same statement applies to a beautiful simulation output which is based on a faulty interpretation of your control system. Simulation technology already plays a critical role in the motor control design process, and this trend will continue to increase as discussed above. But while this shortens the design process, it can also be dangerous if you don’t have a reference point grounded in reality to interpret the simulation results. The computer can NEVER be used as a replacement for human experience or intuition. You can read more of my thoughts on this topic in a previous blog here.

So, there you have the first two. Stay tuned for the rest of the list all this week. And in the meantime...

Keep those motors spinning!

The Ten Commandments of Digital Control (Part 2)

Dave (Wisconsin) Wilson Dec 20 2011 10:45 AM 0


This week, we are counting down to the number one commandment of digital control. Yesterday I discussed more generic issues related to simulation and code generation. But today I want to turn the spotlight onto the Analog-to-Digital Converter. The ADC is one of the most critical peripherals in a digital control application, as it forms the nexus between the analog and digital worlds. It is also one of the most misunderstood peripherals. When it comes to ADCs, many engineers are content to just know the number of bits and the conversion speed. But in digital control applications, we must dig much deeper into the ADC spec if we want to achieve satisfactory results. So continuing with our countdown, here is number 8:

8. Sample often.

Unlike an analog control system, a digital controller only gets discrete moments in time to observe and respond to the system’s behavior. This can reduce system performance if your sampling frequency is too low. Imagine driving your car while texting, and you only look up once every 10 seconds to sample your surroundings! The same effect can happen with your motor control processor. If it is too busy doing other tasks, and not looking at your motor feedback signals frequently enough, your motor will crash! For position and velocity loops, the minimum sampling frequency is dictated by the mechanical poles of your system. It is common to find position and velocity loops running at sampling frequencies of around 2-5 KHz. However, most motor control designs also include current loops. The electrical poles are much higher than the mechanical poles, so sampling frequencies for the current loops are typically between 10-20 KHz. For low inductance motors, this figure can be even higher! As a general rule of thumb, you should set the sampling frequency for a particular control loop to be at least one order of magnitude higher than the unity gain frequency of that control loop’s open-loop response. If you do this, the phase lag contribution from the sample and hold effect will be less than 18 degrees at the unity-gain frequency, as shown below. This is manageable in most cases. The only downside to higher sampling frequencies is that it requires more MIPS. But don’t worry. Eat all the MIPS you want! We’ll make more! :-)


7. Sample simultaneously and synchronously.

Often the controller is required to sample several signals to get the complete picture of what’s happening in the motor. Some of these signals (like the current) can change very rapidly. To get an accurate picture of what’s going on in the motor at that exact moment, you need to sample all of these signals as closely together as possible. Imagine trying to capture a football play by photographing different parts of the field at different times, and then splicing them together. The result will probably be a very inaccurate portrayal of the actual play. But splicing together images that were taken at exactly the same time will result in a much better picture. The same thing applies to a control system with multiple inputs. That’s why most TI processors designed for digital control contain ADCs with multiple channels which can be sampled simultaneously. Also, if your system employs an encoder or resolver, the same requirement applies to it. If you are transforming your current reading via the Park transform, the captured angle information must be acquired at exactly the same time as your current readings. If not, a spatial phase error will exist with the calculated current space vector. This problem is exacerbated at higher motor speeds.

Now let’s discuss why it is so important to sample synchronously. Most motor control systems utilize PWM signals to drive the motor. This results in your input signals being contaminated with noise consisting of integral harmonics of the PWM’s carrier frequency. Fortunately, in many cases you can “alias” out all of these noise harmonics by judiciously timing your sampling intervals to be synchronous with the PWM waveform. A common example of this is shown below, where current waveforms are sampled while using center-aligned PWMs. Right in the center of either the ON pulse or the OFF pulse of the PWM signals, the

current waveforms will be transitioning through their theoretical average values for that PWM cycle. To try and exactly time this moment via software is extremely difficult. That’s why most microcontrollers from TI designed for digital control applications allow the ADC to be optionally triggered by the PWM module. I will have more to say about this later in this series.

Tomorrow I have one more VERY important point to make about ADCs before moving into the digital control algorithm itself. So stay tuned, and in the meantime…

Keep those motors spinning! :-)


Dave (Wisconsin) Wilson Dec 21 2011 14:36 PM 0


We are now halfway through our countdown of the “Ten Commandments of Digital Control”. Yesterday we discussed the Analog-to-Digital Converter, and more specifically, the timing associated with acquiring input samples. But there is even a bigger issue looming in the weeds that can bite you if you aren’t careful. Once the ADC conversion is complete, what do the results mean? How well do you really know what the input signal is, based on looking at these bits? How many bits do you really need, and how many bits can you really trust? So now that the stage is set, let’s continue our countdown with Commandment number 6:

6. Don’t confuse accuracy with resolution.

The ADC is a critical part of your digital control system, but it is often misunderstood. Unfortunately this situation isn’t helped much by misleading claims on some ADC data sheets, where the “real” number of ADC bits is padded with “marketing bits”. According to Dictionary.com, accuracy is defined as “the condition or quality of being true, correct, or exact; freedom from error or defect; precision or exactness; correctness”. However, resolution is defined as “the act or process of resolving or separating into constituent or elementary parts”. Clearly they are not the same thing! When applied to an ADC, accuracy is related to how closely the digital result can be correlated to the actual input voltage. However, resolution is related to identifying the constituent or elementary blocks that make up the digital answer. Ideally this is the LSB value. For example, a 12-bit ADC will ideally have better resolution than a 10-bit ADC, but the accuracy may or may not be better, depending on its gain and offset errors.

While both specs are important in a digital control system, I would argue that resolution is the more important of the two. I have three reasons for saying this:

1. Calibration procedures can be applied to significantly improve the accuracy of the ADC. However, no amount of calibration can affect the resolution of the ADC. In some cases, it is possible to improve resolution by averaging multiple samples, but this is not practical when dealing with rapidly changing signals which are common in many motor control applications.

2. Inaccuracies in some closed-loop applications can be “servoed out”. For example, in a cascaded velocity loop, the output of the velocity controller sets the commanded value for the current controller. If the converted value of current is off


so that it really doesn’t represent the true current, the loop doesn’t care. The velocity loop will just command more or less current until the motor generates the required torque to fix the velocity error.

3. Finally, it is uncommon for ADC accuracy to be the weak link in the signal chain anyway. Once you compensate for the overall gain and offset errors in an ADC, the INL spec is what determines accuracy. Using the ADC on TI’s 2803x devices as an example, the INL error is only +/- 2 LSB! This corresponds to a 0.05% tolerance of a full-scale analog signal applied to the input of the ADC! In most cases, by the time you add up the worst-case inaccuracies of all the components in your amplifier circuit, you are probably way over this value to begin with.

But analog circuits do have one significant advantage…resolution. The resolution of an analog signal is theoretically one electron! Clearly the ADC can’t compete with this. If the resolving power of your ADC isn’t high enough, you end up with quantization noise in your waveforms which degrades performance. This can result in cycle-limit hunting, as the servo loop tries in vain to converge to a value which is in between two digital ADC values.

Also, I would argue that an ADC’s true resolution is limited by the differential nonlinearity (DNL) spec. If you have missing codes in the specified number of bits for that ADC, then that ADC simply cannot resolve to that number of bits. Period. For example, a competitive microcontroller boasts of an integrated 16-bit converter. But in single-conversion mode, its worst case DNL spec can’t even guarantee no missing codes in a 12-bit word length, let alone a 16 bit word! For further discussion about accuracy vs. resolution, read Jose Quinones blog on stepper motors here.

5. Use IIR filters instead of FIR filters in closed-loop applications.

OK, let’s shift gears for a moment and move into the digital control algorithm itself.

Sometimes it seems like the whole world is conspiring against you in an attempt to make your control loop burst into oscillation! But you can take control of the situation by doing a good stability analysis of your system. I like the bode-plot method best because it just seems more intuitive to me. Using this technique, it is easy to see why IIR filters are preferred in closed-loop structures to FIR filters. For example, below is a bode-plot of the frequency response of an “N-point-averager” (which is in fact an FIR filter), compared to a single-pole IIR filter designed to have roughly the same filtering capability. In particular, notice the phase lag generated by the FIR filter compared to the IIR filter. This is important because phase lag is your enemy when it comes to designing a stable system. Also notice that the filter changes the polarity of the signal each time its frequency passes through a zero in

the magnitude plot, as indicated by the 180 degree discontinuities in the phase plot. If the open-loop unity-gain frequency of your control system happens to be close to one of these zeros, you may find that the operation of the loop changes radically with small changes in the power supply voltage or temperature.

Finally, FIR filters take more memory and also more MIPs (one MAC instruction for each tap in the filter) than their IIR counterparts. But they do possess one significant advantage…their transfer function contains only zeros. This is because an FIR filter doesn’t have any feedback paths, which means it will always be stable. However, an IIR filter does contain feedback paths that create poles in its transfer function. You must be very careful where you place these poles, or the filter will become unstable. And once any component in your control loop is unstable, the whole loop will be unstable.

Tomorrow we will continue our stroll through the digital control loop, and explore another structure which can not only improve stability, but improve dynamic response as well! In the meantime…


he Ten Commandments of Digital Control (Part 4)



This week we are counting down the Ten Commandments of Digital Control, and we are only one day away from the NUMBER ONE Commandment. Before discussing today’s Commandments, Let’s review the first six:

10. Be prepared…Model-based code generation is coming!

9. Be skeptical…Garbage in, garbage out!

8. Sample often.

7. Sample simultaneously and synchronously.

6. Don’t confuse accuracy with resolution.

5. Use IIR filters instead of FIR filters in closed-loop applications.

Yesterday I mentioned a control structure that can not only improve stability, but can improve the dynamic response of your system as well. This leads to Commandment number 4:

4. Use feed-forward structures to supplement feedback structures whenever possible.

When I took control theory in the late 70’s, we never learned about feedforward systems. Everything was based on feedback and “G/(1+GH)”. If I wanted a stiff response out of my control loop, the only thing I knew to do was to jack up my gain until my system was just shy of oscillation! But then I read an article by Curtis Wilson (no relation) in the mid 90’s about feedforward control, and it changed the way I think about control systems. As an example of how feedforward works, consider that you have a motor where you want to control its current. The feedback approach would involve sampling the motor current, comparing it to your desired current to generate an error signal, and then feeding that error signal into a control structure to drive the motor’s voltage. But the feedforward approach would ask, “what is the equation for motor voltage v(t)as a function of current i(t)?” Once the equation is defined, you simply set i(t) in the equation equal to your commanded current, and solve for the voltage v(t) required to achieve this current. Assuming


your transfer function is correct, if you then apply that voltage waveform to the motor winding, you should get the desired current waveform.

Feedforward structures are much faster than feedback structures in most cases. This is because a feedback structure has to first develop an error between the commanded and feedback values before it can generate a response. But the feedforward structure doesn’t work on the principle of error. It simply calculates the theoretical value which needs to be applied to your plant’s input (e.g., voltage) to make its output equal to the commanded input value (e.g., current). And it does this without affecting the stability of your system at all, since it does not utilize a feedback loop!

While feedforward structures are great for designing control systems that respond quickly to input changes, they don’t do so well with unpredictable changes in the load or plant. However, this is an area that feedback structures do very well. So, the ultimate solution is a hybrid approach where you use a feed-forward structure to do the heavy lifting to improve transient response when the input changes quickly, and then use feedback to correct for drifting and other unpredictable low frequency effects. In order for the feedback loop to do this, its gain can be set to a fraction of what it would have to be if it was also responsible for the transient response. And lower gains equal better stability! An example of a hybrid feedback/feed-forward controller is shown below.

3. Use observers to snoop on “shy” signals.

Many times you need access to a reclusive signal that you can’t directly measure, such as the back-EMF signal inside a motor, or the angle of the rotor flux. However, if this signal has a well defined relationship to other signals that you DO have access to, you can use something called an OBSERVER to squeeze the missing signal out of the other signals! I continue to be amazed at how well this works! These little filters are incredibly clever, and can seemingly pull a signal out of thin air. By the way, an observer is an example of a feedback structure working in tandem with a feed-forward structure, just like we talked about in the previous section.

There are many different types of observers…too numerous to cover here. Below is an example of a velocity observer typical of what you might find in a digital control system utilizing an encoder. Trying to squeeze velocity information out of an encoder can be daunting, especially if the encoder is moving very slowly. If you simply measure the difference between encoder counts at each sampling update, you end up with a very quantized velocity signal at low motor speeds. On the other hand, if you measure the time between encoder edge transitions, you have lots of numerical resolution, but your velocity sampling frequency gets trashed at low motor speeds. However, an observer can run at the same sampling frequency as the rest of your control loop, and it creates a velocity signal with as much resolution as you want. The feedforward current input signal allows the observer to estimate the velocity signal with zero or near zero phase lag! This is really cool stuff!

We’ve now made it through eight of the Ten Commandments for digital control, but we’ve managed to steer clear of perhaps the most important single peripheral in a digital control application…the PWM module. Tomorrow we will take aim at this module in an attempt to unlock its digital control secrets. In the meantime…





For those of you just joining our discussion, we have been counting down the “Ten Commandments of Digital Control” all this week, leading up to the number one commandment today. But before we get to numero uno, there is another very important aspect of digital control that we need to look at; and that is the PWM process. Just as the ADC is the nexus between the analog and digital worlds, the PWM module does the same function back into the analog world. Considering its strategic contribution to the performance of your control loop, it is only fitting that we devote some time discussing it. So, here’s rule number two:

2. Remember…All PWMs are NOT created equal!

The concept of modulating a control signal on top of a high frequency carrier seems simple enough. But as someone who has designed several different PWM modules, I can attest to the fact that there are many subtleties which can either make or break your control system’s performance. I recall earlier in my career being asked to evaluate a processor for the motor control market. Everything about it was great, except…there was one feature missing in the PWM module that killed its prospects for motor control. A single trigger signal between the PWM module and the ADC converter, because it wasn’t there, made all the difference!

When selecting a PWM module for your digital control application, here are a few features you might want to check out first:

a. PWM resolution. Just as resolution was important with the ADC, so it is also important with your PWM signal. I once designed a servo system using a processor with only 8-bits of PWM resolution, and immediately ran into problems with position dithering. With most PWM modules that use a digital counter to generate the carrier, you end up trading off maximum PWM frequency for resolution, which is dependent on your counter clock frequency. For digital power applications, this can really be a BIG problem. That is why the PWM modules on many of TI’s PiccoloTM family have a high resolution mode which allows 150 pS of resolution! (That’s right…”p” as in Pico-Seconds!)

b. Dead-time. Most PWM modules designed for digital control are capable of directly driving a top and bottom transistor in a totem-pole configuration. This means that each pair of PWM outputs includes a programmable dead-time that is inserted between the turn-off of one PWM signal, and the turn-on of the


complementary PWM signal. For most applications, a single dead-time value for all of the transistors is good enough. But in more advanced PWM modules, each complimentary PWM pair can have its OWN dead-time value, and in some cases, even different dead-times for the top and bottom transistors.

c. PWM channel alignment. This is too big of a topic to cover all of it here, but suffice it to say that how your PWM signals are aligned from phase to phase (e.g., center-aligned, edge-aligned, asymmetrical alignment) has a HUGE impact on the harmonic content of the PWM signals as seen by the motor. Make sure your selected PWM module can generate the alignment modes that will give you the best performance for your application.

d. PWM update rate. Most PWM modules have double-buffered PWM value registers, meaning that the PWM values from the software are loaded to an outer set of registers, and then this data is transferred to the active PWM registers at the start of the PWM cycle. However, what many engineers fail to remember is that this adds phase delay to your control system, and must be considered in any stability analysis of your system. While the data is sitting in these outer registers, it is becoming stale. Many PWM modules (such as the ones on our Piccolo family of processors) have the ability to be updated TWICE during each PWM cycle. This not only improves your phase margin a bit, but it allows your system sampling frequency to actually be twice the PWM frequency. This is also a very useful feature with Space Vector Modulated (SVM) systems, since there are two SVM periods for each PWM period.

e. ADC triggering. As discussed in part 2 of this series, the PWM module and ADC module must be intimately linked in order to remove the PWM harmonics in the ADC input samples. As illustrated in that blog, you want to sample motor currents at exactly the center point of the ON and OFF pulses to achieve this. Ideally this point occurs when the digital counter reaches its maximum and minimum count values when programmed for up/down operation, which is why many PWM modules generate a trigger signal during these moments to use with the ADC. However, depending on how the dead-time is implemented, this can delay the centers of the pulses by a small amount. As a result, some advanced PWM modules (once again, like the one on the Piccolo :-) ) can make use of any unused PWM channel to generate the ADC trigger pulse. This allows the ADC to be triggered literally anywhere within the PWM cycle.

f. Fault Processing. In many motor control applications, safety requirements dictate the necessity to be able to bring your PWMs off-line via hardware the moment a problem is detected. PWM modules designed for digital control usually contain one or more hardware fault inputs for this purpose. On many of the advanced PWM modules, the fault signals can be supplied by an on-board analog comparator, which can directly monitor the level of a hardware signal and automatically generate a fault if the signal goes above or below a software specified

voltage level. The PWMs on the Piccolo 2803x processors contain three analog comparators on-board which can be used for this purpose.

There are other features that you will want to check out as well, but these are the main ones to focus on. Be prepared to become intimate with the PWM module of whatever processor you use in your digital control design.

And now, (drum-roll please)…the Number One Commandment of Digital Control!

1. You can’t go wrong with TI!

Now before you write this whole series off as a giant sales pitch, please consider what I’m about to say here, because I wouldn’t say it if I didn’t totally believe it! In the middle of the last century, there was a saying that “you will never be fired for designing in an IBM computer”. As a young engineer evaluating DSPs for a six-axis controller for a scanning electron microscope, I still remember my boss telling me the same thing about TI! …and he was right! Texas Instruments has a rich history of innovation and early pioneering in motor control. Many features that we take for granted today in the motor control industry were developed and introduced by TI. And the innovation continues. At TI, motor control is not just something we do, it is part of who we are! We are currently making breakthroughs on new hardware features for motor control processors, as well as unbelievable new algorithms to drive your motors. I wish I could tell you more, but suffice it to say that 2012 is going to be a GREAT year for TI in motor control! So stay tuned…

Here’s wishing you and yours a happy and prosperous new year in 2012! I hope the prospects for you personally are as enriching and exciting as I believe they will be for us Motor-heads here at TI! And of course…


See you next year…

the ten commandments of digital control

Documents