EE - Forum Styles

Control Selector Function Block (CTLSL)


Is there a parameter in Control Selector Function Block (CTLSL) to indicate which input of the block has been selected? 

I have a low-select Control Selector Function Block (CTLSL) and I want to know when the SEL_3 is selected.



30 Replies

  • There is no such parameter. I would be useful to be able to reflect which PID is selected in the operator display.

    I used a CALC block to evaluate the BKCAL_OUTx parameters to determine which one does not have a status of GoodCascadeNotSelected. The numeric value of the status is 208, and if a limit condition is set, 209, 210, or 211. So I mask out the last two bits with the number 252, and looking for the result to be = 208. Looks like this:

    If ('^/CTSL/BKCAL_OUT1.ST' & 252) <> 208 then
    If ('^/CTSL/BKCAL_OUT2.ST' & 252) <> 208 then
    OUT1.CV := 3;
    OUT1.CV := 2;
    OUT1.CV := 1;

    Or something similar. Note the code above is not tested. But you get the idea. The CALC/OUT1 parameter holds the selected PID block. Let us know how this works...

    Andre Dicaire

  • In reply to Andre Dicaire:

    Thanks Andre, this was helpful when I was writing one of these.  Below is what I ended up with:

    (* If the Control Select is not in Auto then the downstream loop is likely not is CAS, no selection *)
        (* GoodCascade NotSelected is Status 208-211 mask out the last two bits so all NotSelected
           sub-statuses evaluate to 208 *) (* Only show the input as selected when GoodCascade *)
        IF (('^CTLSL1/BKCAL_SEL1.ST' & 252) <> 208) AND ('^CTLSL1/BKCAL_SEL1.ST' >= 192) THEN
            'OUT1.CV' := 1;
        ELSE IF (('^CTLSL1/BKCAL_SEL2.ST' & 252) <> 208) AND ('^CTLSL1/BKCAL_SEL2.ST' >= 192) THEN
            'OUT1.CV' := 2;
        ELSE IF (('^CTLSL1/BKCAL_SEL3.ST' & 252) <> 208) AND ('^CTLSL1/BKCAL_SEL3.ST' >= 192) THEN
            'OUT1.CV' := 3;
            (* The Block is in Auto with no selected input, this should not happen possibly still handshaking *)
            'OUT1.CV' := 0;
        (* The Control Select Block is not in Auto, so no selected input *)
        'OUT1.CV' := 0;

  • Hello,

    How about if I only have two inputs from 2 PID outputs and my CTLSL1 is in LOW select mode? Will it select the 3rd unused input since its always zero?
    How do I go about it?

    Thanks for your answers.
  • In reply to Rein:

    With the CTLSL 3rd input not connected, the CTLSL block is aware that the input is not used. It will ignore this input and the value of 0.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Thanks Andre,

    But my CTLSL1 is in IMAN. Could it be that the BKCAL_IN in the PID block for IN2 is not connected to the BKCAL_OUT2 of the CTLSL1 block? What should be the mode of the CTLSL1? Because, the permitted modes are only OOS, MAN, and AUTO. Should I select CAS also in the permitted modes and download the module?
  • In reply to Rein:

    IMAN is usually indicative of a downstream block not being in CAS. IMAN is not a selectable mode so adjusting permitted modes will not affect this.

    It could be due to a bad output setting tha AO block to IMAN or simply the AO block not is CAS mode.

    The status of BKCAL_IN on the CTLSL block is likely indicating Not Invited as its sub status.

    When it comes to the CTLSL block I've seen many installations show the two or three PID blocks as separate modules each with their own alarms. The CTLSL is designed for Override or Constaint control. It provides dynamic limiting of the control element to keep the primary loop at its maximum setpoint without exceeding the constraints.

    In this scenario the loop is say a flow loop, with low select CTLSL. A pressure constraint is applied to prevent over pressure. The pressure is affected by other factors and we can not simply place a hi limit on the flow PID block. In this case I like to place the constraint PID in the flow loop. It is not a pressure controller. It is a flow limiter. The operator may be allowed to adjust the constaint, or not, by giving access the SP of the Pressure PID block.

    In other cases you may have two operational modes where a valve is used in flow control sometimes and in pressure control at other times and this is a selection by the Operator, not a constraint control. In that case both loops are exposed with a selector to choose from. Be careful here as having the Output block is a different module than the PID means increased latency in the loop response. This can limit you closed loop response. Keep the output with the fastest loop response requirements

    A third is a multivariable control loop where both pressure and flow are being controlled. You might also have other manipulated variables to consider in a highly interactive process. The MPC blocks would be better choice.

    In addition to the pressure override the flow loop can use an interlock to take further in certain conditions. The constraint PID is tuned to provide stable control at the constraint pressure. Overly aggressive action by the constraint PID have other undesirable effect on the process. Tune the constraint for normal operation and consider interlocks for abnormal conditions.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Hello Andre,

    Thanks for your reply.

    So, the CTLSL1 (module C) should become in AUTO if the downstream block (Module D) is in CAS? Or it should also be in CAS?

    I thought that the BKCAL_IN of the upstream blocks (Modules A & B) which are PID should be connected to the BKCAL_OUT of the downstream block which is the CTLSL1 (Module C), in order to function. That as per Books Online. Or not necessary?

    If the downstream block (module D) is in CAS, are all the upstream blocks like the CTLSL1 (module C) and the PID blocks (modules A & B) should also be in CAS or not necessary? If not, what should be the mode of the upstream PID block (modules A & B)?

    Below is the inter-connection of my modules A, B, C, & D:


  • In reply to Rein:

    As usual, great information from Andre! If at least one of the downstream loops (B and D) has an actual mode of CAS, the CTLS actual mode should go to Auto. Check to make sure all of the "Output Paramters" (e.g. B_LOOP/BKCAL_OUT) are "Floating point plus status", not just "Floating point". Most control features in DeltaV rely on the propagation of the Status along with the Value.
  • In reply to Rein:


    We recently implemented a three AI - low select control scheme for a natural gas supply. 

    It was based on the Control Selector function block application information found in the DeltaV Books Online.

    The logic was simple to implement by following the BOL example.



    Control Selector function block diagram example

  • In reply to fairchdm:

    Be aware that selection of INPUTS to a controller PV is different that selection amongst controller outputs to another loop or final control element! The selections amongts INPUTS to a controller is usually done with either an Input Selector or Signal Selector function block. For the selection amongst controller ouputs to be sent downstream to a loop or final control element, the Control Selector function block must be used! Hope this helps!
  • In reply to Rein:

    Interesting. I've not seen the CTLSL upstream of the PID block. The D PID has to be in CAS/CAS for CTLSL to go out of IMAN.

    The CTLSL should be in AUTO so it drive the D CAS_IN with a signal from either PID A or B. If you alloe CTLSL to go to MAN, then the CAS_IN would be manually controlled from CTLSL. just too many choices for Modes and Parameters all to set the SP of D PID.

    PIDs A and B will stay in IMAN as long as CTLSL is not in AUTO. They can have Target mode of MAN or AUTO. To function properly, both these loops should be in AUTO to allow the integral tracking from the CTLSL BKCAL_OUT signals.

    PID D is not really part of the contro selection. It is down stream, just like the AO block in the example in BOL.

    PID A and B are the inputs being selected. Usually one loop is the primary loop and the second a constraint. You have a cascade loop with a low select override constraint on the Master loop. I have no idea what your process is so i can't comment on the application. I would lock the CTLSL to AUTO, and move it into D module. Your operators either use D when it is not in CAS, or they use A or B when D is in CAS. There is no need for the extra module, which adds latency.

    Good luck.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Is it ok to remove the link between the BKCAL_OUT of the module C and BKCAL_IN of either module A or B? What will happen?
  • In reply to Rein:

    The Bkcal signal is required to allow the selector to track the non selected blocks via the integral term.

    Without BKCAL connection the PID does not participate in block initialization and would drive its output via reset. This would saturate the output and prevent proper operation of the control selector.

    It would not work. BKCAL connection enables GoodCascade status on the OUT signal, and the sub status that goes with it. The OUT signal to the Ctlsl input would be GoodNonCascade and that may prevent it from being selected.

    But I've simply not tried this as I know it will not work for proper low select on constraint control. Give it a try and see what happens. On a simulated loop that is.

    Andre Dicaire

  • The control selector does not show the selected input. It would be best to interrogate the status bits of the BKCAL_OUT's of the block to determine which one is selected. This can be done via the code provided by Andre, or if you have done the homework, you can actually extract the relevant status bits using a bitwise comparator (ask me I did it that way). If the BKCAL_OUT from the control selector is not connected then yes the upstream blocks will not initialize properly, however, if you enable dynamic reset limiting from FRSIPID options, and feedback the PV to the BKCAL_IN of the upstream PID, then you will prevent windup for the unselected loops. This implies if you accidentally/intentionally use a reference as floating-point only then although IMAN will not happen properly, at least the unselected loop will not windup. One of my biggest issues with this block is that it does not have a manual input selector like other systems. I have seen very poor designs because of this, as engineers use XFER blocks to do manual control selection. The problem is that the XFER block strips off the control initialization bits. This results in a clumsy workaround for initializing the non-selected loop. If this frustrates you enough, then you will end up creating your own control selector block which allows for a manual input as well i.e. MID/LOW/HI or MANUAL selection. Again this is something I would recommend DeltaV developers look into for future revisions.
  • In reply to Paul Hughes:

    In v14 there is a new enhanced control selector function block that addresses these issues as well has having extendable parameters to allow more than 3 (up to 16).