Control systems engineering 6th edition pdf download

control system engineering objective questions and answers and also control systems engineering a practical approach
ZackVincent Profile Pic
ZackVincent,United Kingdom,Teacher
Published Date:15-07-2017
Your Website URL(Optional)
            Control Systems Engineering  A Practical Approach  by Frank Owen, PhD, P.E.  Mechanical Engineering Department  California Polytechnic State University  San Luis Obispo, California  May 2012                                                    © by Frank Owen, May 2012 Table of Contents    Preface    Acknowledgements    Chapter 1 – Introduction to control systems    Chapter 2 – Laplace transformations    Chapter 3 – System modeling    Chapter 4 – First‐ and second‐order system response    Chapter 5 – Stability    Chapter 6 – Steady‐state error    Chapter 7 – Root locus    Chapter 8 – Frequency response    Chapter 9 – Designing and tuning PID controllers    Chapter 10 – An introduction to digital control         Preface   Preface  Why this book?  This book has been written for controls students at Cal Poly quite simply to save them money.  There are  many, many good controls books available, but they have, in my opinion, three flaws.    1)  They are very expensive.    2)   They are rather reference books than a basic, first book—what one needs when first approaching  the subject.  Thus we have found at Cal Poly that we buy a book for a lot of money and then use only  a small part of it.  It is not that the parts that we don’t use don’t have any value.  They do.  But one  doesn’t need to buy a complete reference book to understand the basics and the essentials of a  topic.    3)  They are highly mathematical.  Controls is a very mathematical topic, perhaps the most heavily  laden mathematically in mechanical engineering.  There are many good engineers in industry that  are not particularly adept at mathematics, who practice engineering with as much intuition and  common sense as mathematical adeptness.  A mathematical approach to controls loses sight of this,  leaves many people behind, and does not take advantage of the fact that this topic also makes a lot  of sense, a lot of common sense.  Thus the approach taken here is to include what math is necessary  but to appeal to common sense and intuition whenever possible.  With today’s modeling tools— read here Matlab/Simulink—a great deal of the math can be skipped and replaced with model  building, to pose and answer questions that start with “What would happen if we…?”  In addition it has always been my conjecture that what we have developed at Cal Poly in our controls lab  would also be very useful to controls engineers in industry.  Our lab, while not unique, is very rare.  It  brings controls down to earth and teaches controls engineers how to deal with real systems, how to  model them and then tune the models, and how to set up and tune PID controllers for real systems.   These are the essential skills that a controls engineer must have to operate in industry.  In my  experience in academia, these essential skills are not often taught.  Controls students have their heads  filled with mathematics, indeed the mathematics of complex numbers, but then they are not given even  a starting notion of how such knowledge is applicable in the real world.  This book focuses ever on the  real world of controls in industry.  It tries never to lose sight of that goal and tries to avoid the alluring  trap of mathematical elegance and indeed mathematical snobbishness that seems common in the field  of academic controls.  So the book has also been written for industrial practitioners of control theory  who need to understand the topic and then bring into play to their advantage.  The other influence that led me to write this book was the three years I spent teaching controls in  Germany, two years at the Munich University of Applied Sciences and one year at the Karlsruhe  University of Applied Sciences.  In Germany textbooks are rare.  Rather students work from a script, a  collection of the professor’s notes organized and printed for student use.  This book is really a script, a  collection of my notes from teaching controls over the past decade.  Though writing a book is a lot of  Preface‐1   Preface   work, it’s common practice to have short, directed scripts at low costs for poor students.  So I thought,  why don’t we do the same at Cal Poly?  We have lots and lots of experience teaching controls, so we  should be able to come up with a good script.  Besides, with our involvement in our laboratory, we have  already demonstrated that we can come up with a high‐quality document for teaching the lab portion of  the course.  Thus it is my hope that students will benefit from this practical approach to controls just as they are  assuredly benefiting from saving almost 200 (in 2010).  And I hope that this script serves as an example  of what could be done in other courses at Cal Poly if professors would take their hard‐won experience,  collect it, and make it available at low cost to those eager to learn but without a lot of money to buy  expensive reference books.  This does not mean that one shouldn’t buy the expensive reference books.   Maybe one needs them in his or her work.  But at that stage, one has the means to buy them or one’s  a need.  company will buy them when there is  The use of Matlab/Simulink  It is hard nowadays to envision practicing controls engineering without Matlab/Simulink.  The  employment of this software in analyzing systems and designing controllers—indeed now in running  real controllers in physical systems—is de rigueur.  This text does not include a tutorial in learning  Matlab/Simulink.  That’s available online or with the software.  It is assumed that the reader has some  knowledge of this software.  Problems are posed in the text that directly direct the student to use this  software.  Occasionally tips are given in specific applications that illustrate the utility of a particular  Matlab command or Simulink procedure.  If the user’s knowledge of this software is not at a level where  these references to it make sense, he or she should explore the software a bit, researching its help  facility for background knowledge.  Controls requires knowing about only a tiny bit of Matlab and  Simulink.  So the reader is not required to do any extensive foundation‐building in order to be effective  with Matlab/Simulink in his or her study of the subject.  Acknowledgements  Wow, how did a hillbilly guy from a lawyer family in Mississippi ever get to the point that he could sit  down and write a controls book almost directly out of his head?  Well, if I told that whole story, that’d  be a book in itself.  Lots of hard‐won experience but also lots of help along the way.  It’s always been my  contention that when bestowing thanks, we never go far back enough.  So I want to at least go back and  thank my high school mathematics and physics teacher, Mac Egger.  He didn’t plant the original seed,  but he was there close to the beginning.  Then there were lots of twists and turns to get to this point.   Along the way:  Glen Masada at the University of Texas at Austin taught me classical controls when I  went and got a mid‐career PhD.  Just before that I worked at one of the largest coal‐fired plants in the  United States, American Electric Power’s Gavin plant in Gallipolis, Ohio.  A plant engineer there taught  me a lot, Randy Scheidler.  He taught me a lot about power plants but also about the level of knowledge  of good plant engineers in the United States.  Randy served as a sort of model to use in keeping what  I’ve written practical, of trying never to write anything without showing how it is used.  And I must back‐ up further and thank the folks at Trax Corporation in Lynchburg, Virginia for their invitation to come  Preface‐2   Preface   work for seven months with them in 1992 on power plant simulators.  I learned lots about steam power  plants and how they’re controlled from this experience at Trax.  Since my arrival at Cal Poly in 1998 I have been involved in controls as often as possible.  The course  there was handed off to me by Mike Ianci, Ed Garner, and Ed Baker.  They had built a very practical,  hands‐on lab.  Though we’ve replaced much of the equipment in it, some is still left from those days,  and much of what was added can be viewed as refinements and improvements of what they  bequeathed to us.  Here I have the pleasure of working with very practical, hand‐on people like myself— John Ridgely, Charles Birdsong, Bill Murray, and Xi Wu.  All have contributed one way or another to our  work in making this laboratory more practical and hands‐on.  Some have had even to deal with the  consequences of what I regarded as a good idea at the time, that required a lot of work on their parts to  implement, to work the bugs out.  Through their efforts we have a top‐notch controls lab.  I have seen a   one nowhere, neither in America nor in Europe.  It was their sweat that made this lab the great  better teaching tool that it has become.  My two sojourns in Germany were important contributors to this book.  I had the pleasure of working  with several accomplished controls engineers there.  Two stand out.  Manfred Schuster at the Munich  University of Applied Sciences welcomed me into his lab and gave me a very concise script to teach out  of.  His script is, in fact, a model for mine.  At the Karlsruhe University of Applied Sciences I had the  pleasure of working with Helmut Scherf, a committed controls nerd.  Helmut is a rare, rare example of a  practical controls engineer.  He has published a great book in German of Simulink models of very  common, practical systems.  He has built and is still building practical, low‐cost systems for his controls  lab that serve as useful platforms for turning on the controls light in students’ heads.  Many of his  perceptive, cut‐to‐the‐quick methods of thinking about controls topics have been incorporated into this  script.  So that’s the story in brief of how this book came about.  I hope that you enjoy it and find it useful.  Frank Owen  San Luis Obispo, California, U.S.A.  May 2012  Preface‐3   Chapter 1 – Introduction to Control Systems   Chapter 1 – Introduction to Control Systems  Goals  The purpose of this chapter is to give you an overview of the topic of control systems and to introduce  you to the basic concepts that you need to go forward.  Presented are   Basic control loop anatomy, the parts and pieces of control loops and how they are configured   Positioners vs. regulators, the two basic types of control loops   A fly‐by‐wire system vs. a cruise control system, iconic examples of the positioner and the  regulator   A beginning discussion of block diagrams   PID controllers, the most commonly used controllers in industry  Examples of control systems used in industry  Control theory is a relatively new field in engineering when compared with core topics, such as statics,  dynamics, thermodynamics, etc.  Early examples of control systems were developed actually before the  science was fully understood.  For example the fly‐ball governor developed by James Watt to control  overspeed of his steam engine was developed out of necessity, long before the science of controls came  into being.  Figure 1.1 shows an example of this controller.  The fly‐balls are mounted on a shaft that  turns and is driven by the engine through the pulley shown.  As the engine speeds up, the fly‐balls are  flung outward by their centrifugal force.  This outward movement pulls the lever arm down, which raises  its other end.  This is tied to the steam inlet valve, which closes as the flyball weights move further  outward.  So if the engine tries to run away, the inlet steam valve will close, shutting off the fluid driving  the engine.    Figure 1.1 – Flyball governor  Many say that the development of the airplane by the Wright brothers was enabled by their  understanding of controls‐‐that and the development of a light‐weight engine powerful enough to  1‐1   Chapter 1 – Introduction to Control Systems   propel their machine into the air.  Their development of wing warping enabled them to steer their  airplane, something that had been impossible up to that point.  And it is certainly true that much of  control theory grew up with the airplane, as airplanes were developed during the two world wars and  th also throughout the 20  century for civilian purposes.  As jet engines were developed and airplanes  became bigger, it became ever more problematic to pilot an aircraft with just mechanical connections  between the pilot’s controls in the cockpit and the surfaces elsewhere on the airplane that steer it  through the air.  Thus the fly‐by‐wire system was developed, which cut this direct connection between  the cockpit controls and the control surfaces on the airplane.  In a fly‐by‐wire system, the movements of  the stick or yoke and the rudder pedals in the cockpit are merely sensed by sensors.  Electrical signals  are then sent to actuators driving the appropriate surfaces, and then these move the ailerons, the  elevator, or the rudder to steer the plane according to the control inputs made by the pilot.  Of course  the force applied by the actuator on the control surface can be many times what a human could apply  directly.  And the force can be applied at an actuator far distant from the pilot.  So fly‐by‐wire brings  with it the advantage of force amplification and remote control.  In industry one finds control systems of many types.  In a refinery, chemical plant, food processing plant,  or a power generation facility one finds control loops for controlling tank levels, pressures of fluids at  various places in a plant, power output, valve position, pump, fan, or turbine speed.  Modern‐day fighter  jets actually are designed to be unstable.  This allows them to maneuver quickly.  They can only fly  because a control system stabilizes their flight, making corrections at a speed that no pilot could match.   If one of these plane’s control system failed in flight, the plane would be unflyable and would crash.   There has been a tremendous growth of control system use in the modern automobile.  There are even  now drive‐by‐wire and brake‐by‐wire systems, where, like in the airplane, the direct mechanical or  hydraulic connection between input devices and what they control has been cut and replaced by wish‐ sensing devices and then transmission of an electrical signal to an actuator to turn the wheels or to  apply the brakes.  Like the control of the unstable airplane, skid detection and control take advantage of  an automatic control system’s speed.  A driver who loses control of his/her car may be saved by such a  system.  It springs automatically into action upon detecting a skid situation and applies the correct  braking forces to rescue the car from the skid…and it does this before the driver is even aware that a  problem exists.  Besides these applications, control theory is useful even for analyzing manually controlled systems.  A  human operator is in this case actually playing the role of the controller.  A human’s sensing of and  reacting to inputs while manually controlling an industrial system or a vehicle is actually a study in  controls.  His or her reaction times, the force feedback or the angular travel of a steering wheel or an  operating lever, such human‐machine issues are within the realm of control theory.  Mathematical  models of the human controller have even been developed, so that a dynamic model of a manually  operated system can be completed and studied.  Much of what has been discussed here can be illustrated with the example of a pilot in an airplane.   Take the case of an airplane without a fly‐by‐wire system, with direct connections via cables and pulleys  between the cockpit controls and the control surfaces, as one finds in a small, general‐aviation airplane.   A controls expert might study the effect of a human controller during some flight maneuver or critical  1‐2   Chapter 1 – Introduction to Control Systems   situation.  This system is purely mechanical with a human controller in the loop.  But some small planes  also have autopilots, so a controls engineer had to design a system that would sense flight conditions  and operate the controls without intervention by the pilot.  Even more complicated is the case of a  larger airplane with a fly‐by‐wire system.  Controls engineers designed the sensing‐and‐reaction link  between the cockpit controls and the corresponding motion of the control surfaces.  Even when the  plane is being flown in manual mode, a sophisticated control system is engaged simply to sense the  pilot’s movement of the input control levers and pedals and transmit the commanded motion to  actuators that will bring it about.  Now consider the case of a fly‐by‐wire system with an active autopilot.   The control system senses flight conditions—altitude, heading, and speed—and automatically operates  the proper actuators—elevator, ailerons and rudder, and throttle—to maintain desired values.  Thus  these four variants of doing the same task—flying an airplane—show increasingly complex examples of  modern control systems.  Basic control system anatomy  Classical control systems are SISO systems, single‐input‐single‐output, as opposed to MIMO systems,  multiple‐input‐multiple‐output, which are more complicated.  For a control system the input is the  desired value, and the output is the actual value (See Figure 1.2).      Figure 1.2 – SISO control system  A good example is a cruise control system for an automobile.  The user inputs a desired value, say 65  mph.  Usually one does not type this in.  One drives the car up to this speed manually, then pushes a  button.  The speedometer senses the speed, stores this in an on‐board computer, and then it is the job  of the cruise control to keep the automobile at this speed.    Thus, when everything is working as it should, the actual value is equal to the desired value.  In German  these variables are known as the Sollwert, the should‐value, and the Istwert, the is‐value.  In controls it  is always good to bring things down to earth, because controls can get so theoretical, one quickly loses  sight of what is going on or why one is doing what one is doing.  I like to refer to these two values as  “what you want” versus “what you’ve got”.  When what you’ve got isn’t what you want, then  something’s wrong.  When Sollwert – Istwert ≠ 0, then the control loop is not doing its job, and  something is broken or something needs to be changed to make this difference 0.  Actually this difference has a name, the error.  That’s not error in the sense of a mistake.  Rather it’s  error in the sense of deviation.  In a perfectly functioning control system, the error should be 0, and  what you’ve got should be what you want.  Let’s look inside the control loop, at the anatomy of a control loop.  Almost all control loops are the  same.  They are all made up of five components arranged always the same.  Sometimes it is not easy to  1‐3   Chapter 1 – Introduction to Control Systems   recognize these elements in an actual system.  But it’s always a good idea to try.  This structure is  fundamental to control theory and represents the underlying functions that are needed to make  feedback control work.  As you probably have already concluded, the basic structure of a feedback  control system is a loop (see Figure 1.3).      Figure 1.3 – Basic control loop anatomy  The five elements are:  1. the comparator  2. the controller  3. the actuator  4. the “plant”  5. the sensor  Let’s discuss these components one by one.  I’ll present them in the order that’s easiest to use to  identify them in a real system.  Usually the easiest element to identify is the sensor.  For a cruise control  system, the sensor is the speedometer.  The sensor always measures the actual value and then feeds it  back to the comparator to compare with the desired value.  The comparator is just the summing block  that takes as input the desired value and the measured value.  That’s the nature of feedback control,  and that’s why it’s called feedback control:  the actual value is fed back to the desired value and  compared.  Another common example is the thermostat in your house.  A thermometer in your house  measures the interior temperature and then compares that with the desired temperature you have  somehow entered on the faceplate of the thermostat.  The error signal is the output of the comparator.  It is also the input to the controller.  As you can see, all  of these blocks in the block diagram of Figure 2 are SISO blocks, and each output becomes the input of  another block.  The controller takes the input from the comparator, the error, and decides how the  system should respond.  If the error is 0, then what you’ve got = what you want, and the system should  do nothing.  If the error is not 0, then the controller should take some action.    1‐4   Chapter 1 – Introduction to Control Systems   Nowadays, with digital controls, the controller is usually just a piece of software running in a computer  somewhere.  For a cruise control, there is a computer algorithm running in an on‐board computer that  performs this task.  So if someone asked you to point to the controller in the cruise control loop, you’d  have a hard time doing that without talking with the engineers that designed it.  Or you could just point  at a black box in the car and say, “There it is”, and most people would have a hard time disputing this.  If the error is not 0, then the controller needs to take action.  Eventually it wants to influence the plant.   This is a funny term for the thing that we actually want to control.  But control theory grew up in  industrial plants, so that is why this block has this name.  The plant can be hard to identify.  One  identifies it often by asking, “What are we trying to control?” and then the plant is the thing that that  value is a property of.  For example in a cruise control loop, the speed is what we are trying to control.   And the speed is a property of the car.  So the car is the plant in a cruise control loop.  Often the actuator is the hardest component to identify, so often we leave it for last.  Often it is hard to  draw a line between the actuator and the plant.  Often it’s hard to answer the question, “Where does  the actuator end and the plant begin?”  You’ll see this dilemma with experience.  So good questions to  ask are “What does the controller talk to?” or “Where does the controller send its signal?” or “By what  means does the controller influence the plant?”.  In a cruise control system the plant is the car.  The  actuator is the throttle.  Or maybe it’s the engine.  It’s the thing that causes the car’s speed to increase  when the controller notes that the car is going too slow and needs to speed up.  What you have is less  than what you want, so do something.  Thus these five logical components are always present in a classical control loop.  Though it may be  hard, it is always of value to try to identify the physical components that correspond to the logical  components.  Note also in Figure 2 that the signals between the blocks also have names:  1. r – desired value (“r” stands for reference value; this is also known as the controller setpoint)  2. e – error  3. u – command  4. f – force  5. c – actual value (“c” stands for controlled value)  6. b – measured value  These variable names are not standard by any means, but one sees them often.  You should be aware  that often variations of them are used.  But we need names for them so that we can refer to them when  talking about what’s going on in the loop.  Two types of control loops:  positioner and regulator  Control loops come in two flavors—positioners (also known a trackers) and regulators.  Both are made  up of the same components presented above.  What differentiates them is actually how they are used,  what their purpose is.  The control loop shown in Figure 1.3 is a positioner.  This loop can be modified to  1‐5   Chapter 1 – Introduction to Control Systems   configure a regulator, as shown in Figure 1.4.  Note that the difference is the addition of the disturbance  between the actuator and the plant.  This hints at the difference between the two loops.  A positioner  has a desired value that changes often.  A user is operating a plant through the control system.  It is the  job of the control system to sense the operator’s wishes and drive the plant to the point that the user  desires.  In contrast, in a regulator system, the user wants normally that the actual value stay at some  preselected level, even though external influences are working to drive the system off of the preselected  level.  A good example is the cruise control system of a car.  You set the desired speed to a fixed value.   But upward and downward grades tend to make the speed deviate from its desired value.  It is the job of  the control system to keep the system at a preselected speed in the face of disturbances that tend to  deflect the actual speed from this wished‐for speed.    Figure 1.4 – Regulator loop  It is common to arrange control loops so that the input is on the left‐hand side and the output is on the  right‐hand side.  With a regulator loop, when the desired operating level is chosen, the loop selects this  level as the reference level and considers it to be 0.  The loop works in deviations from this operating  level.  We shall see later how this is done.  At present it suffices to note that the desired value is the 0  reference value, so the r input can be eliminated.  The loop can be reconfigured as shown in Figure 1.5.   Here the input is the disturbance, and the output is still the same variable of interest, c.  The reworking  of loops as shown in this example is commonly done in controls and is known as block‐diagram algebra.   We shall see many more examples of this in the material to come.  1‐6   Chapter 1 – Introduction to Control Systems     Figure 1.5 – Reworked regulator loop  PID controllers, the workhorse of the industry  PID (Proportional‐Integral‐Derivative) controllers are by far the most common controllers used in  industry.  The name refers to three different actions that the controller makes in responding to a non‐ zero input, the error, as we have seen above.  Thus we speak of proportional action, integral action, and  derivative action.  The three actions occur simultaneously.  The configuration of the controller is a  parallel configuration, as is demonstrated in Figure 1.6.    Figure 1.6 – PID controller configuration  Note in the figure that the input signal, the error, is first treated one way or another and then multiplied  by a constant.  The top path is the proportional path.  Here the output is proportional to the error,  hence the name.  There is no action taken on the input signal.  It is just multiplied by K  and then passed  P on downstream to the output.  The integral action is the second path.  Note that the error (the input) is  first integrated.  The output of the integrator block is the integral of the error.  Thus if you plotted the  error curve vs. time, this signal would represent the net area under this error curve through time.  This is  then multiplied by K  and becomes the integral action.  The derivative action is the third path.  Note that  I the error is first differentiated.  The output of the derivative block is then not the error but the rate of  change of the error at the current time.  This change rate is then multiplied by K  to become the  D derivative action.  All three actions are added together in the summing block to become the total PID  controller action.  1‐7   Chapter 1 – Introduction to Control Systems   Why one would do this is at this point not clear at all.  But as we shall see, each of these actions has a  specific use or justification and usually improves the control response.  The three constants—K , K, and  P I K —are called the controller gains.  K  is the proportional gain, K  is the integral gain, and K  is the  D P I D derivative gain.  It is also often the case that one of the actions is not present.  As we shall see, the  proportional action is by far the most sensible and useful action.  Often controllers have only P action— that is K  and K  = 0.  We call these P‐only or just P controllers.  A controller with no D action is called a PI  I D controller.  One with no I action is a PD controller.  So we encounter P, PI, PD, and PID controllers.  Note  that all of these have P action.  There may be an oddball case without P action, but that is what it is, an  oddball case.  Problems  1.1 Make a conceptual model of a brake‐by‐wire system.  The force on the brake pedal is sensed as a  desired braking force.  The greater the pedal force, the greater the force applied by the brake pads  to the brake discs.  This measured pedal force is sensed by a load cell, which produces a voltage  proportional to this force.  This voltage is delivered to an interface board, which converts it into a  digital number in a microprocessor.  The controller running in the microprocessor produces an  output signal that is then converted into a voltage that drives an electromechanical actuator.  This  drives a piston, the master cylinder, and produces a pressure.  The pressure works on the brake  piston that applies the braking force to the disc pads.  The braking force is measured using actually  a pressure sensor.  Knowing the size of the brake pads, the braking force can be determined.  The  force applied to the brake pads is not necessarily the same force applied to the pedal, but they are  proportionally related.  Make a block diagram of this system, showing how all the components fit  together to compose the system.  Each block should all contain the name of a system component.   Each line between the blocks should show the type of signal being transmitted between blocks.  1.2  The figure below shows a part of the electrical power generation system in a conventional steam  power plant.  Fuel (gas, oil, or coal) is supplied on the left‐hand side to the boiler.  There water is  heated into steam and stored in a steam drum.  From there the steam flows through a control  valve into the turbine, which turns the plant’s generator.  The generator produces electric power.   There are several SISO loops in play here.  One loads the generator by increasing or decreasing its  electric field.  Of course when more electricity is needed, more fuel will be needed to support this.   But the connection between fuel in and electricity out is not direct.  The three “lollipops” shown  represent measured quantities.  Think about what these might be.  Then write in the blocks the  quantities that are measured.  Draw dashed lines from these lollipops to the actuators that control  them.  It is a chain of events that lead from more power required to more fuel supplied.  Consider  the case of a desired increase in power out.  Write out in words the sequence of cause‐and‐effect  events that will lead the steam plant to a new, higher level of operation.  Make a copy of the  completed diagram to complete the deliverable for this problem.  1‐8   Chapter 1 – Introduction to Control Systems     1.3  Sometimes a plant is a two‐part plant, and a disturbance enters the plant midway between these  two parts.  Draw a regulator loop for such a plant with a negative disturbance entering between  Plant 1 and plant 2.  Let the disturbance be the input to the loop.  1.4  Create a Simulink model of a PID controller.  For this you will need to use gain blocks for the three  controller gains.  Use an integrator block and a differentiator block for the integral action and the  derivative action.  At first just set all gains to  a value of 1.  As input, use a constant block and set  its value to 0.  All three control actions are summed with a sum block.  Use a scope block at the  output of the sum block to capture what output the controller delivers over time.  Also place  scope blocks on all three control actions to see how they behave.  Of course in the real world the  controller would be hooked into a system and receive the system error as its input.  Its output  would be fed downstream to an actuator.  With 0 as a steady input, you have modeled the case of  a control loop where the actual value is equal to the desired value.  What should the controller do  and what does it do?  Now make the input 1.  What does the controller do now?    1‐9   Chapter 9 – Designing and tuning PID controllers   Chapter 9 – Designing and tuning PID controllers  Goals   Provide a practical look at the PID, at how it is thought of and understood by practitioners in  industry   Describe several heuristic tuning methods for PID controllers  In Chapters 7 and 8 we have already gotten a good look at the PID controller.  In the context of root‐ locus and frequency‐response design procedures we have undertaken the design of PID controllers for  various common systems.  In a way these approaches give one a false impression.  They imply that one  must have a system model to tune a PID controller.  That is not, however, common practice in many, if  not most, industrial applications.  For example a tank level controller needs to be implemented.  One  purchases a commercial PID controller and puts it in service on the tank.  One then field tunes the  controller, starting with the proportional gain and then adding integral and derivative gain to improve  system response.   All of this is normally done without a system model.  Indeed, the normal understanding of PID control by a controls technician in a normal plant is much more  intuitive and down‐to‐earth than what you have learned about PID design and tuning via root locus and  frequency response.  Those two technics are powerful design techniques and ought to be understood by  controls technicians…but often they are not.  Thus for the controls engineer, it is important also to gain  this intuitive grasp of PID control simply to be able to communicate effectively with plant controls  technicians.  This common‐sense understanding of PID control offers yet another perspective on this  technology, and this complements the approaches taken already with root locus and frequency  response.  There are a number of accepted non‐model‐based methods for tuning PID controllers—i.e. methods  used for field tuning.  The most well‐known of these is probably the Ziegler‐Nichols tuning method.  That  and others are discussed in this chapter.  The PID controller interface  Figure 9.1 shows the faceplate of a typical PID industrial controller, this one used for temperature  control in a kiln or heat‐treatment oven.    Figure 9.1 – Industrial PID controller faceplate  9‐1   Chapter 9 – Designing and tuning PID controllers   The interface is somewhat sparse because often there are many of these controllers grouped together,  controlling various parts of an industrial process.    The user input panel for this controller consists of the four buttons at the bottom of the faceplate.  The  first button is the manual/automatic button, used to switch between these two modes of operation.   The AUTO light on the left of the faceplate indicates whether the controller is in automatic mode.  In  manual mode the control function is deactivated.  The user can drive the process in manual mode by  using the up and down arrows on the center two buttons.  This adjusts the output from the controller  directly.  This output from the controller is some (settable) range.  Often the control output is calculated  and displayed as percentage of this range, as is shown above in the OUT window.  In manual mode,  when one clicks the up arrow, for example, the percentage output would increase. To run the controller  in automatic mode, one must set the setpoint (and maybe some other parameters, like K , T, and T ).   P I D To do this, one must read the documentation that comes with the controller.  In the case above, the SET  button is used to enter a parameter setting procedure to set the controller parameters for automatic  operation.  In both manual and automatic operation, the display of the PV (process variable) shows the output  coming from the sensor of the variable that is the output from the loop, the variable to be controlled.   SP (setpoint) is the desired value of this output variable.  This is the input to the control loop.  In the  above example, the controller is in automatic mode (the AUTO light is lit).  The actual value of the  controlled process is 316 °F, and the desired value is 325 °F.  The controller is putting out 12% of its  output range to bring the actual temperature up to the desired value.  The ALM light is an alarm light.  This can be set to indicate that the actual value is outside a certain range  around the desired value.  Often alarms can be set at two levels, a warning level and a severe level.  The  warning level will have the light burn amber.  The severe level will have it burn red.  If the AUTO light is  green, this green‐yellow‐red color scheme for the lights will allow an operator to scan a group of these  modules quickly and determine  1. which loops are in automatic operation  2. whether there are any warning‐level alarms active  3. whether there are any severe‐level alarms active  Quarter‐cycle damping  Controllers are “designed” to improve system response or to achieve a desired, prescribed response.   Various aims are possible:   Limit a step response to a specified overshoot.  Recall that the overshoot is a function solely  ∙ of   %100% .  At  = 1 there is no overshoot.  But by specifying no  9‐2   Chapter 9 – Designing and tuning PID controllers   overshoot, one must settle for a longer response, a longer time to reach a new setpoint.  So  often a compromise is made and a little overshoot is accepted for faster reaction speed.   Specify a specific frequency of oscillation.  Note that increasing this frequency decreases the  system’s speed of response, since the response is often just the first half to three‐quarter  wave cycle of the response sinusoid.   Limit or eliminate steady‐state error.   A combination of such specifications.  To meet these needs it is very helpful to remember the geometry especially of complex poles and the  meaning of various distances on this plot.  Figure 9.2 shows this geometry again.    Figure 9.2 – Geometry of complex (oscillating) poles  So by specifying a certain overshoot, one is limiting the dominant closed‐loop pole pair to a ray leading  from the origin at a certain angle  (= arccos ) from the negative real axis.  As explained above, often a  controller is set to give a little overshoot (5‐10%) in order to have the system respond faster.   Alternatively there is a concept called quarter‐cycle damping, whereby each oscillation is 1/4 the  amplitude of the previous oscillation (see Figure 9.3).  For quarter‐cycle damping,  turns out to be  0.2155.  This leads to shorter response times but more overshoot.  Which to pick depends on the  application and the ability to tolerate overshoot.  If the oscillation frequency is specified, then the  vertical distance from the real axis,  , is known.  If both the desired or tolerable overshoot and the  d damping ratio are known, then the desired location of the dominant closed‐loop pole pair is fixed.   Steady‐state error is not readily seen on the plot, so no such statements can be made regarding it and its  placement of poles on the plot above.  9‐3   Chapter 9 – Designing and tuning PID controllers     Figure 9.3 – Quarter‐cycle damping  The PID controller  As explained in Chapter 1 the PID controller is the workhorse of industry.  Most, indeed almost all,  control loops in industry are SISO loops with PID controllers.  So to be active as a control engineer in  industry one must have a good understanding of PID controllers.  And by the same token, with a good  understanding of PID controllers, one can do almost anything one wants in industry.  Even in the rare  case that one needs something other than a PID controller, a good understanding of this workhorse  controller will stand one in good stead to compare an exotic controller with a conventional PID  controller.  Before beginning with the explanation of a PID controller, it is first useful to recall where the controller  is placed in the control loop and what its input and output are.  The controller is just after the  comparator, the summing block that takes the difference between the desired value and the actual  value.  Thus the input to the controller is the error signal.  The controller operates on this error signal  and produces a command that is then sent downstream to the actuator.  The purpose of the control  loop is to drive the error to 0, so that the actual value = the desired value.  If everything is working as it  should, e will be 0 and the controller will take no action.  It will simply put 0 on the output, the input to  the actuator.  This is a command to the actuator to do nothing.  When the actual value is not equal to  the desired value, the controller takes action and produces a non‐zero command for the actuator.  PID, of course, stands for proportion‐integral‐derivative.  A PID controller has a parallel structure with  these three actions (see Figure 9.4).  The three controller constants—K , K, and K —can be tuned to  P I D adjust the relative strength of each action.  The proportional action is the main action, and the other  two actions are add‐ons to improve the control.  Often one sees a P‐only controller, i.e. a controller with  only K  ≠ 0.  O en on sees a PID controller with one ac on—integral or derivative—turned off.  Thus the  P 9‐4   

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.