Recent Control & Safety Systems Discussions
Similar Posts
Enhanced Control Selector Function block
Operator Input to Control Selector Function Block
PID controllers with output signal selector
Control studio function block.
device control function block
Share

Control Selector Function Block (CTLSL)

Hi,

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.

Thanks,

Learner

learner

30 Replies

  • JoshC

    In reply to Paul Hughes:

    As as aside, I don't believe you need dynamic reset limiting enabled in FRSIPID options to prevent the non selected loop from winding up. You can test this and what you should see is the non-selected loop's output goes to the product of the error in percent of span and the proportional gain. The seconds/reset governs the rate at which it reaches that final output. I think the dynamic reset limiting is useful in scenarios such as cascade control where the upstream loop may be selected but the downstream loop is limited in some fashion and thus unable to respond as the upstream loop would like.
  • Andre Dicaire

    In reply to JoshC:

    Josh, you are correct. The Non-selected PID blocks use Integral Tracking, where the Integral term follows the CTLSL OUT value, and the Proportional Term is added to this to get the PID OUT signal. As the constraint PV approaches the constraint SP, the PID OUT will equal the controlling PID OUT and the selector will perform a bumpless transfer when the constraint PV moves past SP, resulting in a lower value and the PID being selected.

    At this point, the Constraint PID is selected and its integral action is enabled. The other loop now tracks in the same way. The non selected PID block responds with proportional action so there is no wind up.

    This all happens because the BKCAL signals are connected. If you chose another signal to feed to the constraint PID, the Not Selected Status would not be present and you would not get the Integral Tracking that ensures the smooth transition at the constraint point. Not Selected is a sub-status to GOODCascade and is only provided from the CTLSL block.

    Although you could connect a different block BKCAL_OUT to constraint PID, you would be breaking the expected handshaking, and although Dynamic Limiting might prevent windup, windup is not the only issue. The key to the constraint control is that the OUT signals line up when the Constraint PV reaches the Constraint SP. This can happen at different OUT values due to the outside influences and interactions in the process. That gives you the dynamic transition point, maximizing control without exceeding the constraint(s).

    As Matt pointed out, v14 now supports a manual Operator selector within the ECTLSL block. There are three significant enhancements here:
    - Operator Selection (User can set to Auto, or specify an input manually),
    - a parameter indicating which of the inputs is selected, and
    - extensible number of inputs up to 16.

    I was concerned with how the ECTLSL handles the OUT signals of the unselected PID blocks when one is manually selected. I could not find it in BOL, but it does as I would hope. When an Input is manually selected via OP_SELECTION, the other BKCAL_SELX signals send an Initialize signal. The unselected loops go to MODE.ACTUAL = IMAN, and their OUT parameters track the ECTLSL OUT parameter. This gives you bumpless transfer between loops as you select them.

    I found one issue. When in AUTO selection, the PID block outputs are all at different values based on each blocks PV to SP error * Gain. If you manually select a different loop than the currently Auto selected input, the ECTLSLS OUT will bump to this new OUTPUT. If you first select the AUTO selected loop, the ECTLSL will initialize all other loops and bumpless transfer will occur on subsequent manual selections.

    In the HMI, a solution could be to limit the Operator to only be able to select the current Input when taking the ECTLSL out of AUTO selection. The SELECTED parameter tells us which Input is the valid initial manual selection. Once the OP_SELECTION is set to a specific input, the operator can select any other input and have bumpless transfer. There are surely a multitude of other solutions. The easiest could be to train the operators, and let them do the right thing. Or one could add a layer to abstraction and provide separate operator parameters that drive some module level logic to ensure the initial manual selection is applied in a two step sequence.

    I'm interested to know if anyone sees a need for both Constraint control and manual input selection on the same process application. I mean, if it is a constraint control problem, should the operator be able to simply select the main loop manually and thus disable the constraint? Or is manual selection a case where the process could be controlled by different process variables, based on independent logic, rather than Auto Selection of High or Low signals, and so Auto Selection would not be valid.

    In this case, one would need to remove Auto as a valid Operator selection. I did not see an option to Disable AUTO, and the $ectlsl_OP_Selection is not exposed. maybe the simple solution is to define your own Named Set parameter and wire this to the OP_SELECTION input of the block. In this named set, you can have more descriptive terms for each Loop, and set the 0 value as not selectable, not visible. Now the OPERATOR cannot place the OP_SELECTION to AUTO.

    When do you think an ECTLSL would require both AUTO and Manual input selection?

    Andre Dicaire

  • Andre Dicaire

    In reply to Andre Dicaire:

    Update. The ECTLSL's OP_SELECTION parameter has a default Named set, but you can change that. makes sense since you would want to define meaningful choices, not just SEL1, SEL2 etc. So, instead of a wired parameter, simply define a named set and configure it to not allow certain named states to be selectable or even visible.

    For a Constraint control where you don't want to allow the user to manually select any loop, the named set would only allow AUTO to be selected. You might show the named states but they can't be selected.

    For a Manual Selection only where you don't want the CTLSL to be placed in AUTO, make the AUTO named state not selectable, and even not visible.

    For applications wanting both auto and manual selection to be available, the named set allows it.

    maybe it's that simple. Still needs more time and some trial applications to confirm if this approach is the right one.

    Andre Dicaire

  • Rein

    In reply to Andre Dicaire:

    I still cannot figure out why the CTLSL (C) and the upstream PIDs (A & B ) are still in IMAN, though, the the downstream PID (D) is already in CAS.

    Below is the ACTION block expression for my CTLSL block. SELECTED is an input parameter block.

    Is there anything wrong with the above expression?

    But I think, this ACTION block has nothing to do with the CTLSL block as it should works on it's own. This ACT block is just to show which input has been selected.

  • Paul Hughes

    In reply to Rein:

    This is PCSD code just to let you know which loop is selected. Check the mode of the SELECTOR block - it might be in manual
  • Rein

    In reply to Paul Hughes:

    Below is the online values of parameters showing that it's target mode in Auto.

  • Paul Hughes

    In reply to Rein:

    The IMAN is most likely because IN3 is BAD not connected. Just change IN3 to GOOD
  • James Beall

    In reply to Paul Hughes:

    When a function block is in IMAN, it is an indication that the block DOWNSTREAM of the function block is not in the mode to accept the OUT from the upstream (CTSL1 in this case) function block. You need to check the downstream block that is receiving the OUT of the CTSL1. Is it in the proper mode? Does the BKCAL_OUT parameter of the downstream block have a status? What is the status of the BKCAL_IN in the module with the CTSL1 block ? I would not put a good status on the CTSL1/IN3 since it could then be selected and it is not an active input.
  • Andre Dicaire

    In reply to Paul Hughes:

    No. IMAN on CTLSL has nothing to do with the IN status. It is driven via BKACL_IN.

    Andre Dicaire

  • Andre Dicaire

    In reply to Rein:

    You need to look at the .ST values. The sub status of GoodCascade. There is a table in BOL that helps you interpret the numbers.

    Andre Dicaire

  • Rein

    In reply to Andre Dicaire:

    Thanks all, especially to Andrei and James. I have seen my problem on IMAN. There's an ADD block in between the BKCAL_OUT of the two downstream PID blocks and the BKCAL_IN of the upstream PID block (see image below). It's the ADD block that makes the status to be in "GoodCascade NotInvited Const". I disconnected the ADD block from the BKCAL_IN of this PID block and connected the BKCAL_OUT of the 2nd downstream PID block to the BKCAL_IN of this upstream PID block, my IMAN disappeared and everything goes into "GoodCascade". My new problem now is how to connect the other BKCAL_OUT of the 1st downstream PID block to the BKCAL_IN of this upstream PID block? Both downstream PID blocks are for flow control valves of different lines which merged into one line and are controlled by this upstream PID block which is a flow controller. The flow controller is cascaded with the upstream CTLSL block.

  • JDWheelis

    In reply to Rein:

    If I properly understand what you're doing, a splitter block would do the trick, as shown in the block diagram below.  The bias and gain blocks wouldn't be needed, unless you want to have the ability to bias one of the feeder flows higher than the other.  The PID1 loop is the flow master, scaled to the total of both the feeder flows controlled by PID2 and PID3.  In this application, the splitter block's purpose is to provide propagate the BKCAL_OUT signals.  The IN_ARRAY and OUT_ARRAY parameters are configured to send the value of CAS_IN to both OUT1 and OUT2,  with values for both of [0, 100, 0, 100].

    I hope this helps, and I've explained it adequately.

    J.D. Wheelis

  • Andre Dicaire

    In reply to JDWheelis:

    Rein, your problem keeps getting more complicated. But generally, a BKCAL_OUT goes to exactly one BKCAL_IN and vice versa. this signal with status is intended to provide handshaking between two cascaded blocks. Control flows in one direction, initialization and selection flows back upstream.

    When you need one block to feed two or more downstream blocks in linked cascade form, then as JD points out, the Splitter expands both the control signal down and the BKCAL signals up. in the end, the upstream PID initializes with the Splitter. The Splitter initializes with the two downstream blocks, and it has the two BKCAL_IN connections for the two downstream blocks.

    You can add more splitters to connect additional downstream blocks as needed. Some have created their own custom Splitter via a CALC or embedded block to have one block that handles more than two downstream blocks, but the logic is the same. The splitter block evaluates both BKCAL IN signals and determines what it needs to initialize to, and then sends this to the upstream PID to initialize it. The First PID to go to CAS mode will initialize the Splitter, and consequently the Upstream PID. The Second loop would need move to the Splitter value. A balance timer is provided to ramp the second loop to its correct value to minimize bump to the process.

    Also be sure all blocks are in the correct execution order so that normal control provides output response in one scan of the module. the Additional blocks in a cascade path require an additional scan to complete the BKCAL signal processing, so it may take two or three scans for the Upstream block to come out of IMAN, but normal control has no such latency.

    Hope you have a better understanding of BKCAL signals, there purpose and how to connect them. Once you get it, it really does make sense..

    Andre Dicaire

  • Rein

    In reply to Andre Dicaire:

    Yes, I have been thinking about the SPLITTER. Have done the same thing in previous projects. I'll try and will let you know. Thanks JD and Andrei.
  • Rein

    In reply to Rein:

    I have added the SPLITTER block and it works. But I have another problem. Since it's about the BKCAL_OUT of the SPLITTER block, it might be better to post it in another forum. Thanks all.

This is the official online community site of the Emerson Global Users Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson Automation Solution's products and services. Our goal is to improve the efficiency and use of automation systems and solutions employed at members’ facilities by sharing our knowledge, experiences, and application information.

User Groups | World Areas | Community Guidelines | Legal Information | Privacy Policy | Contact Community Manager

Website translation provided by Website Translator

© 2015-2022 Emerson Global Users Exchange. All rights reserved.