Automation 101: Open Loop Control

There is no argument that automation can be very expensive and that we have a fiduciary responsibility to our clients to provide the most economical solution possible. Every output, every input, every facet of your automation design will cost you something. There are no free rides, not even for us. But in our zest for cost savings, in our endless quest to make bricks without straw, we can quite easily short change ourselves.

There is, you see, a difference between cheap and economical. Our efforts to be economical often result in us simply being cheap. Being cheap means a low upfront cost. That is all it means. And many project managers, salesmen, cost accountants etc. get caught up in this mistake. The bottom line they look at is in the quote, not the project performance or operational budget that inevitably follows. They will buy a cheaper pump only to find that it breaks down twice as often or worse. It looks good on the initial quote, it reduces your capital expenditure, and it gets your project approved quicker. But a year down the road, after two replacements and 200 hours of downtime, it has cost you 10 times as much as the higher-priced item. We have all been there. We have all cursed the “idiot” who bought “this piece of junk” and caused our lives untold horrors and blown our entire maintenance budget on one component. And truthfully we may have been that idiot once or twice ourselves.

This problem shows up in automation in other ways as well. One manifestation of this that you and I have the joy and responsibility of dealing with is open loop control. Open loop control is the equivalent of throwing a ball with your eyes closed. You know where you would like the ball to land. You of course cannot see the target. To send the ball in what you hope was that direction. But once it leaves your hand, it could literally be anywhere in the universe and you have absolutely no way of telling where it actually is. But then you behave as though it landed perfectly.

Open loop control is a huge leap of faith at best, and sometimes just one of foolishness. You make a decision and then implement that decision with absolutely no idea what the result of that decision is. And this is the worst part: Because you have open loop control elsewhere in your system, the information that you based that original decision on may not be correct in the first place. They may be assumptions made from previous open loop controlled components. So even if the action directed by the programmable logic controller (PLC) was precisely performed, doing so may actually have been a bad decision.

For example, say that you have a motorized valve. I use them all the time. You send a signal from your PLC to the valve telling it to open. You tell the PLC to wait the required time for the actuation to take place. Then you assume it has happened and the PLC now tells the $30,000 pump to turn on and ramp up, and it does perfectly as you requested. We used to call them “Hail Mary” set points. All you got is a wish and a prayer. You are deaf and blind to what is going on in your process at that point.

Now let’s put it into perspective. What if this valve was a tank isolation valve or a divert valve between two tanks, and now your $30,000 pump is sucking from Tank B, which is bone dry, instead of Tank A that is now overflowing? And because your high level switch on Tank A is now tripped, your PLC will ramp up your variable-frequency drive (VFD) and burn out your pump all the quicker. You saved money on the encoder for the valve, some wiring, and an extra input on the PLC. There was less work in manufacturing because there was less instrumentation to wire in. But now you have an overflow in your plant, an environmental non-compliance, and a cavitated $30,000 pump along with the resultant downtime to clean up and repair or replace the pump.

We use this open loop control far too often in automation. Valve actuation, pumps, chemical addition, heaters, fans … look around your P&ID and you will see numerous applications. And what is worse than using open loop is when we apply no control at all. Many times to save money we will install manually actuated or controlled components. In fact most valves are manual. Realistically, nobody can afford to actuate everything or to include feedback in everything. That is simply not practical. But with no control and no feedback the PLC then has absolutely no clue whether or not it is in operational mode. It is possible, remember, to place feedback on critical, manually controlled devices. We end up relying on the operator to check every manual setting and ensure that it is appropriately set. Then with 24/7 manual valves we hope that it is all in order and nobody moves anything.

The solution, in my judgment, is not to put digital encoders on every valve or introduce feedback from every possible source, but to identify those places where feedback is truly necessary to prevent process issues, injuries, environmental compliance issues, or equipment damage, and find some way of determining the results of your process directives.

Look carefully at your process. Ask yourself these questions. What things can go wrong with a component operation? What is the likelihood of each of those faults occurring? Is there a human safety hazard involved? Is there an environmental safety hazard or compliance issue? How much damage would a failure cause? What would the process cost be? What would it cost to fix it? What kind of downtime would result from a failure? Then when you have identified the critical components, what is the simplest, safest, most feasible way to monitor them?

It is a short-form FMEA (Failure Mode Effects Analysis) of your system and subsystem components. These questions will help determine the need for positive feedback on actuations from your PLC, what critical inputs must be included, and what particular feedback would be the best. Do you need an encoder? Would a pressure switch be better? Or do you maybe need to monitor the actual flow? Is there an instrument currently in play whose existing feedback can be your trigger? For example, if you have a flow meter on a line, when the pump turns on, there should be a measurable flow, or change of flow. Monitoring the existing input from that meter could be your pump safety feedback in a pinch. An FMEA of your system is an extremely valuable tool for design. It will save you money, hassles, and time.

Another thing I insist on in my designs that you might want to consider is that, wherever and whenever possible, design everything to fail safe. For example, I use normally closed switches for high level because if it breaks, and the circuit thus opens, I want my PLC to think that my tank has reached high level. If I used a normally open, and it failed, I would eventually get an overflow. Simple, but so often missed by people. Similarly, using a spring return on actuated valves and having their unpowered position be a safe one is incredibly simple, but so often not done.

So don’t go for cheap, go for economical. And decide what is economical not by sticker price, not by what you can “get away with,” but take the time to perform an honest FMEA of each component in your process. Open loop control has its place, but it must be kept in its place. And whenever and wherever possible, design to fail safe. Your operator will love you for it.