Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Standards for PID control

31 views
Skip to first unread message

Zdenek Hurak

unread,
Sep 15, 2003, 10:14:53 AM9/15/03
to
Hi

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

Thanks,
Zdenek Hurak

Herman Family

unread,
Sep 15, 2003, 9:36:35 AM9/15/03
to
I'm not sure if they are regulatory standards but there are:
1. Standard PID equations available in each controller
2. Local naming conventions
3. At least local conventions on color usage on a display
4. Some standards on how well the system will work for process safety.
5. Some standards on safety interlocks, and other details
6. Several standard methods for tuning.

but overall, there is no standard that I know of which says to use a
particular algorithm in a particular place.

Michael


"Zdenek Hurak" <z.h...@c-a-k.cz> wrote in message
news:bk49u3$10as$1...@ns.felk.cvut.cz...

Walter Driedger

unread,
Sep 15, 2003, 11:37:55 PM9/15/03
to
"Zdenek Hurak" <z.h...@c-a-k.cz> wrote in message
news:bk49u3$10as$1...@ns.felk.cvut.cz...
> Hi
>
> Are there any standards for industrial implementation of PID control
> algorithms? Whatever, I just want to get a picture.

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.


Arthur Holland

unread,
Sep 19, 2003, 11:48:28 PM9/19/03
to
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:

http://www.eurotherm.com/training/tutorial/tutor.htm - and select
number 3

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

Zdenek Hurak

unread,
Sep 29, 2003, 8:40:46 AM9/29/03
to
Arthur Holland wrote:

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

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.



> If you want a picture of generally accepted concepts and terminology
> used in the many thousands of industrial PID loops world-wide see:
>
> http://www.eurotherm.com/training/tutorial/tutor.htm - and select
> number 3

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

Best,
Zdenek

Herman Family

unread,
Sep 29, 2003, 10:26:55 AM9/29/03
to
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

"Zdenek Hurak" <z.h...@c-a-k.cz> wrote in message

news:bl927a$jce$1...@ns.felk.cvut.cz...

Zdenek Hurak

unread,
Sep 29, 2003, 3:15:45 PM9/29/03
to
Thanks, that is exactly the kind of answer I was looking for.

Zdenek

Walter Driedger

unread,
Sep 29, 2003, 11:58:49 PM9/29/03
to
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.

"Zdenek Hurak" <barb...@sin.cvut.cz> wrote in message
news:bla0cq$1oli$1...@ns.felk.cvut.cz...

Peter Nachtwey

unread,
Sep 30, 2003, 11:20:19 AM9/30/03
to
"Walter Driedger" <wal...@driesmithdger.ca> wrote in message
news:Zb7eb.48899$TM4.30020@pd7tw2no...

> What a business! If people really knew how little we actually knew what
we
> were doing, they'd be scared.

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.

Andrew Romanenko

unread,
Oct 1, 2003, 9:35:01 AM10/1/03
to
Peter Nachtwey <pnac...@comcast.net> wrote:

> 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.

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

Peter Nachtwey

unread,
Oct 1, 2003, 11:25:03 PM10/1/03
to
"Andrew Romanenko" <and...@eq.uc.pt> wrote in message
news:blel65$303$1...@rena.mat.uc.pt...

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


Andrew Romanenko

unread,
Oct 2, 2003, 5:53:57 AM10/2/03
to
Peter Nachtwey <pnac...@comcast.net> wrote:

> 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.

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.

> As for tweaking, why not calculate gains continuously and truly
> put
> the auto into auto tuning?

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

H Hawkins

unread,
Oct 8, 2003, 12:14:19 AM10/8/03
to
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."

0 new messages