Re: [foxboro] PIDA 'dead-lock' ?

Pat,

I was reminded that I once sent out a notice internally to our DCS group
about a problem with the PIDA block with LIMOPT=3D1. Here it is:

> Perusing the V6.4 Enhancements and Problems Resolved document, I came
> across this item that you guys might want to be aware of. If a PIDA=20
> block ever behaves squirrelly, you may want to read this note a little
> more closely.
>
> Duc
>
>
>
> LIMOPT Parameter in PIDA Block (CAR#1002914)
>
> Problem
> -------
> A problem exists when the PIDA block's limit option (LIMOPT) is set=20
> to 1. If a high or low downstream limiting condition is encountered,=20
> the integral action of the controller is essentially disabled,=20
> preventing the control loop from recovering. There is no visual=20
> indicator or alarm condition of the integral action being disabled.=20
> To recover, you must put the controller in MANUAL, move the final=20
> control element to clear the limiting condition, then place the=20
> controller back in AUTO.
>
>
> Resolution
> ----------
> I/A Series V6.4 software corrects this problem.

Duc

--=20
Duc M. Do
DCS Group, Carrollton Plant
Dow Corning Corp.
Carrollton, KY, US


-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Pat Martens
Sent: Friday, December 23, 2005 2:28 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] PIDA 'dead-lock' ?

I forgot to mension that: version 6.3 !

(Although I've got this problem at LIMOPT=3D1)

----- Original Message -----=20
From: "Jim Kahlden" <James.Kahlden@xxxxxxxx>
To: <foxboro@xxxxxxxxxxxxx>
Sent: Thursday, December 22, 2005 9:46 PM
Subject: Re: [foxboro] PIDA 'dead-lock' ?


Patrick,

I recall there was a Customer Advisory to this a couple of years ago.  I
=3D
believe it was with V6.3 CS Release and the problem was the PIDA block =
=3D
could lock up if LIMOPT =3D3D1 under certain conditions.  Foxboro
recommended=3D
 a work around of LIMOPT =3D3D2 or =3D3D 3 until they could provide a =
fix.
=3D
What version of software are you using?




Jim Kahlden
System Reliability Analyst
Lower Colorado River Authority
Fayette Power Project
6549 Power Plant Road
La Grange, TX 78945
(979) 249-8514 (Ph)
(979) 249-8390 (Fax)
jim.kahlden@xxxxxxxx

>>> foxpat@xxxxxxxxxxxxxxx 12/22/2005 1:14:38 PM >>>
Dear list,
(Sorry for the long piece of prosa !)

I was called in by operations telling me that the output of a controller
=3D
was not moving when the setpoint was (drastically)changed either up or =
=3D
down (so positive or negative offset).
They switched to manual and back to auto and all worked o.k. as before.

I copied the configuration to an offline system to see if I could =3D
reproduce the behaviour which I could !
I then created a completely new configuration from scratch with parms at
=3D
default as much as possible (HSC's at 100%, PB at 100 etc) and was again
=3D
able to reproduce the behaviour.

This is what I have:

1 AIN in manual mode, just to drive the PIDA.BIAS
1 PIDA in auto mode
    MODOPT =3D3D 4
    LIMOPT=3D3D1
    PB=3D3D100
    INT=3D3D10
    BIAS=3D3D:AIN.PNT  (this seems to be the trouble causer!)
    BCALCI=3D3D:AOUT.BCALCO
1 AOUT
    MEAS=3D3D:PIDA.OUT
    PRIBLK=3D3D1

All relevante HSCI's, HSCO's at 100.0

Starting conditions:
AIN.PNT=3D3D50.0=3D20
PIDA.SPT=3D3D50.0
PIDA.MEAS=3D3D50.0
AOUT.MA=3D3D0
AOUT.LOLIM=3D3D10.0    (!!!!!)
AOUT.OUT=3D3D0.0

So everything 'lined-out' at steady state (no PIDA offset)

I next switch the AOUT from manual to auto and it will 'bump' (which is
=3D
normal) from 0.0 to the 10% LOLIM.
The PIDA.OUT will also move to the LOLIM value
If I now DE-crease the PIDA setpoint with 5% the output will DE-crease =
=3D
slightly but due to the LOLIM on the AOUT the AOUT.OUT will remain at
10.0
I then IN-crease the PIDA setpoint with 5% and all is back to the
starting =3D
positions, increase it with an additional 5% and the AOUT will also =3D
increase from 10 to 15% (P-kick) and start integrating from there.
All of this is what I would expect.
(notice I have not touched the PIDA.BIAS value (so the AIN.PNT)

Now the problem part (or the part that I don't understand!)
Back to initial conditions (PIDA.SPT=3D3D50.0 PIDA.MEAS=3D3D50.0 AOUT in =
=3D
manual, output at 0.0 and LOLIM at 10.0 %)

Switch AOUT to auto, again AOUT.OUT jumps to LOLIM and so does the =3D
PIDA.OUT

I now DE-crease the AIN.PNT (linked to the PIDA.BIAS) with 5 % and I =3D
notice the PIDA.OUT will also decrease with 5%.
The AOUT remains at the LOLIM value 10.0%

I then IN-crease the PIDA setpoint with 5% and I would expect to see a =
=3D
positive P-kick of 5% on it's output resulting in a PIDA.OUT of 10%.
This however is NOT the case, the output of the PIDA only increase with
=3D
0.15 %.
I keep increasing the setpoint but the output of the PIDA does only =3D
increase in 0.15% steps.
I now have a huge offset on the PIDA but it does not seem to do anything
=3D
with it ???

There are a couple of ways to get it back to work:
Either:
Toggle the AOUT from AUTO to MANUAL and back to AUTO
or
IN-crease the BIAS input back to it's original 50%

To recap:
If a PIDA detects a limiting condition and the BIAS input forces the =3D
output of the PIDA to even go further (into limiting) AND the BIAS does
=3D
not return to it's original value it seems not only the integral freezes
=3D
but also the P-kick is effected resulting in a situation which does not
=3D
resolve automatically (return from limiting condition) but needs
operator =3D
intervention (toggle from auto to manual to auto) to make it work again.

I was able to solve things by setting PIDA.LIMOPT=3D3D2 in which case =
the
=3D
PIDA seems to integrate it's output so that it will eventually be equal
to =3D
it's BCALCI.=3D20
The thing is, I don't know how to interpret the 'side effects' of =3D
LIMOPT=3D3D2 (possible output offset due to the rectification of noise?? =
=3D
That does not sound like something I want!) and I would expect things to
=3D
work with the default LIMOPT=3D3D1.

Anybody knows (what am I doing wrong, what is it that I do not
understand, =3D
or could it be a bug (our Fox. field engineer would say: that's not a
bug, =3D
it's a feature!) ??

Kind regards and all feedback highly valued !

Patrick Martens
Total Raff. Nederlands N.V.


 
 
_______________________________________________________________________
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:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: