Hi,

I've been a lurker since the inception of this project and have been very impressed by the progress (and felt guilty about being just a lurker).

*** Lurk Mode Off ***

I have some experience working with OPC and have written a simple client. I'm familiar with the basis and concepts of OPC but not an expert. If you wish I can help you with OPC related questions.

I have also been meaning to write a generic PID algorithm for the LPlc but have found excuses for procrastinating. Hopefully one of these days I'll get to it. I don't have any experience with Linux so I'm not sure if that will be a problem in writing the algorithm. I was planning to write it in the form of a Function in C :

PID(PV, SP, OUT, P, I, D)

Would this be adequate or do I need to know about Linux and the other pieces of LPlc ?

*** Lurk Mode On ***

======================================================
Chetan Chothani Tel : 724-746-4969 x2118
Adaptive Resources Fax: 724-746-9260
P.O.Box 62245 E-mail: [email protected]
Pittsburgh, PA 15241 Internet: www.adaptiveresources.com
======================================================


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

 

Hi Chetan,

Welcome aboard.

If you wish to write the PID algorithm, go ahead. I can later merge into the linuxplc.

Do you really think the 6 function arguments are enough? A pid function will need to have memory to implement the Integral portion. Remember also that it will be very unlikely that the function
will execute with a perfect period. At the moment we have not migrated to any RT OS, so no guarantees about timing. You will probably have to
take that into consideration.

I have implemented my version of a PID control function, but would like to see your implementation to make sure mine is correct.
It has been some time since I last had to work with PID controllers.

Mario.

--
----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------



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

 

>I have also been meaning to write a generic PID algorithm for the LPlc but
>have found excuses for procrastinating. Hopefully one of these days I'll get
>to it. I don't have any experience with Linux so I'm not sure if that will
>be a problem in writing the algorithm. I was planning to write it in the
>form of a Function in C :
>
>PID(PV, SP, OUT, P, I, D)
>
>Would this be adequate or do I need to know about Linux and the other pieces of LPlc ?
>

You may also need:
- a mode (auto, manual), unless the manual mode is handled outside the function
- a period (milliseconds between calls) or a timestamp (when called last)
- a variable for the bias (the integrator)

It may be a good idea to use a structure to contain P, I, D, bias and period. The the call would only have 4 parameters (P, I, D and &struct)

Gilles

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

 

This is a good topic, and might set the API a little better in stone for more of the math library, so we should discuss this a little more.

There is more to a PID than described... ie... deadband, forward/reverse acting, output limits, alarm limits, scaling from integer to engineering
values, etc...

The way AB does it is set aside a block of memory for each PID instruction, that is where they keep the configuration data, scratch pad, and other
variables. Oh, a structure...

the prototype for the PID loop could just be the pointer to the PID structure.

myError = PID( &myPIDStruct);

PID() would have to look at each structure everytime it was called, I guess looking for manual/automatic, and do the processing...

There could be some utility functions for the PID to access the structure, or it could be done manually for configuration in the memory map, or by adjusting data in the PID structure with a MOVe or COPy instruction in the ladder program.

Just my $0.02

Blair

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

 

The function arguments shown were for the sake of simplicity and example only. I haven't really put enough thought into it yet.

I'm still struggling with a lot of questions on the algorithm and features such as:
1) Should we include a Filter for measurement noise reduction ?
2) Should the algorithm be PID Series or PID Non-Interacting ?
3) Output Tracking and Integral tracking ?
4) Anti-Reset Windup ?
5) Feed-Forwards ?
6) Internal Gain and Lag for Feed-Forwards or external functions ?
7) Setpoint Ramping ?
8) Setpoint Tracking ?
9) Built-In Cascade hooks ?
10) Self-Tuning ?

and so on ...

Anyway, didn't mean to hijack the discussion from the important stuff. If anyone has any opinions on the above questions please let me know.

chetan

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

 

> I'm still struggling with a lot of questions on the algorithm and features
> such as:
> 1) Should we include a Filter for measurement noise reduction ?

Yes, but make the filter adjustable.

> 2) Should the algorithm be PID Series or PID Non-Interacting ?

both.

> 3) Output Tracking and Integral tracking ?

Yes.

> 4) Anti-Reset Windup ?

Yes

> 5) Feed-Forwards ?

Yes

> 6) Internal Gain and Lag for Feed-Forwards or external functions ?

make it external

> 7) Setpoint Ramping ?

external function

> 8) Setpoint Tracking ?

maybe

> 9) Built-In Cascade hooks ?

no. make this external

> 10) Self-Tuning ?

NO. this should be a separate function.

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

 

> I'm still struggling with a lot of questions on the algorithm and features ...<

You are now talking about serious work.
Here are my opinions.

> 1) Should we include a Filter for measurement noise reduction ?

Yes and no. The filter function should also be available outside the PID.
So, if it is available outside, do we need to complexify the PID parameters?

> 2) Should the algorithm be PID Series or PID Non-Interacting ?

No opinion. Both are workable

> 3) Output Tracking and Integral tracking ?

Going from manual to auto should not change the output.

Manual mode should set integrator (bias) to 0.
> 4) Anti-Reset Windup ?

Yes

> 5) Feed-Forwards ?

Very important

> 6) Internal Gain and Lag for Feed-Forwards or external functions ?

Gain and lag for feed-forwards: Yes. External functions: Desirable.

> 7) Setpoint Ramping ?

Desirable. May also be done outside the PID

> 8) Setpoint Tracking ?

?

> 9) Built-In Cascade hooks ?

Yes. May be done outside the PID if we want to reduce the number of parameters.
This would require a pointer to another PID structure.
> 10) Self-Tuning ?

Why not?

> and so on ...

Alarms, limits, scaling, setpoint clipping, disabling on abnormal PV (bad
transmitter), etc

Gilles

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

 

I have worked with PID done commercially in various ways (Taylor Mod 3, Taylor MOD 30, Taylor Mod 300, Foxboro Spectrum, Foxboro IA, Foxboro board mounted controller, Honeywell TDC 2000, Honeywell TDC 3000, Moore Mycro, an APC platform written for internal use by a Fortune 500 petrochemical company), and wrote an APC (advanced process control) platform to support
my graduate work. For this reason, I have thought about this a lot, and have some opinions and ideas:

>From: "Chothani, Chetan" <[email protected]>
>To: "'[email protected]'" <[email protected]>
>Subject: RE: LinuxPLC: OPC, PID
>Date: Fri, 21 Jul 2000 15:11:47 -0400
>The function arguments shown were for the sake of simplicity and example
>only. I haven't really put enough thought into it yet.
>
>I'm still struggling with a lot of questions on the algorithm and features
>such as:

>1) Should we include a Filter for measurement noise reduction ?

Yes, if you want the possibility of the display of the running PID block to show the unfiltered measurement; and no if you do not care.

In any case a separate filter block (configurable as first and/or second order) should be available that can run at a shorter sample interval to
eliminate aliasing. Usually the field transmitter, measurement block (AIN, FieldBus IN, ModBus IN, ...), and/or A/D controller board can filter.

>2) Should the algorithm be PID Series or PID Non-Interacting ?

Both. If it is done right, the block can process one algorithm, and the only difference is the configuration view of the pararmeters.

So if the configuration view is done well, one user might want to see parameters in one form, and some other user might want to see a different
representation. This includes:
gain vs. proportional band
integral time vs. integral rate
time in minutes, seconds, or hours.

Actually people are confused by the "interacting" designation, because it depends on if you think of the frequency or time domain. I prefer ISA-standard and factored-form (which unambiguously refer to the algebraic representation of the Laplace-transform transfer-function)

Designation Frequency domain Time domain
------------- ---------------- ---------------
ISA standard interacting non-interacting
factored-form non-interacting interacting

>3) Output Tracking and Integral tracking ?

Not necessary if the PID setpoint and output are external (as is the measurement). See comments under 4

>4) Anti-Reset Windup ?

Yes, digitally by looking at the raise-ok and lower-ok count of the output (an analog output, a floating-point structure that serves as the setpoint of a slave cascade (or cascades for fan-out), or a floating-point structure that serves as the input of a feedforward block). The PID block should increment/decrement the raise-ok and lower-ok count of the setpoint (an floating-point structure that serves as a user-entered setpoint, or a floating point structure that serves as the output of a higher-level PID block.

BTW: This scheme (incrementing and decrementing counts, and making decisions based on the count being non-zero, or not equal to the total
configured number of configured connections) can be made to work even when there is fan-in and/or fan-out and some of the parallel blocks execute at
different rates, phases, or less than optimal orders.

I strongly recommend against external reset feedback for anti-reset windup (most frequently found in Foxboro DCS control implementations). It is hard to implement, hard to understand, difficult to display a flag indicating that limiting is active, and almost never performs as well as digital anti-windup.

>5) Feed-Forwards ?

External via summer or multiplier

>6) Internal Gain and Lag for Feed-Forwards or external functions ?

External

>7) Setpoint Ramping ?

External

>8) Setpoint Tracking ?

Not necessary if the PID setpoint and output are external (as is the measurement). See comments under 4

>9) Built-In Cascade hooks ?

Not necessary if the PID setpoint and output are external (as is the measurement). See comments under 4

>10) Self-Tuning ?

Self tuning should be an external function, or could be implemented as a class that entends the basic PID loop. I think that this is important if we want a basic PID block that could execute every 1-15 milliseconds so that the code could potentially be used for gas compressor anti-surge control.

>
>and so on ...
>
>Anyway, didn't mean to hijack the discussion from the important stuff. If
>anyone has any opinions on the above questions please let me know.
>
>chetan

so on includes:

11) P on measurement or error

Configurable by a parameter, dynamically changable while PID block is in auto.

12) D on measurement or error

Configurable by a parameter, dynamically changable while PID block is in auto.

13) D filter ratio (D-filter-time-constant =
alpha*derivative-time-constant)

1/alpha is configurable platform wide as 8, 10, or 16 to match your favorite DCS.

14) D filter conversion from Laplace-transform transfer-function to z-transform transfer-function

Pole-zero mapping, so that alpha*derivative-time-constant is not constrained by the sample time. Some DCSs pick an unfortunate alternative and then constrain derivative-time-constant >= 2 * sample-time/alpha or zero (which eliminates derivative action).

There are at least six ways to convert from Laplace-transform transfer-function to z-transform transfer-function. See Luenenburger:
"Digital Control of Dynamic Systems", and you can amaze people at the next party.

15) incremental vs. positional (full value) Output

Incremental works for most controllers, as long as integral action is non-zero. P-Only or PD controllers sometimes need to be positional (full-value) so that they can be applied to level and gas pressure control loops, or to the multiplier input to the feedforward of a cascade loop

16) Changing tuning parameters (gain, integral time, derivative time) while PID loop is in auto.

Configurable as a lower priority activity while PID block is in auto, as long as PID block is incremental, otherwise requires re- initialization, or re-ramp to alignmen.

17) What does the algorithm do when the PID mode changes.

Well, if configured to do so, the PID block does some extra stuff when changing to or from AUTO (or ON)

increments the output's source counter
increments the setpoint's sink counters
sets setpoint=measurement (one type of bumpless transfer, appropriate for all but the highest PID blocks in a multi-level cascade)
increments the setpoint's raise-ok and lower-ok counters if appropriate

18) Does the PID block need a local/remote/computer setpoint cascade mode

No. The setpoint is always local, remote, and computer. All at once, neither and all three (the zen of resonance). Actually, one might want to prevent access to the setpoints by unauthorized
people/programs/blocks, but that is a more fundamental issue of signal integrity.

19) Does the PID block need a Direct/Reverse option

No. This is a configuration display issue only. Some people have come to prefer a separate reverse/direct bit and a display of a non-negative gain. The result is changing the sign of the gain.

20) Does the PID block need modes other than Auto/Manual?

Actually: I suggest at least:

UNCOnfigured, FAIL, Fail-OFF, OFF, INITializing, CONDitional, REaDY, RUNning, ON

Note the four ASCII characters (which fit nicely in 32 bits) which can map into an enumerated set of states and a set of symbols for program use.

A state evaluator runs in parallel with the PID block. The state evaluator looks at the state of the PID block variables, initiates state transisions (as documented by a state transition diagram), and queues actions on change from or to various states as configured on a PID block basis.

For example, when the measurement fails or a configuration error is detected, the block makes a transition to the FAIL state from any other
state. The block does all the transition from activities (decrementing the raise-OK, lower-OK, source, and sink counters if necessary), and then does the transition to FAIL activities (perhaps posting an alarm). If the measurement becomes good, the mode makes a transition to the FOFF state. Only operator action can initiate transition from the FOFF state by requesting OFF or ON -- this prevents accidental restart of control action when a measurement is intermittent.

Whew! lots of concepts. Actually, many of these ideas made their way into a program called UC-Online which is used at UC Berkeley Chemical Engineering for undergraduate process control education. It is available for other organizations to use for teaching.

Paul H. Gusciora, Ph.D., P.E.
San Rafel, CA

Algorithms are free. What is expensive is interfaces to algorithms, and the
engineering experience to apply them.


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