Re: [foxboro] Cascade Master Block Reversing Control

James,

We noticed similar behaviour on some of our master-slave controls and I 
would like to quote one of the previous replies:

"Cascade loops do strange things sometimes. Is the meas (and therefore the 
BCALCO, and FBK of the primary loop) of the secondary or slave loop changing 
during this behaviour? If so, the FBK of the primary and therefore its 
output would change."

In our case it was not so that the master-slave control would suddenly stop 
working all together (if so in your case then no need to read on), but when 
optimising the tuning we noticed that in some cases the master controller 
seemed to take the reverse action of what you would expect.

Indeed, our conclusions are that the behaviour could be explained by the 
fact that the MEAS of the slave is not closely following it's SPT. This was, 
in our case, caused by a noisy slave measurement (high frequency, beyond 
controllability). If the master should increase the slave setpoint it 
'expects' the slave measurement (and thus the master feedback input) to 
increase as well (at some point in time, in other words: dynamically). It 
does NOT expect the slave measurement to decrease. However, if the slave 
measurement does DEcrease (due to the noisy measurement) the feedback to the 
master controller will DEcrease. Now the reset-windup comes into action.
Suppose the measurement of the slave would keep decreasing all the way to 
0.0 (assuming low range = 0.0), you would not like the output of the master 
to keep integrating all the way to 100%. The recovery of such a situation 
would be very poor!

This all happens very 'dynamically' but it all boils down to the fact that 
the master tries to keep it's output close to the measurement of the slave. 
If the slave becomes limiting (output at HOL or LOL) you can notice the 
output of the master decrease/increase (again dynamically) such that the 
output (and thus the slave RSP) will be close to the slave MEAS which allows 
for a fast recovery of the control when ever the slave recovers from the 
limiting conditions.

I don't know if this helps you any further as I don't know if this is 
identical to your problem.
It's just something which we thought to be a 'bug' at first but can be 
explained!


In short:
If you have a noisy and/or erratic slave measurement or a poorly tuned slave 
controller you could expect to see some 'strange master' behaviour (which 
you just have to 'take for granted').

We tried to resolve this 'problem' by decoupling the master from the slave 
(connecting the master FBK to it's own input. Okay, the 'strange behaviour' 
disappeared but this is not the proper way to configure a master-slave and 
it did not improve overall loop stability (at least not noticeably).

Kind Regards,
Patrick Martens
Process Automation Specialist
Total Raffinaderij Nederland N.V.


----- Original Message ----- 
From: "James B Koenig" <koenigjb@xxxxxxxxxxxxx>
To: <foxboro@xxxxxxxxxxxxx>
Sent: Monday, May 23, 2005 10:05 PM
Subject: [foxboro] Cascade Master Block Reversing Control


Thought I would ask this all knowing - been there - seen that list for
information before I went to TAC.
I have a problem with our cascade loops that only shows up once in awhile.
Lately more often. Every loop I have seen this on is a quiet Master temp
control loop using various temp, press or flow slave controllers.

The Master block will start controlling backwards. Example, when the
measurement rises above setpoint and the output should drive lower, it
actually starts rising instead. If you take the slave block out of remote
and then put it back into remote, the Master block will start acting
correctly again. This only happens on cascaded controls.

This has gone on in several version levels, for many years, but lately I am
told by our Techs that this has been happening once every two to three
weeks now, instead of only happening once every year or so, unless not
being reported.

Almost all of our cascaded controls are configured as shown below. Below is
the configuration of the last one that reversed control.

Currently running v6.5 with AP51B and CP40A's

Master Block (temp)                       Slave Block (press)
AOUT
Period   2                                Period   2
Period   2
Phase    1                                Phase    1
Phase    1
FBK      :SlaveBlock.BCALCO               FBK      :SlaveBlock.OUT
MEAS     :SlaveBlock.OUT
MODOPT   5                                MODOPT   5
PRIBLK   1
INCOPT   0                                INCOPT   1
PRIBLK   0                                PRIBLK   1
INITI    :SlaveBlock.INITO                INITI    :AOUT.INITO
BCALCI   :SlaveBlock.BCALCO               BCALCI   :AOUT.BCALCO
LOCSP    1                                LOCSP    0
                                          RSP      :MasterBlock.OUT
DERIV    0.02                             DERIV    0.0

I have also found several, but not all have had derivative set in the
Master block, the loop that did this a few weeks ago, two weeks in a row
(only known time same control loop this close together), did not have the
derivative set.

No other configuration set other than alarming functions. Since this
appears random , and not sure how to repeat it, I am not sure what my step
might be to stop it form happening.

Has anyone seen anything like this?
Where should I start looking to correct this?

thank you

James B Koenig
Production Data Tech
BASF Corp.



_______________________________________________________________________
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: