Re: [foxboro] PIDA 'dead-lock' ?
- From: Kevin FitzGerrell <fitzgerrell@xxxxxxxxxxxxxxx>
- To: "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
- Date: Fri, 23 Dec 2005 10:19:52 +1300 (NZDT)
Pat,
We've got a CAR in on an issue with the PIDA block and BIAS.
Our problem is different than yours, but the root cause may be the same. When
we upgraded from 6.2.1 to 6.5.1 our PIDA blocks with feedforward (BIAS input)
and MODOPT=7 would no longer control. This was classed as a HOT CAR by Foxboro
(I believe over 2 years ago), but we haven't had any resolution.
Regards,
Kevin FitzGerrell
Carter Holt Harvey, Ltd.
Quoting Pat Martens <foxpat@xxxxxxxxxxxxxxx>:
> 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
- References:
- [foxboro] PIDA 'dead-lock' ?
- From: Pat Martens
Other related posts:
- [foxboro] PIDA 'dead-lock' ?
- From: Pat Martens