Teenagers know what is “cool”. And this week I have two teenage votes in the cool column for the PID control algorithm on the Segway Human Transporter. Well…almost! This week, I took a family vacation to California. It was great to get away from the cold, wind, and snow of Pennsylvania. My two teenage sons and I decided to take a Segway tour of San Francisco, with San Francisco Segway Tours.

If you haven’t seen one, a Segway is a two-wheeled scooter-like device that somehow manages to stand upright, go forward and reverse, and turn tight zero-radius circles. You can find pictures and product info on http://www.segway.com/

After a short training session, we followed our tour guide for a 2+ hour tour of San Francisco. We went up and down hills, through North Beach, past many San Francisco landmarks, and finally out onto the piers near San Francisco Bay. At a top speed of about 10 miles per hour, it was a lot more efficient and less tiring than walking. It was a sunny day, and the sight-seeing was great. But that’s not the best of it…

The controls are actually the cool part. The Segway has mini gyroscope-like devices to measure the angles and the angular momentum of the Segway (and its passenger). The controller moves the two wheels to keep you upright. When you first step up onto the platform, and it feels for a second like you will thrown off. This is because your own system is fighting the Segway to keep you upright. Just relax, and in 5 seconds, you are standing upright, balanced by the machine.

Lean slightly forward, and the machine glides forward. Shift back toward your heels, and it stops. Even though you are only on two wheels, you remain perfectly upright. The angle is being controlled by a PID algorithm, execution 100 times per second, making minute adjustments to the two motors.

There is great article on the Segway available on How Stuff Works. Check it out if you want more details.

In just a few minutes of riding time, the Segway seems completely natural. You don’t even have to think about starting and stopping. You body adapts to the weight shifts pretty easily. In a couple of hours, we covered most of downtown San Francisco, including Lombard Street (not the steep part!), Coit Tower, North Beach, Fisherman’s Wharf, and Ghirardelli Square.

As we finished our trip, zooming around a concrete pier that juts into San Francisco Bay, I couldn’t resist being the “nerdy dad”. I had to explain to my sons how this contraption works. Believe it or not, they actually thought that PID was “cool”!


OK, so you want to be a process control guru. Can you explain your job in one sentence?

Not so easy, is it? Try explaining it to your Mom, or your Grandma, or your neighbor, grocer, or kid’s basketball coach. You might say something like “I work in the automation of process plants, like oil refineries, paper plants, and chemical plants.” That still doesn’t really explain what you DO. Trying to explain it in any level of detail, and you’ll have to explain HMIs, PIDs, PLCs, DCSs, and a host of other TLAs (Three-Letter Acronyms..ha ha).

It is simply a fact that our industry has a lot of jargon. To the layman, it can seem like we are talking another language. “We’re using fieldbus, so we upgraded to Smart IO, but our DCS HMI can’t show the diagnostics, so maybe we should have stayed with 4 to 20 milli-amps.” You get a puzzled look from operators, managers, and even engineers from other fields. How can we combat this problem?

When I first started as a control engineer, DCSs were “the new thing”, and they weren’t well-understood. I began to think of myself as a ‘translator’. I spent a good deal of my time explaining to managers and operators. They wanted to know about costs and benefits of DCSs. They also wanted to know how they worked, why they would be reliable, and so on. I had to find ways of explaining new concepts (even “network” was a relatively new term to many). The more they knew, the easier it was for me to do my “real job”, actually implementing the DCS systems.

Explaining ourselves does not always come naturally to we engineers. We draw on a different base of experience than “lay people”, and we can come across as arrogant if we over-explain. So it is a good idea to practice how we communicate. Here are some suggestions for how we can practice explaining ourselves:

1. Explain your job to a 5-year-old.
2. Explain your job to a grandparent, or someone who doesn’t use computers.
3. Practice an “elevator speech”. Imagine you have 30 seconds to convince your boss’s boss to fund your next big project. What would you say? Now, practice it. Really. Say it out loud. Time yourself. Don’t waste a single word.
4. Try to explain something complicated in a simple picture. Try “ratio control”, or “feedforward”. You are limited to a half a sheet of paper, or one napkin. No more than 5 written words allowed.

These are just some practice exercises to help you develop your ability to get your point across quickly, and simply, without drifting back into “control engineer language.” Good luck with it.

By the way, here’s a cool example of visual communication from a mathematician:

OK, so here’s a shameless plug for my short book “Mastering Split-Range Control”. It’s 30 pages, with everything you could ever want to know about Split-Range Control. Available via Amazon CreateSpace at: https://www.createspace.com/3395995 .

Split-range control uses a single controller with two control valves to maintain a single process variable. It can be used for a variety of applications, such as heating and cooling of a tank or a room. Split-range control is widely used in the process industries, such as pulp and paper, oil and petrochemicals, and mining.

The book covers all aspects of the use of split-range control. Starting with the basics, the book discusses when to use split-range and when not to, costs and benefits, how to configure the control strategy, how to calibrate the valves, how to tune the loops, and even how to train operators and troubleshoot problems. Color pictures illustrate the key concepts.

Ah, summer! Time for days at the beach, relaxing with family. Take some downtime around the house, order take-out food, and let teh laundry go for a few days. It feels to good that we don’t have to be “in control” all the time.

But what about your plant? Can you afford for it to not be “in control”?

It may surprise you to find out that, in a typical plant, 30% of control loops are running in MANUAL. That is, they are not “in control” at all. Any upset that comes along passes right through!

This can lead to losses in efficiency, and greater potential for safety or environmental problems. In fact, control loops left in manual have been found at the root cause of several industrial disasters.

Should you run out to the plant, and force everything into AUTO? No, no, no!! Control Loops in MANUAL are more of a symptom than a problem. Usually, the operator put the loop in MANUAL for a reason: The tuning was bad, the instrument failed, or there was a control valve problem.

As a good control guru, you want to be sure that your plant stays “in control”, even while you are out on vacation. Here are some suggestions:
1. Start by understanding the extent of the problem in your plant. Monitor the % of control loops in MANUAL using on-line tools, like Control Loop Monitoring.
2. For each loop, make sure you understand WHY it was left in MANUAL. Ask the operators. Then resolve the root cause issue.
3. Continue to monitor for loops in MANUAL. This is a very effective way to spot new problems when they occur, even if the operator forgot to tell you about it.

I recently flew in a small single-engine airplane, equipped with an autopilot. As we cruised along at 17,000 feet, I had a chance to find out exactly how the autopilot worked.

I had heard that most auto-pilots were simple proportional-only controllers. But I could see right away that this auto-pilot must have some integral action as well.

I could see this because the controller managed to get the altitude exactly right. There was never an “offset”. You may recall from your control theory that a P-only controller will always be vexed by “offset” – a permanent error between SP and PV, except at one setpoint value.

There is no Derivative action in the autopilot, for fairly obvious reasons. (imagine how it would react to turbulence!)

The excellent control of altitude (and heading) was cool enough. But what really caught my attention was the mechanism for changing controller setpoints.

A small LCD input device allowed the pilot to provide a new setpoint for altitude AND a vertical speed setpoint…essentially setting a setpoint ramp rate. What a simple interface for some fairly complex control.

Keep in mind that ramping between two setpoints is an EXCELLENT technique to reduce control variation. When you make sudden setpoint changes, the process responds jerkily, and downstream operations may be affected. When you ramp between setpoints, the transition can be as gradual as you want it to be.

Most DCS systems can be configured to allow setpoint ramping. However, it may not always be easy to configure or to operate.

The auto pilot also used “PV Tracking”. This means that while the controller was in MANUAL, the setpoint was continually adjusted to match the PV. This provides for a “bumpless transfer” when the controller returns to AUTO. The downside is that you must be vigilant about putting the setpoint back to where you want it when you go to AUTO.

The controller had more cool features. You could pull the PV information from a variety of sources (altimeter, GPS), and, of course, there were many ways to quickly disable or override the autopilot.

The point of all of this is…Always be on the lookout for more ways to become a better process control guru. You may find examples all around you.