Copyright 1992, Jack G. Ganssle

Abstract

As a designer, you can make decisions that greatly impact the environment. Here's how to save energy.

Published in Embedded Systems Programming, June 1992

I just finished reading Al Gore's compelling "Earth in the Balance", which gives a blueprint for a way out of the abyss of global warming and ozone depletion.

Senator Gore misses an important opportunity.

Information processing can replace "things". Information, which can be neither seen nor felt, which consumes no resources and pollutes not at all (unless, as Senator Gore asserts, you consider data about nuclear weapon design a form of informational toxic waste), actually replaces iron and coal, silicon and circuit boards. A smart thermostat reduces energy use (and thus, coal consumption) by lightening the furnace's workload. Microprocessor-based lawn sprinklers shut off the faucet even when forgetful humans do not. Distributed processing in an airplane replaces miles of heavy (and environmentally costly) copper wire.

Did you know that the Sunday edition of the New York Times consumes 75,000 trees every week? It's pretty clear that someday newspapers will be downloaded to our personal terminals. Phone numbers change so quickly that fewer and fewer of us use paper-consuming phone books; in France these were abolished in favor of the electronic Minitel system years ago.

Personally, I believe that high integration electronics, coupled with clever code and good algorithms, offer the most realistic near term solutions for many of our looming environmental crisises.

We embedded designers are the guardians of this technology. We should look at every decision we make in terms of its environmental impact. Some simple decisions we make in high volume applications make a big difference. For example, in a printer, shut down the motors when they are not needed. This little software addition prolongs the motor life and reduces energy consumption. It benefits for both the world and your customer. Motor Alternatives

Lights and motors consume the bulk of the electricity produced in this country. It would seem logical, therefore, to concentrate on making both much more efficient. The new compact florescent light bulbs can go a long way to optimizing electricity used for illumination, but it seems little thought goes into the motor problem. We're not talking about trivialities here - one report I saw pegged motor power at 50% of all electricity used.

No doubt new motor designs based on rare-earth magnets and other technologies will some day make the motors themselves more efficient. However, as embedded designers there are a number of things we can do now to use them in a more earth-friendly manner.

Sometimes you can just yank the motor out of the system altogether. Clever use of CMOS logic can sometimes reduce the need for fans, for example. Or, where a little cooling is really needed, new piezzo-electic fans move small amounts of air without generating wasteful heat.

An alternative approach is to use appropriate technology. I'm writing this on a beautiful little Librex notebook computer, which has a micro-motor driving the itty-bitty 60mb hard disk. The Librex is not a CAD machine, but it excels at word processing and the more routine tasks that actually consume 99% of the average person's day. Overdesigning generates a product that costs and consumes more. Motor Problems

Smaller motion controllers usually use DC (Direct Current) motors. They are cheap and easy to control. Hard disk drives, autopilot actuators, windshield wipers, and the like all use DC motors.

The torque produced by a DC motor is proportional to the applied current. The (unloaded) angular shaft speed is a function of voltage. It's interesting to apply power to one of these while holding it in your hand. Even a little toy motor will suddenly jerk in opposition to the sudden inrush of current when first switched on. How often do you really need all of that torque?

Even a lightly loaded motor will start with a huge torque surge because of the way the units are built. They really are little more than windings of wire, which act as electrical inductors. As every first year EE knows, inductor current is equal to the change in voltage, or:

i= L (dv/dt)

where i is current, L is the size of the inductor, and dv/dt is calculus-speak for the rate of change of voltage.

Conventional systems that close a relay or enable a transistor to suddenly start the motor generate a very rapid build up of voltage, driving the current consumed to an instantaneous very high value. Given that motor torque is proportional to current, this causes the motor to start with a bang.

A lot of systems just cannot use all of that initial torque. The railroads understand this problem. Most modern locomotives are diesel- electric, where a big generator makes electricity to run a motor that drives the wheels. (You can't drive the wheels with a gas or diesel engine directly, because internal combustion engines produce no torque at zero speed, and you surely don't want to slip a clutch on a several thousand ton train!) If the drive wheels received all of the power the motor could make at once, the wheels would spin, generating no drive and damaging the mechanical components.

To sum this up: starting a motor quickly just wastes power, unless that very high torque surge is really needed. Systems much smaller than a locomotive will suffer from wasted power, spinning wheels (or some other manifestation of over torquing), and overloaded geartrains leading to premature failures.

In non-positive drive situations (like the train - the wheels are not cogged; they rely only on friction) you cannot put a position encoder on the drive wheel if there is any chance the wheels will spin. Thus, over torquing the motor also can require you to add an expensive idler wheel just to drive an encoder. I know, having made this mistake years ago on a huge PDP-11 controlled moving instrumentation cluster.

Finally, driving a motor hard will produce electrical noise that will appear all over the spectrum. I remember a steel plant that used a house-size reversing motor to run the plate mill. Once every few seconds, as the motor reversed direction, enough energy was radiated to destroy unprotected electronics.

You can eliminate all of these problems by using smarter motor-control software and some additional electronics. Accelerate the motor slowly, building up the current drive until it reaches the required speed.

Start Slow!

The simplest acceleration technique is just to have the software drive a digital to analog converter with increasing values. The output of the D/A is amplified and applied to the motor's terminals. A timer generates an interrupt ever millisecond or so; the service routine adds some offset to the current D/A value and returns. Once the desired operating speed is reached, stop the addition!

If you add a constant to the D/A on each interrupt, the velocity profile is trapezoidal. It ramps linearly up to a maximum value and then stops at that value. This is a big improvement over hard starting the motor, but will not give the most efficient torque versus power consumption.

A better solution is a parabolic velocity profile. Bring the motor up to speed non-linearly, following some sort of parabolic curve shape. Remember that a parabola is defined by y=ax**2.

Parabolic profiles are almost never used because they are considered to be harder to implement in the software. Sure, more code is involved, but the problem is not very difficult. If you just want to get a motor going from stopped to full bore in some fixed period of time, build a table of values to add to the D/A output on each interrupt. These will start off as being rather large, and will taper of as the maximum speed is reached. Write a little Turbo-C program to calculate the table values, creating them along an x**2 parabolic curve shape.

The problem is a bit harder if the system incorporates feedback. Suppose the motor must run at some very specific speed, like in a CD player or a hard disk drive. Some sort of encoder will give a pulse indicating the system's current rotational speed. It's impossible to generate an a priori parabola that will reach the desired velocity. One solution is to use a modified parabola that gets the angular rotation within, say, 90% of the correct value using a pre-computed table. Then, switch to a linear dynamically computed algorithm to bring the motor the last little bit of the way up to speed. Switchers

Driving a DC motor from a D/A converter tends to use a lot of expensive electronics. Sometimes these circuits waste more power than you can save with your clever algorithms. In the last decade or so switching power supply technology has come into its own. Switchers, as they are colloquially known, are very efficient and waste minimal power. Switching techniques are sometimes used to control motors as well.

You cannot make a switcher that drives a linearly increasing voltage to the motor. Switchers are either off or on; you'll put out full power or none. This sounds as bad as the situation we started with, where simply turning the motor on consumed lots of power and created a slew of other problems.

We can still replace power consumption with information processing. Design the software to produce a series of pulses to the motor control electronics. Vary the width of the pulses to control the motor's speed.

Each pulse causes a magnetic field to build up and collapse inside of the motor. The motor does not rapidly start and stop, since these fields take surprisingly long periods of time to decay. The motor ees an almost analog drive; the field created by the current pulse just complements the decaying field from the previous one.

This technique is called Pulse Width Modulation (PWM). You can create an energy efficient velocity profile with PWM by varying the pulse widths to drive the motor to speed slowly.

While it is certainly possible to have really smart code that generates each pulse, it makes more sense to use a pair of retriggerable timers. That is, the timers count to zero and then restart automatically from some programmed value. Connect them so the first timer starts the second when it counts to zero; the first restarts when the second completes. Tie the output of the first timer to the switcher that drives the motor.

By varying the count down values of the two timers you can make any pulse width needed. Generally, I load complementary values into timer 1 and timer 2 so that as timer 1 gets longer, timer 2 gets shorter. At the limit of full speed operation the motor sees essentially a DC pulseless signal.

The software can load a velocity profile from tables as before. However, these values are now count down values for the timers. Every millisecond or so modify the pulse shape. There is no reason not to generate a parabolic profile to reduce energy wastage.

Sometimes you need every bit of usable torque possible during motor startup. The heavily loaded train will get underway best if the torque is just a bit less than that required to spin the drive wheel. One way to handle this is to ramp up the motor current until the wheel just starts to spin, and then back it off. You can accommodate varying conditions this way (say, water on the track). It is possible to monitor the wheel slippage just by looking at the current the motor consumes; if it suddenly drops off, then less torque is being produced and consumed, indicating that the wheel has started to spin.

Stepper motors are often selected for applications where the computer controls a motor to move something to a specific spot, because of the ease of controlling their absolute angular position. A conventional DC motor is also an option. This is a tough problem, and is best solved with a PID (Proportional Integral Differential) algorithm. PID loops are beyond the scope of this article. Intel's AP-428 Application Note has some canned code and flowcharts for PID motor control using the 80196 processor. Braking

When it's time to stop a DC motor you can decelerate it along a trapezoidal or parabolic profile. When coupled with a PID algorithm you get high efficiency control of the motor's position.

However, if you really don't care what the position of the motor is (say, if you are just turning a motor off in a printer), consider using smart braking. Don't just remove the power and let the motor coast to a stop; harness the energy in the motor's rotational inertia to do something useful.

Steve Roberts is a fairly well known biker (pedal biker, that is). His bike is a miracle of embedded engineering. Some micros control navigation, others handle power needs. He has a built-in Mac and DOS machine, with keypads installed in the handgrips so he can type while riding.

His breaking system is "regenerative"; instead of converting the machine's forward momentum to heat as normal friction brakes do, he couples the wheels to small motors. The motors drive his electrical charging system. The motors are engaged electrically only during braking, and act as generators, supplying an important amount of energy to his batteries.

Any system with a motor can use this principle. Sure, most of the time it is more trouble than it is worth, but with the new proliferation of micro-power embedded systems, it makes sense to at least consider regenerative braking for each DC motor.

The technique is simple; remove power from the motor, and have the software command the electronics to connect a load across the motor. The load could be a rechargable battery. It could even be the system battery (be sure it is diode isolated). Conclusion

Think green when designing embedded systems. You will be making a big difference.

Though I took a cheap shot at Al Gore's new book, it is indeed a great work I highly recommend to thinking people. In this campaign season it is nice to see a politician, any politician, take a courageous, well thought out stand.

Reference: "Earth in the Balance", by Al Gore, 1992, Houghton Mifflin Company, NY, NY

Reference: "Distributed Motor Control Using the 80C196KB", Application Note AP-428, Intel Corporation, 1989. Order Number 270701-001.