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 = 4
    LIMOPT=1
    PB=100
    INT=10
    BIAS=:AIN.PNT  (this seems to be the trouble causer!)
    BCALCI=:AOUT.BCALCO
1 AOUT
    MEAS=:PIDA.OUT
    PRIBLK=1

All relevante HSCI's, HSCO's at 100.0

Starting conditions:
AIN.PNT=50.0 
PIDA.SPT=50.0
PIDA.MEAS=50.0
AOUT.MA=0
AOUT.LOLIM=10.0    (!!!!!)
AOUT.OUT=0.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=50.0 PIDA.MEAS=50.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=2 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=2
(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=1.

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

Other related posts: