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

Pat,
        I'm assuming that the AIN.PNT used for the PIDA.MEAS parameter
comes from a different block than the AIN.PNT used for the PIDA.BIAS
parameter.  Is that correct?  I remember we had a similar issue
associated with LIMOPT when we converted all of our PID, PIDE, PIDX,
PIDXE blocks to PIDA's.  The old PID blocks didn't have a LIMOPT
parameter but responded as if they used the LIMOPT equal ONE of the PIDA
strategy.  FYI, the string (LIMOPT =3D 1), gets butchered by OUTLOOK
Exchange Server, sometimes,and makes it look like LIMOPT equal 3D1.
(Yes Kevin F., I remember your solution but it is one we can't address
from within our corporate confines).
        Since we are currently locked at Ver. 6.2.1, we decided to use
LIMOPT equal ZERO on some of our controllers that displayed the problem.
Although FOXDOC doesn't say that ZERO is an option, it did correct our
problem but may allow integral windup when PV is out of range?
        Supposedly the LIMOPT equal ONE problem was resolved in Version
6.4, (see Duc's email clipped from 6.4 Enhancements and Problems
Resolved).  I hope some of this info is helpful.
Cheers,
Tom VandeWater

Below are some excerpts about LIMOPT clipped from FOXDOC.

"LIMOPT (limit option) lets you specify the anti-windup strategy used
for recovering from a limiting condition. For the default value of
LIMOPT (1), integral action is frozen, when the output or a downstream
block is limited and the integral term is between output limits.
Downstream block limiting is propagated back through status bits in the
BCALCI input."

"BATCHO Batch Control Option is a Boolean input that enables the PIDA
block to operate as a preloadable controller. You can change BATCHO only
by reconfiguring the block. When BATCHO is true, and a limit condition
exists, the integral term is set to the value nearer the limit, PRLOAD
or the value selected when LIMOPT is 2. This tends to avoid saw-tooth
ratcheting and excessively slow recovery."

"FBK Integral Feedback is a connectable, settable, real input used to
generate integration action. Its function is to prevent integral windup
when LIMOPT is 3, and to allow tighter tuning of a primary controller.
If FBK is not linked to a source, it is connected to BCALCI, provided it
is linked. Otherwise, FBK is automatically connected to OUT."

"LIMOPT=20
Limit Option is a configurable, settable integer that specifies the
anti-windup strategy for recovering from a limiting condition. LIMOPT
values range from 1 to 3 and map to the following strategies:=20
1 =3D  Freezes the integral term between the effective limit values when
limiting is detected. This is the default choice. The net
proportional and derivative term must subside to the difference
between the effective limit value and the integral term before the
output comes out of limit and integration resumes.=20

2 =3D  Adjusts the integral term so that the prelimited output is equal
to the effective limit value when limiting is detected. As soon as
the net proportional and derivative terms change direction, the
output comes out of limits and integration resumes. This
produces a more sluggish non-overshooting recovery.=20

3 =3D  Allows the integral term to exponentially coast up to the
effective limit value with the integral time constant. If the limit
condition persists long enough (several integral time constants),
the net proportional and derivative term must change sign
before the output comes out of limit and integration resumes.
The result may be an overly-aggressive overshooting recovery."

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

In my example the PIDA.MEAS is not linked so I can set it from a
display.

In the 'live' situation it's tied to an AIN.PNT with IOMOPT=3D1

Regards,

Pat

----- Original Message -----=20
From: "Johnson, Alex P (IPS)" <alex.johnson@xxxxxxxxxxxxxxxx>
To: <foxboro@xxxxxxxxxxxxx>
Sent: Thursday, December 22, 2005 10:38 PM
Subject: Re: [foxboro] PIDA 'dead-lock' ?


What is MEAS on the PIDA tied to in your example?

Regards,

Alex Johnson
Invensys Systems, Inc.
10900 Equity Drive
Houston, TX 77041
713.329.8472 (voice)
713.329.1700 (fax)
713.329.1600 (switchboard)
alex.johnson@xxxxxxxxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On
Behalf Of Pat Martens
Sent: Thursday, December 22, 2005 1:15 PM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] PIDA 'dead-lock' ?

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
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.
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.




_______________________________________________________________________
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=3Djoin
to unsubscribe:      =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave




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

Other related posts: