I have a request to allow the operator to select one of two levels as the "master" of a cascaded flow loop.
Normally, the level in the overhead from tower "O" is controlled by (cascaded to) the flow to tower "B". But when tower "B" has troubles, the overhead flow bypasses the entire tower, to the outlet flow of tower "B". So we want this "B" outlet flow to take a setpoint from either the tower "B" bottoms level, or from the tower "O" overhead level controller. When tower "B" is bypassed, its level measurement could be unreliable and / or show transient levels from maintenance activities.
I like using the Control Selector function block, since it handles all the BKCAL_IN / OUT cascade-initialization handshaking very nicely and keeps both "upstream" PID blocks from being in an abnormal state. But I can't see a way to allow an operator to "select" one or the other "master" - like you'd have in a ISEL block (OP_SELECT parameter). What are the other options?
1) Make the CTSEL a "high select" and force the not-selected block to manual with an output of zero?
1A) Use the CTSEL block and address placing the unused level in MAN procedurally?
2.) Make the two levels inputs to an ISEL block and send the OUT to a single (level) PID block cascaded to the "B" bottoms flow? would likely have some tuning challenges - gain scheduling . . . ?
3.) Use a CALC block and just do the cascade initialization by copying input statuses to output statuses. Anyone know the correct status for "GoodCascadeNotSelected" and all the other ones (and in what sequence) the "unselected" PID would need to see? Is "not selected" a higher status than "not invited"?
Anyone see an elegant solution with standard function blocks and minimal coding?
I've had this type of request before, and have seen it handled pretty much every way you've laid out.
The idea behind the control selector is to work as an override control exclusively.
Note In Auto mode, when any of the connected SEL_ 1, SEL_2 or SEL_3 inputs have Bad status during block execution, the block transitions its actual mode to Man. When the Bad SEL_1, SEL_2 or SEL_3 input transitions back to Good status, the block resumes Auto operation
This may not work for you, as a bad status from your out of service PID controller will trigger the Control selector to go to Manual.
It would seem that option 2 makes the most sense since you don't plan on switching control on a regular basis and you don't have to go down the path of option 3 in which you reproduce the back calc initialization logic (which I've seen done before as well).
In reply to gamella:
Hi John,
The most elegant & efficient way is to replace the CTLSL block with CALC block & do the handshake based on selection.
I had the code somewhere..... Will try to find & send you the same.
For the status codes, search "Function Block Status Information" section in BOL. "GoodCascadeNotSelected" is not a valid status. You can use "GoodCascade NotSelected NotLimited (208)" or "GoodNonCascade NonSpecific NotLimited (128)" instead. It is better to use 128, so the mode of slave does not go to CAS.
While initialising the cascade, you will have to check for "GoodCascade InitializationRequest NotLimited (200-203)" from slaves & respond to only selected one with "GoodCascade InitializationAcknowledge NotLimited (196)". Rest of the status handling happens automatically....
Best Regards,
Amod.
Interesting. Hadn't thought of using RCAS - very clean & simple. In the BG block, I'm guessing the OUT of the master PID's are connected to the TRACK_IN of the respective BG, and selection is made by turning TRACK_IN_D on or off . . . ?
Setpoint limits? I've seen BG do some interesting things with the SP if it isn't clamped to a very small number . . .
What is the "selection" (high, middle, low) in the CTSEL? Does it matter?
Thanks & Rgds
John
In reply to amodbobade:
John,
The big question is what happens to the the non-selected Loop when it isn't the selected master and then what happens when it becomes selected.
I believe the best answer to your configuration is option 3 so that the not selected Loop can be in IMAN and track the SP of the slave so when it does become the selected loop, there is no bump in the process.
A long time ago we suggested to technology that the Control Selector block be changed to allow an operator selection and I believe that it was written up to do so but it has never been implemented in the product to date.
We have done this many times and I have a sample config (v12 ok?) that I can email if you provide your email or you can get my contact info from Gary Lipson (he works for Ashland).
I can also provide a list of all the status values at the same time.
Regards,
Matt
Hi,
Out of curiosity, I tried out the approach gamella has suggested in one module.... It works really fine with the use of BG blocks. A clean solution.....
Thanks for sharing this method on the forum.
I had left the BG block IN as "0" considering both PID's in same range, & PID output is connected to CAS_IN. Backcalculations were connected from BG to PID as well.
As Matt has correctly indicated, 'the question is what happens to the the non-selected Loop'. In this case, since the BG block is in LO mode, the respective PID goes to IMAN & hence tracks the CTLSL block back calculation.
The only issue is, if operator wants to keep both loops working & compare the outputs before switching. With a calc block (option 3), it is really easy to customise this by controlling the cascade handshake statuses. But can also be achieved by removing the backcalculations from BG to PID blocks.
(Last time when I implemented this, the requirement was that operator can only switch when this difference is less than 3%. Until then he can still monitor both loops, as they continue to generate outputs like in a automatic override control.) PID coming out of tracking (LO) to AUTO can also have bump on the output, if SP-PV tracking is disabled to mantain SP.
That example seems like alot of overhead to do this and the config below allows the operator to switch at anytime because the not selected loop(s) is following what the downstream is doing so there will be no bump:
When PID1 is selected:
When PID1 is NOT selected:
If both loops are to control (modulate it's output) while the selection is made, then this logic changes slightly. You will need something very similar to logic shown but I believe the status logic would use a 208 (GoodCascade NotSelected) instead of 204.