Hello Everyone,

I am going through the programs and will take some time to understand the total program.

As far as PID algorithm goes, well, there are several ways in which PID is implemented:

*PI*
In the first method Gain, integral time (repeats per minute) is used.

Here the gain value is multiplied by the error. And the Integral time is also multiplied by the error. Typical use that i have seen is in MOD-30 controllers from taylor (now ABB i believe).

The second method is the proportional band and integral factor (minutes per repeat).
Here the error is divided by the proportional band and error integral is divided by integral factor. Such implementation I believe is in Foxboro 761.

*BIAS*
Bias in mathematical terms is the addition to the pid equation.

*Dead time.*
Dead time factor gives the time which is required to see the effect of the gain action. or in some cases PI action. here gain action is first taken and then after the dead time, the I action is to start or the PI action starts and then the D action starts after some time.

*D*
the D factor acts either on process or on error.
i have found that the use of D on process helpful in many cases and on error in some cases.
In the first case the d element value is dependent on the rate of change of the process variable.
In the second case the D element value is dependent on the rate of change of error.

feedforward and dyanamic compensation are some other factors but those are not present in many PID implementations and can be skipped in the
first release unless the algorithm is already present.

hope this helps.

Anand

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

This is right, but proportional band and integral factor is not something you see in most modern controllers unless it is there as an option for those more used to the "old" way of setting the parameters. Those two can also be two independent choices (pband and integral time can be used
at the same time).

Your explanation of dead time seems a little bit strange however. This is not anything you normally find (as parameter) in controllers but rather a thing found as sad reality in the process.

There are however dead time compensating controllers, but it seems a little bit out of scope right now. A dead time compensating controller is normally not done as you describe it and I don't see any real reason to implement what you describe (if I understood your explanation correctly). Can you give me a description of in what cases this parameter is used and why?

A side note about bias:
bias is something added to the output unchanged, if the I part of the controller is used bias don't have any meaning except possibly at startup. In some controllers bias and I part is
sharing the same register (the I part is effectively changing the bias). This does not make any difference at all for the control and can be implemented as you wish. A better implementation is to implement bumpless transfer, this is easiest if bias and I part share the same register. It is done like this: When in manual let the P part and (if used) the D part calculate, but don't use them for the output. Don't let the I part change the value (or in reality it doesn't matter)

When switching from manual to auto:
Set the bias/I-sum to output-P-D
This means the next update will produce the same output except for whatever changes in process value you got between those updates.

When switching from auto to manual:
Set the manual output register to the value of output

/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

On Wed, Jul 18, 2001 at 10:58:28AM -0600, Johan Bengtsson wrote:
> ...
>
> A side note about bias:
> bias is something added to the output unchanged, if the I part
> of the controller is used bias don't have any meaning except
> possibly at startup. In some controllers bias and I part is
> sharing the same register (the I part is effectively changing
> the bias). This does not make any difference at all for the
> control and can be implemented as you wish.

From a user's perspective I think the bias-as-integral can/does serve a useful purpose, since it represents the loop's current zero-error output. A good feel for the state of the loop can be had by viewing the bias (integral) and the output. The output gives an instantaneous picture, while the integral gives a longer term view of the state of the loop.

--
Ken Irving <[email protected]>

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

good point

/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

dead time is basically supposed to act agains the lag to a force applied.
There are several implementations, I say this from an users experience. It is also possible that some compromise may have been made at those older days when memory and other issues could have prohibited them to implement it in a particular way.

Dead time:

Say a distillation column top temperature is being controlled. Then the reflux change will take a small amount of time to get reflected on the top temperature.

If you want to badly avoid overshoot, it is better to take the P value and act on the output, wait for a time period and then start the I action.

This is good enough for static changes. If you observe dyanamic disturbances then you can start i action beforehand.

Anand

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

When one considers the ubiquity of PID loops in process control and motion control, it seems whenever they're discussed there seem to be many interpretations and variations of the algorithms.
PID loops have been used long enough you'd think there'd be some published algorithms, but I don't think I've ever seen a reference. It's a
big topic here now, but it has made the rounds a couple times on the a-list as well.
Does each PLC or DCS manufacturer who offers PID control basically roll their own algorithms? Do they publish them, or is it a magic box that
you toss some numbers at it until the control loop behaves in a tolerable manner?
Perhaps I should re-post this on the automation list.

Rufus

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

So basically: at startup you start with just P and then turn on I (and possibly D)
Does this happen at other times than at startup (setpoint changes comes to mind)?

Would it not be better to tune the PID according to this? I don't say it is wrong, but it sounds like the tuning in such cases possibly is a little bit close to unstable.

Should I action be turned on gradually?

/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Well, I have just finished a *LONG* discussion there, and introducing a new one right now would not be a good idea, you could look at that one however if you like...

To make a long list of possibilities not so long:

There are several things to consider when implementing PID:

1. Structure, they have different names but there are basically tree forms, serial, ideal, and independant
Other names exists, such as parallel, but in some times this mean ideal and in some times it means independant.

serial is the "old" standard form, in these you basically do like this:
error=(setpoint-processValue)
a=error*gain
Isum+=a*timeStep/Itime
b=a+Isum
Dpart=(b-last_b)*Dtime/timeStep
out=b+Dpart

That means, you apply gain, you apply I and you apply D (note that you always add the input to I and the output from I and the same for D to form the next signal)
ideal in the current standard form seen in almost every place there is a decent PID implementation, surely in all DCS, and all PID controllers you buy as an off the shelf self-containing thing

It is implemented in the way I have said before
error=(setpoint-processValue)
a=error*gain
Isum+=a*timeSteg/Itime
Dpart=(a-last_a)*Dtime/timeStep
out=a+Isum+Dpart

independant is the form starting this thread
error=(setpoint-processValue)
Ppart=error*gain
Isum=error*timeStep/Itime
Dpart=(error-last_error)*Dtime/timeStep
out=Ppart+Isum+Dpart

So much for that, the one to use is ideal if it is only one of them, otherwise it is something the user selects and ideal should always be one of the options

A side note: if you only have PI serial and ideal becomes the same.

The next thing to consider is if the D part should be acting on setpoint changes of not, in most cases (but not all) is it most desireable if this not is done. ie the D part should only act on
changes in process value. This should always be implemented in a way that makes the dynamics for process value changes the same regardless of if this option is used or not.

The next thing, starting the latest firestorm about PID on Alist, was if this idea should be applied to the P part too, it could be good but only if the user seltects it and should absolutely
be an user selectable option if used.

Ok, another point is that the D-part really should be filtered and not implemented as above. This is a standard low pass filter of the first order whit the time constant equal to Dtime/leadQuote
leadQuote is a number that in many controllers are fixed at a value around 5 to 15, a "normal" value being 9. In some controllers it is changeable by the user (I suggest implementing
it like that).

Then you always have an option of inverting the output, ie changing the controller to "Direct action". In this mode a rising process value gives a rising output instead of the normal "reversed action" when it goes down instead.

There should be a possibility to turn the PID into manual operation, all good implementations make this transfer without changing the output (bumpless transfer) in both directions.

Implementations in PLC:s are sometimes made by people not used to process control and some implementations are quite poor considering the above.

Most old tuning methods are targeting the serial form and most new (and new versions of old) tunign methods targets the ideal form. Note again there is no difference if D is not used.

Manually tuning a PID should be what is expected, that means ideal in most cases. Conversion formulas from serial to ideal exists and between ideal and independant.

/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

johan.bengtsson:
> So much for that, the one to use is ideal if it is only one of them,
> otherwise it is something the user selects and ideal should always be one
> of the options

To place my suggestion on that chart, it's combined ideal and independent.
For ideal, leave Pgain at 1.0. For independent, leave masterGain at 1.0.

Perhaps Pgain should be called ``independent gain'' and/or masterGain should be called ``ideal gain''.

If you couldn't care less as long as it works, tune using all four.

Serial could be accomodated by adding another tuning parameter Sgain:

error = (desired - actual) * masterGain
P = error * Pgain;
I += error * Igain * time

Dbase = error + I * Sgain
D = (Dbase - last_Dbase) * Dgain / time

output = P+I+D

Sgain would be set to 0.0 for ideal and independent (default)
1.0 for serial

Other values for Sgain are probably not sensible, but maybe someone will find a use for them.

Again, note that Dgain is a time in seconds and Igain is a frequency (rpm or 1/time).

> Then you always have an option of inverting the output, ie changing the
> controller to "Direct action". In this mode a rising process value gives
> a rising output instead of the normal "reversed action" when it goes down
> instead.

Easily done by making masterGain negative (-1 for independent) or by putting the output of the PID through a constant multiply block.

Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sourceforge.net

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Dear Rufus:
I shall try to answer your questions as much as I know.

1. Each PLC or DCS manufacturer who offers PID control uses its own programs for PID algorithm and its practice. Some manufacturers have even a few programs, like PID 1, PID 2, PID 3, and so forth.

Generally, large, reputable, DCS manufacturers, such as Invensys (Foxboro Company), Honeywell, Emerson (its division that previously named
Fischer-Rosemount Systems), ABB (Its division of the old name Fischer & Porter and Taylor) and Yokogawa, have expertise in the PID control. Although each company claims its algorithm is better than others, all of them are equally effective.

I heard but have not personally evaluated that some PLC's PID have quite weaknesses.

2. Inherent issues with the PID algorithm
The PID algorithm is mathematically same, although there are two way of expressions, the position form and the velocity form. When you
mathematically integrate the equation in the velocity form, the result becomes the position form.

The mathematical expression of PID does not hint its associated problems. In practice, engineers face many issues, however. Some of them, although not exhaustive, are,
a. Overrange: The most algorithms handle the variables, such as process variables, set points and outputs, in 'percent of the span of the input
variables.' When the process variable exceeds the span, we have to handle the case properly.

b. Resolution: ADC in the products have a limited resolution, like 10 bits, 12 bits, 16 bits, and execution of the PID algorithm has resolution
depending upon the word length ( recently, this is less problem). If DCS does not have the resolution, the control result will have a remaining error. When we increased the resolution of HW and SW, we often faced the time constraints in the real time operation of PID control, and excessive cost as well.

c. Reset wind-up: "I" of PID stands for integration. In the jargons in our industry, integration is called reset. The PID algorithm has the term of integration, the magnitude of the integration term will increase toward infinitive if the difference between the process variable and the set point remains for a long time. This causes a problem since the HW register size is
finite (16 bits, 32 bits) and the word length or resolution of SW is limited. This problem is called "reset windup," a terminology from the
analog era. Practical technique to handle reset windup is called anti-reset wind-up.

d. Bumpless transfer: PID automatic control accompanies with manual control.
When we transfer the control from manual to automatic, for example, we should do so seamlessly, in other words, bumpless in the loop operation.

e. other issues

All of the large DCS manufacturers have expertise, based upon experience over 70 years, in furnishing the solutions of the inherent issues. Manufacturers have different practice in them, even their algorithms are mathematically same. If there is any short coming in PID control of PLC, it may be in handling these issues.

Therefore, I would like to suggest LinusPLC will take PID control from large DCS manufacturers or their joint activities. They market specific products for PID control, beside DCS. Their name is 'single loop PID controller.'

3. PID control does not start operating in a manner "You toss some numbers at it until the control loop behaves in a tolerable manner." The PID algorithm has three coefficients. You have to properly set them in order to have the loop operate well. The procedure to determine the coefficients is called "tuning" PID loop. A number of tuning practices and theories were
developed.

The reputable manufacturers of DCS and PID controllers provide the software, called self-tuning or auto-tuning. The software does tuning for the users or assist them in tuning.

Two coefficients of the PID loop out of three is time-dependent. Therefore, the sampling cycle of the loop must be accurately fixed. The reputable
companies of DCS and single loop controllers rigorously maintain the sampling cycle constant. Some of PLC designers, I heard, hardly realize this need.

4. Manufacturers publish the PID algorithm and description of their solution to the inherent issues in their manuals of DCS and single loop PID
controllers. Of course, the companies have the copyright of them and some have patents with the practices, even if the algorithm is mathematically
known.

5. The published PID algorithm, except books for automatic control
I would like to mention two published PID documents.

a. ISA
ISA SP50 Feildbus Committee issued ISA-TR50.02, Part 9-2000 Technical Report. The representatives of the users and manufacturers of DCS drafted it. It contains the specification, description of the PID algorithm and solutions for the inherent issues. Someone may program for PID control based
upon this report.

You may contact ISA for your assistance,
Ms. Lois M. Ferson
ISA
67 Alexander Ave.
Research Triangle Park
North Carolina 919-549-8411
Phone 919-549-8411

b. Fieldbus Foundation
As you may know, Fieldbus Foundation (FF) is an organization promoting fieldbus, supported by the member companies. Invensys, Emerson, Honeywell
and Yokogawa are the major members.

FF issued the specification for various functions that fieldbus devices execute. One of them is the PID algorithm and solution for the inherent
issues. You may contact FF to find if it would allow you to use its PID algorithm.
Fieldbus Foundation
9390 Research Boulevard,
Suite II-250
Austin, TX 78759-9780, USA
You may see it website, www.fieldbusfoundation.com.

With best wishes,

Matt Kazahaya
Ex Vice president, Marketing, Technology and Corporate Planning, Fischer & Porter Company
A member of ISA SP 50 Fieldbus committee
A US representative to IEC fieldbus subcommittee.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Think of it this way: The proportional term (or gain) is the driving force. It causes your output to change. However, you generally end up with an exceptional steady state error. In other words, with P only control, and a setpoint change from 50 to 70 percent (I'm only throwing around numbers here) you might end up with an output of 80, which would then give you a 10% steady state error (80-70=10).

This is where the integral term comes in to play. Integral minimizes steady state error. Once you have tuned the proportional term to give you the fastest, stable, response possible, you then adjust the Integral term to minimize the steady state error - stopping before you go unstable.

The only thing left would be the derivitive term. Derivitive is a dampening factor. You would use it when you need to crank up the proportional term real high to get a fast response (helps minimize overshoot, etc.). It often causes instability and should be used only when absolutely necessary.

This is a "very" basic explanation without the math. Lags, deadtime, and a host of other things add to the fray.

Good luck........

 

But I do care, not really how it is implemented exactly but how it is to be tuned. There should be those three parameters (gain, Itime and Dtime) and (preferably) a switch saying what type (serial/ideal/idependant). The actual implementation can be done as you suggest but
after recalculating the input parameters to the ones used by the implementation (and you don't really need the masterGain to do that) just the Pgain, Igain and Dgain

I did get a little bit confused by the result for
serial -> independant formulas (I have calculated them from serial -> ideal and ideal -> independant and they should be correct, but I have to check them)

Serial:
Pgain=gain*(Itime+Dtime)/Itime
Igain=gain/Itime
Dgain=gain*Dtime


Ideal:
Pgain=gain
Igain=gain/Itime
Dgain=gain*Dtime


Independant:
Pgain=gain
Igain=1/Itime
Dgain=Dtime

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

johan.bengtsson:
> But I do care, not really how it is implemented exactly but how it is to
> be tuned.

Sorry, that comment was really poorly worded.

What I meant is, you can either tune it using one of the two models by selecting the appropriate three parameters, or you can tune it using all
four if that's easier to think about or if there's some reason for using a combined model.

> There should be those three parameters (gain, Itime and Dtime) and
> (preferably) a switch saying what type (serial/ideal/idependant).

That's the other way of implementing it.

> The actual implementation can be done as you suggest but after
> recalculating the input parameters to the ones used by the implementation
> (and you don't really need the masterGain to do that) just the Pgain,
> Igain and Dgain

No, masterGain is superfluous, it is merely intended as a convenience.

> Serial:
> Pgain=gain*(Itime+Dtime)/Itime
> Igain=gain/Itime
> Dgain=gain*Dtime

> Ideal:
> Pgain=gain
> Igain=gain/Itime
> Dgain=gain*Dtime

> Independant:
> Pgain=gain
> Igain=1/Itime
> Dgain=Dtime

Sounds good.


Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sourceforge.net

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc