Re: [foxboro] Query on override controllers
- From: "foxpat" <foxpat@xxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Fri, 7 Jan 2011 20:04:16 +0100
Hi,
On our old DCS (Controle Bailey MicroZ) override controllers were typically
configured by having the output of one PID block set the high/low limits of
the other PID block.
Our first Foxboro PIDA implementation was just that; a copy of the old
configuration.
After playing with the PIDA block a bit we found out that override
controllers can be implemented on I/A with just 2 PIDA blocks and an OUTSEL
block and standard BCALCI/BCALCO linking.
In my experience however, it works best if the LIMOPT of both PIDA blocks
are set at 3. This will make sure the override controller does not 'kick-in'
by a proportional action before it's setpoint is exceeded and will keep a
(required) GAP between the main- and override-controller outputs.
Whenever the override controller is below setpoint (supposing it is a high
override control) the integral action of the PIDA will manipulate it's
output so that it remains 'out-of-the-way' of the main control. It will not
increase (or decrease) up to the output limits (no reset wind-up) but stay
near the output of the main contoller. So, there will be a GAP but this is
good because you do not want the override controller to override just yet.
The GAP however, will dynamically become smaller the closer the override
controller gets to its setpoint. This depends on the tuning of the
controller. Assuming the main controller offset is close to zero, the
override controller will take over exactly at the point where it's offset
changes sign (in other words; when it's setpoint is exceeded).
If dynamics of the main controller and overrided controller are about the
same this should work perfectly. It becomes more difficult (tuning wise) if
the dynamics of both control loops are very different.
If the LIMOPT of the PIDA blocks are left at 1 the output of the non-active
controller will just freeze at its last value. This will lead to undesired
results where the main controller and override controller will constantly
switch if both measurements increase/decrease simultaneously.
I would suggest to configure a simple simulation, build some trends, set the
PIDA.LIMOPT to 1, do some steptesting, set PIDA.LIMOPT to 3 and compare.
Kind regards,
P. Martens
Total Raff. Ned. NV.
-----Oorspronkelijk bericht-----
Van: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
Namens Andriny Bt Rusman (R&T/PETH)
Verzonden: vrijdag 7 januari 2011 13:46
Aan: foxboro@xxxxxxxxxxxxx
Onderwerp: [foxboro] Query on override controllers
Dear list,
I have always had this question unanswered but only until recently it
seemed ridiculous to not find out about it. It is about override
controllers. When it is inactive (not selected for control) and the
override controller is configured to track the active controller's OP,
there'll be a gap between the outputs of the 2 controller. I've
wondered how this gap is reduced (in terms of speed), when the override
controller is suddenly asked to take over control. Is it a function of
the controller tuning? I've implemented some override controllers and
some has a noticeably slow response when the control is suddenly handed
over to these overrides due to these gaps. The gaps can be really big
and since some overrides are the 1st barrier of protection before going
to other levels, sluggish response is not acceptable.
Appreciate it if anybody can help explain the mechanics and perhaps, how
to speed up response for the override to take over control.
Best regards,
Andriny Rusman
Staff Engineer,
Advanced Process Control,
Group Technology Solutions,
Level 8, Menara Dayabumi
Phone: 03-2783 6317
Petronet: 8-333-6317
Fax: 03-2783 6499
email: andriny@xxxxxxxxxxxxxxx <mailto:andriny@xxxxxxxxxxxxxxx>
DISCLAIMER : This e-mail and any files transmitted with it ("Message") is
intended only for the use of the recipient(s) named above and may contain
confidential information. You are hereby notified that the taking of any
action in reliance upon, or any review, retransmission, dissemination,
distribution, printing or copying of this Message or any part thereof by
anyone other than the intended recipient(s) is strictly prohibited. If you
have received this Message in error, you should delete this Message
immediately and advise the sender by return e-mail. Opinions, conclusions
and other information in this Message that do not relate to the official
business of PETRONAS or its Group of Companies shall be understood as
neither given nor endorsed by PETRONAS or any of the companies within the
Group.
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
