Re: [foxboro] PIDA 'dead-lock' ?
- From: "Pat Martens" <foxpat@xxxxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Fri, 23 Dec 2005 08:28:24 +0100
I forgot to mension that: version 6.3 !
(Although I've got this problem at LIMOPT=1)
----- Original Message -----
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 =
believe it was with V6.3 CS Release and the problem was the PIDA block =
could lock up if LIMOPT =3D1 under certain conditions. Foxboro recommended=
a work around of LIMOPT =3D2 or =3D 3 until they could provide a fix. =
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 =
was not moving when the setpoint was (drastically)changed either up or =
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 =
reproduce the behaviour which I could !
I then created a completely new configuration from scratch with parms at =
default as much as possible (HSC's at 100%, PB at 100 etc) and was again =
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 =3D 4
LIMOPT=3D1
PB=3D100
INT=3D10
BIAS=3D:AIN.PNT (this seems to be the trouble causer!)
BCALCI=3D:AOUT.BCALCO
1 AOUT
MEAS=3D:PIDA.OUT
PRIBLK=3D1
All relevante HSCI's, HSCO's at 100.0
Starting conditions:
AIN.PNT=3D50.0=20
PIDA.SPT=3D50.0
PIDA.MEAS=3D50.0
AOUT.MA=3D0
AOUT.LOLIM=3D10.0 (!!!!!)
AOUT.OUT=3D0.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 =
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 =
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 =
positions, increase it with an additional 5% and the AOUT will also =
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=3D50.0 PIDA.MEAS=3D50.0 AOUT in =
manual, output at 0.0 and LOLIM at 10.0 %)
Switch AOUT to auto, again AOUT.OUT jumps to LOLIM and so does the =
PIDA.OUT
I now DE-crease the AIN.PNT (linked to the PIDA.BIAS) with 5 % and I =
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 =
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 =
0.15 %.
I keep increasing the setpoint but the output of the PIDA does only =
increase in 0.15% steps.
I now have a huge offset on the PIDA but it does not seem to do anything =
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 =
output of the PIDA to even go further (into limiting) AND the BIAS does =
not return to it's original value it seems not only the integral freezes =
but also the P-kick is effected resulting in a situation which does not =
resolve automatically (return from limiting condition) but needs operator =
intervention (toggle from auto to manual to auto) to make it work again.
I was able to solve things by setting PIDA.LIMOPT=3D2 in which case the =
PIDA seems to integrate it's output so that it will eventually be equal to =
it's BCALCI.=20
The thing is, I don't know how to interpret the 'side effects' of =
LIMOPT=3D2 (possible output offset due to the rectification of noise?? =
That does not sound like something I want!) and I would expect things to =
work with the default LIMOPT=3D1.
Anybody knows (what am I doing wrong, what is it that I do not understand, =
or could it be a bug (our Fox. field engineer would say: that's not a bug, =
it's a feature!) ??
Kind regards and all feedback highly valued !
Patrick Martens
Total Raff. Nederlands N.V.
=20
=20
_______________________________________________________________________
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=20
=20
foxboro mailing list: http://www.freelists.org/list/foxboro=20
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin=
=20
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave=
=20
=20
_______________________________________________________________________
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
_______________________________________________________________________
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
- References:
- Re: [foxboro] PIDA 'dead-lock' ?
- From: Jim Kahlden
Other related posts:
- Re: [foxboro] PIDA 'dead-lock' ?
- From: Jim Kahlden