dear all
Can anyone tell how to achieve bumpless transfer in cascade loops along with different modes the primary and secondary controllers are during execution.
B/R Kiran
dear all
Can anyone tell how to achieve bumpless transfer in cascade loops along with different modes the primary and secondary controllers are during execution.
B/R Kiran
Do you need a solution for a specific platform, or a description of the theory involved?
As an aside, IMO bumps can and sometimes should be accepted in the interests of simplicity. Initialisation functions can result in unexpected behaviour at times with some control configurations.
I'm not so sure that I understand all that you are trying to do, and what platform you are trying it on. Generally, if you have the setpoints track the process values, then you get a bit closer to what you want. As far as the different modes, depending on the system, you may want to write a control program or algorithm which sets all the modes correctly. Try to have as few operator inputs as possible. By having the operator only poke one button to make the entire change, you'll have happier operators and more control over the various modes that are used.
I'm not sure I answered your question. If you were to clarify it a little we might come closer to your needs.
Michael
Would have thought a good place to begin is the velocity form of the control algorithm
The details depend upon the particular model controller being used, if it is a "store bought" controller.
In the most common (as far as I know) method, the output of the primary (or master) controller tracks the setpoint of the secondary (or slave) controller when the secondary is not in "remote setpoint" or "cascade" mode.
Some information can be found at my web site:
John
hi,
let say u got two controler (ctr) in a cascate control schems
The normal situation is : primary in AUTO secondary in CAS (Cascate)
if for any reasons, operations break the cascate (place the secondary in AUTO), and manualy chg the secondary SP, what appen
first because the secondary ctr is now in AUTO the primary initialyze (enter in INIT) : and the primary OP is set equal to the secondary SP
when u put back the secondary in CAS, the primary stop INIT and calc back is OP according is own SP and PV, the new OP will probably be different from SP previously enter by operation, and you get a Bump...
there is two std way to avoid the bump
1 : configure the primary to track the PV : that option equalize the primary SP with the primary PV during initialization step (INIT), when u restor the cascate the primary recalc is OP but SP is now equal to PV so there is no reason to move OP (and primary OP have been init to secondary SP)2 : you don't want the prim SP to be chg : u need to use an OPBIAS option to slowly ramp the OP set during INIT ( equal to sec SP when this one was in AUTO) to the new primary calculated OP
Have something to add? Share your thoughts — no account required.
Ask the community — no account required