Standards for PID control

Hi

Are there any standards for industrial implementation of PID control algorithms? Whatever, I just want to get a picture.

Thanks, Zdenek Hurak

Not really. But a good place to start is the algorithms available within Foundation Fieldbus. I have a feeling FF is going to standardize a lot more than just the signal levels on pair of wires.

Walter.

I don't believe this question is specific enough to yield an answer. It happens all the time with this newsgroup.

If you want a picture of generally accepted concepts and terminology used in the many thousands of industrial PID loops world-wide see:

This example is a temperature loop but it deals with the basics of PID control. It is just one of hundreds of articles to be found on PID on the web.

Art

I only wanted to learn if there are ANY standards that PID controllers in industry must (or should) follow. Something like IEC 61499 for logic controllers (more precisely, function blocks stuff). I don't really feel my question was that vague.

Thank for a nice link. Even though it does not answer my question, I find it very nice and useful.

Best, Zdenek

To the best of my knowledge, there are no implementation standards. Each manufacturer is allowed to develop whatever equations they wish, and they do. Honeywell, for example, has at least 6 different equations for PID based controls, none of which are the same as what chromolux uses.

Some use straight gains, others use inverse times, bandwidth expressions, etc. Some use absolute outputs, others use relative outputs. Some allow filtering, averaging, clamping, ramping, multiple gains, variable gains, bumpless transfer, self tuning, and others don't.

To top it off, there are also a number of different tuning standards and protocols. Some are based on quarter wave damping, some aren't. Some are based on seat of the pants operations, others more on mythology. I still haven't figured out how a few loops I've looked at were tuned (or mistuned).

There are naming conventions, often specific to an installation or a manufacturer. These change from time to time.

There are not architecture standards. You can use a database lookup, object oriented programming, top down programming, assembler, or whatever your heart desires, as long as you don't copy another vendor too closely. I've seen controllers which were fully object oriented, and some which were half oop and half top down (or bottom up).

The only things that are marginally standard is that we expect them to somehow control the process using roughly the same old control algorithms we learned in our control classes years ago, and the use of one or more of several standard input and output protocols.

One (almost) standard I've gotten used to is that the old pneumatic controllers typically required a screwdriver, and the new electronic ones typically use a keypad based input.

I hope this gave you a bit of an answer. I'm not sure it was the one you were looking for. There might be some standards, but there are enough non standard details which tend to obfuscate them.

Michael

Thanks, that is exactly the kind of answer I was looking for.

Zdenek

Herman Family wrote:

What a business! If people really knew how little we actually knew what we were doing, they'd be scared. There is one standard that has some terminology definitions of PID control and that is ISA 51.1, Process Instrumentation Terminology. People sometimes refer to an "ISA standard controller" but there is no such thing. This spec is the closest, but all it provides is a few definitions of terms.

Walter.

Someone admits the truth!

I just shake my head and wonder how the world turns. Fortunately the world turned before PIDs or control. I have seen statements like "gains are not calculated, they are tuned" and I shake my head. The people that make "tuning" software make good use of the general ignorance by selling the magic packages that conjures up the gains. Only the high priest hood seem to know how to wave the magic wand. Ignorance cost a lot.

This topic deserves another thread because it is off topic and a potentially big one.

Peter,

While lousy software will always remain lousy software, the statement about the gains may be a little exaggerated but it has a good reason to exist. While it is possible to calculate an estimate of the PID parameters, you will almost always have to fine tune them on the actual plant. Why? Because the model you use to calculate those parameters is just an approximation of the plant's behavior. Unfortunately, the world is nonlinear, and time variant for that matter.

Regards, Andrey Romanenko

I wasn't implying the auto tuning software is lousy. I was just saying that it the auto tuning software appears to be magic to most people. If auto tuning software was understood then people would be doing their own calculations for the gains. As for tweaking, why not calculate gains continuously and truly put the auto into auto tuning?

Peter Nachtwey

Oh, I didn't mean all (auto)tuning software is lousy, either. I understand your concern about the tuning process being magic to many plant floor people. However, one needs some knowledge to perform the calculations. On the other hand the tuning can be carried out by the seat of one's pants. And many companies cannot afford having engineers on the payroll. They call up "superengineer" companies to solve problems.

This stuff is tricky, of course. It is the old good compromise between robustness and efficiency, and between stability and adaptability. Besides, the adaptation algorithm itself has to be tuned.

Andrey Romanenko

Re: auto-auto tuning.

Don't forget the only way to check the true response of a system is to give it a little nudge/jiggle and see what it does. You're not going to gain a lot of efficiency if you jiggle things too often just to make sure you still know how it will react.

Why not generic continuously autotuning products? a) adaptive algorithms are not guaranteed stable for any plant. b) Best performance requires someone to say what best is... ie. overshoot/response time. c) Probably would have a statutory warning on the label: "WARNING: This Controller May Occasionally Cause Plant Oscillations If Steady State Plant Operation Is Too Smooth For Autotuning Algorythm"

or alternately

"WARNING: Like an understimulated employee, this controller may start playing with things if it gets bored, you may disable this behaviour, however it can not be guaranteed that the controller will be awake enough to react to sudden changes."