Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Experion LX
Control Builder Components
Theory
EXDOC-XX16-en-110A
R110
February 2014
Release 110
Honeywell
Notices and Trademarks
While this information is presented in good faith and believed to be accurate, Honeywell disclaims
the implied warranties of merchantability and fitness for a particular purpose and makes no
express warranties except as may be stated in its written agreement with and for its customers.
In no event is Honeywell liable to anyone for any indirect, special or consequential damages. The
information and specifications in this document are subject to change without notice.
Honeywell, PlantScape, Experion® LX, and TotalPlant are registered trademarks of Honeywell
International Inc.
Release Information
Document Name Document ID Release Publication
Number Date
Symbol Definitions
The following table lists those symbols used in this document to denote certain conditions.
Symbol Definition
Symbol Definition
Parameters .............................................................................................................979
17.2 Change Execute (CHGEXEC) Block ......................................................... 979
Description .............................................................................................................979
17.3 CHGEXEC Usage Considerations for Change Driven Execution.......... 980
17.4 Change Driven Application Risk Factors ................................................ 982
17.5 Blocks Qualified for Use with CHGEXEC Block ..................................... 983
17.6 Experion LX Controller Platform Support for CHGEXEC ....................... 987
17.7 CHGEXEC Main Parameter Details ........................................................... 987
17.8 CHGEXEC Cascading Between Control Modules Example ................... 990
Graphical Examples of Cascaded CHGEXEC control charts .................................990
Cascaded CHGEXEC functional considerations ....................................................991
17.9 CHGEXEC Cascading Within Control Module Example ......................... 993
EXITOPT considerations for cascaded CHGEXEC in single CM ...........................994
17.10 Importance of Using Consistent Input Data ............................................ 994
Wrong input data example ......................................................................................995
Correct input data example ....................................................................................995
17.11 Periodic Auto Trigger Function of CHGEXEC ......................................... 996
Auto Trigger application support .............................................................................997
ATUOPERIOD sets period for Auto Trigger ...........................................................997
TRIGGER output and Auto Trigger execution ........................................................998
Relationship between Auto Trigger and AUTOPHASE for synchronization prevention
...............................................................................................................................998
AUTOPERIOD configuration restrictions ................................................................999
17.12 Execution Order Considerations for CHGEXEC within CM ................... 999
17.13 CHGEXEC Behaviors for State Transitions ........................................... 1000
17.14 CHGEXEC Supports Checkpoint Function............................................ 1002
17.15 Load Monitoring Parameters .................................................................. 1003
17.16 Sample CHGEXEC TESTOPT Procedure ............................................... 1003
17.17 Examples and Scenarios ......................................................................... 1005
CheckBool functionality ........................................................................................1005
CheckBool Scenario 1 ..........................................................................................1008
CheckBool Scenario 2 ..........................................................................................1009
Function................................................................................................................1118
Inputs....................................................................................................................1119
Outputs .................................................................................................................1119
Control logic .........................................................................................................1119
Open sequence logic ............................................................................................1121
Close sequence logic ...........................................................................................1123
Error handling .......................................................................................................1125
MAINIBV parameters............................................................................................ 1125
19.7 SOLENOID (Solenoid Valve Drive Control) Block ................................. 1125
Description ...........................................................................................................1125
Function................................................................................................................1133
Configuration examples ........................................................................................1134
Inputs....................................................................................................................1145
Outputs .................................................................................................................1145
Error handling .......................................................................................................1145
States ...................................................................................................................1145
State parameters and descriptors.........................................................................1146
Mode and mode attribute......................................................................................1147
Safe output state ..................................................................................................1148
Command dependency on switches and mode attribute ......................................1148
Local manual ........................................................................................................1149
Permissive interlocks ............................................................................................1149
Safety Override Interlock ......................................................................................1150
Override Interlocks ...............................................................................................1150
Configurable Override/Permissive Interlock Bypass .............................................1150
Alarms ..................................................................................................................1151
Seal-in option .......................................................................................................1152
Initialization Manual condition ...............................................................................1153
OP initialization option ..........................................................................................1153
Initialization Manual Condition with Safety Override Interlock, Override Interlocks,
LocalMan, and OP Initialization ............................................................................1154
Initialization request flags .....................................................................................1154
OP and DO initialization after load........................................................................1155
Maintenance statistics ..........................................................................................1155
Output requests ....................................................................................................1155
Output command ..................................................................................................1156
Logic override OPREQ .........................................................................................1157
Tables
Table 1 Expression operators, functions, and strings reference ................................ 281
Table 2 Expression operators, functions, and strings reference ................................ 688
Figures
Figure 1 Generic single-loop controller functions. ........................................................ 46
Figure 2 Simplified overview of Experion LX architecture. ........................................... 48
Figure 3 Typical linking of Function Blocks through Control Builder. ........................... 50
Figure 4 Component block names are dependent on container block tag name for
system wide recognition. ........................................................................................ 52
Figure 5 Sample Control Builder configuration with sample tag name assignments. .. 53
Figure 6 Sample PID cascade loop configuration ........................................................ 57
Figure 7 Cycle time loading for sample container block configurations for a 50 ms CEE.
................................................................................................................................ 66
Figure 8 Peer-to-peer is layered upon CDA connection-oriented communications. ... 117
Figure 9 Example of DEF and REF block functions in CB configuration using REMCAS
block. .................................................................................................................... 125
Figure 10 Configuration example using single CAB insertion for regulatory control block
.............................................................................................................................. 206
Figure 11 Configuration example using multiple CAB insertions for regulatory control
block ..................................................................................................................... 209
Figure 12 Configuration example using two CAB insertions of the same type for
regulatory control block ........................................................................................ 211
Figure 13 Example of CB configuration using AUTOMAN block. .............................. 229
Figure 14 Example of CB configuration using ENHREGCALC block. ........................ 258
Figure 15 Example of CB configuration using OVRDSEL block. ............................... 329
Figure 16 Simple cascade control loop example. ...................................................... 348
Figure 17 Functional block diagram of typical PID cascade operation. ..................... 365
Figure 18 Example of CB configuration using a PID block for single loop control. .... 366
Figure 19 Example of CB configuration using two PID blocks for cascade loop control.
.............................................................................................................................. 368
Figure 20 PID block with SP ramping parameters configured for monitoring. ............ 378
Figure 21 PIDER block used in a cascade control strategy with PID, AUTOMAN, and
NUMERIC blocks ................................................................................................. 444
Figure 22 PIDER block with SP ramping parameters configured for monitoring. ....... 469
Figure 23 Simple PID with feedforward control loop example. .................................. 486
Figure 24 PID block with SP ramping parameters configured for monitoring. ........... 512
Figure 25 Example of Position Proportional loop for controlling valve position. ........ 547
Figure 26 Example of Position Proportional loop for controlling valve position through
pulse length or pulse count function. .................................................................... 548
Figure 27 PID block with SP ramping parameters configured for monitoring. ........... 554
Figure 28 Example of pulse count control algorithm outputs ..................................... 566
Figure 29 Example of pulse length control algorithm outputs .................................... 570
Figure 30 Functional diagram of ramp and soak (set point) programmer in PID control
loop. ...................................................................................................................... 585
Figure 31 Example CB configuration using RATIOBIAS block................................... 606
Figure 32 Example CB configuration using RATIOCTL block. ................................... 636
Figure 33 Functional block diagram of typical remote cascade operation. ................ 729
Figure 34 Example of CB configuration using REMCAS block .................................. 731
Figure 35 Example CB configuration using a SWITCH block to assign a different primary
to a secondary. ..................................................................................................... 760
Figure 36 Example CB configuration using multiple SWITCH blocks to assign a primary
to a different secondary. ....................................................................................... 761
Figure 37 Example CB configuration using AUXCALC block for range conversion... 784
Figure 38 Example CB configuration using AUXSUMMER block to calculate PV based
on three inputs. ..................................................................................................... 791
Figure 39 Example CNTUPFL parameter configuration using edge-triggered ........... 797
Figure 40 Example diagram for edge-triggered ........................................................... 797
Figure 41 Example CNTUPFL parameter configuration using level-triggered ............ 798
Figure 42 Example diagram for level-triggered............................................................ 799
Figure 43 Example of CB configuration using a TOTALIZER block in a flow control loop.
.............................................................................................................................. 874
Figure 44 Configuration example using single CAB insertion. ................................... 892
Figure 45 Configuration example using multiple CAB insertions ............................... 894
Figure 46 Configuration example using two CAB insertions of the same type........... 896
Figure 47 DEVCTL block major functions and parameters - See Figure 43 also. .... 918
Figure 48 More DEVCTL block major functions and parameters. .............................. 919
Figure 49 Example of CB configuration using a DEVCTL block to provide two status
outputs. ................................................................................................................. 921
Figure 50 Example of CB configuration using DEVCTL block to provide two on pulse
outputs. ................................................................................................................. 923
Figure 51 CHGEXEC block graphical representation in control drawing ................... 980
Figure 52 Control Modules With Cascaded CHGEXEC Instances ............................ 990
Figure 53 Primary Control Module in Cascaded CHGEXEC (CM_CHGEXEC_PRI). 991
Figure 54 Secondary Control Module in Cascaded CHGEXEC (CM_CHEXEC_SEC)991
Figure 55 Cascaded CHGEXEC Within Single Control Module ................................ 993
Figure 56 Wrong Use Of CHGEXEC: Downstream Logic Pulls Change Data Directly995
Figure 57 Correct Use Of CHGEXEC: Downstream Logic Pulls From CHGEXEC Output
.............................................................................................................................. 996
Figure 58 Sample CHECKBOOL Strategy linking Control Modules in Project Mode1006
Figure 59 Viewing Sample CHECKBOOL Strategy Linking Control Modules in
Monitoring Mode ................................................................................................. 1007
To/From
Field
Devices
Function Description
• Output (OP)
• Alarm Conditions
Communications Driver The communications driver serves as the translator for the
data that flows between the human interface and the
control data process or functions. It translates signals into
appropriate display data or control action.
Function Description
Control Data Processor The control data processor defines the operating
characteristics for the controller which is usually stored in
memory as the controller's configuration database. It solves
the configured or selected Proportional, Integral, and
Derivative (PID) control equation and usually runs self-
diagnostic tests.
I/O Interface The I/O interface links all analog and digital I/O to the
control data processor for communications with field
devices. It provides any signal conversion needed to
condition an input or output for use by the processor or field
device.
graphically build the exact control operations you need for your process. There are three
major types of blocks which are listed below.
Component A block which exists only as a component PID (All blocks listed in CM
of a container block. It appears as a generic and SCM Libraries in
named block with configurable pins and Control Builder, with the
parameters within a container block in exception of CM and SCM,
Control Builder. Note that a component )
block may also be referred to as a Basic
Function Block, or just a Basic Block.
In this document, we use "Function Block" as a generic term, which applies to all three
types of blocks, listed above. Once you begin using the Control Builder application, you
will be able to readily associate block type with the graphic style used to represent a
given Function Block on the display.
ATTENTION
The HANDLER blocks are component type blocks even though they do
contain STEP and TRANSITION function blocks. Within the CEE, they are
implemented as components of the SCM block and not as container type
blocks.
The following figure gives a block diagram view of how FBs are typically linked
through Control Builder configuration.
Parameter names
The parameters associated with a given Function Block have pre-assigned names. These
parameter names are dependent type names. That is, you must prefix a parameter name
with its appropriate Tag Name or Full Tag Name when you need to provide reference to
a specific parameter on a system wide basis. A parameter name has one of these general
formats for system wide recognition depending upon whether it is associated with an
independent or a dependent type Function Block.
• For an independent type block: <Independent Tag Name>.<Parameter Name>
• For a dependent type (component) block: <Independent Tag Name>.<Dependent
Tag Name>.<Parameter Name>
For example, to reference the output (OP) parameter of a PID block named PIDA in a
Control Module named CM1; you would identify the parameter as follows:
• CM1.PIDA.OP
• To reference the Execution State (EXECSTATE) parameter of a Control Module
named PIDLOOP, you identify the parameter as follows:
• PIDLOOP.EXECSTATE
The main item to remember about naming is that you must specify a unique name for the
Function Block or parameter that should be recognized on a system wide basis.
The following figure illustrates some typical Tag Name assignments used in a sample
Control Builder configuration.
Refer the following table for a description of the callouts in the figure above.
Callout Description
Note that the format for these tag names is used for example
purposes only.
Callout Description
that the Control Module FB executes the transfer just before it starts the execution of the
block algorithm.
An active connector allows the block algorithm to read connection status as part of its
processing and take action based on that status. A passive connector does not allow a
block to determine its connection status and it returns a failsafe value in response to a
connection break caused by a communication or configuration error. Depending on the
data type, the failsafe value is OFF, 0 (zero), NaN (Not a Number), or blank.
For Control Module configuration, you can assume that the given failsafe value appears
for a passive input parameter when its connection is broken. Both active and passive
connectors can reference parameters on blocks within the given container block or
outside the container block. The active connector allocation is noted for each parameter
in the Control Builder Parameter Reference.
FTE
Notes:
Configurable Values for CM/SCM 50, 100, 200, 500ms, 1s, 2s.
Execution Periods
C300 Redundancy
The following table lists data pertinent to the configuration of C300 Controllers for
redundant operation.
Notes:
1
Dual I/O Link failures may cause longer interruption times in the order of several
seconds.
Max Initiator Whole Array Request Rate (to all peers) 2500 EPS
Notes:
1
Exchange Peer-Peer does not count against this limit.
2
There are 31 connections reserved for Peer-Peer in the C300. One
connection is reserved for Internal C300 use-only, leaving 30 connections
available for user peer-to-peer configurations.
3
Redundant devices that use two PCDI Master blocks count as only one device.
4
PCDI impact on C300 performance can be estimated with the C300
50mSec CEE
50mSec CEE
50mSec CEE
C300 CEE
C300 IO capacity
The following table lists I/O configuration constraints you should observe to avoid
overloading the C300 Controller and impacting its ability to operate correctly.
interpretation of how the processing of some sample Control Module configurations are
scheduled across the timing cycles for a 50 ms CEE.
Timing Cycles
0 1 2 3 4 5 6 7 8 9 10 20 0
A A A A
CM1 CM1 CM1 CM1 CM1 CM1 CM1 CM1
Loaded B
B B B
Function CM2
Blocks C CM2 CM2 CM2
SCM1
0 50 100 150 200 250 300 350 400 450 500 1000 2000
Time (Milliseconds)
A Control Module CM1 configured for Execution Phase of 0, Execution Period
of 200ms, and order in CEE of 10. It executes in timing cycles 0, 4, 8, 12,
16, 20, 24, 28, 32, 36.
Figure 7 Cycle time loading for sample container block configurations for a
50 ms CEE.
For example, a Control Module block with an Execution Period of 200 milliseconds and
a Phase of 1 runs in cycles 1, 5, 9, ...,37. Another Control Module block with an
Execution Period of 200 milliseconds and a Phase of 2 runs in cycles 2, 6, 10, ...,38. The
66 Experion LX Control Builder Components Theory R110
Honeywell February 2014
1. Control Builder Components
1.4. Function Block Execution Schedules
entry value range for the Execution Phase is -1 and 0 to 39. However, the system accepts
and clamps values outside the appropriate range for a given Period as long as the value is
within the overall entry range. A block with an Execution Period of 50 milliseconds is
always evenly distributed, since it runs in every cycle. The following table identifies the
timing cycles in which a container FB executes for the given combination of Execution
Period and Phase values. For now, a Phase value of -1 is changed to 0. Later, a Phase
value of -1 instructs the CEE to assign Phase values that distributes the overall-
processing load.
50 ms CEE
50 0 0, 1, 2, 3, . . ., 39
100 0 0, 2, 4, . . ., 38
100 1 1, 3, 5, . . ., 39
200 0 0, 4, 8, . . ., 36
200 1 1, 5, 9, . . ., 37
200 2 2, 6, 10, . . ., 38
200 3 3, 7, 11, . . ., 39
50 ms CEE
1000 0 0, 20
1000 1 1, 21
1000 2 2, 22
1000 3 3, 23
1000 4 4, 24
1000 5 5, 25
1000 6 6,26
1000 7 7, 27
1000 8 8, 28
1000 9 9,29
1000 10 10, 30
1000 11 11, 31
1000 12 12, 32
1000 13 13, 33
1000 14 14, 34
1000 15 15, 35
1000 16 16, 36
1000 17 17, 37
1000 18 18, 38
1000 19 19, 39
2000 1 1
50 ms CEE
2000 2 2
2000 : :
2000 39 39
For blocks scheduled to start execution in the same cycle, you can configure the Order in
CEE parameter value (0 to 32767) on the Parameters Configuration form to stagger the
execution order of the container blocks within the cycle. That is, the block with the
lowest Order in CEE value configured executes first. If both blocks have the same Order
in CEE value, the CEE determines the order of execution and maintains it.
You can choose to display or conceal the value of ORDERINCM on the FB faceplate.
This setting is configured through the System Preferences dialog box (Control Builder
> Edit > System Preferences). By default, the option is disabled. If the option is
selected, the parameter value is displayed on the top-left corner of the FB faceplate. The
parameter value overlays any icon or FB name that appears on the top-left corner of the
faceplate. You can choose to display the block's Execution Order in CM value through
the block's ORDERINCM parameter.
You can configure the parameter through the FB configuration form or by double-
clicking the parameter on the FB faceplate. Note that any change made to the parameter
value is visible only on the project side. To view the configured value on the monitor
side, load the modified strategy.
ORDERINCM parameter does not apply to CM, IOM, SCM, or SCM component blocks.
It is applicable only for blocks that execute inside the CM.
A typical PID Loop CM should have component function blocks with ORDERINCM
value as displayed in the following figure.
Input Channels FBs do a sample and hold operation when they execute. IOCHANNEL
FBs read data from the associated IOM FB in CEE IOLINK and hold that data. If the
parent CM has an Execution Period greater than 50 milliseconds, the input
IOCHANNEL FBs will hold values static even if the corresponding data is changing at
the IOM FB.
IOM FB schedule
IOM FBs have a fixed Execution Period of 50 milliseconds, for 50 ms CEE, and
Execution Phase of 0. They execute ten times or once every 50 millisecond cycle at the
beginning of each cycle. This means the Order in CEE value does not apply either, since
the IOM FBs execute before all other blocks in the cycle.
IOM FBs collect and distribute I/O data as it passes between the Control Processor
module and I/O Module devices. They pack and unpack the data in preparation for input
and output operations.
CEEC300 FB schedule
CEEC300 FBs have a fixed Execution Period of 2000 milliseconds. The Execution Phase
is fixed at 19 for the CEEC300 FB. The CEEC300 FB executes after all other blocks in
the cycle.
The CEEC300 FBs handle housekeeping functions, which are not directly related to the
configuration of control strategies. These functions include maintaining instrumentation
statistics, maintaining state data, and reporting diagnostic alarms.
Cycle overruns
Cycle overruns occur when the scheduled processing for a cycle does not finish by the
start of the next cycle. Potential causes for overruns include the following:
• Unbalanced loading across the execution cycle.
• Loaded configuration is too large.
• Combination of block and communication processing is too large for a particular 50-
millisecond cycle.
The CEEC300 FB responds to cycle overruns as follows.
• Completes execution of all blocks on the current cycle.
• Delays execution of the waiting cycle until the start of the next 50 millisecond time
interval.
• Allows communications and housekeeping operations within the C300 FB to catch
up while execution of the waiting cycle is being delayed.
The CEE issues a diagnostic alarm for cycle overruns that occur on a regular basis. The
conditions for reporting and clearing this alarm are summarized below based on the
controller running the CEE.
You must change a CEE configuration that causes regular overruns by reducing the total
load or improving the balance of the load across the timing cycles.
Data categories
The major data categories found in the CEEC300 FB are summarized below.
Severe Error The load of a block is being stopped. (Note that the load of
other container blocks will continue, if applicable). For
example, error message "CM17 - Maximum Available User
Memory Exceeded" mentions that the user memory
allocation was exhausted during block load.
This error message generation applies for on-line parameter stores as well as block
configuration load related stores. For example, an error message can be generated for an
on-line parameter store if its value or other conditions are incorrect.
Upon the restoration of power, the C300 runs its startup diagnostics to verify that its
RAM was retained during the power interruption. If the C300 detects RAM errors, it
starts up with a "null" database. If the C300 detects no RAM errors, it starts up with the
database it had prior to the power interruption. In this case, the CEEC300 FB transitions
to its Idle state at startup so you can determine if other FB data needs to be changed
before you resume control by manually invoking the CEEC300 FB Run state. (Note that
the Idle to Run transition triggers output path initialization.)
If RAM errors were detected or you did not load the CEEC300 FB before the power
interruption, the CEEC300 FB state will be NotLoaded at startup.
Upon any C300 startup, the CEE reissues all active notifications as part of the Experion
LX notification recovery routine. The CEE also issues "state" transition notifications
from the CEEC300 FB that are logged in the event journal to show whether or not an
RRSU occurred.
REFERENCE - INTERNAL
Refer to the Control Builder Notifications Theory for more information.
50 ms C300 50 ms C300
(PU/Module (MU/Module)
Execution)
50 ms C300 50 ms C300
(PU/Module (MU/Module)
Execution)
(Average consumption of available IOMs)
50 ms C300 50 ms C300
(PU/Module (MU/Module)
Execution)
History items)
50 ms C300 50 ms C300
(PU/Module (MU/Module)
Execution)
NOTES:
Note 1: Total Processing Resources (PU/sec) per module are computed as = Processing
Resource Consumption (PU/module execution) / Execution Period (sec/module
execution).
2OO3 64
ABS 48
ADD 108
AICHANNEL 100
AIMODULECLS 552
AINIMODULECLS 684
ALMPANEL 212
ALMWINDOW 128
AND 44
AOCHANNEL 184
AOMODULECLS 588
AONIMODULECLS 668
AUTOMAN 1268
AUXCALC 536
AUXSUMMER 684
CABLOCK
CDBLOCK 164
CEEC300FB 30164
CHECKBAD 44
CHECKBOOL 976
CHGEXEC 112
CONTACTMON 68
CONTROLMODULE 288
DATAACQ 680
DEADTIME 784
DELAY 48
DEVCTL 1104
DICHANNEL 100
DIGACQ 120
DIMODULECLS 280
DIV 56
DOCHANNEL 132
DOMODULECLS 968
ENHAUXCALC 932
ENHGENLIN 1784
ENHREGCALC 2628
EQ 80
EXECTIMER 120
EXP 48
FANOUT 2700
FIRSTOUT 204
FLAG 52
FLAGARRAY 44
FLOWCOMP 480
FTRIG 36
GE 80
GENLIN 304
GRPCAPRBK 648
GT 80
HANDLER 44
HTMOTOR 1096
LE 80
LEADLAG 240
LEVELCOMP 240
LIMIT 140
LN 48
LOG 48
LT 80
LTMOTOR 992
MAINIBV 268
MAX 108
MAXPULSE 48
MESSAGE 212
MIN 108
MINPULSE 48
MOD 56
MUL 108
MUX 56
MUXREAL 108
MVOTE 68
NAND 44
NE 80
NEG 48
NOON 100
NOR 44
NOT 36
NUMERIC 64
NUMERICARRAY 48
OFFDELAY 48
ONDELAY 48
OR 44
OVRDSEL 1864
PCDI_MASTER 25512
PCDI_FLAGARRCH 13512
PCDINUMARCH 9140
PCDINTEXTARRCH 3232
PHASE 420
PID 1892
PIDER 2016
PIDFF 2012
PID-PL 2904
POSPROP 2016
POW 56
PULSE 48
PULSECOUNT 336
PULSELENGTH 316
PUSH 192
QOR 60
RAMPSOAK 1588
RATIOCTL 1768
RCM 3128
REGCALC 1988
REGSUMMER 1492
REMCAS 1492
ROC 156
ROL 40
ROR 40
ROUND 48
RS 36
RTRIG 36
SCM 3128
SEL 40
SELREAL 60
SHL 40
SHR 40
SIGNALSEL 520
SOLENOID 960
SQRT 48
SR 36
STARTSIGNAL 44
STEP 200
SUB 56
SWITCH 2544
SYNC 176
TEXTARRAY 48
TIMER 72
TOTALIZER 248
TRANSITION 184
TRIG 36
TRUNC 48
TYPECONVERT 156
UCM 296
VALVEDAMPER 1120
WATCHDOG 48
XOR 44
Infrastructure services
The infrastructure services would consist of a variety of system enablers, two of the most
important are a Real Time Operating System, vendor purchased or custom developed,
and a set of Communication Services. Another important set of infrastructure services
provide a runtime environment and a set of utilities for use by the Application Program.
Application Program
Above these infrastructure services there might be a monolithic Application Program.
The end user develops this program and implements custom control strategies.
Supposing that multiple control strategies are supported within this program, all
applications implemented within it share certain properties since it is a single program.
For example, they are all loaded together and have the same timing properties. Assuming
that the timing properties have the potential to be fast, they are unregulated.
Execution Timing The hypothetical controller does not regulate the execution period of the
application program. This can be an advantage in fast, discrete control
applications. End users deliberately choose to use a small application
program to get the fastest possible response time. However, it can be a
disadvantage in continuous applications where the scaling of time
constants required for time discretization works best under a well
regulated execution period.
Data Reference This coupling is designed into the application by the end user and is
Memory Utilization A form of coupling exists between different control strategies in any case
where there is reliance on a common resource. This is true for memory
utilization.
CPU Utilization Another common resource shared across control strategies is CPU
execution time.
Communication Data transfer between control strategies and IO requires the use of
Bandwidth Utilization communication bandwidth. Similarly data transfer between control
strategies and supervisory controllers, peer controllers or HI requires the
use of communication bandwidth.
Infrastructure services
As in the hypothetical controller, a CEE-based controller has a base software layer called
Infrastructure Services. These services are a combination of purchased and custom-
developed software components. They include a Real Time Operating System and
Communication Services. They set up an environment in which the execution and
communication requirements of control strategies can be met.
Application programs
The architecture of a CEE-based controller also resembles the hypothetical controller.
That is, it supports application layers which sit above the Infrastructure Services.
However, it differs in that the application layers are constructed with a built-in
partitioning. The controller application is partitioned in the following two different ways.
• Partitioning between program and data set.
• Partitioning between native programs and custom programs.
Load / Unload When a control module containing only native block types is loaded, it
has no impact on any other control module.
If a custom block type and its instances are being used within an industry
which requires explicit qualification procedures, then modifying the type
may require that ultimately every control module using an instance of
that type must be re-qualified.
Data Reference Data reference coupling between modules is an expected part of any
control configuration and is consistent with the control mission. The
extent to which there may be no data transfer between modules is
completely controlled by the application engineer.
However, the design of the CEE controller and the Experion LX system
employ a feature which minimizes impact to running modules when they
are referenced by other modules, by supervisory controllers or by human
interface devices. This feature is that all modules and all algorithm
blocks within modules have inherently external parameter linkage.
External parameter linkage means that from the moment when the
module is first loaded, its entire data content, as exposed through named
parameters, can be accessed from outside the controller. When new
displays are created or when existing displays are modified, no modules
or application programs need change in order to publicize newly
Memory Utilization Modules are coupled in the sense that they all use memory from a
common pool. In general, changes in the memory requirements of one
module do not impact any other module. However, if the controller is very
full then the module which needs to be loaded may not fit into the
remaining memory. This occurs if an application engineer increases the
module's configuration so that it requires more memory. Or if the
application engineers have changed other modules so that on reload of
this module, enough memory is not available..
The one exception to the CEE policy that memory allocations never
change except in connection with module load is the basic block type
PID-PL. Instances of this block can change their memory utilization as a
result of delay tuning. If PID-PL is heavily used it is possible for its
memory utilization to impact other modules the next time they are
loaded. If application engineers want to avoid this possibility, they should
allow plenty of spare memory in the initial configuration of CEE or they
should avoid the use of PID-PL.
CPU Utilization Like memory, the CPU processing time available within a CEE-based
controller can be thought of as a single resource pool from which all
modules draw. Reliance on this common pool introduces a potential
coupling between modules. However, the design of the control
processing scheme within the CEE eliminates this coupling except in the
Execution Timing Tested that the execution timing of a particular module is independent of
any other module in the absence of overruns during original
implementation phases by measurements of the time regulation of the
fundamental control cycle.
Load / Unload The fact that Experion LX CMs and SCMs can be loaded independently
as it continuously gets revalidated with every control configuration that is
created. The other modules that are unaffected is implicitly revalidated
when the control strategies behave as testers expect.
Data Reference The fact that CEE and Experion LX system support inherently external
parameter linkage gets continuously revalidated every time a tester
makes a custom display. Testers know that they can read any parameter
data supported by a module without having to change the module
configuration or reload the module.
Memory Utilization Explicit testing has been done on the behavior of the controller when
module configuration memory is exhausted. This testing has confirmed
that an explicit error message is returned and that there are no adverse
effects other than rejection of the load.
CPU Utilization Explicit testing is done on the behavior of control execution in response
to overload and in response to configurations with poor balancing. The
response is controlled overruns. The overruns are counted and when
they occur repetitively an alarm is generated which is l validated.
Communication Explicit testing has been done on the communication load that can be
Bandwidth Utilization handled by each of the communication channels used at run time by a
CEE-based controller. The capacities are consistent with published
Experion LX specifications.
Category Description
Programmatic Coupling These are dependencies which occur from the fact that
algorithms are implemented in a monolithic program or
which occur from the fact that there are explicit data
dependencies among the algorithms. Load / Unload,
Execution Timing and Data Reference are examples of
Programmatic Coupling.
Resource Coupling Other dependencies are less direct but can occur from
the fact that control algorithms execute on the same
hardware platform and share computing resources. Of
the types of coupling described in the preceding
sections, Memory Utilization, CPU Utilization and
Communication Bandwidth Utilization are examples of
Resource Coupling.
Notes
1. Tagged basic blocks are not in the same name space as the container that they reside in, but
short name entry is supported. A relative parameter reference could not be made from a
parameter reference on a tagged block to another tagged block within the same container.
1. Tagged basic blocks are not in the same name space as the container that they
reside in, so relative references are only displayed in short name format if the reference
is on the same block as the tagged basic block.
• COMMAND=3
The following example illustrations show how expressions would appear with Short
Name as the selected Relative Reference Display Option.
• History, trend and group parameters that are defined on TAGGED blocks:
− GROUP.PARAM
− HIST.GATEPARAM
− HIST.PARAM
− TREND.PARAM
• Parameters on the STEP block related to procedural operations:
− CURRVALREF
− MONTASKREF
− OP[].CURRVALREF
− OP[].ENTRYVALREF
− OP[].MONTASKREF
− OP[].TARGETVALREF'
• Parameters on the SCM and RCM associated with the alias table:
− ALIASREF
In addition to these parameter references, Control Builder allows the origin parameter of
projected parameters to be entered as a relative reference
The following example illustration displays how other parameters appear if Short Name
is the Relative Reference Display Option selection.
The peer subscription period parameter defines the update period used for cyclic "get"
requests for peer references. The peer store response time expiration time parameter
defines the expiration time used in waiting for "store" responses. In addition to system
wide default values, the values for specific CEE peers can be adjusted by users with an
Engineer access level or higher in the Monitor mode of Control Builder.
Cache Manager
One Time
Request/Response
Subscription List
Writes
Cache Update
& Write
Cache Update
Cache Update
Read &
CDA
Reads
CDA CDA CDA Request/
Pub/Sub Scattered Scattered Scattered Response
Manager Pub/Sub List Pub/Sub List Pub/Sub List
Publish/Subscribe
Publish/Subscribe
Publish/Subscribe
Response
NUMCCLRQU parameter is the number of initiator requests from all connections and
gives the total initiator count. The NUMCCLRQU value is shown on the Statistics tab
and the value of SUBSCPERIOD is shown on the Peer Configuration tab of the CEE
configuration page.
total initiator rate of the node. Perform the steps below to configure the initiator rate of
the node.
Step Action
1 For each Target node (Peer Environment Name) configured in the Peer
Environment Table (on the Peer Configuration tab), locate the same Target
Name in the Initiator Connections table (on the Peer Communications tab).
This number (x1) should be used as an index into the arrayed parameters to
obtain the initiator rate for this connection using the formula below.
Note: The Peer Subscription Period is used in the Peer Environment table for
SUBSCPERIOD of the target node.
3 Repeat steps 1 and 2 for each node listed in the Peer Environment table to
calculate the individual initiator rate for each of the connections.
4 For target nodes that do not have an entry in the Peer Environment Table,
locate the connection index (y1) for these target nodes, which is obtained
from the Initiator Connections list on the Peer Communications tab.
5 Calculate the initiator rate for these target nodes using the formula below.
Note: The global Subscription Period value is used for SUBSCPERIOD (on
the Peer Configuration tab).
6 Add the initiator rates obtained in the steps above for all the connections to
obtain the total initiator rate.
Example:
This CEE block shows the Peer Environment Table with one target node configured,
C300_15, with a Peer Subscription Period of 500mS.
C300_59 is configured to use the Global Subscription Period which is 500sec. (shown
above) and is shown on the Peer Communications tab which lists both initiator
connections.
In Station, the number of initiator requests is listed for each indexed connection.
To calculate the Initiator rate for C300_15 find its connection index from the Peer
Communications tab which is 2. The Peer Subscription Period configured for this node is
500mS = 0.5 Seconds.
Initiator Rate for the connection to the target C300_15
To calculate the Initiator rate for C300_59, find its connection index from the Peer
Communications tab which is 1. This node uses the global Subscription Period which is
1sec.
Initiator Rate for the connection to the target C300_59 =
If Function Block Is From This Library Then, It Can Be Used With This Control
in Control Builder . . . Environment . . .
C300/CEE
C300/CEE
C300/CEE
If Function Block Is From This Library Then, It Can Be Used With This Control
in Control Builder . . . Environment . . .
C300/CEE
C300/CEE
C300/CEE
C300/CEE
C300/CEE
The following table includes descriptions of the callouts in the figure above.
Callout Description
1 The PID_PRIMARY block represents the remote primary control loop for a
cascade loop using the REMCAS block. It is contained in a CM named
REMCAS_PRIMARY, which is assigned to CEE0101.
This means the PID_PRIMARY block is considered a REF type block and
the REMCAS_1 block is considered a DEF type block for peer-to-peer
communications of the BACKCAL data.
This means the PID_PRIMARY block is considered a DEF type block and
the REMCAS_1 block is considered a REF type block for peer-to-peer
communications of the control variable data.
5 The REMCAS block operates like any cascaded secondary loop except
that it can switch between two different primaries.
This means the PID_PRIMARY block is considered a DEF type block and
the REMCAS_1 block is considered a REF type block for peer-to-peer
communications of the control variable data.
Callout Description
This means the REMCAS_1 block is considered a DEF type block and the
PID_PRIMARY block is considered a REF type block for peer-to-peer
communications of the BACKCAL data.
• A function block may have both DEF and REF relationships as shown in the
configuration example in the previous figure. This means a REF block can also be a
DEF block to another DEF block.
ATTENTION
BOOTP services on prior-release Servers must be disabled because
they do not provide enough information.
ATTENTION
All FTE System Preferences for all clusters must be configured with the
same information.
Once a device has obtained its IP Address and NTP Server IP Address(es), it retains
them until its Device Index is changed or firmware is reloaded.
TIME
Use of TIME CDPs requires attention to issues of time zone. In particular, users who
create algorithms to manipulate CDPs of type TIME must understand the Experion LX
policy with respect to time zones and daylight savings time. This policy is stated below.
• When TIME parameters are transported from an EE to displays they are always
assumed to be in UTC. User algorithms must publish TIME parameters in UTC and
not in local time.
• When HMI receives TIME parameters from an EE and displays them, they are
converted from UTC to local time. The conversion takes into account whether
daylight savings time is currently in effect.
• When HMI receives user input of TIME parameters it is assumed that they have
been supplied as values consistent with the local time zone and with any seasonal
daylight savings adjustment currently in effect. They are converted to UTC before
transport to any EE or user algorithm.
TIMEOFDAY
As with TIME CDPs, use of TIMEOFDAY CDPs requires attention to issues of time
zone. In particular, users who create algorithms to manipulate CDPs of type
TIMEOFDAY must understand the Experion LX policy with respect to time zones and
daylight savings time. This policy is stated below.
• When TIMEOFDAY parameters are transported from an EE to HMI they are always
assumed to be in UTC modulo 24 hours. User algorithms must publish
TIMEOFDAY parameters in UTC modulo 24 hours and not in local time.
• When HMI receives TIMEOFDAY parameters from an EE and displays them, they
are converted from UTC modulo 24 hours to local time. The conversion takes into
account whether daylight savings time is currently in effect.
• When HMI receives user input of TIMEOFDAY parameters it is assumed that they
have been supplied as values consistent with the local time zone and with any
seasonal daylight savings adjustment currently in effect. They are converted to UTC
modulo 24 hours before transport to any EE or user algorithm.
DELTATIME
Whenever a user algorithm manipulates CDPs of type DELTATIME, the algorithm is
implemented as a CAB program or as an SCM or calculator expression, behavior of the
datum is simple and intuitive with respect to HMI.
• Time zone is irrelevant to the display of DELTATIME parameters.
• DELTATIMEs are always displayed as time intervals in a format such as "DD
HH:MM:SS".
Step Action
Step Action
Step Action
End If
(The statement If DateTime.Now = CAPTURETIME.Value does not
work because until the CAB receives the value of CAPTURETIME it is in
UTC, not local time.)
Step Action
1 Setup Custom Data Block (CDB) located within a Control Module. Name the
Custom Data Block CDB2.
2 Locate CDB2 in a control module called CM2. The SCM uses CDB2 within
CM2 as a data repository.
4 The SCM's transition waits until the specified time before advancing. The
transition condition expression reads: UTCNOW = CM2.CDB2.STARTTIME
UTCNOW is the valid time parameter to use in this instance. UTC (Universal
Coordinated Time) is stored raw time with no time zone and no daylight
savings time adjustments. UTC is converted to local time when shown to the
user and then includes time zone and daylight savings time adjustments.
Step Action
1 Create a Custom Data Block (CDB) called CDB1 in a Control Module called
CM1.
Step Action
3 To capture the time the command was issued and save it in a proper format,
SCM1.STEP1 uses the output expression:
CM1.CDB1.CMDISSUETIME := UTCNOW
UTCNOW is the valid time parameter to use in this instance. UTC (Universal
Coordinated Time) is stored raw time with no time zone and no daylight
savings time adjustments. UTC is converted to local time when shown to the
user and then includes time zone and daylight savings time adjustments.
CEE Restarts
The two types of restarts are:
• Cold Restart initiated on transition of CEESTATE from idle to run occurs
− After the CEEC300 is created and the initial configuration is loaded.
− After restore of a checkpoint so that the CEE database is neither null nor newly
loaded from CB. In this case, a careful policy must be followed so that the data
is preserved and reinitialized.
The policy followed by cold restart assumes that much of the state data is stale. Any live
data which can be derived directly from the process is wiped out and much of the
operational data which was captured in the saved checkpoint is reinitialized. All
configuration data is saved across cold restart.
A typical example of operational data which is lost is the mode of a primary RegCtl
block connected to a direct analog output. In cases of CEE-to-CEE regulatory cascades
the mode is shed to manual upon cold restart.
• Warm Restart is initiated on transition of CEESTATE from idle to run and its most
important application occurs after restore of a checkpoint. Warm Restart differs
from Cold Restart in the policy it applies in choosing data to preserve and data to
reinitialize. Warm restart preserves all data that cold restart preserves but preserves
additional operational data as well.
A typical example of operational data which is preserved is the mode of a primary
RegCtl block connected to a direct analog output. In cases of CEE-to-CEE regulatory
cascades this mode is retained across warm restart.
CEE can be commanded to go to run from idle through a warm start transition even
when there has been no checkpoint restore. For example, if a user loads an entire CEE
through configuration load he will normally go to run with a cold start command but
R110 Experion LX Control Builder Components Theory 137
February 2014 Honeywell
6. Cold and Warm Restart Functionality
6.1. Overview
nothing prevents him from commanding warm start. In regulatory cascades MODE
values loaded as configuration data is retained across warm restart even if the cascade
terminates on a direct analog output.
6.2 Planning
Invariant or Variant Restart Behaviors
CEE blocks can be broadly divided into two categories with respect to how they behave
on restart.
• Blocks which perform the same start up initialization regardless of the type of restart
in progress.
• Blocks which perform different start up initializations depending on whether a cold
or warm restart occurs.
The following broad principles generally apply to all blocks regardless of whether they
change behavior in response to cold or warm restart.
• PV handling on warm and cold restart
PV handling does not change in response to the selection of warm or cold restart
unless otherwise noted (TOTALIZER is the only exception). Upon restore of a
checkpoint PVs are initialized to their fail safe values (NaN in the case of floating
point PVs). For PV algorithms which involve historical computation state (filters,
delays, and so on) all history is re-initialized.
• Alarm handling on warm and cold restart
When a node other than that which issued the alarm is restarted, alarm timestamps
are preserved. However, when a CEE is restarted, any alarms reported by the nodes
themselves acquire the time stamp that goes with the time of restart. The timestamp
of original report is not retained. This applies regardless of whether the restart is
warm or cold.
parameter. In other cases, parameters like this are implemented along with many
others within a block.
Examples of data storage parameters and their blocks are as follows: PV and PVFL
parameters on FLAG block; PV parameter on NUMERICARRAY block;
RECTARGET[ ] parameter on the SCM module; all parameters of Custom Data
Block (CDB) types created by end users.
For data of this kind the restart behavior is simply that the value is held. That is, if
the value was restored by checkpoint restore then it is held across restart.
• Logic gates: hold on all restarts
Logic gate inputs and outputs are held for any type of CEE restart. This is consistent
with the Inactivation and Activation behavior of an individual Control Module. The
inputs and outputs are held to allow certain configuration changes without affecting
other strategies that may reference gate outputs. Note that this implies a logic gate
contained in a Control Module that is not executing has its output held at the value
calculated at the last time it did execute, or at an initialized value after load. Careful
consideration is required when the outputs are referenced outside the containing
Control Module. For restarts of an entire CEE, the normal method of proper
ordering of a set of related Control Modules' execution through PERIOD, PHASE,
and ORDERINCEE should be used. For agents in peer nodes referencing a gate
output, or in critical applications where Inactivation of only one of several related
Control Modules needs to be tolerated, consideration should be given to
implementation the inter-Control Module references using CHECKBOOL pairs.
Logic gate inputs and outputs are not treated as persistent state variables in CEE.
Thus, they are not restored as part of a configuration load nor saved as part of
checkpoint data. On any execution, including the first following a restart, connected
gate inputs are fetched just before the output is calculated. This insures that logic
gate outputs contained within an executing control module are a function of the most
currently fetched inputs.
In the case of a load or checkpoint restore, all outputs are set to False, and inputs are
set to default values appropriate for the block type. This policy insures that output
values are at a defined, known state, after load even if the value is read before first
block execution. Thus, if an output value happens to be read by an off node agent
before first execution, it always return False. Logic strategies must be designed so
that they are tolerant of the appearance of False valued outputs before first execution
of the source block. Again, for critical applications, it may be necessary to utilize
CHECKBOOL pairs for inter-Control Module references to fully specify behavior
The policies governing logic gate behavior for restart and load allow strategies to be
configured that allow detection of certain types of restarts. For example if a FLAG
block's PVFL is TRUE at the time as checkpoint save, or is configured as TRUE
before load, it is restored as TRUE. If connected to an RTRIG's IN, the RTRIG
generates a pulse only on the first restart following a restore. In all cases this type of
implementation is not recommended. If detection of various restart types is
required, it should only be implemented using the STARTSIGNAL block.
• Non-Logic Blocks that maintain state/history: initialize to current inputs from
infinite past
Examples of blocks which follow this rule are DATAACQ (filter state is initialized
to current input upon all restarts), LEADLAG (difference equation state is set to
zero or to match input upon all restarts), DEADTIME (delay queue is initialized to
current input upon all restarts), DELAYTIME (shift register is initialized to current
input upon all restarts).
Not all block types with invariant restart behavior are covered by the principles listed
above. For these, restart behavior is case specific and is prescribed by their functional
definition. A few examples are noted in the table below.
Special Case Blocks with Invariant Restarts
CEE Block
The CEE function block does nothing that distinguishes warm restart from cold restart
except for notification reporting. Its behavior with respect to notification reporting is as
follows.
• On Warm restart, the CEEC300 reports idle to run state change event occurred with
a warm restart.
• On Cold restart, the CEEC300 reports idle to run state change event occurred with a
cold restart.
Logic Blocks
Startsignal
STARTSIGNAL is a Logic function block supported to aid in the handling of restarts
within Control Modules. It may be optionally used within any Control Module to give
the designer better control over how the module initializes in response to events such as
cold or warm restart. STARTSIGNAL is useful in logic gate configurations which hold
state.
Block STARTSIGNAL supports read-only parameters which may be accessed to drive
initialization actions. Each parameter has "pulse" semantics which means that each
parameter normally holds a value which indicates that no initialization is required. When
a transition occurs appropriate parameters acquire an informative value. This value lasts
until the end of the first block execution which follows the transition. After first
execution the parameter is reset to a value which indicates that no restart has occurred
since the last execution. A STARTSIGNAL instance must always be configured so that
its ORDERINCM parameter places its execution after that of any blocks which read its
parameters.
Parameter Description
Parameter Description
Parameter RESTART may be displayed on the symbol faceplate of block RESTART for
monitoring purposes but it nly shows a value other than NONE until first execution.
Parameter RESTART may be used to drive initializations within the control module but
in many cases it is more convenient to use one of the associated Boolean-valued flag
parameters.
CEESTARTOPT • ALWAYSCOLD
For this configuration, SCMs execute cold start behavior
(Access Lock = regardless of the restart commanded for CEE as a whole.
ENGR) This means that MODE is changed to Manual. Other
parameters such as MODEATTR and STATE are left
unchanged.
• ALWAYSWARM
For this configuration, SCMs execute warm start behavior
148 Experion LX Control Builder Components Theory R110
Honeywell February 2014
6. Cold and Warm Restart Functionality
6.3. Configuration of Restart Behaviors
CEETOPTSTART • ON
When CEE restarts, the SCM starts executing at the top of
(Access Lock = the Check handler unless the operator commands execution
ENGR) to start at a different handler. The values of CEERESADDR[
] and the various SET.UPDCEERESOPT parameters have
no impact on where the SCM resumes execution. This is the
default value.
• OFF
When CEE restarts, the SCM starts executing a the step
within the Main handler that is indicated by the value of
CEERESADDR[ ].
the top of the Check handler unless the operator commands execution to start at a
different handler. This is true even if CEETOPSTART = OFF.
The value of CEERESADDR[ ] can change as the SCM executes. It can either change
automatically, under the action of the STEP.UPDCEERESOPT parameters, or it can
change as a result of explicit store commands issued by SCM expressions. Whatever the
value of CEERESADDR[ ] is at restart, the SCM resumes execution at that step within
the Main handler unless the operator commands execution to start at a different handler.
STEP.UPDCEERESOPT • ON
If the step is within the Main handler, then on
(Access Lock = ENGR) execution the step it assigns its own name to that
element of CEERESADDR[ ] which corresponds to its
thread of execution. This causes the SCM to restart
at this step should the CEE cease to execute before
the step has completed and if CEETOPSTART is
OFF. If the step is within a handler other than the
Main handler, then UPDCEERESOPT has no impact.
This is the default value.
CEERESADDRN[ ]
The CEERESADDR[ ] parameter may be explicitly changed by SCM expressions, but
not through direct assignment to parameter CEERESADDR[ ]. This is because
EXCMODEOPT
The SCM parameter EXCMODEOPT maintains its pre-existing meaning. Its
corresponding behavior can be relevant to cold restart scenarios as noted in the following
table.
NONE There has been no restart transition since the last execution of
the SCM/RCM.
CMLOAD The SCM/RCM has been loaded since its last execution. This
value also applies the very first time an SCM/RCM is executed.
CMACTIVE The SCM/RCM has been stopped and reset since its last
execution.
CEECOLD The CEE containing the SCM/RCM has moved through a cold
restart since the last execution of the SCM/RCM.
CEESWITCH The controller hosting the CEE which contains the SCM/RCM
has moved through a redundancy switchover since the last
execution of the SCM/RCM.
There is an implicit priority to the values of RESTART, which insure that the condition
requiring the strongest initialization can always be seen. This allows SCM expressions to
be written so that they may always do the strongest initialization necessary. The priority
is as follows:
• CMLOAD > CMACTIVE > CEECOLD > CEEWARM > CEESWITCH > NONE
SCM Blocks
SCM:STEP
SCM functions as an integrated whole with all component objects (handlers, transitions
and steps) behaving in consistent fashion. Of the various SCM components, only the
STEP has state which must be handled differently depending on whether the restart is
warm or cold. All STEP data is initialized appropriately based on the restart transition
and configuration options of the parent SCM. Specific functionalities of STEP are
described in the preceding Sequential Control Module (SCM) section.
Regulatory Cascades
CEE regulatory control (RegCtl) blocks can be organized in cascade relationships with
other RegCtl blocks and with non-RegCtl blocks. The cascades can be confined to a
single Execution Environment (EE) or they can extend beyond a single EE. In the
context of restart, cascade behavior generally falls into two broad categories.
a) Resume automatic control without human intervention if automatic control was operative
before shut down.
b) Do not resume automatic control until there has been some form of
acknowledgement from a human operator.
Which of these two behaviors applies depends on:
• the nature of the cascade relationship
• the type of node hosting the primary
• the type of node hosting the secondary
• how the node coming back from shutdown is restarted
In all cases for all restart types and all topologies, CEE restarts eventually result in full
initialization of internal dynamics of RegCtl blocks. The general behavior is that the
output (OP) is initialized to match the downstream output value and the internal states of
difference equations are set to zero. Set Point (SP) is either initialized to track PV or is
held unchanged. Whether SP tracks PV or is preserved depends upon the setting of
parameters PVTRAKOPT and PVTRAKOPTAI.
CEE to CEE Cold When the secondary is a regulatory control block, mode
is preserved. When the secondary is a direct analog
output, mode is overwritten to manual.
6.4 Operations
Across Experion LX there are several different kinds of subsystems which respond to
"activation" or "start up" commands. Though similar, the manner in which these
subsystems respond is not equivalent in all cases. The table below illustrates the
differences.
CM Yes No No No
IOM Yes No No No
Because of the different types of startup transitions supported across different Experion
LX subsystems, the HMI which issues startup commands includes Restart functionality.
The following principles apply:
• "Activation" applies only to CMs, SCMs and IOMs
• "Run", "Warm Start" and "Cold Start" are applied, as appropriate. to the idle to run
transition of Execution Environments
Step Action
1 Open the CEE function block form either directly from Control Builder project
or monitor.
2 Choose the command from the CEE Command drop down menu. Drop down
menu choices are: None, Idle, WarmStart, and ColdStart.
Step Action
How it works
Any condition that breaks the communication path between the physical I/O module and
the I/O function block initiates a control mode shed. The most common causes of loss
communications are as follows:
• Loss of communication on the I/O link.
• Failure of the I/O processor.
• The diagnostic failure of an individual slot. Only applicable for slot status conditions
that truly indicate a broken output path. For example, a "Communication error"
indicating a failure in communication to the IOM or an individual hardware failure
on a slot. This means that a "Bad calibration" error does not initiate a shed (or back
initialization for that matter), since it does break the output path.
ATTENTION
These common actions do not break the communications path or initiate a
control mode shed:
ATTENTION
You can optionally enable this functionality of specifying a time delay for the
regulatory control blocks to shed the control mode in the event of an IO
communication loss. For more information on how to optionally enable this
functionality, refer to Enabling the option of specifying time delay for REGCTL
blocks to shed the mode.
• Disable – When this parameter is disabled, the regulatory control blocks shed their
mode to MANual immediately after an IO communication loss. This is the existing
functionality.
The default value of the BADOCOPTENB parameter is “Disable”.
Note: Only the users with an AppDevOnly access level can change the
BADOCOPTENB value. Also, you can change the BADOCOPTENB value only from
the Project view before loading the CM.
ATTENTION
The BADOCOPT parameter is available for configuration only if the
BADOCOPTENB parameter is enabled.
The following figure displays a sample Main tab in which the Enable Bad Output
Connection Option check box is selected (enabled). Note that only if this check box is
selected, you can enter a value in the Bad Output Connection Option field. If the Enable
Bad Output Connection Option check box is cleared (disabled), the Bad Output
Connection Option field is disabled (appears dimmed).
1 - 60 Mode sheds to MANual and the mode After the IO communication is restored, the
attribute changes to Operator based initialization request is reset and you must
on the following conditions: revert the mode setting manually. However, if
the IO communication is restored within the
When the BADOCOPT value is less specified time delay, there is no need to revert
than its associated Control Module’s the mode setting.
execution period, the mode shedding
occurs after a time delay of one CM
Period. For example, if the Control
Module’s execution period is 5 secs
and the BADOCOPT value is 1 sec
then the mode shed to MANual
happens after 5 seconds. (1 block
execution cycle)
ATTENTION
In the event of a controller switchover, the secondary controller that assumes the
primary state retains the same BADOCOPT, BADOCOPTENB
UNCMDCHGALM.OPT, UNCMDCHGALM.PR, and UNCMDCHGALM.SV
parameter options as that of the primary controller, before the switchover
occurred.
Refer to the Control Builder Parameter Reference document for more information
on these parameters.
• All the outputs connected to the block have lost communications with the IO.
However, if even one of the outputs resumes communication with the IO, the
initialization of the block happens.
• All the outputs are connected to an AO and all the secondaries connected to the
block have lost communications with IO. However, if one of the outputs resumes
communication with IO, re-initialization of the block is requested.
• For a Fanout block with mixed OP connections to the AO and the regulatory blocks,
the BADOCOPT parameter is applicable when the following conditions exists.
− All the outputs connected to the block are not communicating with their
secondaries.
− All the secondaries are requesting the block to initialize.
However, if the last output connected to an AO channel loses communication with the
IO, the block sheds mode based on the option configured in the BADOCOPT.
Between 0 – You change the BADOCOPT Change comes into effect only when
60 secs value to a value between 0 – 60 the timer is terminated after the period
while the delay timer is running. is over or the communication is
restored.
NaN You change the BADOCOPT Change comes into effect immediately.
value to NaN while the delay timer Mode does not shed to MANual. Timer
is running. is reset.
Between 1 – You change the mode to a non- Mode sheds to MANual, even if the
60 secs MANual mode after the block has specified time delay is not expired.
shed to MANual after the specified However, if the communication error is
time delay or restored and restarted, the mode
sheds to MANual after the specified
You set the mode to MANual time delay is expired.
before the delay time expires and
then change the mode to a non-
MANual mode.
Between 1 – You set the CEE to Idle or make Timer value is reset. The timer is
60 secs the Control Module containing the restarted after the CEE is started,
regulatory block inactive. Control Module is active and the IO
communication loss continues to exist.
Between 1 – You perform a Checkpoint Save Checkpoint Save does not store the
60 secs operation. active delay timer value. When the
checkpoint data is restored, the
BADOCOPT parameter option is
restored but the delay timer value is
not restored but reset. If the IO
communication is not restored at this
point, this is considered a new
instance and the delay timer is
restarted.
Between 1 – You perform a RAM Retention RAM Retention Restart does not
60 secs Restart. restore the active timer value but it is
reset.
Detail Displays
The Bad Output Connection Option (BADOCOPT) and UnCommanded Mode Change
(UNCMDCHGALM) parameters appear in the Station detail displays only if the
BADOCOPTENB parameter is enabled in the Main configuration form of the regulatory
control blocks.
The BADOCOPT and the UNCMDCHGALM parameters appear in the following details
displays of the regulatory control blocks.
• SysDtlRegctla.htm
• sysdtlpida.htm
• sysdtlpide.htm
• sysdtlpidpla.htm
• sysdtlpidplf.htm
• sysdtlpidplaltf.htm
• sysdtlpidplalta.htm
• sysdtlrampa.htm
• sysdtlrampd.htm
The following figure displays the detail display of the Main tab of a regulatory control
block.
The following figure displays the detail display of the Alarms tab of a regulatory control
block.
Export functionality
It may help to think of the Export function as a dynamic copy operation for the ERDB
being accessed through Control Builder. This function lets you export a portion of the
ERDB or the whole ERDB as viewed through the Project Tree in Control Builder. The
exported or copied portion of the ERDB is automatically stored in the C:\Program
Files\Honeywell\Experion\Engineering Tools\Ixport directory location by default. The
following figure shows how an exported ERDB viewed in the Project Tree appears in the
Ixport file folder for example purposes only.
The export function lets you export The exported portions or all of the ERDB are stored in
all or a portion of the ERDB viewed the Ixport folder at directory location c:\Program
in the Project Tree to the Ixport Files\honeywell\Experion\Engineering Tools\ by
folder or a user-defined location. default.
By default, the ERDB used by Control Builder is stored in SQL Server under the
filename ps_erdb (default name). This is the ERDB that is being viewed in the Project
Tree.
Import functionality
It may help to think of the Import function as a dynamic paste operation for the ERDB
being accessed through Control Builder. This function lets you import a portion of an
exported ERDB or the whole exported ERDB as viewed through the Import dialog box.
The imported or pasted portion of the exported ERDB is automatically written to the
Project Tree, which is associated with the ps_erdb file in the SQL Server. If an imported
block has the same name as one already in the Project Tree, the configuration data for the
same named block in the Project Tree is overwritten by configuration data for the
imported block. The following figure shows the informational type messages generated
for the Import of an exported block named AIM_Backup into the Project Tree for
example purposes only.
Database Database
ps_erdb ps_erdb
(copy) (paste)
Ixport
File
You can click the hyperlinks of the parameters and view the CM and SCM parameter
information. In the SCM chart, expressions appear with a background color. When you
move the mouse pointer on a parameter, the hyperlink is visible and you can click it to
navigate to the corresponding chart.
ATTENTION
The hyperlinks appear with the normal text color and the hyperlink text color is
not used in the SCM chart of Monitoring mode.
The following figures show how a configured SCM chart named example_scm appears
in the Monitoring Tab of Control Builder and in the Chart Tab of the example_scm
Detail display in Station for example purposes only.
For more information on colors and their meanings, see Operator's Guide.
<TF><F608
15></TF>
The following figures show how a configured CM chart named CM102 appears in the
Monitoring Tab of Control Builder and in the Control Module Tab of the CM102 Detail
display in Station for example purposes only.
ATTENTION
You can only monitor parameters shown on SCM and CM charts in Detail
Displays. You must access charts through the Monitoring mode in Control
Builder to initiate allowable parameter changes.
• A tool button on the chart Detail display lets you change the scale factor of the
chart for viewing as well as cancel or resume the Chart Automatic Tracking feature
for an SCM chart display.
• Open only one SCM or CM chart for display in Station at a time.
• You can display the same SCM or CM chart on multiple Stations at the same time.
• You can display different SCM or CM charts on multiple Stations at the same time.
• Since the operator security level can be changed through Station, it is possible that
the security level for Station is different than the security level for Control Builder.
• A communications failure results in question marks (?) being shown in place of live
values until the fault is cleared.
I/O Functions
Series 8 I/O: in conjunction with Input/Output Termination Assemblies (IOTSs), the
IOMs perform input and output scanning and processing for field I/O.
A redundant I/O Link is standard for added security.
Warning Questionable. Some cable errors detected during last pass of periodic
channel swap. The errors detected did not exceed the periodic swap
threshold setting. The default setting for the PERSWAPTHRES
parameter is 10 errors per minute.
Error Bad. Either the cable errors detected during the last pass of periodic
channel swap or the sum of errors detected for the last 10 passes of
periodic channel swap on this cable exceeds the periodic swap
threshold setting of 10 errors per minute.
When the status of a cable transitions to the error state, a cable error alarm is generated
and the periodic channel swap function is automatically disabled. The status of the other
cable changes to unknown, since cable statuses cannot be validated until the periodic
channel swap function is re-enabled.
Once the cable fault is corrected, the periodic channel swap is enabled, and the cable
status returns to Ok, the cable status alarm returns to normal.
To minimize repetition of data, this document does not include topics specific to the
physical equipment type blocks (self-standing FBs) and the Control Module FB, and it
does not list all the parameters associated with a given FB. This information can be
found in the Experion LX Control Builder Components Reference.
Proportional, Integral PID-PL (Profit Loop Provides PID control using a model
& Derivative with PKS) Block predictive control package called Profit
Profit Loop PKS Loop PKS that incorporates robust
control techniques to enhance control
performance despite process model
uncertainty and measurement error.
Proportional, Integral PIDFF (PID with Provides the same classic PID function
& Derivative with Feedforward) Block as outlined above with the ability to
Feedforward accept a "feedforward" signal. You can
configure the feedforward signal to be
added to or multiplied by the PID's
incremental output to meet varying
control requirements.
Ramp Soak RAMPSOAK Block Provides an output that follows the user
configured sequence of ramp/soak pairs.
Each ramp/soak pair consists of a
configurable soak value or ramp target
value, a soak time and a ramp rate.
Typically, used in conjunction with a PID
block.
Ratio Control RATIOCTL (Ratio Accepts the actual value of the controlled
Control) Block flow (X1), the actual value of the
uncontrolled flow (X2) and the target ratio
between the flows (SP), and calculates
the target value of the controlled flow
(OP) and the actual ratio between the
− PULSECOUNT
− PULSELENGTH
− REGCALC
• You can use CAB instances for standalone operation or as programs whose
execution is inserted into the flow of other compatible blocks. For standalone
operation, you must configure the CAB for an Access Level of PROGRAM. For
insertion program operation, you must configure the CAB for an Access Level of
CONTCONTROL.
• You must insert CAB instances in the same Control Module that contains the
regulatory control block.
• If you insert multiple CAB programs at the same point, the order in which the
insertions are configured determines their execution order. During configuration, the
ORDERINCM parameter of the inserted CAB instance changes automatically to
match the calling regulatory control block and the INSERTION parameter of the
inserted CAB instances is set to TRUE.
• CAB instances configured for insertion execute only when they are called during the
regulatory control block execution and are not executed as part of the normal
Control Module execution.
• CAB instances configured for insertion should normally have no outside pin
connections configured. If you need to share CAB instance data with blocks other
than the one with inserted CAB programs, you can use parameter connectors or
direct wire connections to configured pin connections for custom data parameters on
the CAB instance. See the Pin connections to inserted CAB instances section for
more information.
• The Control Builder application does not allow you to configure the same CAB
instance as an insertion by more than one Regulatory Control block.
Function Requirement
Error Handling The CAB program must not abort when the regulatory control
block goes into a bad control state. The output value CV must be
set to NaN, when the value of the required input is bad. This
causes the regulatory control block to go into a bad control state.
Initialization The CAB program algorithm must calculate the initialization value
(INITVAL) that is to be propagated to its primaries during
initialization. The algorithm must perform CV calculations based
on the control state of the regulatory control block, which can be
determined by reading the value of the CTLSTATE parameter. If
the CTLSTATE value is INIT, the regulatory control block is in its
initialization state.
Function Requirement
Override Feedback If the regulatory control block is part of an override strategy, the
CAB program must set the appropriate override status and
calculate the override value to be propagated to its primary. The
override status to be propagated is written to the parameter
PRIMDATA.ORFBSTS and the override feedback value is stored
in the PRIMDATA.ORFBVAL parameter. The following is a high
level implementation detail for the override propagation.
BEGIN
PRIMDATA.OROFFSET = SECDATAIN.OROFFSET
PRIMDATA.HISELECT = SECDATAIN.HISELECT
PRIMDATA.PROPOVRD = TRUE
PRIMDATA.ORFBVAL = SECDATAIN.ORFBVAL
PRIMDATA.ORFBVAL = NaN
PRIMDATA.ORFBSTS = NOTCONNECTED
PRIMDATA.ORFBVAL = NaN
PRIMDATA.ORFBSTS = SECDATAIN.ORFBSTS
END
Function Requirement
Floating Bias The standard Regctl algorithms include a floating bias function so
that output is bumpless during mode changes. If this function is
required, the floating bias functionality has to be implemented in
the CAB program.
Timeout If the input timeout function is needed, the CAB program must
implement the timeout processing as part of the program.
CAB instance. If pin connections are configured, then the data transfer operates as
follows:
• Pin connections always transfer data into a CAB insertion program just before
execution of the calling block.
• Pin connections always transfer data out of a CAB insertion program just before
execution of the block that is pulling the CAB Custom Data Parameter (CDP).
Note that the CAB instance generates an exception event on the first
encounter only and does not regenerate the event on the next
execution, if it remains in the exception state.
For example, if a Ctl_Alg insertion program fails, control output processing, windup
processing, and so on is not performed. The parameter INITMAN is set to TRUE, which
causes the regulatory control block to go to INIT state.
Callout Description
If the CAB_1 instance is not used for an insertion point and the
INSMASTER parameter is turned Off or set to False, it is included in
the Control Module execution list and runs normally during each
cycle. In this case, no tag name appears in the Insertion Point field on
the block's configuration form and the CAB must be re-configured for
an Access Level of PROGRAM.
If the CAB program encounters an exception failure (example divide by zero), it returns
an exception status to the calling master pida. This causes pida to go into an INIT
state, INITMAN is set to true, and it skips the rest of its processing. On the next
execution cycle, pida remains in INIT unless the CAB returns a NORMAL status.
When the exception condition clears, the pida block executes normally.
Note that the CAB instance generates an exception event on the first encounter only
and does not regenerate the event on the next execution, if it remains in the exception
state.
Callout Description
If the CAB program encounters a termination failure (example execution time is too
long), CAB_1A returns a termination status to the calling master pida. In this case,
pida sets INITMAN to true and skips the rest of its processing. On the next execution
cycle, pida remains in INIT unless the problem has been corrected and the program
returns a NORMAL status.
With a termination failure, the CAB instance does not execute again unless manually
restarted. You should correct the defect in the program before reactivating the control
strategy. If you just try restarting a terminated CAB program, it will most likely
terminate again.
Callout Description
Callout Description
4A are added to the Control Module containing the AUTOMANA
block.
If CAB_1A fails, none of the steps after input processing are executed in the current
cycle including the execution of the other three insertion programs CAB_2A, CAB_3A
and CAB_4A. That is, the output values (CV and OP) remains unchanged and will not
be recalculated based on the new input values fetched in the current cycle.
If CAB_2A fails, the execution of CAB_3A, CAB_4A, control output processing and
windup processing are skipped. If this happens, the CV value remains at the old value
If CAB_3A fails, control output processing, windup processing and CAB_4A are
skipped. In this case, the output value OP will not be computed to match the CV value
calculated in the CAB_2A program.
Callout Description
If CAB_4A fails, windup and feedback processing are skipped. In this case, the windup
states will not be recomputed and propagated to the primaries..
Callout Description
Callout Description
3 The CAB instances named CAB_1A and CAB_2A are added to the
Control Module containing the pida block.
Comparing the respective coefficients of equations 4 and 5, gives the Non-Interactive PID
tuning coefficients in terms of the Interactive PID tuning parameters as follows:
(T1 + T2 ) T1T2
K ni = K ; TI = T1 + T2 ; TD =
T1 (T1 + T2 )
where,
K – interactive gain
If the block is in initialization in The OP value will not be impacted by any change other than
the previous scenarios, the INITVAL from the secondary. The OP is dynamically
updated based on the SIOPT, only after the block comes out
of initialization.
When there is a Program store • The Mode will be shed but the OP will not be set based on
configured to set the SIFL to ON the Shed option.
once and if the block is in
• The OP will be equal to the INITVAL from the secondary in
initialization,
this case.
• The user has to execute the program to pulse the SIFL to
When SIFL changes from ON to • The function block clears the Safety Interlock alarm (if one
OFF, was issued).
• If mode was shed and the mode remains in Manual mode,
the function block issues an initialization request to its
primary. The user must return the block to its normal mode.
• If mode was not shed, the function block clears its windup
condition .
Each AUTOMAN block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that Tab. This data is only provided
as a quick document reference, since this same information is included in the on-line
context sensitive Help.
Output • High Limit (%) (OPHILM) - Lets you specify the output
high limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
Control Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Insertion Type Lets you include an insertion type from a CAB instances in
the block. See CAB insertion configuration considerations
for regulatory control blocks for more information
The block calculates the output value (CV) using the following equation:
CV = K X1 + OPBIAS.FIX + OPBIAS.FLOAT
Where:
X1 = input value
• K and OPBIAS.FIX may either be fixed (that is, stored manually or by the program)
or external (that is, brought from another block).
• After an initialization, the block calculates OPBIAS.FLOAT as follows:
Function
The AUTOMAN block is typically used:
• in a cascade control strategy where one of the upstream blocks may not accept an
initialization request from its secondary.
• between a FANOUT block and a final control element to provide a "bumpless"
output on return to cascade.
ATTENTION
The AUTOMAN block:
Configuration example
The following figure and its companion callout description table show a sample
configuration that uses an AUTOMAN block between a FANOUT block and a
downstream PID block for quick reference.
The following table includes descriptions of the callouts in the figure above.
Callout Description
Callout Description
1 You can use the FANOUT block to distribute a single primary output to
multiple secondaries. (Note that the individual
BACKCALCIN/BACKCALCOUT connections for each FANOUT output
used are automatically built by Control Builder as implicit/hidden
connections.)
Since the FANOUT block only initializes when all of its secondaries request
it, insert an AUTOMAN block for individual downstream blocks (like PIDB in
this example) to ensure bumpless transfer during mode changes.
2 You can specify a gain and bias for each of the FANOUT block outputs.
This block applies a user-specified gain and bias to the output. The user-
specified values can be fixed or external. A fixed value is stored manually
or by a program, and an external value comes from another function block.
The AUTOMAN block uses the following equation to calculate its output.
• CV = K X1 + OPBIAS.FIX + OPBIAS.FLOAT
• where:
− K = gain for CV
− X1 = input value
− OPBIAS.FIX = fixed output bias (user-specified)
− OPBIAS. FLOAT = floating output bias (calculated)
Inputs
The AUTOMAN block requires one input - X1:
• X1 = initializable input which, if used, must be pulled from another block (it cannot
be stored).
Output
The AUTOMAN block has the following initializable outputs:
• OP = calculated output, in percent.
• OPEU = calculated output, in engineering units.
ATTENTION
A connection to OP or OPEU may be created, but not to both. Therefore,
this block may have only one secondary. If a connection to OP or OPEU is
not created, the AUTOMAN block does not have a secondary. Alternately, if
OP or OPEU is connected to a non-initializable input, the AUTOMAN block
does not have a secondary.
ATTENTION
The AUTOMAN block provides the X1 input range (XEUHI/XEULO) to the
primary through BACKCALC. The primary uses this for its output range
(CVEUHI/CVEULO).
Output ranges
CVEUHI and CVEULO define the full range of CV in engineering units.
If the AUTOMAN block has a secondary, it brings the secondary's input range through
BACKCALC and sets its CV range to that. If it has no secondary, CVEUHI and
CVEULO track the X-input range (XEUHI and XEULO).
• OPHILM and OPLOLM define the normal high and low limits for OP as a percent
of the CV range. These are user-specified values.
OP is clamped to these limits if the algorithm's calculated result (CV) exceeds them
or another block or user program attempts to store an OP value that exceeds them.
However, the operator may store an OP value that is outside these limits.
• OPEXHILM and OPEXLOLM define the extended high and low limits for OP as a
percent of the CV range. These are user-specified values. The operator is prevented
from storing an OP that exceeds these limits.
Output bias
The output bias (OPBIAS) is added to the algorithm's Calculated Value (CV) and the
result is stored in CV. CV is later checked against OP limits and, if no limits are
exceeded, it is copied to the output.
The OPBIAS is the sum of the user-specified fixed bias (OPBIAS.FIX) and a calculated
floating bias (OPBIAS.FLOAT). The purpose of the floating bias is to provide a
bumpless transfer when the function block initializes or changes mode.
• OPBIAS is recomputed under the following conditions to avoid a bump in the
output. (Note that the function block only applies OPBIAS.FLOAT to the output for
the latter two conditions, when it is the first initializable block.)
− When the function block starts up (that is, goes Active).
− When the function block initializes (for example, the secondary requests
initialization).
− When the mode changes to Cascade.
• The following occurs when you set the OPBIAS value.
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the
entered value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
ATTENTION
When the function block goes Active or the Mode changes to Auto or
Cascade, OPBIAS and OPBIAS.FLOAT are recomputed.
• There are no limit checks applied when you set an OPBIAS or OPBIAS.FIX value.
However, after the total bias is added to CV, the result is compared against the
output limits and clamped, if necessary.
• You configure the value for the fixed bias (OPBIAS.FIX) and it is never overwritten
by the floating bias (OPBIAS.FLOAT). That is, the total bias eventually equals the
OPBIAS.FIX , if you configure OPBIAS.RATE to ramp down OPBIAS.FLOAT.
• You may store to OPBIAS.FIX only if the function block is inactive or the MODE is
Manual; or if it is a PID or PIDFF function block with the CTLEQN set to E. When
you store to OPBIAS.FIX, the following occurs:
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the new
value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
• The OPBIAS.FLOAT is calculated as follows.
Where:
If OPBIAS.FLOAT is not zero, you can configure it to ramp down to zero through
the OPBIAS.RATE parameter.
• You configure the OPBIAS.RATE to apply a ramp rate to the OPBIAS.FLOAT. It is
only used when the OPBIAS.FLOAT is not zero. The OPBIAS.RATE is expressed
in Engineering Units per minute and may have the following values.
− Zero:
If OPBIAS.RATE is zero, a OPBIAS.FLOAT is calculated and bumpless
transfer is guaranteed. However, if OPBIAS.FLOAT is not zero, it will never
ramp down. As previously mentioned, you can reset the OPBIAS.FLOAT to
zero by manually entering a value for OPBIAS.
− Non-zero:
If OPBIAS.RATE is not zero, an OPBIAS.FLOAT is calculated and bumpless
transfer is guaranteed. If the OPBIAS.FLOAT is not zero, it is ramped to zero at
the rate you configured for the OPBIAS.RATE parameter.
Where:
− NaN:
When the OPBIAS.RATE is Not a Number (NaN), no OPBIAS.FLOAT is
calculated. This means a bump in the output occurs, if the primary does not
accept this block's initialization value.
ATTENTION
The OUTIND parameter has no affect on the block's control operation. The
CTLACTN parameter on the Algorithm tab still supports the output direction of
the block, the OPTDIR parameter on the Main tab for the AOCHANNEL block
form applies the conversion of OP to OPFINAL. You can manipulate the
DIRECT/REVERSE selections for the OUTIND, CTLACTN, and OPTDIR
parameters to meet your process and operator needs.
OP 100.0 - Actual OP
The user store of an OP related parameter is intercepted and reversed when OUTIND
equals REVERSE. For example, a store of OPHILM = 80 produces OPLOLM = 100 -
80, so the OPHILM parameter will then view OPHILM = 100 - 20.
ATTENTION
The swapping/reversal of values will not be done, if the block was loaded with
REVERSE OUTIND configured. The reversal of values will be done only on a
subsequent change to the OUTIND value, if appropriate.
For example: If a PID block is loaded with OPHILM = 95, OPLOLM = 10 and
OUTIND as REVERSE, the OPHILM and OPLOLM after load will still be 95
and 10, respectively.
OP Alarms considerations
When the OUTIND parameter value is set to REVERSE, the OP values displayed for the
high or low CEE Output Alarms are reversed. In the Alarm Summary display, the OP
values of the high alarms and the low alarms are swapped. The Output Alarms display
shall track the value of displayed output parameters. An OUTIND value of REVERSE,
shall show the limit and value subjected to reversal. For example, an OPHI alarm will
have the displayed trip limit set to 100 - (output low limit).
If the OUTIND parameter setting is changed:
• from Direct, DirectDispInd, or ReverseDispInd to Reverse or
• from Reverse to Direct, DirectDispInd, or ReverseDispInd,
a return for the existing Output Alarm condition occurs and a new Output Alarm would
be sent.
Mode Handling
The AUTOMAN block supports both the Cascade and Manual modes:
• If Mode is CAScade: X1 must come from another block.
• If Mode is MANual: an operator or a user program (X1 is ignored) may store OP.
Timeout Monitoring
If mode is CAScade, the AUTOMAN block performs timeout monitoring on X1. If the
X1 value is not updated within a predefined time (TMOUTTIME), the AUTOMAN
block invokes timeout processing as follows:
• Sets the "input timeout" flag (TMOUTFL).
• Sets the input value to Bad (NaN - Not a Number).
• Requests the X1 primary to initialize.
Note that the AUTOMAN block does not support mode shedding on timeout.
The maximum time between updates is specified by TMOUTTIME (in seconds).
ATTENTION
If the input is from a connection in another controller in a peer-to-peer
architecture, the actual timeout time equals the configured TMOUTTIME and
the CDA timeout time. The CDA timeout time equals four times the configured
CEE subscription rate. For example, if the CEE subscription rate is 100
milliseconds and the TMOUTTIME is 5 seconds, the actual timeout time for
the block is 4 times 100ms plus 5s or 5.4 seconds.
Control Initialization
The AUTOMAN block brings initialization requests from its secondary through
BACKCALC. In addition, the secondary may propagate one-shot initialization requests
to the block.
If the secondary is requesting initialization, the AUTOMAN block -
• Initializes its output toCV = initialization value from the secondary
INITREQ(X1) = On
CV - OPBIAS.FIX
INITVAL(X1) =
K
− Where:
CV = calculated value
K = Output gain
ATTENTION
Following a return to cascade, each secondary provides an initialization
request to its primary and in most cases the primary adjusts its output
accordingly. However, if the primary is a FANOUT block, it may ignore the
initialization request. The AUTOMAN block compensates for this by applying
a floating bias to the output.
Windup processing
Every regulatory control type block maintains anti-reset windup status for its output
(ARWOP) and each of its initializable inputs (ARWNET). The following table lists the
possible values for ARWOP and ARWNET parameters.
ARWOP computation
The ARWOP indicates if the output (OP) can be raised or lowered. The PID-type
function blocks use ARWOP to restrict integral control. When ARWOP contains a value
other than Normal, the PID block stops integral control in the windup direction. Integral
control continues in the other direction, as does proportional and derivative control. But,
windup status has no impact on proportional and derivative control.
If a function block has a secondary, it fetches the secondary's windup status and
recomputes its ARWOP. The conditions within the function block, such as output being
at its high limit, also affect the ARWOP. The ARWOP is computed as follows, assuming
the block has only one output or that it is not a FANOUT block.
ARWNET computation
When ARWNET is HiLo, stores to SP are not limited, rather this is the status propagated
to the primary. The only limiting anti-reset windup status ever does is to stop integral
action in one or both directions on PID blocks. For any other regulatory control type
block, ARWNET is not used for any kind of limiting. The ARWNET is computed as
follows, assuming the block has only one output or that it is not a FANOUT block.
The CV is NaN
NORMAL HI HI
NORMAL LO LO
HI NORMAL HI
HI HI HI
HI LO HILO
HI HILO HILO
LO NORMAL LO
LO HI HILO
LO LO LO
LO HILO HILO
HILO HI HILO
HILO LO HILO
AUTOMAN parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the AUTOMAN block.
Each ENHREGCALC block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that Tab. This data is only provided
as a quick document reference, since this same information is included in the on-line
context sensitive Help.
Setpoint • SP (SP) - Lets you specify an initial set point value. The
default value is 0.
• High Limit (SPHILM) - Lets you specify a high limit value
for the SP. If the SP value exceeds this limit, the block
clamps the SP to the limit value and sets the SP high
Output • High Limit (%) (OPHILM) - Lets you specify the output
high limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
to 500 and you enter a High Limit of 90%, the high limit
in engineering units is 90% times 450 or 405 + 50
(CVEULO) equals 455. This check is not applied for a
function block that is in the MANual mode. The default
value is 105%.
• Low Limit (%) (OPLOLM) - Lets you specify the output
low limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
to 500 and you enter a Low Limit of 10%, the low limit in
engineering units is 10% times 450 or 45 + 50
(CVEULO) equals 95. This check is not applied for a
function block that is in the MANual mode. The default
value is -5%.
• Extended High Limit (%) (OPEXHILM) - Lets you specify
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
Control Builder.
Monitoring Parameters Lets you select the available parameters that can appear
on the face of the function block in the Monitoring tab in
Control Builder.
Insertion Type Lets you include an insertion type from a CAB instances in
the block. See CAB insertion configuration considerations
for regulatory control blocks for more information.
Function
• Each expression can contain any valid combination of inputs, operators and
functions; and may perform arithmetic or logic operations.
• You can write expressions for calculating CV under normal, initialization and
override feedback conditions. Or, you can write expressions which produce
initialization and override feedback values for this block and its primaries.
• You can assign the result of an expression or an input to any assignable output,
which produces the same outputs as every other regulatory control block. You can
assign the same input to multiple outputs.
Configuration example
The following figure shows a sample configuration using an ENHREGCALC block in a
ratio control loop.
If Mode is . . . Then,
Manual (MAN) the output can be set by the operator or a user program.
The SP input is ignored.
Automatic (AUTO) the block derives OP; the initializable input (SP) may be
stored by the operator or a user program.
If Mode is . . . Then,
The initialization request occurs when the MODE changes from CAScade to MANual,
but not from MANual to CAScade. When the block is put in MANual mode, it initializes
itself and requests its primary to initialize.
Inputs
The ENHREGCALC block has the following inputs.
• SP- An initializable input. If Mode is CAScade, SP is pulled from another function
block. If Mode is AUTO, it may be stored by the operator or a user program.
• X[1] through X[10] general purpose inputs.
• XB[1..10] individually configurable bias value for each X input.
• XDESC[1..10] individually configurable description for each X input.
• XENABLE[1..10] individually configurable enable/disable switch for each X input.
• XK[1..10] individually configurable gain value for each X input.
• XKB[1..10] individual inputs with gain and bias values applied to them.
• XSTS[1..10] individual status for each X input.
• XSUB[1..10] individually configurable substitute value for each X/PX input, when
corresponding X input is disabled.
• XWHIFL - An external windup high flag.
• XWLOFL - An external windup low flag.
Since SP is an initializable input, the block can have one primary. There is one primary
for each initializable input.
Initializable input
Since SP is an initializable input, the block can have one primary. There is one primary
for each initializable input. The ENHREGCALC block performs the following
processing functions.
• SP limit checking
SP limit checking
SP Limit Processing makes sure the SP value does not exceed configured limits. These
limits are configured with the following parameters:
• SPHILM SP high limit
• SPLOLM SP low limit
If the input SP value is outside the range specified by SPHILM and SPLOLM, the
function block clamps SP to the appropriate limit and sets the appropriate limit exceeded
flag (SPHIFL or SPLOFL).
SPHILM and SPLOLM are configured in the same engineering units, as SP. Crossover
of set point limits is not allowed. SPHILM and SPLOLM can be changed even when the
Control Execution Environment (CEE) is in RUN and the Control Module (CM) is
Active.
When the SP limits are violated or the SP returns to normal, the network Anti-Reset
Windup status (ARWNET) is recomputed and the primary's windup status is set.
SPTVSTATE current target value processing state (possible states are Off,
Preset, Run)
The system calculates a ramp time (SPTVTIME), based on the normal ramp
rate
SPTVRATE = SPTVNORMRATE
Otherwise,
SPTVRATE = NaN
• If you specify a ramp time (SPTVTIME), the function block calculates a ramp rate
(SPTVRATE) as follows:
If SPTVTIME is non-zero:
Otherwise,
SPTVRATE = NaN
• If the user changes the normal ramp rate (SPTVNORMRATE), the function block
recalculates the ramp time and rate (SPTVTIME and SPTVRATE) as follows:
If SPTVTIME is non-zero:
SPTVRATE = SPTVNORMRATE
Otherwise,
SPTVRATE = NaN
TIP
A one-shot initialization does not cause a change in SPTVSTATE.
TIP
When SP is ramping, ARWNET is not shown on the Group or Detail displays.
Initializable outputs
"Initializable output" and "initializable input" are variable attributes, similar to data type
or access level. A parameter with the "initializable" attribute has an associated
BACKCALC variable, and when a connection is created between an initializable input
and initializable output, you can also create a BACKCALC connection. Control Builder
automatically builds the required BACKCALC connections, so you do not have to
create them manually. These "implicit" build connections are "hidden" from view and the
related parameter pins are not exposed on the control chart.
ATTENTION
Be sure you use a FANOUT block to make multiple output connections. We
recommend that you do not make multiple connections from a single
ENHREGCALC output.
ATTENTION
This block gets the secondary's input range regardless of SECINITOPT.
This means regardless of whether the secondary's initialization and
override data is used.
OPHILM and OPLOLM define the normal high and low limits for OP, as a percent of
the CV range. You must specify these values.
OP is clamped to these limits if the algorithm's calculated result (CV) exceeds them, or
another function block or user program attempts to store an OP value that exceeds them.
However, the operator may store an OP value that is outside these limits.
OPEXHILM and OPEXLOLM define the extended high and low limits for OP, as a
percent of the CV range. You must specify these values.
The operator is prevented from storing an OP value that exceeds these limits.
Assignable outputs
You can assign expression results and/or inputs to the following parameters.
• CVSRC - CV output source selector.
• CVINITSRC - CVINIT source selector.
• CVORFBSRC - CVORFB source selector.
• INITREQSRC - INITREQ (initialization request flag) source selector.
• INITVALSRC - INITVAL (initialization value) source selector.
• ORFBVALSRC - ORFBVAL (override feedback value) source selector.
• ORFBSTSSRC - ORFBSTS (override feedback status) source selector.
For example, you can assign the result of the second expression to CVSRC and the result
of the fourth expression to CVINITSRC and CVORFBSRC. You may assign the same
input to multiple outputs. You may also assign inputs directly to outputs, such as
assigning X[1] and X[2] to INITVALSRC and INITREQSRC, respectively.
The assignable expression and input parameters are as follows:
C[1..8] - Expressions
CSTS[1..8] - Expression Status
X[1..10] - Inputs
XSTS[1..10] - Input Status
ATTENTION
The ENHREGCALC block does perform data conversions, if the source and
target parameters are of different types. For example, if you assign the
INITREQSRC to X[2], the block converts the real type data from X[2] into
Boolean type data for INITREQ[1] that it sends to its primary. You must be
careful when making assignments that the resulting data conversions do not
make sense. For example, if you assign XSTS[1] to ORFBSTSSRC, the two
statuses are entirely different and they cause the block to produce
unexpected results.
− ORFBSTSSRC
− You can assign these parameters to an input or an expression result, or leave
them unassigned. The following table summarizes possible outcomes for
specified parameter assignments. You may need to assign an INITVALSRC to
compute a customized initialization value for the primary based on the CVSRC
assignment.
Control initialization
The ENHREGCALC block brings initialization requests from its secondary through
BACKCALC. In addition, the secondary may propagate one-shot initialization requests
to this block. (Note that SECINITOPT may be used to ignore initialization requests from
the secondary.)
If the secondary is requesting initialization, the ENHREGCALC block:
• initializes its output:
• builds an initialization request for the designated primaries using the assignable
output parameters INITREQSRC and INITVALSRC. If you configure no
assignments for these parameters, the block behaves like other regulatory control
blocks, using the corresponding values brought from its secondary.
Be careful when making INITREQSRC and INITVALSRC assignments to avoid
producing the wrong results. For example, you assign the INITREQSRC parameter to
C[2], which produces a result of TRUE, and the ENHREGCALC block's mode is
CAScade and its INITMAN parameter is OFF. Also, you have assigned CVSRC to C[1],
which is configured as "X[1] +10.0", and INITVALSRC to C[3], which is configured as
this block's CV. Assume at some moment that X[1] is 15.0 and it produces a C[1] of
25.0, resulting in CV = INITVAL[1] = 25.0. The primary initializes itself with the value
R110 Experion LX Control Builder Components Theory 267
February 2014 Honeywell
13. Regulatory Control
13.5. ENHREGCALC (Enhanced Regulatory Control Calculator) Block
25.0. This means that the next time the ENHREGCALC block runs it receives an X[1]
value of 25.0 from the primary, resulting in C[1] = CV = 35.0. Thus, each cycle that
ENHREGCALC runs, its CV increments by 10.0, producing seemingly wrong results.
Output bias
The output bias (OPBIAS) is added to the algorithm's Calculated Value (CV) and the
result is stored in CV. CV is later checked against OP limits and, if no limits are
exceeded, it is copied to the output.
The OPBIAS is the sum of the user-specified fixed bias (OPBIAS.FIX) and a calculated
floating bias (OPBIAS.FLOAT). The purpose of the floating bias is to provide a
bumpless transfer when the function block initializes or changes mode.
• OPBIAS is recomputed under the following conditions to avoid a bump in the
output. (Note that the ENHREGCALC block only applies OPBIAS.FLOAT to the
output for the latter two conditions, when it is the first initializable block.)
− When the function block starts up (that is, goes Active).
− When the function block initializes (for example, the secondary requests
initialization).
− When the mode changes to Auto or Cascade.
• The following occurs when you set the OPBIAS value.
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the
entered value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
ATTENTION
When the function block goes Active or the Mode changes to Auto or
Cascade, OPBIAS and OPBIAS.FLOAT are recomputed.
• There are no limit checks applied when you set an OPBIAS or OPBIAS.FIX value.
However, after the total bias is added to CV, the result is compared against the
output limits and clamped, if necessary.
• You configure the value for the fixed bias (OPBIAS.FIX) and it is never overwritten
by the floating bias (OPBIAS.FLOAT). That is, the total bias eventually equals the
OPBIAS.FIX , if you configure OPBIAS.RATE to ramp down OPBIAS.FLOAT.
• You may store to OPBIAS.FIX only if the function block is inactive or the MODE is
Manual; or if it is a PID or PIDFF function block with the CTLEQN set to E. When
you store to OPBIAS.FIX, the following occurs:
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the new
value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
• The OPBIAS.FLOAT is calculated as follows.
Where:
If OPBIAS.FLOAT is not zero, you can configure it to ramp down to zero through
the OPBIAS.RATE parameter.
• You configure the OPBIAS.RATE to apply a ramp rate to the OPBIAS.FLOAT. It is
only used when the OPBIAS.FLOAT is not zero. The OPBIAS.RATE is expressed
in Engineering Units per minute and may have the following values.
− Zero:
If OPBIAS.RATE is zero, an OPBIAS.FLOAT is calculated and bumpless
transfer is guaranteed. However, if OPBIAS.FLOAT is not zero, it never ramps
down.
− Non-zero:
If OPBIAS.RATE is not zero, an OPBIAS.FLOAT is calculated and bumpless
transfer is guaranteed. If the OPBIAS.FLOAT is not zero, it is ramped to zero at
the rate you configured for the OPBIAS.RATE parameter.
Where:
− NaN:
When the OPBIAS.RATE is Not a Number (NaN), no OPBIAS.FLOAT is
calculated. This means a bump in the output occurs, if the primary does not
accept this block's initialization value.
• After initialization, the ENHREGCALC block calculates the floating bias using the
following equation.
Where:
ATTENTION
The OUTIND parameter has no affect on the block's control operation. The
CTLACTN parameter on the Algorithm tab still supports the output direction of
the block, the OPTDIR parameter on the Main tab for the AOCHANNEL block
form applies the conversion of OP to OPFINAL. You can manipulate the
DIRECT/REVERSE selections for the OUTIND, CTLACTN, and OPTDIR
parameters to meet your process and operator needs.
OP 100.0 - Actual OP
The user store of an OP related parameter is intercepted and reversed when OUTIND
equals REVERSE. For example, a store of OPHILM = 80 produces OPLOLM = 100 -
80, so the OPHILM parameter get will then view OPHILM = 100 - 20.
ATTENTION
The swapping/reversal of values will not be done, if the block was loaded with
REVERSE OUTIND configured. The reversal of values will be done only on a
subsequent change to the OUTIND value, if appropriate.
For example: If a PID block is loaded with OPHILM = 95, OPLOLM = 10 and
OUTIND as REVERSE, the OPHILM and OPLOLM after load will still be 95
and 10, respectively.
the same. On Migration from a block with OUTIND support, the OUTIND parameter
value will be restored after migration.
The OUTIND parameter value will also be preserved on checkpoint; restored on Ram
Retention Restart and there will be no bump of OP on WarmStart. Alarm regeneration on
WarmStart, will be supported for these situations similar to other parameters.
OP Alarms considerations
When the OUTIND parameter value is set to REVERSE, the OP values displayed for the
high or low CEE Output Alarms are reversed. In the Alarm Summary display, the OP
values of the high alarms and the low alarms are swapped. The Output Alarms display
shall track the value of displayed output parameters. An OUTIND value of REVERSE,
shall show the limit and value subjected to reversal. For example, an OPHI alarm will
have the displayed trip limit set to 100 - (output low limit).
If the OUTIND parameter setting is changed:
• from Direct, DirectDispInd, or ReverseDispInd to Reverse or
• from Reverse to Direct, DirectDispInd, or ReverseDispInd,
a return for the existing Output Alarm condition occurs and a new Output Alarm would
be sent.
Timeout monitoring
If mode is CAScade, the ENHREGCALC block performs timeout monitoring of the
initializable input, SP If the SP value is not updated within a predefined time
(TMOUTTIME), the block invokes timeout processing as noted in the following section.
The maximum time between updates is specified by TMOUTTIME (in seconds)
Timeout processing
If SP times out, the ENHREGCALC block does the following:
• Sets the input timeout flag (TMOUTFL)
• Holds SP at its last good value.
• Sheds to a user-specified timeout mode (MODE = TMOUTMODE).
• Requests the SP primary to initialize (via BACKCALCOUT)
ATTENTION
If the input is from a connection in another controller in a peer-to-peer
architecture, the actual timeout time equals the configured TMOUTTIME
plus the CDA timeout time. The CDA timeout time equals four times the
configured CEE subscription rate. For example, if the CEE subscription rate
is 100 milliseconds and the TMOUTTIME is 5 seconds, the actual timeout
time for the block is 4 times 100ms plus 5s or 5.4 seconds.
If the ORFBVAL and ORFBSTS are not assigned and this block has a secondary, the
ORFBVAL and ORFBSTS received from the secondary are used to compute ORFBVAL
for the primary. When the override status from the secondary changes from selected to
unselected, this block does the following:
ATTENTION
You can use SECINITOPT to ignore override requests from the secondary.
You can customize the override feedback computation and propagation using the
following block parameters.
ORFBSTSSRC - If you make an ORFBSTSSRC parameter assignment, the
ENHREGCALC block computes the override feedback status from the assignment and
uses it for override processing and propagation to the primary. If you do not make an
assignment, the ENHREGCALC block uses the override status received from the
secondary for override processing, just like other regulatory control blocks do.
Windup handling
The ENHREGCALC block derives the ARWOP from a combination of the following
parameters and the secondary's windup status.
• CV
• XWHIFL
• XWLOFL
The following table summarizes how the block derives ARWOP for some given
conditions.
When the ENHREGCALC block computes its ARWOP windup status for its primary
(ARWNET[1]), which is computed based on ARWOP, it will be propagated to the
primary just like other regulatory control blocks.
ATTENTION
The ARWNET[1] computation is independent of whether gain (K) is positive
or negative.
Windup processing
Every regulatory control type block maintains anti-reset windup status for its output
(ARWOP) and each of its initializable inputs (ARWNET). The following table lists the
possible values for ARWOP and ARWNET parameters.
ARWOP computation
The ARWOP indicates if the output (OP) can be raised or lowered. The PID-type
function blocks use ARWOP to restrict integral control. When ARWOP contains a value
other than Normal, the PID block stops integral control in the windup direction. Integral
control continues in the other direction, as does proportional and derivative control. But,
windup status has no impact on proportional and derivative control.
If a function block has a secondary, it fetches the secondary's windup status and
recomputes its ARWOP. The conditions within the function block, such as output being
at its high limit, also affect the ARWOP. The ARWOP is computed as follows, assuming
the block has only one output or that it is not a FANOUT block.
ARWNET computation
When ARWNET is HiLo, stores to SP are not limited, rather this is the status propagated
to the primary. The only limiting anti-reset windup status ever does is to stop integral
action in one or both directions on PID blocks. For any other regulatory control type
278 Experion LX Control Builder Components Theory R110
Honeywell February 2014
13. Regulatory Control
13.5. ENHREGCALC (Enhanced Regulatory Control Calculator) Block
block, ARWNET is not used for any kind of limiting. The ARWNET is computed as
follows, assuming the block has only one output or that it is not a FANOUT block.
The CV is NaN
NORMAL HI HI
NORMAL LO LO
HI NORMAL HI
HI HI HI
HI LO HILO
HI HILO HILO
LO NORMAL LO
LO HI HILO
LO LO LO
LO HILO HILO
HILO HI HILO
HILO LO HILO
Expressions
You can write up to eight expressions, each expression can contain any valid
combination of inputs, operators, and functions. Table 1 lists the expression operators
and functions supported by this block for reference as well as some case sensitive strings
that can be used for special value constants in expressions.
ATTENTION
Do not use equality operands = and <> to compare FLOAT64 and FLOAT32
floating point values in expressions. Use inequality operands Less Than (<),
Less Than or Equal To (<=), Greater Than (>), or Greater Than or Equal To
(>=) instead.
Operators Description
Unary +-
Parenthesis ()
Array Syntax []
Unary Functions
Operators Description
LN Natural logarithm of a
number (log to the base of
e)
Operators Description
ABSTOD Takes an absolute time DTIMNUM Takes a delta TIME data type
data type and strips off the and returns a 64-bit float
year and date and returns representing the number of
a 64-bit float representing milliseconds.
the time of day in
milliseconds.
TOD Returns the current local TIMNUM Takes an Absolute TIME data
time of day as Time of Day type and returns a 64-bit float
data type representing the total number
of milliseconds since Jan 1,
1972.
UTCTOD Returns the current UTC UTCNOW Returns the current UTC date
time of day as Time of Day and time of day as an absolute
data type time data type
1
Be sure you specify the trigonometric functions cosine, sine, and tangent in radians and
not degrees.
PI PI (3.14159. . .)
E e (2.718. . .)
Parameters in Expressions
You must specify a parameter by its full tag name (for example,
"CM25.PumpASelect.PVFL", or "CM57.PID100.MODE"). In effect, tag names allow
expressions to have an unlimited number of inputs, and work with any data type.
However, do not use more than six parameter references in an expression.
Hard limit of six parameter references in an expression is not documented. In fact,
Knowledge Builder states, "In effect, tag names allow expressions to have an unlimited
number of inputs, and work with any data type." Customer is concerned that the KB
statement is extremely misleading. This issue applies to AUXCALC, ENHAUXCALC,
REGCALC, and ENHREGCALC; and releases R210 and R300.
Expression descriptor parameters (EXPRDESC[1..8]) are used with the expression
constant parameters (CONST[1..8]) for providing a short description for the expressions.
The EXPRDESC[1..8] parameter can be modified only during the strategy configuration,
and is available even if CONSTENABLE is set to “FALSE”.
The expression syntax has been expanded. Delimiters (') can be used in an expression
containing an external reference component. The format for the delimiter usage is as
follows:
• TagName.'text'
TagName is the name of the external reference component (i.e. an OPC Server). Text can
contain any characters, space, and special characters except for the delimiter character.
When entering this format, only the syntax and TagName are checked for accuracy. The
correct syntax of TagName-dot-delimiter-text-delimiter is verified and the TagName is
verified to be an external reference component. If either of these stipulations is incorrect,
an error is issued. The text between the delimiters is not checked. It is the users
responsibility to ensure that the text is something that the external reference component
will understand. If this text is incorrect, runtime errors will occur.
ATTENTION
When the expression is sent to the external reference component, the
delimiters are removed: TagName.'text' becomes TagName.text.
TIP
You can use the integer parameters YEAR, MONTH, DAY HOUR, MINUTE,
and SECOND that provide local date and time for the controller in all
expressions, just like other integer parameters.
ATTENTION
The constant values can be directly configured (using CONST[1..8]) in the
Calculator blocks and a short description for the expressions can also be
provided (using (EXPRDESC[1..8]).
The expression constant parameters (CONST[1..8]) are used with the expressions as
follows:
• An expression can be configured using the expression constants parameters
(CONST[1..8]).
Example:
CM1.CALC1.CONST[1] * CM1.CALC1.X[2] + CM2.REGCALCA.CV
Example:
CM1.CALC1.CONST[CM1.CALC1.X[1]] + CM1.CALC1.X[2]
The results of the expressions, which use the CONST [1...8] parameters, are affected if
you change the values of these parameters on the Constants tab.
Example 1
Example 2
In this case, if an input is disabled, the corresponding substitute value is used in the
expressions.
Operator Description
:= Assignment - used only in the SCM Step Output blocks to assign the
results of an expression to a reference.
Example:
Operator Description
CM.block.mystringparam := CM.desc
+ Concatenation
Example:
CM.block.mystringparam + CM.desc
= Equal to
Example:
CM.block.mystringparam = CM.desc
Example:
Time constants
You can use the following valid time constants in expressions.
• An Absolute Time constant is entered MM/DD/YYY hh:mm:ss:uuuu, where uuuu is
milliseconds
• A Delta Time constant is entered as hh:mm:ss:uuuu, where uuuu is milliseconds
• Time of Day constant is also entered as hh:mm:ss:uuuu.
Operator Description
:= Assignment - used only in the SCM Step Output blocks to assign the
results of an expression to a reference. The data type in the
expression result must agree with the data type of the reference.
+ If both operands are of the same time data type the result is the
same data type. Delta time or Time of Day can be added to an
absolute time, which results in absolute time. Time of day can be
added to delta time, which results in a delta time. See the next
section Adding time data types. .
One operand can be a delta time or time of day data type and the
second operand must be a number. The result is a delta time data
type.
=, <>, <=, Compares two operands of type time. Both operands must be of the
>=, <, > same time data type.
1
The DAY, HOURS, MINS, SECS Operators are not case specific.
• CEE01.CURRTIME + 2
• CEE01.CURRTIME > 5.0
REFERENCE - INTERNAL
Refer to Time Support in Experion LX System for more information about time
support in the system
ENHREGCALC parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the ENHREGCALC block.
Each FANOUT block supports the following user configurable attributes. The following
table lists the given name of the "Tab" in the parameter configuration form and then
briefly describes the attributes associated with that Tab. This data is only provided as a
quick document reference, since this same information is included in the on-line context
sensitive Help.
Common Output • High Limit (%) (OPHILM) - Lets you specify the output
high limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
to 500 and you enter a High Limit of 90%, the high limit
in engineering units is 90% times 450 or 405 + 50
(CVEULO) equals 455. This check is not applied for a
function block that is in the MANual mode. The default
value is 105%.
• Low Limit (%) (OPLOLM) - Lets you specify the output
low limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
to 500 and you enter a Low Limit of 10%, the low limit in
engineering units is 10% times 450 or 45 + 50
(CVEULO) equals 95. This check is not applied for a
function block that is in the MANual mode. The default
value is -5%.
• Extended High Limit (%) (OPEXHILM) - Lets you specify
the output extended high limit as a percent of the
Calculated Variable range (CVEUHI - CVEULO). For
Individual Output • Gain (K[1..8]) - Lets you specify a gain (K) value to be
factored into the equation for calculating the CV output
value for each individual output. See the equation
following this table for details. The default value is 1.
• Output Bias (OPBIAS[1..8].FIX) - Lets you specify a fixed
bias value in engineering units that is added to the
Calculated Variable (CV) output value for each individual
output. See the Output Bias section for this function
block for details. The default value is 0, which means no
value is added.
• Output Bias Rate (OPBIAS[1..8].RATE) - Lets you
specify an output floating bias ramp rate in engineering
units per minute for each individual output. This bias rate
is only applied when the floating bias is non-zero. See
the Output Bias section for this function block for details.
The default value is Not a Number (NaN), which means
no floating bias is calculated. As a result, if the primary
does not accept the block's initialization value, a bump in
OP occurs.
• Enable Secondary Initialization Option
(SECINITOPT[1..8]) - Lets you specify if the block is to
ignore initialization and override requests from the
secondary or not for each individual output. The default
selection is Enabled (checked, do not ignore).
R110 − Disable
Experion LX Control Builder –Components
An alarm is Theory 297
not notified whenever a mode
February 2014 Honeywell
shed happens in the event of an IO communication
loss.
Note: This parameter is available for configuration only if
the Enable Bad Output Connection Option is enabled.
13. Regulatory Control
13.6. FANOUT Block
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
Control Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Each output value (CV [1..8]) is calculated using the following equation:
CV(n) = X1 K(n) + [OPBIAS(n).FIX + OPBIAS(n).FLOAT]
where:
X1 = input value
• A separate gain [K(n)] and bias [OPBIAS(n).FIX] may be specified for each output.
• K(n) and OPBIAS(n).FIX may either be fixed (that is, stored manually or by the
program) or external (that is, brought from another block). You can specify a
different gain and fixed bias value for each output.
• The FANOUT block applies a separate floating bias to each output.
• The OP% is the CV expressed as a percentage of the CV range for that secondary.
The values for CVEUHI and CVEULO are set to be the same as the values for
PVEUHI and PVEULO for the secondary. The PVEUHI and PVEULO values are in
turn input by the user.
After an initialization, the block calculates OPBIAS(n).FLOAT for each output as:
OPBIAS(n).FLOAT = CVINIT(n) - [K(n) X1 + OPBIAS(n).FIX]
where:
ATTENTION
The FANOUT block is the only Regulatory Control Block that can have
multiple secondaries.
Function
The FANOUT block provides a "bumpless" output for each of up to eight outputs
following initialization or mode changes.
Configuration example
See the previous Example of CB configuration using AUTOMAN block. figure for an
example of a FANOUT block being used to provide multiple outputs from a single PID
block.
Inputs
The FANOUT block requires one input - X1:
• X1 = initializable input which must come from another block (it cannot be set by an
operator or a program).
• You must specify an engineering unit range (XEUHI and XEULO) for X1. The
block applies no range check. It assumes that X1 is within the specified range.
• XEUHI and XEULO define the full range of X1:
− XEUHI represents the 100% of full scale value.
− XEULO represents the 0% of full scale value.
ATTENTION
The FANOUT block:
Outputs
The FANOUT block may have up to 8 initializable outputs as follows:
• OP[1..8] - calculated output, in percent.
• OPEU[1..8] - calculated output, in engineering units.
Output ranges
• CVEUHI[1..8] and CVEULO[1..8] define the full range of CV in engineering units
for each given output.
− The FANOUT block does separate ranging for each output by maintaining a
separate CV range for each output which tracks the input range of the
corresponding secondary.
− The CV range for each output must be the same as the input range of each
secondary. The FANOUT block brings the input range from each secondary
(through BACKCALC) and stores it as the corresponding CV range. As a
result, each output may have a different CV range. For example, a FANOUT
block has its outputs OP[1] and OP[2] connected to blocks PID1 and PID2,
respectively. It brings the input ranges of PID1 and PID2 and sets its CV ranges
of OPX[1] and OPX[2] to these input ranges, respectively.
− The FANOUT block brings the secondary's input range regardless of
SECINITOPT (that is, regardless of whether the secondary's initialization and
override data will be used).
• OPHILM and OPLOLM define the normal high and low limits for OP as a percent
of the CV range. These are user-specified values. The same limits apply to all
outputs.
Output bias
The output bias (OPBIAS) is added to the algorithm's Calculated Value (CV) and the
result is stored in CV. CV is later checked against OP limits and, if no limits are
exceeded, it is copied to the output. Since the FANOUT block can have up to eight
outputs, a separate output bias is determined for each output. This means that the
parameters referenced in this discussion are actually indexed to the given output. For
example, OPBIAS[1] and CV[1] are indexed to OP[1], and so on for the other seven
outputs numbered 2 to 8.
The OPBIAS is the sum of the user-specified fixed bias (OPBIAS.FIX) and a calculated
floating bias (OPBIAS.FLOAT). The purpose of the floating bias is to provide a
bumpless transfer when the function block initializes or changes mode as long as the
FANOUT block is the first initializable block.
• OPBIAS is recomputed under the following conditions to avoid a bump in the
output. (Note that the function block only applies OPBIAS.FLOAT to the output for
the later two conditions, when it is the first initializable block.)
− When the function block starts up (that is, it is Active).
− When the function block initializes (for example, the secondary requests
initialization).
− When the mode changes to Cascade (as applicable for the given block).
• The following occurs when you set the OPBIAS value.
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the
entered value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
ATTENTION
When the function block goes Active or the Mode changes to Cascade (as
applicable for the given block), OPBIAS and OPBIAS.FLOAT are
recomputed.
• There are no limit checks applied when you set an OPBIAS or OPBIAS.FIX value.
However, after the total bias is added to CV, the result is compared against the
output limits and clamped, if necessary.
• You configure the value for the fixed bias (OPBIAS.FIX) and it is never overwritten
by the floating bias (OPBIAS.FLOAT). This means the total bias will eventually
equal the OPBIAS.FIX , if you configure OPBIAS.RATE to ramp down
OPBIAS.FLOAT.
• You may store it to OPBIAS.FIX only if the function block is inactive or the MODE
is Manual; or if it is a PID or PIDFF function block with the CTLEQN is set to E.
When you store to OPBIAS.FIX, the following occurs:
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the new
value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
The OPBIAS.FLOAT is calculated as follows.
Where:
If OPBIAS.FLOAT is not zero, you can configure it to ramp down to zero through
the OPBIAS.RATE parameter.
Where:
− NaN:
When the OPBIAS.RATE is Not a Number (NaN), no OPBIAS.FLOAT is
calculated. This means a bump in the output will occur, if the primary does not
accept this block's initialization value.
Mode handling
The FANOUT block supports both the Cascade and Manual modes:
• If mode is CAScade, then: X1 must be pulled from another block.
• If mode is MANual, then: OP may be stored by the operator or a user-program
(X1 is ignored).
Timeout monitoring
If mode is CAScade, the FANOUT block performs timeout monitoring on X1. If the X1
value is not updated within a predefined time (TMOUTTIME), the FANOUT block
invokes timeout processing as follows:
• Sets the "input timeout" flag (TMOUTFL).
ATTENTION
If the input is from a connection in another controller in a peer-to-peer
architecture, the actual timeout time equals the configured TMOUTTIME and
the CDA timeout time. The CDA timeout time equals four times the configured
CEE subscription rate. For example, if the CEE subscription rate is 100
milliseconds and the TMOUTTIME is 5 seconds, the actual timeout time for
the block is 4 times 100ms plus 5s or 5.4 seconds.
Control initialization
The FANOUT block brings initialization requests from its secondary through
BACKCALC. In addition, the secondary may propagate one-shot initialization requests
to the FANOUT block.
If all secondaries are requesting initialization and the SECINITOPT for corresponding
outputs is enabled, the FANOUT block -
− Initializes its output so CV[1..8] = INITVAL[1..8] from corresponding
secondary
• Builds an initialization request for the primary as follows:
INITREQ(X1) = On
CV - OPBIAS(last).FIX
INITVAL(X1) =
K(last)
− Where:
CV calculated value
ATTENTION
• SECINITOPT may be used to ignore initialization requests from selected
secondaries.
− Where:
BACKCALC processing
BACKCALC contains initialization, windup, and range data from each secondary. The
FANOUT block always uses the secondary's windup status and range data, and you may
specify whether to ignore initialization through the SECINITOPT parameter. There is 1
SECINITOPT per secondary.
Since initialization and windup data may be received from multiple secondaries, the
FANOUT block applies the following rules to decide what it should propagate from its
secondaries:
c) Initialization is propagated only if all secondaries are requesting it. The FANOUT
block uses the initialization value from the last secondary to request it.
SECINITOPT may be used to ignore initialization requests from selected
secondaries.
d) Refer to Windup Processing below.
ATTENTION
While the Fanout block contains multiple outputs, it has only one main output,
so only one OUTIND parameter will be supported on the block.
You choose from the following configuration selections to tailor the block's output to
meet your particular operation and display requirements.
ATTENTION
The OUTIND parameter has no affect on the block's control operation. The
CTLACTN parameter on the Algorithm tab supports the output direction of the
block, the OPTDIR parameter on the Main tab for the AOCHANNEL block
form applies the conversion of OP to OPFINAL. You can manipulate the
DIRECT/REVERSE selections for the OUTIND, CTLACTN, and OPTDIR
parameters to meet your process and operator needs.
OP 100.0 - Actual OP
The user store of an OP related parameter is intercepted and reversed when OUTIND
equals REVERSE. For example, a store of OPHILM = 80 produces OPLOLM = 100 -
80, so the OPHILM parameter will then view OPHILM = 100 - 20.
ATTENTION
The swapping/reversal of values will not be done, if the block was loaded with
REVERSE OUTIND configured. The reversal of values will be done only on a
subsequent change to the OUTIND value, if appropriate.
For example: If a PID block is loaded with OPHILM = 95, OPLOLM = 10 and
OUTIND as REVERSE, the OPHILM and OPLOLM after load will still be 95
and 10, respectively.
OP Alarms considerations
When the OUTIND parameter value is set to REVERSE, the OP values displayed for the
high or low CEE Output Alarms are reversed. In the Alarm Summary display, the OP
values of the high alarms and the low alarms are swapped. The Output Alarms display
shall track the value of displayed output parameters. An OUTIND value of REVERSE,
shall show the limit and value subjected to reversal. For example, an OPHI alarm will
have the displayed trip limit set to 100 - (output low limit).
If the OUTIND parameter setting is changed:
• from Direct, DirectDispInd, or ReverseDispInd to Reverse or
• from Reverse to Direct, DirectDispInd, or ReverseDispInd,
a return for the existing Output Alarm condition occurs and a new Output Alarm would
be sent.
• If all secondaries are in low windup, the FANOUT block propagates a low windup
status to its primary (ARWAY = Lo).
Note that if the gain is reversed for one of the outputs, then high windup on that output is
the same as low windup on the others.
The FANOUT block propagates a normal windup status to its primary under the
following conditions:
• If at least one secondary has a normal windup status.
• If at least one secondary is in Hi windup and another is in Lo.
Note that the FANOUT block checks the windup status from all secondaries, regardless
of SECINITOPT selection.
ARWOP computation
The ARWOP indicates if the output (OP) can be raised or lowered. The PID-type
function blocks use ARWOP to restrict integral control. When ARWOP contains a value
other than Normal, the PID block stops integral control in the windup direction. Integral
control continues in the other direction, as the proportional and derivative control. But,
windup status has no impact on proportional and derivative control.
If a function block has a secondary, it fetches the secondary's windup status and
recomputes its ARWOP. The conditions within the function block, such as output being
at its high limit, also affect the ARWOP. The ARWOP is computed as follows, assuming
the block has only one output or that it is not a FANOUT block.
ARWNET computation
When ARWNET is HiLo, stores to SP are not limited, rather this is the status propagated
to the primary. The only limiting anti-reset windup status does is to stop integral action in
one or both directions on PID blocks. For any other regulatory control type block,
ARWNET is not used for any kind of limiting. The ARWNET is computed as follows,
assuming the block has only one output or that it is not a FANOUT block.
The CV is NaN
NORMAL HI HI
NORMAL LO LO
HI NORMAL HI
HI HI HI
HI LO HILO
HI HILO HILO
LO NORMAL LO
LO HI HILO
LO LO LO
LO HILO HILO
HILO HI HILO
HILO LO HILO
FANOUT parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the FANOUT block.
Each OVRDSEL block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that Tab. This data is only provided
as a quick document reference, since this same information is included in the on-line
context sensitive Help.
Input • High Limit (XEUHI) - Lets you specify the high input
range limit that represents 100% full scale input for all
the block inputs (X[1..4]). The default value is 100.
• Low Limit (XEULO) - Lets you specify the low input
range limit that represents the 0 full scale input for all the
block inputs (X[1..4]). The default value is 0 (zero).
• Enable Input Bypassing (ORBYPPERM) - Lets you
specify whether or not an operator can explicitly bypass
(ignore) any input to the block. The default selection is
disabled (unchecked or OFF), which means an operator
cannot bypass any input.
• Timeout Time (TMOUTTIME) - Lets you specify a time in
seconds that must expire before the block assumes that
its input update has timed out. The block must be in
Output • High Limit (%) (OPHILM) - Lets you specify the output
high limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
to 500 and you enter a High Limit of 90%, the high limit
in engineering units is 90% times 450 or 405 + 50
(CVEULO) equals 455. This check is not applied for a
function block that is in the MANual mode. The default
value is 105%.
• Low Limit (%) (OPLOLM) - Lets you specify the output
low limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
to 500 and you enter a Low Limit of 10%, the low limit in
engineering units is 10% times 450 or 45 + 50
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
Control Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Insertion Type Lets you include an insertion type from a CAB instances in
the block. See CAB insertion configuration considerations
for regulatory control blocks for more information
Function
This block always forces the unselected inputs to track the selected input by enabling the
override feedback option. You select the override option by setting the parameter
OROPT to ON or by selecting the Enable Override Option check box on the block's
parameter configuration form.
If OROPT is . . . Then, . . .
Step Action
Step Action
2 The cascade executes as normal, where each block fetches its input and
performs its normal algorithm calculation.
As previously stated, this block "provides" override feedback data to every block in an
upstream cascade. It doesn't matter how many blocks are upstream, or whether they are
on-node or off. However, the keyword here is "provides" because it may take several
execution cycles for the data to reach the furthest block. The OVRDSEL block will
propagate the data to a limited number of on-node blocks. (See limitations below.)
When it reaches that limit, it will interrupt the propagation and pass the data to the next
upstream block through BACKCALC. When the upstream block fetches BACKCALC,
it detects that override propagation was interrupted, and resumes propagating (subject to
the same limitations).
Limitations:
• For a given input path, propagation stops at a block that is inactive.
• For a given path, propagation is interrupted at a block with an off-node primary. The
primary resumes propagation on its next execution cycle.
• For a given path, propagation is interrupted after five upstream blocks. The sixth
block resumes propagation on its next execution cycle.
Example: Assume an OVRDSEL block has four inputs, where one input is a cascade of
nine upstream blocks, and each of the others is a cascade of four upstream blocks. Also,
assume that all of the blocks are on-node. Then, the OVRDSEL block will propagate to
the first five blocks in the first cascade, and to every block in the other cascades. The
next time the sixth block runs, it will bring BACKCALC from the fifth, determine that
propagation was interrupted, and resume propagation to the remaining blocks in that
cascade.
ATTENTION
The system's ability to interrupt and resume override propagation has
advantages and disadvantages.
If you have an override strategy where all blocks must have their override
data in sync, then that strategy must be on the same node, and have no more
than five blocks in each input cascade.
This block provides a bypass flag for each input, which allows the operator, another
function block, or a user program to exclude any input from being selected. Inputs may
be bypassed regardless of whether OROPT is On or Off.
This block provides bumpless switching by applying a floating bias to the output,
regardless of whether OROPT is On or Off.
Configuration example
The following figure and its companion callout description table show a sample
configuration that uses an OVRDSEL block to provide override feedback data to
upstream PID blocks for quick reference.
Callout Description
1 Use the PV parameter connection to carry data from the analog input to the
PID block. The default PV connection is exposed, but the implicit/hidden
connection function automatically makes a connection to a value/status
parameter (PVVALSTS) when it is required.
Callout Description
3 The Enable Override Option (OROPT) is selected for the OVRDSEL block.
This means that the Not Selected primary PID's output is initialized to the
same value as the Selected PID's output. You must configure the OP
parameter to appear on the faceplate of the block through the Monitoring
Parameters tab in the block configuration form.
5 You can configure the OVRDSEL block to select the lower of the two
primary inputs by selecting Equation B or the higher of two inputs by
selecting Equation A.
Configuration considerations
Keep the following considerations in mind when configuring control strategies using
OVRDSEL blocks.
• When possible, load control strategies using OVRDSEL blocks in the same CEE.
Only the most downstream OVRDSEL block in the cascade propagates the override
feedback value to its primaries. When this strategy is in the same CEE, the
propagation of override feedback value to the unselected primaries of an OVRDSEL
block takes place in one execution cycle of the block. The means the override
feedback value and other feedback data are the most recent values.
• In any control strategy that includes OVRDSEL blocks, the sequence of execution
of all blocks is very important. All the primaries should run before the OVRDSEL
block that propagates the feedback gets a chance to execute. This another reason for
loading control strategies that include OVRDSEL blocks in the same CEE. The
following configuration scenarios outline some typical execution settings for
reference.
− If all the blocks are contained in the same Control Module, all the primaries
should execute before the OVRDSEL block does. This means the
ORDERINCM parameter of the OVRDSEL block must be larger than the
corresponding number for all its primaries. For example, if Control Module
CM01 has blocks PID01, PID02, PID03, PID04, and OVRDSEL05, the
suggested settings for the ORDERINCM parameter are PID01.ORDERINCM <
PID02.ORDERINCM < PID03.ORDERINCM < PID04.ORDERINCM <
OVRDSEL05.ORDERINCM.
− If primaries are residing in different Control Modules within the same CEE, the
previous scenario still applies for the Control Module containing the OVRDSEL
block. Plus, the ORDERINCEE parameter setting for the Control Modules that
contain other primaries should be smaller than the ORDERINCEE parameter
for the Control Module that contains the OVRDSEL block. For example, if
Control Module CM01 contains a PID cascade loop with an OVRDSEL block
and Control Modules CM02 and CM03 contain other primaries of the
OVRDSEL block, the suggested settings for the ORDERINCEE parameter are
CM01.ORDERINCEE > CM02.ORDERINCEE > CM03.ORDERINCEE.
− The strategy includes a cascade loop with an OVRDSEL block that propagates
only 5 on-node regulatory control blocks in its one execution cycle. The
propagation then continues through the BACKCALC connection , when the
primary runs the next time. The override feedback value could be old for any
primaries that are off-node or beyond the limit of 5.
R110 Experion LX Control Builder Components Theory 331
February 2014 Honeywell
13. Regulatory Control
13.7. OVRDSEL (Override Selector) Block
Inputs
The OVRDSEL block accepts one to four inputs - X[1] through X[4]. It requires at least
two inputs, but they can be any of the four.
• X[1] through X[4] are initializable inputs.
• The inputs must be pulled from other function blocks; you cannot store to them.
• This block may have two to four primaries, depending on the number of inputs that
are configured. (There is one primary per initializable input.)
Input ranges
XEUHI and XEULO define the full range of inputs.
• XEUHI represents the 100% of full scale value.
• XEULO represents the 0% of full scale value.
This block assumes that all X-inputs are within XEUHI and XEULO. It applies no range
checks.
Input descriptors
You can define descriptor (name) of up to 15-characters for each input. The descriptors
reside in the XDESC parameter, and when an input is selected, the corresponding
descriptor is copied to SELXDESC.
When SELXINP is updated, then SELXDESC is automatically updated.
Initializable outputs
"Initializable output" and "initializable input" are variable attributes, similar to data type
or access level. A parameter with the "initializable" attribute has an associated
BACKCALC parameter, and when you create a connection between an initializable input
and initializable output, you can also create a BACKCALC connection. Control Builder
automatically builds the required BACKCALC connections, so you don't have to create
them manually. These "implicit" build connections are "hidden" from view and the
related parameter pins are not exposed on the control chart.
For example, if you connect OP from a PID block to an OVRDSEL block or an
AOCHANNEL block, Control Builder automatically creates the BACKCALCOUT to
BACKCALCIN connection.
The OVRDSEL block has the following initializable outputs:
332 Experion LX Control Builder Components Theory R110
Honeywell February 2014
13. Regulatory Control
13.7. OVRDSEL (Override Selector) Block
ATTENTION
This block fetches the secondary's input range regardless of SECINITOPT
(i.e., regardless of whether the secondary's initialization and override data will
be used).
• OPHILM and OPLOLM define the normal high and low limits for OP, as a percent
of the CV range. These are user-specified values.
− OP will be clamped to these limits if the algorithm's calculated result (CV)
exceeds them, or another function block or user program attempts to store an
OP value that exceeds them. However, the operator may store an OP value that
is outside these limits.
• OPEXHILM and OPEXLOLM define the extended high and low limits for OP, as a
percent of the CV range. These are user-specified values.
− The operator is prevented from storing an OP value that exceeds these limits.
• OPTOL allows the user to configure a tolerance limit for the manually entered OP.
If the difference between the new OP value and the current OP value is greater than
OPTOL, then confirmation is required from the user to store this new value.
ATTENTION
The OUTIND parameter has no affect on the block's control operation. The
CTLACTN parameter on the Algorithm tab still supports the output direction of
the block, the OPTDIR parameter on the Main tab for the AOCHANNEL block
form applies the conversion of OP to OPFINAL. You can manipulate the
DIRECT/REVERSE selections for the OUTIND, CTLACTN, and OPTDIR
parameters to meet your process and operator needs.
OP 100.0 - Actual OP
The user store of an OP related parameter is intercepted and reversed when OUTIND
equals REVERSE. For example, a store of OPHILM = 80 produces OPLOLM = 100 -
80, so the OPHILM parameter get will then view OPHILM = 100 - 20.
ATTENTION
The swapping/reversal of values will not be done, if the block was loaded with
REVERSE OUTIND configured. The reversal of values will be done only on a
subsequent change to the OUTIND value, if appropriate.
For example: If a PID block is loaded with OPHILM = 95, OPLOLM = 10 and
OUTIND as REVERSE, the OPHILM and OPLOLM after load will still be 95
and 10, respectively.
OP Alarms considerations
When the OUTIND parameter value is set to REVERSE, the OP values displayed for the
high or low CEE Output Alarms are reversed. In the Alarm Summary display, the OP
values of the high alarms and the low alarms are swapped. The Output Alarms display
shall track the value of displayed output parameters. An OUTIND value of REVERSE,
shall show the limit and value subjected to reversal. For example, an OPHI alarm will
have the displayed trip limit set to 100 - (output low limit).
If the OUTIND parameter setting is changed:
• from Direct, DirectDispInd, or ReverseDispInd to Reverse or
• from Reverse to Direct, DirectDispInd, or ReverseDispInd,
a return for the existing Output Alarm condition occurs and a new Output Alarm would
be sent.
Mode handling
This function block supports the Cascade and Manual modes.
If MODE is . . . Then, . . .
The initialization request occurs when the MODE changes from CAScade to MANual,
but not from MANual to CAScade.
Timeout monitoring
If MODE is CAScade, this block performs timeout monitoring on all inputs (X[1..4])
that are not bypassed. (See Bypass Processing paragraph below.) If an input value is not
updated within a predefined time (TMOUTTIME), the block invokes timeout processing.
The maximum time between updates is specified by TMOUTTIME (in seconds)
Timeout processing
This function block only performs timeout monitoring on inputs that are not bypassed.
(See Bypass Processing paragraph below.)
If MODE is CAScade and an input times out, this block does the following :
• Sets the "input timeout" flag (TMOUTFL)
• Sets the input value to Bad (NaN).
• Requests the input's primary to initialize
This block does not support mode shedding on timeout.
ATTENTION
If the input is from a connection in another controller in a peer-to-peer
architecture, the actual timeout time equals the configured TMOUTTIME plus
the CDA timeout time. The CDA timeout time equals four times the configured
CEE subscription rate. For example, if the CEE subscription rate is 100
milliseconds and the TMOUTTIME is 5 seconds, the actual timeout time for
the block is 4 times 100ms plus 5s or 5.4 seconds.
Bypass processing
You may explicitly bypass (ignore) any input. The primary will initialize if it is
bypassed. The following parameters support this:
• ORBYPASSFL[1..4] - Override Bypass Flags. A flag for each input; used to specify
which inputs should be bypassed. If a flag is set, the corresponding input is not used
in the selection process. If all bypass flags are set, this block holds CV at its last
value. This block uses the bypass flags regardless of whether OROPT is ON or OFF.
• ORBYPPERM- Override Bypass Enable. Indicates if the operator is allowed to
bypass inputs.
Equations
The OVRDSEL block selects one of the inputs according to the following user-selected
equations:
• Equation A - select the highest of the non-bypassed inputs:
This block stores the number of the selected input in parameter SELXINP, and sets or
resets the input selection flags SELXFL(1..4). There is one selection flag per input; ON
means the input was selected, and Off means it was not.
This block compares the currently selected input against the other inputs. In the case of
equal values, the current input remains the selected input. For example, assume that
X[2] and X[3] have the same value and X[3] is the selected input. If that value is
selected, the selected input remains X[3].
Input switching
This block provides bumpless switching by applying a floating bias to the output,
regardless of whether OROPT is On or Off.
Output bias
− The function block ramps the OPBIAS.FLOAT to zero by applying the
following calculation each time it executes.
Where:
− NaN:
When the OPBIAS.RATE is Not a Number (NaN), no OPBIAS.FLOAT is
calculated. This means a bump in the output will occur, if the primary does not
accept this block's initialization value.
Bad CV processing
If the selected input is bad and MODE is Cascade, this block does the following:
• sets CV to Bad (NaN)
• sets the Bad Control flag (BADCTLFL)
When the selected input returns to normal, this block does the following:
Control initialization
This block brings initialization requests from its secondary through BACKCALC. In
addition, the secondary may propagate one-shot initialization requests to this block.
You can use SECINITOPT to ignore initialization requests from the secondary.
If the secondary is requesting initialization, this block:
• initializes its output:
Value Sent to
• Override feedback value: The OVRDSEL block sends its current CV to each of its
primaries.
− The CV is clamped to OPHILM if it is greater than OPHILM and to OPLOLM if
it is less than OPLOLM.
• Override offset flag: This flag only applies to upstream PIDs; it indicates if the PID
should apply a calculated offset to the override feedback value.
− If the offset flag is Off, the PID doesn't apply an offset; it initializes its CV as
follows:
CV = override feedback value
− If the offset flag is On, the PID applies an offset; it initializes its CV as follows:
CV = (override feedback value) + Gain (PVP - SPP) for direct control action.
CV = (override feedback value) - Gain (PVP - SPP) for reverse control
action.
− è Gain (PVP - SPP) < 0.0 and the downstream OVRDSEL block is a Low
selector.
Windup processing
Every regulatory control type block maintains anti-reset windup status for its output
(ARWOP) and each of its initializable inputs (ARWNET). The following table lists the
possible values for ARWOP and ARWNET parameters.
ARWOP computation
The ARWOP indicates if the output (OP) can be raised or lowered. The PID-type
function blocks use ARWOP to restrict integral control. When ARWOP contains a value
other than Normal, the PID block stops integral control in the windup direction. Integral
control continues in the other direction, as does proportional and derivative control. But,
windup status has no impact on proportional and derivative control.
If a function block has a secondary, it fetches the secondary's windup status and
recomputes its ARWOP. The conditions within the function block, such as output being
at its high limit, also affect the ARWOP. The ARWOP is computed as follows, assuming
the block has only one output or that it is not a FANOUT block.
ARWNET computation
When ARWNET is HiLo, stores to SP are not limited, rather this is the status propagated
to the primary. The only limiting anti-reset windup status ever does is to stop integral
action in one or both directions on PID blocks. For any other regulatory control type
R110 Experion LX Control Builder Components Theory 343
February 2014 Honeywell
13. Regulatory Control
13.7. OVRDSEL (Override Selector) Block
block, ARWNET is not used for any kind of limiting. The ARWNET is computed as
follows, assuming the block has only one output or that it is not a FANOUT block.
The CV is NaN
NORMAL HI HI
NORMAL LO LO
HI NORMAL HI
HI HI HI
HI LO HILO
HI HILO HILO
LO NORMAL LO
LO HI HILO
LO LO LO
LO HILO HILO
HILO HI HILO
HILO LO HILO
OVRDSEL parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the OVRDSEL block.
The PID block has two analog inputs - a process variable (PV) and a set point (SP). The
difference between PV and SP is the error and this block calculates a control output (OP)
that should drive the error to zero.
The following equations are supported:
• Proportional, Integral, and Derivative (PID) on the error
• Proportional and Integral (PI) on the error and Derivative (D) on changes in PV
• Integral (I) on the error and Proportional and Derivative (PD) on changes in PV
F
Fuel Flow Temperature
Controller Controller
PV PV
OP SP OP SP
Each PID block supports the following user configurable attributes. The following table
lists the given name of the "Tab" in the parameter configuration form and then briefly
describes the attributes associated with that Tab. This data is only provided as a quick
document reference, since this same information is included in the on-line context
sensitive Help.
SetPoint • SP (SP) - Lets you specify an initial set point value. The
default value is 0.
• High Limit (SPHILM) - Lets you specify a high limit value
for the SP. If the SP value exceeds this limit, the block
clamps the SP to the limit value and sets the SP high
flag (SPHIFL). The default value is 100.
• Low Limit SPLOLM) - Lets you specify a low limit value
for the SP. If the SP value falls below this limit, the block
clamps the SP to the limit value and sets the SP low flag
(SPLOFL). The default value is 0.
• Mode (TMOUTMODE) - Lets you select the desired
MODE the block is to assume, if an initializable input
times out, which means the input has not been updated
within a designated timeout time. The selections are
AUTOmatic, BCAScade, CAScade, MANual, NONE, and
NORMAL. The default selection is MANual.
• Time (TMOUTTIME) - Lets you specify a time in
seconds that must expire before the block assumes that
its input update has timed out. The block must be in
CAScade mode for it to monitor its primary input for
timeout. The default setting is 0, which means the
timeout function is disabled.
If the input is from a connection in another controller in a
peer-to-peer architecture, the actual timeout time equals
the configured TMOUTTIME plus the CDA timeout time.
The CDA timeout time equals four times the configured
CEE subscription rate. For example, if the CEE
subscription rate is 100 milliseconds and the
TMOUTTIME is 5 seconds, the actual timeout time for
the block is 4 times 100ms plus 5s or 5.4 seconds.
• Enable Advisory SP Processing (ADVDEVOPT) - Lets
you specify whether or not the block is to generate a
deviation alarm when the PV deviates from a user
specified "advisory" SP value. The default selection is
unchecked (Disabled).
• Advisory SP Value (ADVSP) - Lets you set an advisory
SP value in PV engineering units, when Advisory SP
Processing is enabled. When PV exceeds or deviates
from this value, the block generates an advisory
deviation alarm.
Output • High Limit (%) (OPHILM) - Lets you specify the output
high limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
to 500 and you enter a High Limit of 90%, the high limit
in engineering units is 90% times 450 or 405 + 50
(CVEULO) equals 455. This check is not applied for a
356 Experion LX Control Builder Components Theory R110
Honeywell February 2014
13. Regulatory Control
13.8. PID Block
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
Control Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Insertion Type Lets you include an insertion type from a CAB instances in
the block. See CAB insertion configuration considerations
for regulatory control blocks for more information
Function
A PID requires two inputs - a process variable (PV) and a set point (SP):
• PV is pulled from another function block.
PV is typically pulled from a Data Acquisition (DATAACQ) function block which
performs PV limit checking and alarming.
• SP is pulled from another function block, or stored by the operator or a user
program.
If SP is pulled from a primary, the PID's Mode must be Cascade; and if it is stored
by the operator or a user program, Mode must be Manual or Automatic. If Mode is
Cascade, the PID must perform timeout checking on SP (to make sure the primary is
periodically updating it).
A PID also has the following optional inputs. Typically, these are flags which may be
stored by the operator or user program to change the normal operation of the PID.
• ESWAUTO, ESWCAS, ESWMAN and SI - Indicates if an external source, such as
a user program, wants to change the PID's Mode:
− If ESWAUTO = On, the external source wants to change the Mode to Auto.
− If ESWCAS = On, the external source wants to change the Mode to Cascade.
− If ESWMAN = On, the external source wants to change the Mode to Manual.
− If SI = On, the external source wants to invoke the PID's safety interlock logic.
If a BACKCALC connection is made to the secondary, the PID reads BACKCALCIN
from the secondary before calculating its OP:
• BACKCALCIN is a "data container", which means it contains many pieces of
information but is accessed by a single read. Among other things, the information in
BACKCALCIN indicates if the secondary is wound-up or if it wants the PID to
initialize.
• The individual BACKCALCIN/BACKCALCOUT connections for each output used
are automatically built by Control Builder as implicit/hidden connections. This
Functional scenario
This scenario is based on the functional block diagram of a typical cascade loop shown
in the following figure and it assumes the following:
• The PID2's Mode is Cascade. As a result, SP is pulled from a primary (PID1), and
the PID2 must perform timeout checking on it.
• Both PID1 and 2 pull PV from Data Acquisition (DATAACQ) function blocks as
shown in following figure.
• The PID1 has an active output. As a result, it reads BACKCALCIN from and
provides OP to the secondary (PID2).
• The PID2 will never be wound-up, and never request the PID1 to initialize. In
addition, the PID1 will never be wound-up, and never request its SP to initialize.
• The PV, SP and OP connections are all good which means there are no
communication errors or timeouts.
PV OP
DATAACQ Secondary BACKCALCOUT
P1 PV SP PID2
DATAACQ Typically goes to
P1 PV PV OP Analog Output
Channel FB
The functional steps associated with this PID operating scenario are listed in the
following table.
Step Action
1 The PID1 provides a value to the PID2 SP variable (before the PID1
executes).
3 The PID2 performs timeout checking on SP (to make sure the variable has
been updated). The SP timeout value is configurable.
4 The PID1 checks PVSOURCE and decides whether or not to fetch PV. If
PVSOURCE = Auto, it brings PV from the DATAACQ; otherwise, it simply
uses the current value of PV.
6 The PID1 reads BACKCALCIN from the secondary, and decides if windup or
initialization processing is required. The BACKCALOUT to BACKCALIN
connection is hidden.
9 The PID1 performs limit checking and alarming (if required) on OP.
Configuration examples
• Single PID Loop: The following figure and its companion callout description table
show a sample configuration that uses a PID block to form a single control loop for
The following table includes descriptions of the callouts in the figure above.
Callout Description
1 Use the PV parameter connection to carry data from the analog input to the
PID block. The default PV connection is exposed, but the implicit/hidden
connection function automatically makes a connection to a value/status
parameter (PVVALSTS) when it is required.
Callout Description
3 Use the OP parameter connection to send output data to the Analog Output
Channel (AOC) block. The default OP connection is exposed, but the
implicit/hidden connection function automatically makes a connection to a
value/status parameter (OPX/OPEUX) when it is required.
• Cascade PID Loop: The following figure and its companion callout description table
show a sample configuration that uses two PID blocks to form a cascade control
loop for quick reference. The view in the following figure depicts a loaded
configuration in Monitoring mode.
The following table includes descriptions of the callouts in the figure above.
Callout Description
Callout Description
1 Use the PV parameter connection to carry data from the analog input to the
PID block. The default PV connection is exposed, but the implicit/hidden
connection function automatically makes a connection to a value/status
parameter (PVVALSTS) when it is required.
See the description for Callout 2 in the table for the previous figure
(Example of CB configuration using a PID block for single loop control.) for
more detailed information about the elements that make up the secondary
data.
Required inputs
The required number of inputs is determined by the mode of the PID block.
R110 Experion LX Control Builder Components Theory 369
February 2014 Honeywell
13. Regulatory Control
13.8. PID Block
Initializable outputs
"Initializable output" and "initializable input" are variable attributes, similar to data type
or access level. A variable with the "initializable" attribute has an associated
370 Experion LX Control Builder Components Theory R110
Honeywell February 2014
13. Regulatory Control
13.8. PID Block
ATTENTION
Be sure you use a FANOUT block to make multiple output connections. We
recommend that you do not make multiple connections from a single PID
output.
Control initialization
The PID block brings initialization requests from its secondary through BACKCALC. In
addition, the secondary may propagate one-shot initialization requests to this block.
• Note that SECINITOPT may be used to ignore initialization requests from the
secondary.
• If the secondary is requesting initialization, the PID block:
− initializes its output
CV = initialization value from the secondary
Output bias
If the PID block algorithm is configured as Equation E, the output bias (OPBIAS) is
added to the algorithm's Calculated Value (CV) and the result is stored in CV. CV is later
checked against OP limits and, if no limits are exceeded, copied to the output.
If the PID block algorithm is configured as Equation A, B, C, or D, no output bias
(OPBIAS) is applied.
The OPBIAS is the sum of the user-specified fixed bias (OPBIAS.FIX) and a calculated
floating bias (OPBIAS.FLOAT). The purpose of the floating bias is to provide a
bumpless transfer when the function block initializes or changes mode as long as the PID
block is the first initializable block.
• OPBIAS is recomputed under the following conditions to avoid a bump in the
output. (Note that the PID block only applies OPBIAS.FLOAT to the output for the
latter two conditions, when it is the first initializable block.)
− When the function block starts up (that is, goes Active).
− When the function block initializes (for example, the secondary requests
initialization).
− When the mode changes to Auto or Cascade.
• The following occurs when you set the OPBIAS value.
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the
entered value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
ATTENTION
When the function block goes Active or the Mode changes to Auto or
Cascade, OPBIAS and OPBIAS.FLOAT are recomputed.
• There are no limit checks applied when you set an OPBIAS or OPBIAS.FIX value.
However, after the total bias is added to CV, the result is compared against the
output limits and clamped, if necessary.
• You configure the value for the fixed bias (OPBIAS.FIX) and it is never overwritten
by the floating bias (OPBIAS.FLOAT). This means the total bias will eventually
equal the OPBIAS.FIX , if you configure OPBIAS.RATE to ramp down
OPBIAS.FLOAT.
• You may store to OPBIAS.FIX only if the function block is inactive or the MODE is
Manual; or if it is a PID or PIDFF function block with the CTLEQN set to E. When
you store to OPBIAS.FIX, the following occurs:
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the new
value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
• The OPBIAS.FLOAT is calculated as follows.
Where:
If OPBIAS.FLOAT is not zero, you can configure it to ramp down to zero through
the OPBIAS.RATE parameter.
• You configure the OPBIAS.RATE to apply a ramp rate to the OPBIAS.FLOAT. It is
only used when the OPBIAS.FLOAT is not zero. The OPBIAS.RATE is expressed
in Engineering Units per minute and may have the following values.
− Zero:
If OPBIAS.RATE is zero, a OPBIAS.FLOAT is calculated and bumpless
transfer is guaranteed. However, if OPBIAS.FLOAT is not zero, it will never
ramp down.
− Non-zero:
If OPBIAS.RATE is not zero, an OPBIAS.FLOAT is calculated and bumpless
transfer is guaranteed. If the OPBIAS.FLOAT is not zero, it is ramped to zero at
the rate you configured for the OPBIAS.RATE parameter.
Where:
− NaN:
When the OPBIAS.RATE is Not a Number (NaN), no OPBIAS.FLOAT is
calculated. This means a bump in the output will occur, if the primary does not
accept this block's initialization value.
− The operator is prevented from storing an OP value that exceeds these limits.
Parameter Description
Parameter Description
Normal Ramp Rate Normal ramp rate value in engineering units that you
(SPTVNORMRATE) enter. The value can be Not a Number (NaN) or greater
than zero. If value is NaN, it means a "step change" in the
SP, which is the same as a ramp time of zero.
Max. Ramp Deviation Lets you specify a maximum deviation in engineering units
(SPTVDEVMAX) per minute allowed between PV and SP during ramping.
The value can be NaN or greater than zero. If value is
NaN, it means no ramp deviation checking is done.
You can configure these other SP ramping related parameters to appear as block pins or
monitoring parameters that can be viewed on the block during Control Builder
monitoring, as shown in the following figure. You can access these parameters to invoke
and monitor SP ramping while monitoring the control strategy through Control Builder
or the PID Loop Point Detail display in Station.
Parameter Description
Parameter Description
SPTV SP target value that you enter. You can only set SPTV
when the SPTVOPT is Enabled, the SPTVSTATE is Off or
Preset, and the block's mode is Auto or Manual. When you
set SPTV with the block's Control Module active, this
occurs:
• The block calculates a ramp time (SPTVTIME).
Parameter Description
• Preset, or
• Run
The following table includes descriptions of the callouts in the figure above.
Callout Description
1 Block's mode must be Auto and SPTVSTATE must be Preset, before you
can start SP ramping by setting SPTVSTATE to Run with SPTV set to
desired value.
3 You can only set a value for SPTV and SPTVTIME, when:
• SPTVSTATE is Off or Preset, and
ATTENTION
• When SP ramping is Enabled, the SPTVSTATE must be Off before
you can make changes to the SP limits (SPHILM and SPLOLM).
PV tracking
The PV Tracking option sets SP equal to PV when a cascade is broken due either to
function block initialization or operator or program action (such as, setting the mode to
Manual).
You select the Enable PV Tracking selection on the block configuration form to enable
the function (PVTRAKOPT = Track).
ATTENTION
• PV tracking does not occur on recovery from a bad PV.
PID equations
The PID block provides five different equations for calculating the PID - the CTLEQN
parameter is used to specify the desired equation.
• Equation A - all three terms (Proportional, Integral, Derivative) act on the error (PV
- SP) as follows:
-1 1 T2S
CV = K * L 1+ + * PVPS - SPPS
T1S 1 + a * T2 S
• Equation B - the proportional and integral terms act on the error (PV - SP) and the
derivative term acts on changes in PV as follows:
-1 1 T2S 1
CV = K * L 1+ + * PVPS - 1 + * SPPS
T1 S 1 + a * T2 S T1S
• This equation is used to eliminate derivative spikes in the control action as a result
of quick changes in SP.
• Equation C - the integral term acts on the error (PV - SP) and the proportional and
derivative terms act on changes in PV as follows:
-1 1 T2S 1
CV = K * L 1+ + * PVPS - * SPPS
T1S 1 + a * T2 S T1S
1
CV = L-1 * PVPS - SPPS
T1S
ATTENTION
Equation E does not work with the override feedback function. It is a whole
value algorithm that bumps the output to PV-SP regardless of the ORFBVAL
preset to CV.
− Output bias processing adds a fixed bias (user specified) and floating bias
(calculated to provide bumpless transfer after initialization or mode change) to
the unbiased CV.
ATTENTION
To prevent a bump in the output, you must configure the OPBIAS.RATE
parameter for a value (in Engineering Units per minute) other than 0.0
(zero) or NaN (Not a Number) to enable the ramping function for the
floating bias.
PVP = PV in percent
s = La Place operator
SPP = SP in percent
Gain options
If PID equation A, B, or C is selected, any of the following gain equations may be
chosen:
• Linear Gain - provides a proportional control action that is equal to a constant (K)
times the error.
− This is the most commonly-used gain option - K is a user-specified constant and
has a default value of 1.0.
• Gap Gain - used to reduce the sensitivity of the control action when PV is in a user-
specified band (gap) around the set point.
− Gap size and control action are specified at configuration time through the
following parameters:
K = KLIN
K = KLIN KMODIFGAP
• Nonlinear Gain - provides control action that is proportional to the square of the
error, rather than the error itself.
− Gain (K) is derived as follows:
PV - SP
K = KLIN * NLFORM + NLGAIN *
(PVEUHI - PVEULO)
Where:
• External Gain - where, when gain (K) is selected, it is modified by an input value
that can come from either the process, another function block, or a user program.
− The main use of this option is to compensate for nonlinear process gain - you can
tune the PID gain independently of the normal operating point of the process.
K = KLIN KMODIFEXT
Where:
WARNING
You cannot always reverse output (OP) resulting from changes you make to a
tuning constant gain (K), integral time (T1) or derivative time (T2) in an online
control loop.
You cannot undo a change in a tuning constant in an online control loop by simply
changing the constant back to its original value. The output (OP) does not jump back to
its original prior value just because you return the constant to its prior value. In this case,
you must put the loop in MANUAL mode and set the output (OP) to the desired value
before returning the loop to AUTO mode.
Timeout monitoring
If mode is CAScade, the PID block performs timeout monitoring on SP - if a good SP
value is not received within a predefined time (TMOUTTIME), the PID block invokes
timeout processing.
The maximum time between updates is specified by TMOUTTIME (in seconds)
Timeout processing
If mode is CAScade and SP times out, the PID block does the following:
ATTENTION
If the input is from a connection in another controller in a peer-to-peer
architecture, the actual timeout time equals the configured TMOUTTIME
plus the CDA timeout time. The CDA timeout time equals four times the
configured CEE subscription rate. For example, if the CEE subscription rate
is 100 milliseconds and the TMOUTTIME is 5 seconds, the actual timeout
time for the block is 4 times 100ms plus 5s or 5.4 seconds.
ATTENTION
The OUTIND parameter has no affect on the block's control operation. The
CTLACTN parameter on the Algorithm tab still supports the output direction of
the block, the OPTDIR parameter on the Main tab for the AOCHANNEL block
form applies the conversion of OP to OPFINAL. You can manipulate the
DIRECT/REVERSE selections for the OUTIND, CTLACTN, and OPTDIR
parameters to meet your process and operator needs.
OP 100.0 - Actual OP
The user store of an OP related parameter is intercepted and reversed when OUTIND
equals REVERSE. For example, a store of OPHILM = 80 produces OPLOLM = 100 -
80, so the OPHILM parameter get will then view OPHILM = 100 - 20.
ATTENTION
The swapping/reversal of values will not be done, if the block was loaded with
REVERSE OUTIND configured. The reversal of values will be done only on a
subsequent change to the OUTIND value, if appropriate.
For example: If a PID block is loaded with OPHILM = 95, OPLOLM = 10 and
OUTIND as REVERSE, the OPHILM and OPLOLM after load will still be 95
and 10, respectively.
the same. On Migration from a block with OUTIND support, the OUTIND parameter
value will be restored after migration.
The OUTIND parameter value will also be preserved on checkpoint; restored on Ram
Retention Restart and there will be no bump of OP on WarmStart. Alarm regeneration on
WarmStart, will be supported for these situations similar to other parameters.
OP Alarms considerations
When the OUTIND parameter value is set to REVERSE, the OP values displayed for the
high or low CEE Output Alarms are reversed. In the Alarm Summary display, the OP
values of the high alarms and the low alarms are swapped. The Output Alarms display
shall track the value of displayed output parameters. An OUTIND value of REVERSE,
shall show the limit and value subjected to reversal. For example, an OPHI alarm will
have the displayed trip limit set to 100 - (output low limit).
If the OUTIND parameter setting is changed:
• from Direct, DirectDispInd, or ReverseDispInd to Reverse or
• from Reverse to Direct, DirectDispInd, or ReverseDispInd,
a return for the existing Output Alarm condition occurs and a new Output Alarm would
be sent.
Windup handling
When a windup condition is reached, the PID block stops calculating the integral term,
but continues to calculate the proportional and derivative term.
• A windup condition exists if:
Windup processing
Every regulatory control type block maintains anti-reset windup status for its output
(ARWOP) and each of its initializable inputs (ARWNET). The following table lists the
possible values for ARWOP and ARWNET parameters.
ARWOP computation
The ARWOP indicates if the output (OP) can be raised or lowered. The PID-type
function blocks use ARWOP to restrict integral control. When ARWOP contains a value
other than Normal, the PID block stops integral control in the windup direction. Integral
control continues in the other direction, as does proportional and derivative control. But,
windup status has no impact on proportional and derivative control.
If a function block has a secondary, it fetches the secondary's windup status and
recomputes its ARWOP. The conditions within the function block, such as output being
at its high limit, also affect the ARWOP. The ARWOP is computed as follows, assuming
the block has only one output or that it is not a FANOUT block.
ARWNET computation
When ARWNET is HiLo, stores to SP are not limited, rather this is the status propagated
to the primary. The only limiting anti-reset windup status ever does is to stop integral
action in one or both directions on PID blocks. For any other regulatory control type
block, ARWNET is not used for any kind of limiting. The ARWNET is computed as
follows, assuming the block has only one output or that it is not a FANOUT block.
The CV is NaN
ARWOPIN parameters have on the ARWNET and ARWOP parameters, which are not
user configurable.
NORMAL HI HI
NORMAL LO LO
HI NORMAL HI
HI HI HI
HI LO HILO
HI HILO HILO
LO NORMAL LO
LO HI HILO
LO LO LO
LO HILO HILO
HILO HI HILO
HILO LO HILO
When the override status changes from selected to unselected, the PID block does the
following:
• Recomputes CV:
− If the override offset flag is Off:
Offset = (PVP-SPP)
Offset = K * (PVP-SPP)
Where:
K = overall gain
PV = PV in engineering units
PVP = PV in percent
SPP = SP in percent
PID parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the PID block.
• Range control - Processes where range control will be beneficial, such as tank
surge control. In this case, range control constrains the PV within a user
specified range (gap) rather than to a fixed set point
Additional descriptive details are provided in the following discussions:
Benefits
• Graphic presentation
• Modes
• Configurable attributes
Benefits
Key benefits of Profit Loop PKS include:
Benefit Discussion
Superior Because it is a predictive controller, Profit Loop PKS directly accounts for
control transportation delays and other difficult to control behavior. This approach
leads to superior control of processes with significant deadtime, inverse
response, or noisy measurement.
Single tuning Uses a single tuning "knob," the performance ratio. If the controller is sluggish
handle and unresponsive, decreasing the performance ratio will improve
performance. If the controller is oscillatory or operating conditions change
frequently, increasing the performance ratio will slow the controller response
to gain robustness.
Benefit Discussion
Integrated tools Profit Loop PKS includes Profit Loop Assistant, a suite of tools for configuring,
monitoring, and maintaining Profit Loop PKS blocks.
The Profit Loop PKS Assistant is a companion intended to simplify your Profit
Loop PKS configuration activities. With the Assistant, a good understanding
of the math and concepts involved in model predictive control is not required;
the Profit Loop PKS Assistant will aid you in the development of the model.
In addition, the Profit Loop PKS Assistant provides diagnostic tools to assist
with troubleshooting loop performance problems. For example, you can check
for control valve stiction or enter specific tuning parameters for a PID-PL loop.
Range control Employs the patented Range Control Algorithm found in Honeywell's Profit
Controller advanced control software. Unlike traditional PID, Profit Loop PKS
is not restricted to a single target (the set point), but may actively constrain
the response within a user-specified range.
This capability makes it ideally suited to tank capacity (surge) control where
the tank level must be bounded but is otherwise free to move. Here, the
control objective is to minimize change to the in-flow or out-flow of the tank.
Optimization When the process is not constrained to a set point, Profit Loop PKS provides
freedom to choose the ultimate resting value for the process. The process
may completely float within the range, or a secondary "optimization" objective
may be imposed to drive the process to an optimal state.
Dual objective The key advantage of optimization over set point control is that the response
control of the optimizer and controller can be tuned separately, providing dual
objective control.
Discrete As a predictive controller, Profit Loop PKS models the behavior of the PV
analysis based on changes in the OP. If PV measurements are not available, Profit
Loop PKS proceeds with the control calculation using the current model
estimate.
Graphic presentation
The PID-PL block looks like this graphically:
Modes
The PID-PL operates in one of three distinct modes:
• When CTLEQN is any one of the PID equations (EQA, EQB, and so on) and not
PROFITLOOP, this block behaves as a standard PID control block. (For help on the
this mode, see PID Block in the Reference Data for Functional Block Types,
Regulatory Control Blocks section of this document.)
• When CTLEQN is PROFITLOOP and CTRLMODE is set to SETPOINT, this block
operates as a set point controller. Profit Loop PKS calculates a control output (OP)
that drives the process variable (PV) to the set point (SP).
• When CTLEQN is PROFITLOOP and CTRLMODE is set to RANGE, this block
calculates a control output (OP) to merely constrain the process variable (PV)
between an upper bound (SPHI) and lower bound (SPLO). A secondary objective
can be applied to set the PV within the range, but specification of this objective is
optional.
The remainder of this discussion concentrates on the latter two operating modes. Where
appropriate, the term "setpoint control" will be applied to the second operating mode,
and "range control" will be applied to the third. These two modes are distinguished by
the setting of the CTRLMODE parameter.
Configurable attributes
Each PID-PL block supports the following user-configurable attributes. The following
table lists the given name of the tab in the parameter configuration form and then
describes the attributes associated with that tab. Several attributes parameters) are
identical to those for the PID block; references are made as appropriate. This information
is also included in Control Builder's on-line context-sensitive Help.
Main All attributes configured on this tab are the same as those for the PID
block. Refer to either the online Help in Control Builder for details, or to
Reference Data for Functional Block Types, Regulatory Control Blocks,
PID Block in this document.
Algorithm Many attributes configured on this tab are the same as those for the PID
block. Attributes specific to the PID-PL block are as follows:
• Control Equation Type (CTLEQN) - For the PID-PL block, the Control
Equation Type must be PROFITLOOP. If you want to change from
PID-PL (Profit Loop PKS) to a standard PID block, the block must be
inactive. For details on changing from PID to PID-PL (or PID-PL to
PID), see the Experion LX Control Building Guide, Working with Profit
Loop PKS, Converting a PID-based Control Loop to PID-PL.
• ProfitLoop Control Mode (CTRLMODE) - Lets you select the means
of control for the PID-PL block:
− SETPOINT: With this selection, the function block will attempt
to have the PV track the setpoint (SP).
− RANGE: With this selection, the function block will attempt to
have the PV stay within high and low setpoint limits (SPHI and
SPLO).
• ProfitLoop Performance Ratio (PRFRATIO) - This setting is for non-
integrating processes (D[1] 0). It defines how hard the function
block will "push" to a setpoint or range limit. Enter a performance
ratio value of 0.1 to 10.0 for the desired ratio of closed loop control
For details on remaining attributes on this tab, which are the same as
those for the PID block, refer to either the online Help for Control
Builder, or to Reference Data for Functional Block Types, Regulatory
Control Blocks, PID Block in this document.
SetPoint Many attributes configured on this tab are the same as those for the PID
block. Attributes specific to the PID-PL block are as follows:
• SP Range SP High (SPHI) - For PID-PL blocks with a Control Mode
of RANGE, this entry lets you specify the upper range limit, in
Engineering Units. The value must be greater than or equal to SPLO,
and less than SPHILM, that is: SPLO SPHI < SPHILM.
• SP Range SP Low (SPLO) - For PID-PL blocks with a Control Mode
of RANGE, enter the lower range limit, in Engineering Units. The
value must be less than or equal to SPHI, and greater than SPLOLM,
that is: SPLOLM < SPLO SPHI.
• ProfitLoop Range Control Ramping, SPLO Ramp Rate
400 Experion LX Control Builder Components Theory R110
Honeywell February 2014
13. Regulatory Control
13.9. PID-PL (Profit Loop PKS) Block
For details on remaining attributes on this tab, which are the same as
those for the PID block, refer to either the online Help for Control
Builder, or to Reference Data for Functional Block Types, Regulatory
Control Blocks, PID Block in this document.
Output Many attributes configured on this tab are the same as those for the PID
block. The attribute specific to the PID-PL block is as follows:
Reducing the noise level leads to a reduction in valve travel with fewer
valve reversals. There is little impact on the responsiveness of the
control algorithm to fast disturbances.
For details on remaining attributes on this tab, which are the same as
Advanced This tab is used for configuring the process model for your Profit Loop
PKS controller. This is manual entry of a model in Laplace form. In
addition, optimization, PV, and OP settings can be made, as detailed in
the following discussions.
Advanced, The entries in this area of the Advanced tab allow you to define the
Model area transfer function model of process dynamics to be used in the control of
your process. Use this form if you have a good understanding of the
math and concepts involved in model predictive control and you do not
wish to use the Profit Loop PKS Assistant.
Actions that can be taken on this tab, related to the definition of your
model, include:
• Update Model - (UPDATEMODEL) - The model defined in the PID-
PL configuration form can be downloaded to the active controller.
Clicking this button updates model values in the ERDB, calculates
the model, and calculates the controller.
The model in the controller will differ from the one defined in the
configuration forms if you have made changes in the forms since the
model was last updated, or a model has been defined in the Profit
Loop PKS Assistant and downloaded to the controller.
Notes: With a speed of 6.0, the optimizer tries to bring the process to
its steady-state value by the end its of control horizon (the optimizer
is as aggressive as the controller). With a speed of 3, the optimizer is
twice as slow; with 12, twice as fast. The default value for
OPTSPEED is 2.
• Profit Loop PKS uses the following formula:
− Where:
CLOSEDLOOPRESP = Closed-loop response time
OPTSPEED = Optimization speed
OPTRESP = Settling time associated with changes induced
through optimization
• SP Offset, Low Limit (SPLOOPTOFFSET) - Profit Loop PKS can be
configured to optimize the process over a limited operating range,
which is more restrictive than the normal control range bounded by
SPLO and SPHI. To do this,
− the Control Mode (on the Algorithm form) must be set to
RANGE, and
− the Optimizer Mode (on the Advanced form) must be set to
other than NONE.
− Set the SP low limit for optimization by entering the amount by
which you want to restrict the lower limit (the "offset"). The
optimized low limit is then calculated as follows:
SPLOLMOPT = SPLO + SPLOOPTOFFSET
Advanced, Async PV Option (PVASYNCOPT) -This setting tells the function block
PV Configuration when not to expect a new PV measurement (when not to expect a
area change), so that the function block does not react to obsolete
information.
• CONTINUOUS: The PV measurement is updated at least once with
every execution period. Select this setting when the sensor involved
generates a continuously updated signal, such as a thermocouple or
strain gauge.
• ONPVCHANGE: The PV measurement is updated when the PV
parameter changes. This selection is appropriate with such sensors
as gas chromatographs.
Alarms Most attributes configured on this tab are the same as those for the PID
block. Attributes specific to the PID-PL block are as follows:
• Predicted PV High - Trip Point (PREDPVHIALM.TP) - For PID-PL
blocks, at every execution period, Profit Loop PKS estimates the
steady-state value for both the PV and OP. The predicted PV high
alarm can be used to indicate when the predicted steady-state PV
value exceeds the value specified here for more than a specified time
(bad PV shed time).
− A value greater than or equal to zero enables the predicted PV
high alarm trip point.
− NaN (Not a Number) disables the predicted PV high alarm.
• Predicted PV High - Priority (PREDPVHIALM.PR) - The priority level
for the corresponding alarm type can be selected, using the following
categories:
− NONE: The alarm is not reported to the system and is not
annunciated.
For details on remaining attributes on this tab, which are the same as
SCM All attributes configured on this tab are the same as those for the PID
block. Refer to either the online Help in Control Builder for details, or to
Reference Data for Functional Block Types, Regulatory Control Blocks,
PID Block in this document.
Block Pins Lets you select the available parameters that you want to expose as
input/output pins on the function block graphic in Control Builder.
Configuration Lets you select the available parameters that you want to appear on the
Parameters face of the function block in the Project tab in Control Builder.
Monitoring Lets you select the available parameters that you want to appear on the
Parameters face of the function block in the Monitoring tab in Control Builder.
Block Preferences Lets you change several block-viewing preferences including the color
of the block's faceplate.
Template Defining Lets you view and define parameters for associated templates.
Insertion Type Lets you include an insertion type from a CAB instances in the block.
See CAB insertion configuration considerations for regulatory control
blocks for more information
Function
The Profit Loop PKS control algorithm belongs to a class of controllers known as
"model predictive control." These controllers rely on a dynamic model to predict future
movement in the process variable. If this predicted PV does not meet the control
objectives (maintain at current setpoint), control action is taken to realign the PV with its
objectives. In contrast, a PID controller uses past and current error trajectories to restore
the PV to its SP within one control move, regardless of the long-term consequences of
the move.
Additional functional details about Profit Loop PKS are provided in the following
discussions:
• Model prediction
• Model biasing
• Control action
• Range control
• Optimization
• Predictive alarming
• External gain updating
Model prediction
The first step in any model predictive control scheme is to predict the future trajectory
for the PV assuming no further movement in the OP. To make these predictions, Profit
Loop PKS uses a dynamic model to relate past OP movement to future PV movement.
Model prediction is shown graphically in the following figure.
In the preceding figure, the white line represents the predicted future PV trajectory. (This
is the line in the upper right quadrant of the graph.)
For Profit Loop PKS, the dynamic model is entered as a Laplace transfer function of the
form:
where
G is the process gain;
T is the deadtime;
n and are the process dynamics.
Model biasing
In practice, there will always be a mismatch between the model prediction and the real
process measurement. This difference can be attributed to a number of sources:
inaccuracy of the model, measurement noise, external process disturbances, etc. If the
model does not correct for this difference, the model prediction will slowly wander from
the actual PV and the function block's integral action is lost.
To account for the mismatch, Profit Loop PKS compares its PV prediction for the current
time to the current process measurement. The difference between these values is referred
to as the bias and is added to the future PV trajectory.
In practice, the above bias is susceptible to high frequency signal noise, which could
ultimately lead to excessive control action. To eliminate the noise effect, Profit Loop
filters the raw bias applying the filtered value to future PV trajectories.
For especially noisy measurements, Profit Loop PKS employs a proprietary noise
reduction filter to the bias. Unlike a simple PV filter, this filter eliminates measurement
noise but reacts quickly to persistent external disturbances.
MODELPV is the value the current model prediction without any biasing. Under normal
circumstances changes in the unbiased model prediction should track actual process
changes (both in magnitude and time). If there is a significant difference between the
responses, the process model should be updated using the Profit Loop Assistant tools.
To simplify model validation, a reset bias button is available on the detailed displays.
This button sets MODELPV equal to the current PV, for easy monitoring of further
changes in their values.
Control action
Once a future trajectory has been calculated, control action is implemented to force this
process trajectory toward its control objective. Typically, this involves the calculation of
the control actions necessary to bring the process variable to its setpoint over the course
of the trajectory. Alternatively, the controller minimizes future errors.
e1 e2 e3 e4 e5 e6
While the exact calculation of the control action is too complicated for this document, it
involves the inversion of the process model thus relating error to control action. If the
error is zero (the control objective is met), no further control action is required in this
execution cycle, and the OP is unchanged.
When minimizing future errors, there are several ways to define optimality. For instance,
one algorithm may weight more heavily the initial errors, a second the final error, and a
third equally weight all errors. Using different optimality criteria leads to different
solutions.
Profit Loop PKS focuses on the later part of the trajectory from the closed-loop response
time onward. It then determines the minimum control action necessary to bring the
process variable to its setpoint (and keep it there) before the user-specified closed-loop
response time. Because this algorithm uses the minimum energy to meet its control
objective, it is more robust to inaccuracies in the model than other model predictive
control algorithms.
e1 e2 e3 e4 e5 e6
To tune the function block, you must specify the closed-loop response time. To make
tuning simpler, this response time is normalized by the open loop response time, and the
ratio of the response times, the performance ratio is entered. A performance ratio of 1
indicates that the function block should bring the process to its setpoint value in
approximately open loop response time minutes. This function block action is similar to
the response from a steady-state-only controller.
When the performance ratio is less than 1, more aggressive control is required as the
process is driven to its setpoint faster than its natural (open loop) response. In contrast, a
performance ratio greater than 1 generates laxer control but is more robust to modeling
errors.
When the process is not self-correcting (contains an integrator), the open loop response
time is not defined, and consequently, the use of a performance ratio is meaningless.
Under these circumstances, you enter the closed-loop response time directly, and the
performance ratio is reset to 1.
Range control
With the above algorithm, it is possible to control the PV within a user-entered range
instead of to a hard target (SP). Errors then represent the deviation of the future
trajectory outside of the operating range. If the future trajectory lies inside the operating
range, there is no error.
R110 Experion LX Control Builder Components Theory 415
February 2014 Honeywell
13. Regulatory Control
13.9. PID-PL (Profit Loop PKS) Block
Conceptually, Profit Loop's range control option is PID gap control with a gap gain
factor of 0. However, unlike gap control, Profit Loop PKS considers the long-term
process response and not the current process value, applying control action only when
the projected PV trajectory is out of bounds.
The parameters SPHI and SPLO define the operating range for the gap, in the same
engineering units as SP. This block ensures these values do not exceed the absolute SP
range limits, SPHILM and SPLOLM, capping the operating range limit when required.
Furthermore, if the input SP value is outside the range specified by SPHI and SPLO, this
function block clamps SP to the appropriate limit. This additional restriction on SP only
applies when the range control option is selected. Otherwise, the SPHI and SPLO
parameters track the current setpoint, SP.
The user-entered parameter, CTRLMODE, indicates whether Profit Loop PKS controls
within a range, (RANGE), or to a setpoint (SETPOINT). The parameter has no meaning
if PID control is selected.
Optimization
With range control, the steady-state operating conditions are allowed to float (within the
range); there is no unique resting value. While this may be acceptable for dynamic
control, it may not be suitable for planning and long-term operations.
To define the steady-state operations, Profit Loop PKS includes a small optimizer that
allows you to specify the desired steady-state operating conditions. Depending on the
control objectives (as specified by the OPTMODE parameter), you can minimize the
process variable (MINIMIZE), maximize this variable (MAXIMIZE), aim to a user-
entered target (OPTTARGET), or aim toward a narrower PV range but not to a unique
value (DUALRANGE). Furthermore, you can disable this option completely (NONE).
The rate at which the process approaches steady-state operations is typically slower than
the rate at which dynamic constraints are resolved. This allows Profit Loop PKS to be
configured for two control objectives - quick resolution of dynamic errors with a slower
approach to optimal operations.
The optimization rate is normalized by the closed-loop response time and specified by
the parameter, OPTSPEED:
When OPTSPEED = 6, the optimizer tries to bring the process to its steady-state value
by the end its control horizon. When OPTSPEED = 3, the optimizer is twice as slow;
when 12, twice as fast. The default value for OPTSPEED is 2.
If the optimizer is allowed to force the process against one of its operating limits, there
will be times when the optimizer overshoots the limit causing dynamic control action in
the opposite direction. If left unchecked, this can lead to process oscillations around the
optimal value.
To circumvent this problem, the optimizer is restricted to a narrower range than the
controller. User specified offsets dictate how narrow the optimization range is. For all
optimization modes except OPTTARGET, Profit Loop PKS calculates the optimization
limits as deviations from the function block high and low operating range (SPHI and
SPLO).
The following figures illustrate how Profit Loop PKS uses optimizer offsets to set high
and low optimization limits.
SPLOLMOPT
Offset SPLOOPTOFFSET
For OPTTARGET optimization, Profit Loop PKS calculates the optimization limits as
deviations from setpoint (SP). Using non-zero optimizer offsets is equivalent to DUAL
RANGE optimization but with the optimization range tracking any setpoint changes. The
following figure illustrates this situation.
Offset SPHIOPTOFFSET
SETPOINT (SP)
Offset SPLOOPTOFFSET
SPLOLMOPT
Predictive alarming
At every execution period, the Profit Loop PKS algorithm estimates the steady-state
value for both the PV and OP (STEADYSTATEPV and STEADYSTATEOP). This
function block may be configured to generate an alarm when the predicted steady-state
PV exceeds a user-specified trip point (PREDPVHIALM for high PV predictions and
PREDPVLOALM for low predictions). Both alarms are analog alarms and, as such,
support individual trip points, priorities, and severities.
• Because the gain multiplier is restricted to be greater than 0, the process model gain
never changes direction.
• A user program or another function block changes the active value,
PROCGAINACT, directly. This value is restricted to be non-zero, to prevent
division by zero, but may otherwise change directions.
Similar to gain scheduling, the process deadtime can be altered through an external input.
Use this option to compensate for nonlinear process delay changes. Two methods of
deadtime updating are supported:
• An operator or another function block changes a process deadtime bias,
PROCDEADTIMEBIAS. The actual process delay (active deadtime) is then
computed as:
Configuration examples
Four examples are discussed in the following paragraphs:
• Gain scheduling
• Setpoint control
• Range control
• Discrete analyzer
• Gain scheduling
Setpoint control
The following figure and table show a sample configuration that uses a PID-PL block to
form a single control loop set for setpoint control. Note that this configuration is nearly
identical to the single-loop PID configuration.
Callout Description
1 Use the PV parameter connection to carry data from the analog input to the
data acquisition block.
2 Use the data acquisition block to filter and scale the PV input. This block
also maintains several PV alarms.
3 Use the PID-PL block for control. A separate SP block pin is exposed for
on-line parameter changes. To implement Profit Loop PKS control, the
control equation is set to PROFITLOOP and control mode to SETPOINT.
Callout Description
Range control
The following figure and table show a sample configuration that uses a PID-PL block to
form a single control loop set for range control.
Callout Description
Discrete analyzer
The following figure and table show a sample configuration for interfacing a PID-PL
block to a discrete analyzer. In this example, the analyzer maintains two digital signals-
an on-off flag to indicate when the analyzer is in calibration, and a 30-second pulse
signal whenever a new measurement is available.
Callout Description
Callout Description
3 The calibration flag runs directly to the calibration pin on the PID-PL block.
As long as this signal is ON, the analyzer is presumed to be calibrating.
The new sample input is buffered by the FTRIG block before it links to the
new sample pin on the PID-PL block.
4 FTRIG captures the leading edge of the new sample pulse and sets the
new sample flag on the PID-PL block. The new sample parameter remains
ON for one execution period before it is reset by FTRIG.
Gain scheduling
The following figure and table show a sample configuration that uses gain scheduling
with PID-PL. In this example, the gain of a level controller depends on the level in the
tank. This may occur if the geometry of the tank changes as the level rises and falls.
Callout Description
Required inputs
The PID-PL block requires two inputs: PV and SP. See Required inputs for the PID
block for details on these inputs.
For range control, the PID-PL block requires two additional inputs: SPHI and SPLO.
These parameters cannot be initialized. They can be pulled from another block, set
through operator entry, or stored by a user program.
Initializable outputs
The PID-PL block supports a single initializable output. Like PID, this calculated output
can be either in percent, OP, or in engineering units, OPEU. See Initializable outputs for
the PID block for more details.
Control initialization
The PID-PL block brings initialization requests from its secondary through the hidden
BACKCALC connection. In addition, the secondary may propagate one-shot
initialization requests to this block.
• SECINITOPT may be used to ignore initialization requests from the secondary.
• If the secondary is requesting initialization, the PID-PL block:
− initializes its output
CV = initialization value from the secondary.
− uses the initialized CV value in model predictions
Output bias
Profit Loop PKS does not support an output bias. For details on the biasing of PID
algorithms, see Output bias for the PID block.
over a period of time. The SPHI and SPLO ramp rates are independent and specified
through the parameters, SPHIRAMPRATE and SPLORAMPRATE (engineering units /
min). Entering NaN provides immediate ramping to the new limit, and consequently,
disables this option.
Mathematically, limit ramping can be represented as:
where
SPHIACTIVE and SPLOACTIVE represent the effective range limits at any given
execution period.
SP limit ramping only applies when the operating range becomes more restrictive
(Newly entered SPHI < Current SPHI or newly entered SPLO > Current SPLO).
Otherwise, the range limit change is immediately applied.
When the current range limit is far from its newly entered value, it may take a
considerable amount of time before the active value reaches its new limit. This is an
unnecessary delay if the process is operating well within the new operating range. To
avoid this delay, Profit Loop employs a proprietary algorithm to bring the active value
"close" to the newly entered limit before it starts ramping. This one shot correction
avoids bumping the process, yet applies ramping in a more meaningful fashion.
Furthermore, this feature eliminates problems associated with fat fingering (accidentally
depressing a key twice, e.g. entering 500 instead of 50) a range limit. For example,
consider an SPHI change from 99 to 100. If an operator enters 1000 instead of 100, the
SPHIACTIVE immediately moves to 1000. If the operator re-enters the limit as 100,
there may be a considerable delay before SPHIACTIVE ramps from 1000 back to 100.
One shot correction eliminates most of this delay.
PV tracking
The PV Tracking option sets SP equal to PV when automatic control is disabled (e.g.
cascade is broken, mode is manual). Having SP track PV avoids output bumps when
automatic control is reestablished. See PV tracking for the PID block for
implementation details.
For range control, SPHI and SPLO also track out of range PV values when automatic
control is disabled and PV tracking is enabled. The following rules apply:
• If SPLO is greater than SP then set SPLO equal to SP
ATTENTION
• SPHI and SPLO track the current SP (and only indirectly the PV).
ATTENTION
The Bad PV duration alarm is in addition to any other Bad PV alarms,
specifically the Bad PV alarm in the DATAACQ block.
PV Calibration
On occasion, one may wish to intentionally disable the PV measurement without
inactivating the control module or placing the function block in MAN. This is most
evident when the PV's sensor is recalibrated and such recalibration causes undesirable
control action. A calibration flag, CALIBRATION, is provided for this purpose.
Asynchronous PV Inputs
Many specialty process sensors are discontinuous, generating results on an infrequent
basis relative to the control execution period. This is especially true among gas
chromatographs where a new reading is generated every 2-40 minutes.
When these sensors are used in PID control, control error continues to integrate between
sensor updates. This may lead to unnecessary overshoot in the control action and
oscillation in the PV response.
With Profit Loop PKS, the PID-PL block updates only when a new sensor reading is
available. This has the effect of disabling integration between sensor readings
eliminating function block overshoot. Between sensor readings, Profit Loop
• Disables updating of bias between model prediction and PV
• Continues control action based on model prediction only
Profit Loop uses the parameter PVASYNCOPT to specify when and how a PV is
updated. When PVASYNCOPT set to:
• Continuous - PV (and PV bias) is updated every execution cycles regardless of its
value. This is the correct setting when the sensor involved generates a continuously
updated signal, such as a thermocouple or strain gauge.
• OnPvChange - PV bias is updated only when there is a change in the PV value
from one execution period to the next.
− Note: Avoid this setting if noise alters the PV value between analyzer updates.
• External Sync - PV bias is updated when an external flag indicates a new analyzer
reading. This external flag should be connected to the Boolean parameter,
NEWSAMPLE.
ATTENTION
• Logic blocks should be employed to set and reset the NEWSAMPLE flag.
It is the users responsibility to design and construct the appropriate logic.
Control Equations
The PID-PL block supports the standard 5 PID equations (EqA through EqE) found on a
PID block as well as the Profit Loop equation. You specify which equation to use
through the CTLEQN parameter.
To provide expansion for future PID type equations, the Profit Loop option is shown at
the bottom of the CTLEQN list after options EqF and EqG. EqF and EqG are provided
for possible future expansion of the PID equation set. If you select either of these
options, an error message is displayed indicating an invalid entry.
With standard PID-type function blocks, the control equation can only be altered while
the control module is inactive, preventing algorithm initialization errors. This
requirement is too restrictive for Profit Loop, which maintains a running initialization
value regardless of the mode of operation. Consequently, PID-PL supports the hot swap
from a PID equation to Profit Loop on an active control module. Hot swapping is
supported in one direction only; to revert back to PID control, user must first inactive the
control module.
For more information on PID equations, see PID equations for the PID block.
ATTENTION
The OUTIND parameter has no affect on the block's control operation. The
CTLACTN parameter on the Algorithm tab still supports the output direction of
the block, the OPTDIR parameter on the Main tab for the AOCHANNEL block
form applies the conversion of OP to OPFINAL. You can manipulate the
DIRECT/REVERSE selections for the OUTIND, CTLACTN, and OPTDIR
parameters to meet your process and operator needs.
OP 100.0 - Actual OP
The user store of an OP related parameter is intercepted and reversed when OUTIND
equals REVERSE. For example, a store of OPHILM = 80 produces OPLOLM = 100 -
80, so the OPHILM parameter get will then view OPHILM = 100 - 20.
ATTENTION
The swapping/reversal of values will not be done, if the block was loaded with
REVERSE OUTIND configured. The reversal of values will be done only on a
subsequent change to the OUTIND value, if appropriate.
For example: If a PID block is loaded with OPHILM = 95, OPLOLM = 10 and
OUTIND as REVERSE, the OPHILM and OPLOLM after load will still be 95
and 10, respectively.
The OUTIND parameter value will also be preserved on checkpoint; restored on Ram
Retention Restart and there will be no bump of OP on WarmStart. Alarm regeneration on
WarmStart, will be supported for these situations similar to other parameters.
OP Alarms considerations
When the OUTIND parameter value is set to REVERSE, the OP values displayed for the
high or low CEE Output Alarms are reversed. In the Alarm Summary display, the OP
values of the high alarms and the low alarms are swapped. The Output Alarms display
shall track the value of displayed output parameters. An OUTIND value of REVERSE,
shall show the limit and value subjected to reversal. For example, an OPHI alarm will
have the displayed trip limit set to 100 - (output low limit).
If the OUTIND parameter setting is changed:
• from Direct, DirectDispInd, or ReverseDispInd to Reverse or
• from Reverse to Direct, DirectDispInd, or ReverseDispInd,
a return for the existing Output Alarm condition occurs and a new Output Alarm would
be sent.
WARNING
You cannot always reverse output (OP) resulting from changes you make to a
tuning constant gain (K), integral time (T1) or derivative time (T2) in an online
control loop.
You cannot undo a change in a tuning constant in an online control loop by simply
changing the constant back to its original value. The output (OP) does not jump back to
its original prior value just because you return the constant to its prior value. In this case,
you must put the loop in MANUAL mode and set the output (OP) to the desired value
before returning the loop to AUTO mode.
Timeout monitoring
The PID-PL block monitors for communication timeouts between primary and secondary
controllers of a cascade pair. This block uses the same methodology as the PID block.
See Timeout monitoring for the PID block for implementation details.
Windup handling
Profit Loop PKS maintains integral action by updating a bias between its model
prediction and the current process measurement, PV. If the function block is in windup,
the input to the process model may not represent what was actually implemented by the
control loop - causing an additional bias.
To prevent this additional bias, Profit Loop PKS actively unwinds a secondary control
module in windup. To do this, the primary's OP is slowly moved in the direction to
relieve windup. When the primary reaches this value, the secondary function block will
be at the edge of its windup condition - oscillating in and out of windup.
To force the OP to unwind and to prevent OP moves that exacerbate windup, Profit Loop
temporarily adjusts its internal OP operating limits. These adjusted limits are displayed in
the OPHIACTIVE and OPLOACTIVE parameters. Ordinarily, these limits are identical
to the OPHILM and OPLOLM, respectively.
Windup processing
Every regulatory control type block maintains anti-reset windup status for its output
(ARWOP) and each of its initializable inputs (ARWNET). The following table lists the
possible values for ARWOP and ARWNET parameters.
ARWOP computation
The ARWOP indicates if the output (OP) can be raised or lowered. The PID-type
function blocks use ARWOP to restrict integral control. When ARWOP contains a value
other than Normal, the PID block stops integral control in the windup direction. Integral
control continues in the other direction, as does proportional and derivative control. But,
windup status has no impact on proportional and derivative control.
If a function block has a secondary, it fetches the secondary's windup status and
recomputes its ARWOP. The conditions within the function block, such as output being
at its high limit, also affect the ARWOP. The ARWOP is computed as follows, assuming
the block has only one output or that it is not a FANOUT block.
ARWNET computation
When ARWNET is HiLo, stores to SP are not limited, rather this is the status propagated
to the primary. The only limiting anti-reset windup status ever does is to stop integral
action in one or both directions on PID blocks. For any other regulatory control type
block, ARWNET is not used for any kind of limiting. The ARWNET is computed as
follows, assuming the block has only one output or that it is not a FANOUT block.
The CV is NaN
NORMAL HI HI
NORMAL LO LO
HI NORMAL HI
HI HI HI
HI LO HILO
HI HILO HILO
LO NORMAL LO
LO HI HILO
LO LO LO
LO HILO HILO
HILO HI HILO
HILO LO HILO
PID-PL parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the PID-PL block.
The PIDER block accepts five analog inputs - a process variable (PV), a set point (SP), a
reset feedback value (RFB), a tracking value (TRFB), and a tracking control switch (S1).
The difference between PV and SP is the error and this block calculates a control output
(OP) that should drive the error to zero.
The reset feedback (RFB) signal comes from the remote controller's PV, and the tracking
value (TRFB) comes from its PV or SP. By monitoring the remote controller's PV and
SP, the PIDER block can determine if the remote controller is responding. If the remote
controller is not responding, it can prevent its own output from winding up.
The tracking control switch (S1) determines the output of the PIDER block. The S1
parameter is usually stored through an output connection from another function block, or
by a user program. When S1 is Off, the PID control value output (CVPID) is combined
with the reset feedback (RFB) value to obtain the control value (CV); and when it is On,
CV is set equal to the tracking value (TRFB).
Configuration example
The following illustration shows a PIDER block configured in a cascade control strategy.
Each PIDER block supports the following user configurable attributes. The following
table lists the given name of the "Tab" in the parameter configuration form and then
briefly describes the attributes associated with that Tab. This data is only provided as a
quick document reference, since this same information is included in the on-line context
sensitive Help.
SetPoint • SP (SP) - Lets you specify an initial set point value. The
default value is 0.
• High Limit (SPHILM) - Lets you specify a high limit value
for the SP. If the SP value exceeds this limit, the block
clamps the SP to the limit value and sets the SP high
flag (SPHIFL). The default value is 100.
• Low Limit SPLOLM) - Lets you specify a low limit value
for the SP. If the SP value falls below this limit, the block
clamps the SP to the limit value and sets the SP low flag
(SPLOFL). The default value is 0.
• Mode (TMOUTMODE) - Lets you select the desired
MODE the block is to assume, if an initializable input
times out, which means the input has not been updated
Output • High Limit (%) (OPHILM) - Lets you specify the output
high limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
to 500 and you enter a High Limit of 90%, the high limit
in engineering units is 90% times 450 or 405 + 50
(CVEULO) equals 455. This check is not applied for a
function block that is in the MANual mode. The default
value is 105%.
• Low Limit (%) (OPLOLM) - Lets you specify the output
low limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
to 500 and you enter a Low Limit of 10%, the low limit in
engineering units is 10% times 450 or 45 + 50
(CVEULO) equals 95. This check is not applied for a
function block that is in the MANual mode. The default
value is -5%.
• Extended High Limit (%) (OPEXHILM) - Lets you specify
the output extended high limit as a percent of the
Calculated Variable range (CVEUHI - CVEULO). For
example, If the CV range is 50 to 500 and you use the
452 Experion LX Control Builder Components Theory R110
Honeywell February 2014
13. Regulatory Control
13.10. PIDER (PID with External Reset Feedback) Block
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
Control Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Insertion Type Lets you include an insertion type from a CAB instances in
the block. See CAB insertion configuration considerations
for regulatory control blocks for more information
Function
The PIDER block requires five inputs -- PV, SP, RFB, TRFB and S1. RFB is the reset
feedback value, TRFB is the tracking value, and S1 is a tracking control switch (a
Boolean input). S1 indicates whether the PID output should be combined with the RFB
or replaced by TRFB.
• PV is pulled from another function block.
PV is typically pulled from a Data Acquisition (DATAACQ) function block which
performs PV limit checking and alarming.
• SP is pulled from another function block, or stored by the operator or a user
program.
If SP is pulled from a primary, the PID's Mode must be Cascade; and if it is stored
by the operator or a user program, Mode must be Manual or Automatic. If Mode is
Cascade, the PID must perform timeout checking on SP (to make sure the primary is
periodically updating it).
• RFB signal comes from the remote (foreign) controller's PV, and the tracking value
comes from its PV or SP. If the PIDER block is used for external tracking features
only, this input is not required. You cannot store a value to this parameter.
• TRFB is pulled from another function block. You cannot store a value to this
parameter.
• S1 is triggered by another function block or set by a user-written program. When S1
is Off, the PID control value output (CVPID) is combined with the reset feedback
(RFB) value to obtain the control value (CV); and when it is On, CV is set equal to
the tracking value (TRFB).
A PIDER also has the following optional inputs. Typically, these are flags which may be
stored by the operator or user program to change the normal operation of the PIDER.
• ESWAUTO, ESWCAS, ESWMAN and SI - Indicates if an external source, such as
a user program, wants to change the PIDER's Mode:
− If ESWAUTO = On, the external source wants to change the Mode to Auto.
− If ESWCAS = On, the external source wants to change the Mode to Cascade.
− If ESWMAN = On, the external source wants to change the Mode to Manual.
− If SI = On, the external source wants to invoke the PIDER's safety interlock
logic.
If a BACKCALC connection is made to the secondary, the PIDER reads BACKCALCIN
from the secondary before calculating its OP:
• BACKCALCIN is a "data container", which means it contains many pieces of
information but is accessed by a single read. Among other things, the information in
BACKCALCIN indicates if the secondary is wound-up or if it wants the PIDER to
initialize.
• The individual BACKCALCIN/BACKCALCOUT connections for each output used
are automatically built by Control Builder as implicit/hidden connections. This
means you do not have to manually wire BACKCALC connections in Control
Builder.
• The secondary builds BACKCALCIN when it receives a read request from the
primary. This way, BACKCALCIN is guaranteed to contain the most current status.
Required inputs
The required number of inputs is determined by the mode of the PIDER block.
• If Mode is CAScade, five inputs are required - PV, SP, RFB, TRFB and S1.
• If Mode is AUTOmatic or MANual, PV, RFB, TRFB and S1 are required.
− SP is the only initializable input; other inputs are non-initializable.
− PV must be pulled from another block; you cannot store to it - typically it is
connected to the output of an auxiliary or data acquisition (DATAACQ) block.
− If Mode is CAScade, SP is pulled from another block; if Mode is AUTOmatic, it
may be stored by the operator or a user program.
− The PIDER block may have one primary or none, depending on whether SP is
configured or not; there is one primary per initializable input.
− RFB and TRFB must be pulled from another block, you cannot store to them.
The RFB input is optional. If the PIDER block is used for external tracking
features only, the RFB input is not required.
− S1 can be triggered by another function block or set by a user-written program.
• The PIDER block assumes PV is within PVEUHI and PVEULO - it applies no range
check - however, PV typically comes from a data acquisition (DATAACQ) block
which applies its own limit and range check.
• SPHILM and SPLOLM define set point operating limits in engineering units.
− The operator is prevented from storing a set point value that is outside these
limits; if the primary or a user program attempts to store a value outside of the
limits, the PIDER block clamps it to the appropriate limit and sets the primary's
windup status.
− The PIDER block provides the SP high/low limits (SPHILM/SPLOLM) to the
primary through BACKCALC. The primary uses this for its output range
(CVEUHI/CVEULO).
• SP contains set point value in engineering units and SPP contains the value in
percent.
− If Mode is AUTOmatic, the operator or a user program may store to either SP or
SPP.
− The PIDER block monitors SP for time-out.
• The RFB and TRFB values typically come from a remote controller. The PIDER
block applies no range check for these parameters.
• The S1 input is a Boolean flag and the values are only On and Off.
Initializable outputs
"Initializable output" and "initializable input" are variable attributes, similar to data type
or access level. A variable with the "initializable" attribute has an associated
BACKCALC variable, and when a connection is created between an initializable input
and initializable output, you can also create a BACKCALC connection. Control Builder
automatically builds the required BACKCALC connections, so you don't have to create
them manually. These "implicit" build connections are "hidden" from view and the
related parameter pins are not exposed on the control chart.
ATTENTION
The PIDER block does not support output initialization, and therefore cannot
have a secondary. Initialization only occurs when the tracking control switch
(S1) is On.
ATTENTION
Be sure you use a FANOUT block to make multiple output connections. We
recommend that you do not make multiple connections from a single PID
output.
Control initialization
The PIDER block does not perform normal initialization and windup processing
associated with secondaries. Initialization occurs when the tracking control switch (S1) is
On.
This block provides the same initialization data to its primary as the normal PID block
• Note that SECINITOPT may be used to ignore initialization requests from the
secondary.
• If the secondary is requesting initialization, the PID block:
− initializes its output
CV = initialization value from the secondary
− sets initialization request parameters for its primary
INITREQ = On
INITVAL = SP
Output bias
If the PIDER block algorithm is configured as Equation A, B, C, or D, no output bias
(OPBIAS) is applied.
The OPBIAS is the sum of the user-specified fixed bias (OPBIAS.FIX) and a calculated
floating bias (OPBIAS.FLOAT). The purpose of the floating bias is to provide a
bumpless transfer when the function block initializes or changes mode as long as the
PIDER block is the first initializable block.
• OPBIAS is recomputed under the following conditions to avoid a bump in the
output. (Note that the PIDER block only applies OPBIAS.FLOAT to the output for
the latter two conditions, when it is the first initializable block.)
− When the function block starts up (that is, goes Active).
− When the function block initializes (for example, the secondary requests
initialization).
− When the mode changes to Auto or Cascade.
462 Experion LX Control Builder Components Theory R110
Honeywell February 2014
13. Regulatory Control
13.10. PIDER (PID with External Reset Feedback) Block
ATTENTION
When the function block goes Active or the Mode changes to Auto or
Cascade, OPBIAS and OPBIAS.FLOAT are recomputed.
• There are no limit checks applied when you set an OPBIAS or OPBIAS.FIX value.
However, after the total bias is added to CV, the result is compared against the
output limits and clamped, if necessary.
• You configure the value for the fixed bias (OPBIAS.FIX) and it is never overwritten
by the floating bias (OPBIAS.FLOAT). This means the total bias will eventually
equal the OPBIAS.FIX , if you configure OPBIAS.RATE to ramp down
OPBIAS.FLOAT.
• You may store to OPBIAS.FIX only if the function block is inactive or the MODE is
Manual; or if it is a PID or PIDFF function block with the CTLEQN set to E. When
you store to OPBIAS.FIX, the following occurs:
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the new
value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
• The OPBIAS.FLOAT is calculated as follows.
Where:
OPBIAS.FLOAT will be zero. However, if the primary does not accept this block's
initialization request because the primary is a FANOUT block or it was configured
to ignore initialization, then OPBIAS.FLOAT value will not be zero.
If OPBIAS.FLOAT is not zero, you can configure it to ramp down to zero through
the OPBIAS.RATE parameter.
• You configure the OPBIAS.RATE to apply a ramp rate to the OPBIAS.FLOAT. It is
only used when the OPBIAS.FLOAT is not zero. The OPBIAS.RATE is expressed
in Engineering Units per minute and may have the following values.
− Zero:
If OPBIAS.RATE is zero, a OPBIAS.FLOAT is calculated and bumpless
transfer is guaranteed. However, if OPBIAS.FLOAT is not zero, it will never
ramp down.
− Non-zero:
If OPBIAS.RATE is not zero, an OPBIAS.FLOAT is calculated and bumpless
transfer is guaranteed. If the OPBIAS.FLOAT is not zero, it is ramped to zero at
the rate you configured for the OPBIAS.RATE parameter.
Where:
− NaN:
When the OPBIAS.RATE is Not a Number (NaN), no OPBIAS.FLOAT is
calculated. This means a bump in the output will occur, if the primary does not
accept this block's initialization value.
• OPHILM and OPLOLM define the normal high and low limits for OP as a percent
of the CV range - these are user-specified values.
− OP is clamped to these limits if the algorithm's calculated result (CV) exceeds
them, or another block or user program attempts to store an OP value that
exceeds them.
− The operator may store an OP value that is outside of these limits.
• OPEXHILM and OPEXLOLM define the extended high and low limits for OP as a
percent of the CV range - these are user-specified values.
− The operator is prevented from storing an OP value that exceeds these limits.
• MAXRFBDEV is the maximum deviation allowed between CV and RFB, in
percent. It is used to provide windup protection for OP.
− If the scaled, integrated deviation of CV from RFB exceeds MAXRFBDEV in
the positive direction, the PIDER block sets the output windup status (ARWOP)
to High, which will prevent CV from going higher. If the deviation exceeds
MAXRFBDEV in the negative direction, it sets ARWOP to Low, which will
prevent CV from going lower. This occurs only if the tracking control switch
(S1) is Off.
Parameter Description
Normal Ramp Rate Normal ramp rate value in engineering units that you
(SPTVNORMRATE) enter. The value can be Not a Number (NaN) or greater
than zero. If value is NaN, it means a "step change" in the
SP, which is the same as a ramp time of zero.
Parameter Description
Max. Ramp Deviation Lets you specify a maximum deviation in engineering units
(SPTVDEVMAX) per minute allowed between PV and SP during ramping.
The value can be NaN or greater than zero. If value is
NaN, it means no ramp deviation checking is done.
You can configure these other SP ramping related parameters to appear as block pins or
monitoring parameters that can be viewed on the block during Control Builder
monitoring, as shown in the following figure. You can access these parameters to invoke
and monitor SP ramping while monitoring the control strategy through Control Builder
or the PID Loop Point Detail display in Station.
Parameter Description
SPTV SP target value that you enter. You can only set SPTV
when the SPTVOPT is Enabled, the SPTVSTATE is Off or
Preset, and the block's mode is Auto or Manual. When you
set SPTV with the block's Control Module active, this
occurs:
Parameter Description
• Preset, or
• Run
The following table includes descriptions of the callouts in the figure above.
Callout Description
1 Block's mode must be Auto and SPTVSTATE must be Preset, before you
can start SP ramping by setting SPTVSTATE to Run with SPTV set to
desired value.
Callout Description
3 You can only set a value for SPTV and SPTVTIME, when:
• SPTVSTATE is Off or Preset, and
ATTENTION
• When SP ramping is Enabled, the SPTVSTATE must be Off before
you can make changes to the SP limits (SPHILM and SPLOLM).
PV tracking
The PV Tracking option sets SP equal to PV when a cascade is broken due either to
function block initialization or operator or program action (such as, setting the mode to
Manual).
You select the Enable PV Tracking selection on the block configuration form to enable
the function (PVTRAKOPT = Track).
Typically, PV tracking is configured for PID blocks in a cascade configuration strategy.
This allows the PIDs to resume control with no error after initialization or when they are
taken out of Manual mode.
If PV tracking is configured, the block sets SP equal to PV (subject to SP limits) when
either of the following conditions exist:
• block is in Manual mode
• block is initializing and not in Auto mode.
ATTENTION
• PV tracking does not occur on recovery from a bad PV.
PID equations
The PIDER block provides four different equations for calculating the PID - the
CTLEQN parameter is used to specify the desired equation.
• Equation A - all three terms (Proportional, Integral, Derivative) act on the error
(PV - SP) as follows:
-1 1 T2S
CV = K * L 1+ + * PVPS - SPPS
T1S 1 + a * T2 S
• Equation B - the proportional and integral terms act on the error (PV - SP) and the
derivative term acts on changes in PV as follows:
-1 1 T2S 1
CV = K * L 1+ + * PVPS - 1 + * SPPS
T1 S 1 + a * T2 S T1S
• This equation is used to eliminate derivative spikes in the control action as a result
of quick changes in SP.
• Equation C - the integral term acts on the error (PV - SP) and the proportional and
derivative terms act on changes in PV as follows:
-1 1 T2S 1
CV = K * L 1+ + * PVPS - * SPPS
T1S 1 + a * T2 S T1S
1
CV = L-1 * PVPS - SPPS
T1S
ATTENTION
To prevent a bump in the output, you must configure the OPBIAS.RATE
parameter for a value (in Engineering Units per minute) other than 0.0
(zero) or NaN (Not a Number) to enable the ramping function for the
floating bias.
PVP = PV in percent
s = La Place operator
SPP = SP in percent
If the tracking switch S1 is Off, this block combines RFB with the PID output as
follows:
If the tracking switch (S1) is On, the PIDER block forces CV to track the tracking value
(TRFB) input as follows:
Where:
s = La Place operator
Gain options
If equation A, B, or C is selected, any of the following gain equations may be chosen:
• Linear Gain - provides a proportional control action that is equal to a constant (K)
times the error.
− This is the most commonly-used gain option - K is a user-specified constant and
has a default value of 1.0.
• Gap Gain - used to reduce the sensitivity of the control action when PV is in a user-
specified band (gap) around the set point.
− Gap size and control action are specified at configuration time through the
following parameters:
K = KLIN
K = KLIN KMODIFGAP
• Nonlinear Gain - provides control action that is proportional to the square of the
error, rather than the error itself.
− Gain (K) is derived as follows:
PV - SP
K = KLIN * NLFORM + NLGAIN *
(PVEUHI - PVEULO)
Where:
• External Gain - where, when gain (K) is selected, it is modified by an input value
that can come from either the process, another function block, or a user program.
− The main use of this option is to compensate for nonlinear process gain - you can
tune the PID gain independently of the normal operating point of the process.
− For example, in controlling the level of a tank whose cross-section is not
constant, the gain could be modified to compensate for the nonlinear rate of
level change that is caused by the changing shape of the tank.
− Gain (K) is derived as follows:
K = KLIN KMODIFEXT
Where:
ATTENTION
The OUTIND parameter has no affect on the block's control operation. The
CTLACTN parameter on the Algorithm tab still supports the output direction of
the block, the OPTDIR parameter on the Main tab for the AOCHANNEL block
form applies the conversion of OP to OPFINAL. You can manipulate the
476 Experion LX Control Builder Components Theory R110
Honeywell February 2014
13. Regulatory Control
13.10. PIDER (PID with External Reset Feedback) Block
WARNING
You cannot always reverse output (OP) resulting from changes you make to a
tuning constant gain (K), integral time (T1) or derivative time (T2) in an online
control loop.
You cannot undo a change in a tuning constant in an online control loop by simply
changing the constant back to its original value. The output (OP) does not jump back to
its original prior value just because you return the constant to its prior value. In this case,
you must put the loop in MANUAL mode and set the output (OP) to the desired value
before returning the loop to AUTO mode.
Timeout monitoring
If mode is CAScade, the block performs timeout monitoring on SP - if a good SP value
is not received within a predefined time, the block invokes timeout processing.
The maximum time between updates is specified by TMOUTTIME (in seconds)
Timeout processing
If mode is CAScade and SP times out, the block does the following:
• Sets the input timeout flag (TMOUTFL)
• Holds SP at its last good value.
• Sheds to the user-specified timeout mode (MODE = TMOUTMODE).
• Requests the primary to initialize.
The block sets its cascade request flag (CASREQFL), if SP times out and sheds to
AUTOmatic mode. This indicates that the block is waiting to return to the CAScade
mode, and it will as soon as it brings a good SP value. When it receives a good SP value,
the block does the following:
• Changes the mode back to CAScade.
• Updates the SP.
You cannot set the CASREQFL. However, it can be cleared by setting the block's
MODE to MANUAL. This allows you to disable the automatic return to Cascade mode.
• The block only sets CASREQFL if the original mode was Cascade, the SP input
times-out, and TMOUTMODE = AUTO.
ATTENTION
If the input is from a connection in another controller in a peer-to-peer
architecture, the actual timeout time equals the configured TMOUTTIME
plus the CDA timeout time. The CDA timeout time equals four times the
configured CEE subscription rate. For example, if the CEE subscription rate
is 100 milliseconds and the TMOUTTIME is 5 seconds, the actual timeout
time for the block is 4 times 100ms plus 5s or 5.4 seconds.
Windup handling
When a windup condition is reached, the block stops calculating the integral term, but
continues to calculate the proportional and derivative term.
• A windup condition exists if:
− PID block has a secondary and the secondary is in windup.
R110 Experion LX Control Builder Components Theory 479
February 2014 Honeywell
13. Regulatory Control
13.10. PIDER (PID with External Reset Feedback) Block
− PID block's output exceeds one of the user-specified output limits (OPHILM,
OPLOLM).
Windup processing
Every regulatory control type block maintains anti-reset windup status for its output
(ARWOP) and each of its initializable inputs (ARWNET). The following table lists the
possible values for ARWOP and ARWNET parameters.
ARWOP computation
The ARWOP indicates if the output (OP) can be raised or lowered. The PID-type
function blocks use ARWOP to restrict integral control. When ARWOP contains a value
other than Normal, the PID block stops integral control in the windup direction. Integral
control continues in the other direction, as does proportional and derivative control. But,
windup status has no impact on proportional and derivative control.
If a function block has a secondary, it fetches the secondary's windup status and
recomputes its ARWOP. The conditions within the function block, such as output being
at its high limit, also affect the ARWOP. The ARWOP is computed as follows, assuming
the block has only one output or that it is not a FANOUT block.
ARWNET computation
When ARWNET is HiLo, stores to SP are not limited, rather this is the status propagated
to the primary. The only limiting anti-reset windup status ever does is to stop integral
action in one or both directions on PID blocks. For any other regulatory control type
block, ARWNET is not used for any kind of limiting. The ARWNET is computed as
follows, assuming the block has only one output or that it is not a FANOUT block.
The CV is NaN
ARWOPIN parameters have on the ARWNET and ARWOP parameters, which are not
user configurable.
NORMAL HI HI
NORMAL LO LO
HI NORMAL HI
HI HI HI
HI LO HILO
HI HILO HILO
LO NORMAL LO
LO HI HILO
LO LO LO
LO HILO HILO
HILO HI HILO
HILO LO HILO
• If S1 is On and the tracking value (TRFB) is bad, the block sets CV to NaN (Bad).
− When the TRFB returns to good, CV is initialized, and the dynamic PID terms
are returned to steady- state. If configured, an initialization request is sent to the
primary.
PIDER parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the PIDER block.
The PIDFF block has three analog inputs - a process variable (PV), a set point (SP), and
a feedforward signal (FF). The difference between PV and SP is the error and this block
calculates a control output (OP) that should drive the error to zero. The feedforward
484 Experion LX Control Builder Components Theory R110
Honeywell February 2014
13. Regulatory Control
13.11. PIDFF (PID with Feedforward) Block
signal (FF) is included in the calculation of the PID's incremental output before the full
value output is accumulated.
The following equations are supported:
• Proportional, Integral, and Derivative (PID) on the error
• Proportional and Integral (PI) on the error and Derivative (D) on changes in PV
• Integral (I) on the error and Proportional and Derivative (PD) on changes in PV
• Integral (I) only
• Proportional (P) only
The PIDFF block may be used to provide feedforward response in a typical PID control
loop application. The following figure shows a PID with feedforward controller being
used with a lead/lag relay to provide dynamic feedforward control for a feed flow
application. In this case, the basic idea is to measure the feed flow variations and
feedforward this information to the appropriate control valve before the closed-loop
system senses that the disturbance has arrived.
The lead/lag relay adds a dynamic or time variable in the feedforward circuit. It can
either advance or delay a signal going through it. The "leads" and "lags" are adjustable so
that a signal going in comes out varying in time over a broad range of shapes.
You can easily configure this control strategy in Control Builder using the PIDFF block
in conjunction with IOCHANNEL and Auxiliary type function blocks, which include
DEADTIME and LEADLAG blocks.
F
T
Lead-Lag
Relay
P1 PV
Each PIDFF block supports the following user configurable attributes. The following
table lists the given name of the "Tab" in the parameter configuration form and then
briefly describes the attributes associated with that Tab. This data is only provided as a
quick document reference, since this same information is included in the on-line context
sensitive Help.
SetPoint • SP (SP) - Lets you specify an initial set point value. The
default value is 0.
• High Limit (SPHILM) - Lets you specify a high limit value
for the SP. If the SP value exceeds this limit, the block
clamps the SP to the limit value and sets the SP high
flag (SPHIFL). The default value is 100.
• Low Limit (SPLOLM) - Lets you specify a low limit value
for the SP. If the SP value falls below this limit, the block
clamps the SP to the limit value and sets the SP low flag
(SPLOFL). The default value is 0.
• Mode (TMOUTMODE) - Lets you select the desired
MODE the block is to assume, if an initializable input
times out, which means the input has not been updated
within a designated timeout time. The selections are
AUTOmatic, BCAScade, CAScade, MANual, NONE, and
NORMAL. The default selection is MANual.
• Time (TMOUTTIME) - Lets you specify a time in
seconds that must expire before the block assumes that
its input update has timed out. The block must be in
CAScade mode for it to monitor its primary input for
timeout. The default setting is 0, which means the
timeout function is disabled.
If the input is from a connection in another controller in a
peer-to-peer architecture, the actual timeout time equals
the configured TMOUTTIME plus the CDA timeout time.
The CDA timeout time equals four times the configured
CEE subscription rate. For example, if the CEE
subscription rate is 100 milliseconds and the
TMOUTTIME is 5 seconds, the actual timeout time for
the block is 4 times 100ms plus 5s or 5.4 seconds.
• Enable Advisory SP Processing (ADVDEVOPT) - Lets
you specify whether or not the block is to generate a
deviation alarm when the PV deviates from a user
specified "advisory" SP value. The default selection is
unchecked (Disabled).
• Advisory SP Value (ADVSP) - Lets you set an advisory
SP value in PV engineering units, when Advisory SP
Processing is enabled. When PV exceeds or deviates
from this value, the block generates an advisory
Output • High Limit (%) (OPHILM) - Lets you specify the output
high limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
to 500 and you enter a High Limit of 90%, the high limit
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
Control Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Insertion Type Lets you include an insertion type from a CAB instances in
the block. See CAB insertion configuration considerations
for regulatory control blocks for more information
Function
A PIDFF requires up to three inputs - a process variable (PV), a set point (SP), and a
feedforward (FF):
• PV is pulled from another function block.
PV is typically pulled from a Data Acquisition (DATAACQ) function block, which
performs PV limit checking and alarming. The PV is non-initializable input.
• SP is pulled from another function block, or you can store a value to it or use a value
from a user program.
If SP is pulled from a primary, the PIDFF's Mode must be Cascade; and if you store
a value or use a user program, Mode must be Manual or Automatic. If Mode is
Cascade, the PIDFF must perform timeout checking on SP (to make sure the primary
is periodically updating it). The SP is an initializable input.
• FF is pulled from another function block.
FF is typically pulled from a LEADLAG function block, which provides dynamic
signal adjustments. The FF is a non-initializable input.
A PIDFF also has the following optional inputs. Typically, these are flags, which may be
stored by the operator or user program to change the normal operation of the PID.
• ESWAUTO, ESWCAS, ESWMAN and SI - Indicates if an external source, such as
a user program, wants to change the PID's Mode:
− If ESWAUTO = On, the external source wants to change the Mode to Auto.
− If ESWCAS = On, the external source wants to change the Mode to Cascade.
− If ESWMAN = On, the external source wants to change the Mode to Manual.
− If SI = On, the external source wants to invoke the PIDFF's safety interlock
logic.
If a BACKCALC connection is made to the secondary, the PIDFF reads BACKCALCIN
from the secondary before calculating its OP:
• BACKCALCIN is a "data container", which means it contains many pieces of
information but is accessed by a single read. Among other things, the information in
BACKCALCIN indicates if the secondary is wound-up or if it wants the PIDFF to
initialize.
• The BACKCALCIN/BACKCALCOUT connection for each secondary used is
automatically built by Control Builder as implicit/hidden connections. This means
you do not have to manually wire BACKCALC connections in Control Builder.
R110 Experion LX Control Builder Components Theory 501
February 2014 Honeywell
13. Regulatory Control
13.11. PIDFF (PID with Feedforward) Block
• The secondary builds BACKCALCIN when it receives a read request from the
primary. This way, BACKCALCIN is guaranteed to contain the most current status.
Functional scenario
This scenario is based on the functional block diagram of a typical feedforward loop
shown in the following figure and it assumes the following:
• The PIDFF's Mode is AUTOmatic. As a result, SP is set by the operator or a user
program.
• PIDFF pulls PV from Data Acquisition (DATAACQ) function block as shown in
the following figure.
• PIDFF pulls FF from the LEADLAG function block as shown in the following
figure.
• The PV, FF, and OP connections are all good which means there are no
communication errors or timeouts.
OP
AICHANNEL LEADLAG
PV P1 PV
The functional steps associated with this PIDFF operating scenario are listed in the
following table.
Step Action
1 The Operator provides a value to the PIDFF1 SP variable (before the PIDFF1
executes).
3 The PIDFF1 checks PVSOURCE and decides whether or not to fetch PV. If
PVSOURCE = Auto, it brings PV from the DATAACQ; otherwise, it simply
uses the current value of PV.
8 The PIDFF1 performs limit checking and alarming (if required) on OP.
• CAS (CAScade)
− If mode is CAScade, SP is pulled from a primary; if the primary is off-control
(that is, inactive or initializing) or the connection is bad, the PIDFF block
invokes timeout processing.
Required inputs
The PIDFF block requires both PV and FF inputs to provide its feedforward function.
The PV and FF inputs must be pulled from other blocks; you cannot store to them.
Typically, they are connected to the output of an auxiliary or data acquisition
(DATAACQ) block.
The SP input is not required, since it does not have to be pulled from another function
block.
• If Mode is CAScade and the SP is pulled from another function block, it receives its
value from an upstream primary and it is an initializable input.
• If Mode is CAScade and the SP is not connected to another function block, the
value of the SP is frozen at the last acquired value.
• If Mode is AUTOmatic, the SP value may be stored by the operator or a user
program.
The PIDFF block may have one primary or none, depending on whether SP is pulled
from another block or not; there is one primary per initializable input.
− The operator is prevented from storing a set point value that is outside these
limits; if the primary or a user program attempts to store a value outside of the
limits, the PID block clamps it to the appropriate limit and sets the primary's
windup status.
• SP contains set point value in engineering units and SPP contains the value in
percent.
− If Mode is AUTOmatic, the operator or a user program may store to either SP or
SPP.
Initializable outputs
"Initializable output" and "initializable input" are variable attributes, similar to data type
or access level. A variable with the "initializable" attribute has an associated
BACKCALC variable, and when a connection is created between an initializable input
and initializable output, you can also create a BACKCALC connection. Control Builder
automatically builds the required BACKCALC connections, so you don't have to create
them manually. These "implicit" build connections are "hidden" from view and the
related parameter pins are not exposed on the control chart.
For example, if you connect OP from a PIDFF block to a PID block or an
AOCHANNEL block, Control Builder automatically creates the BACKCALCOUT to
BACKCALCIN connection.
• OP = Calculated output, in percent.
• OPEU = Calculated output, in engineering units.
You may create a connection to OP or OPEU but not both. Therefore, this block may
have only one secondary. If you do not create a connection to OP or OPEU, then the
block does not have a secondary. Alternately, if you connect OP or OPEU to a non-
initializable input, then this block does not have a secondary. (Note that the default OP
connection pin is exposed on the blocks and the implicit/hidden connection function
automatically makes the appropriate value/status parameter (OPX/OPEUX) connection
when required. For example, if you connect the output from a primary PID block
(PIDA.OP) to the set point of a secondary PID block (PIDB.SP), the implicit/hidden
connection is made to PIDA.OPX to provide value/status data.)
ATTENTION
Be sure you use a FANOUT block to make multiple output connections. We
recommend that you do not make multiple connections from a single PID
output.
Control initialization
The PIDFF block brings initialization requests from its secondary through BACKCALC.
In addition, the secondary may propagate one-shot initialization requests to this block.
• Note that SECINITOPT may be used to ignore initialization requests from the
secondary.
• If the secondary is requesting initialization, the PIDFF block:
− initializes its output
CV = initialization value from the secondary
− sets initialization request parameters for its primary
INITREQ = On
INITVAL = SP
INITMAN = On
Output bias
If the PIDFF block algorithm is configured as Equation E, the output bias (OPBIAS) is
added to the algorithm's Calculated Value (CV) and the result is stored in CV. CV is later
checked against OP limits and, if no limits are exceeded, copied to the output.
If the PIDFF block algorithm is configured as Equation A, B, C, or D, no output bias
(OPBIAS) is applied.
The OPBIAS is the sum of the user-specified fixed bias (OPBIAS.FIX) and a calculated
floating bias (OPBIAS.FLOAT). The purpose of the floating bias is to provide a
bumpless transfer when the function block initializes or changes mode as long as the
PIDFF block is the first initializable block.
• OPBIAS is recomputed under the following conditions to avoid a bump in the
output. (Note that the PIDFF block only applies OPBIAS.FLOAT to the output for
the latter two conditions, when it is the first initializable block.)
− When the function block starts up (that is, goes Active).
− When the function block initializes (for example, the secondary requests
initialization).
− When the mode changes to Auto or Cascade.
• The following occurs when you set the OPBIAS value.
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the
entered value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
ATTENTION
When the function block goes Active or the Mode changes to Auto or
Cascade, OPBIAS and OPBIAS.FLOAT are recomputed.
• There are no limit checks applied when you set an OPBIAS or OPBIAS.FIX value.
However, after the total bias is added to CV, the result is compared against the
output limits and clamped, if necessary.
• You configure the value for the fixed bias (OPBIAS.FIX) and it is never overwritten
by the floating bias (OPBIAS.FLOAT). This means the total bias will eventually
equal the OPBIAS.FIX , if you configure OPBIAS.RATE to ramp down
OPBIAS.FLOAT.
• You may store to OPBIAS.FIX only if the function block is inactive or the MODE is
Manual; or if it is a PID or PIDFF function block with the CTLEQN set to E. When
you store to OPBIAS.FIX, the following occurs:
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the new
value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
• The OPBIAS.FLOAT is calculated as follows.
Where:
If OPBIAS.FLOAT is not zero, you can configure it to ramp down to zero through
the OPBIAS.RATE parameter.
• You configure the OPBIAS.RATE to apply a ramp rate to the OPBIAS.FLOAT. It is
only used when the OPBIAS.FLOAT is not zero. The OPBIAS.RATE is expressed
in Engineering Units per minute and may have the following values.
− Zero:
If OPBIAS.RATE is zero, a OPBIAS.FLOAT is calculated and bumpless
transfer is guaranteed. However, if OPBIAS.FLOAT is not zero, it will never
ramp down.
− Non-zero:
If OPBIAS.RATE is not zero, an OPBIAS.FLOAT is calculated and bumpless
transfer is guaranteed. If the OPBIAS.FLOAT is not zero, it is ramped to zero at
the rate you configured for the OPBIAS.RATE parameter.
Where:
− NaN:
When the OPBIAS.RATE is Not a Number (NaN), no OPBIAS.FLOAT is
calculated. This means a bump in the output will occur, if the primary does not
accept this block's initialization value.
− Note that this PIDFF block brings the secondary's input range regardless of
SECINITOPT (that is, regardless of whether the secondary's initialization and
override data are used).
• OPHILM and OPLOLM define the normal high and low limits for OP as a percent
of the CV range - these are user-specified values.
− OP is clamped to these limits if the algorithm's calculated result (CV) exceeds
them, or another block or user program attempts to store an OP value that
exceeds them, however, the operator may store an OP value that is outside of
these limits.
• OPEXHILM and OPEXLOLM define the extended high and low limits for OP as a
percent of the CV range - these are user-specified values.
− The operator is prevented from storing an OP value that exceeds these limits.
Parameter Description
Normal Ramp Rate Normal ramp rate value in engineering units that you
(SPTVNORMRATE) enter. The value can be Not a Number (NaN) or greater
than zero. If value is NaN, it means a "step change" in the
SP, which is the same as a ramp time of zero.
Max. Ramp Deviation Lets you specify a maximum deviation in engineering units
(SPTVDEVMAX) per minute allowed between PV and SP during ramping.
The value can be NaN or greater than zero. If value is
NaN, it means no ramp deviation checking is done.
You can configure these other SP ramping related parameters to appear as block pins or
monitoring parameters that can be viewed on the block during Control Builder
monitoring, as shown in the following figure. You can access these parameters to invoke
and monitor SP ramping while monitoring the control strategy through Control Builder
or the PID Loop Point Detail display in Station.
Parameter Description
Parameter Description
SPTV SP target value that you enter. You can only set SPTV
when the SPTVOPT is Enabled, the SPTVSTATE is Off or
Preset, and the block's mode is Auto or Manual. When you
set SPTV with the block's Control Module active, this
occurs:
• The block calculates a ramp time (SPTVTIME).
Parameter Description
• Preset, or
• Run
The following table includes descriptions of the callouts in the figure above.
Callout Description
1 Block's mode must be Auto and SPTVSTATE must be Preset, before you
can start SP ramping by setting SPTVSTATE to Run with SPTV set to
desired value.
3 You can only set a value for SPTV and SPTVTIME, when:
• SPTVSTATE is Off or Preset, and
ATTENTION
• When SP ramping is Enabled, the SPTVSTATE must be Off before
you can make changes to the SP limits (SPHILM and SPLOLM).
PV tracking
The PV tracking option sets SP equal to PV when a cascade is broken due either to
function block initialization or operator or program action (such as, setting the mode to
Manual).
PV tracking is configured by setting PVTRAKOPT = Track.
ATTENTION
• PV tracking does not occur on recovery from a bad PV.
(The CVn is computed based on equation E using SP and PV and includes the
OPBIAS terms.)
(The CVn is computed based on equation E using SP and PV and includes the
OPBIAS terms. This ensures that there is no "bump" in the output, when the
feedforward input goes from good to bad.)
(Note: FFLGV is initialized to 1.0. Therefore, if FFn is Bad from the start, then:
− If FFn is okay but the status of FF n-1 is Bad, then CV is kept as is (to prevent a
bump) and CVPID is back-calculated as follows:
(Where CVPID is computed based on equation E using SP and PV and includes the
OPBIAS terms.)
(Note: FFLGV is initialized to 1.0. Therefore, if FFn is Bad from the start, then:
− If FFn is ok but the status of FF n-1 is Bad, then CV is kept as is (to prevent a
bump) and CVPID is back-calculated as follows:
Where:
CVPID = full-value output of the PID block without the FF term (This
is a calculated value and not a user-visible parameter.)
PID equations
The PIDFF block provides five different equations for calculating the PID - the
CTLEQN parameter is used to specify the desired equation.
ATTENTION
The CV term used in the following PID equations is the same as the CVpid
term used in the previous feedforward equations. It represents the full value
output of the PID function without the FF term added.
• Equation A - all three terms (Proportional, Integral, Derivative) act on the error
(PV - SP) as follows:
-1 1 T2S
CV = K * L 1+ + * PVPS - SPPS
T1S 1 + a * T2 S
• Equation B - the proportional and integral terms act on the error (PV - SP) and the
derivative term acts on changes in PV as follows:
-1 1 T2S 1
CV = K * L 1+ + * PVPS - 1 + * SPPS
T1 S 1 + a * T2 S T1S
• This equation is used to eliminate derivative spikes in the control action as a result
of quick changes in SP.
• Equation C - the integral term acts on the error (PV - SP) and the proportional and
derivative terms act on changes in PV as follows:
-1 1 T2S 1
CV = K * L 1+ + * PVPS - * SPPS
T1S 1 + a * T2 S T1S
1
CV = L-1 * PVPS - SPPS
T1S
ATTENTION
Equation E does not work with the override feedback function. It is a whole
value algorithm that bumps the output to PV-SP regardless of the ORFBVAL
preset to CV.
− Output bias processing adds a fixed bias (user specified) and floating bias
(calculated to provide bumpless transfer after initialization or mode change) to
the unbiased CV.
ATTENTION
To prevent a bump in the output, you must configure the OPBIAS.RATE
parameter for a value (in Engineering Units per minute) other than 0.0
(zero) or NaN (Not a Number) to enable the ramping function for the
floating bias.
PVP = PV in percent
s = La Place operator
SPP = SP in percent
Gain options
If PID equation A, B, or C is selected, any of the following gain equations may be
chosen:
• Linear Gain - provides a proportional control action that is equal to a constant (K)
times the error.
− This is the most commonly-used gain option - K is a user-specified constant and
has a default value of 1.0.
• Gap Gain - used to reduce the sensitivity of the control action when PV is in a user-
specified band (gap) around the set point.
− Gap size and control action are specified at configuration time through the
following parameters:
K = KLIN
K = KLIN ∗ KMODIFGAP
• Nonlinear Gain - provides control action that is proportional to the square of the
error, rather than the error itself.
− Gain (K) is derived as follows:
PV - SP
K = KLIN * NLFORM + NLGAIN *
(PVEUHI - PVEULO)
Where:
• External Gain - where, when gain (K) is selected, it is modified by an input value
that can come from either the process, another function block, or a user program.
− The main use of this option is to compensate for nonlinear process gain - you can
tune the PID gain independently of the normal operating point of the process.
− For example, in controlling the level of a tank whose cross-section is not
constant, the gain could be modified to compensate for the nonlinear rate of
level change that is caused by the changing shape of the tank.
− Gain (K) is derived as follows:
K = KLIN KMODIFEXT
Where:
ATTENTION
The OUTIND parameter has no affect on the block's control operation. The
CTLACTN parameter on the Algorithm tab still supports the output direction of
the block, the OPTDIR parameter on the Main tab for the AOCHANNEL block
form applies the conversion of OP to OPFINAL. You can manipulate the
DIRECT/REVERSE selections for the OUTIND, CTLACTN, and OPTDIR
parameters to meet your process and operator needs.
OP 100.0 - Actual OP
The user store of an OP related parameter is intercepted and reversed when OUTIND
equals REVERSE. For example, a store of OPHILM = 80 produces OPLOLM = 100 -
80, so the OPHILM parameter get will then view OPHILM = 100 - 20.
ATTENTION
The swapping/reversal of values will not be done, if the block was loaded with
REVERSE OUTIND configured. The reversal of values will be done only on a
subsequent change to the OUTIND value, if appropriate.
For example: If a PID block is loaded with OPHILM = 95, OPLOLM = 10 and
OUTIND as REVERSE, the OPHILM and OPLOLM after load will still be 95
and 10, respectively.
OP Alarms considerations
When the OUTIND parameter value is set to REVERSE, the OP values displayed for the
high or low CEE Output Alarms are reversed. In the Alarm Summary display, the OP
values of the high alarms and the low alarms are swapped. The Output Alarms display
shall track the value of displayed output parameters. An OUTIND value of REVERSE,
shall show the limit and value subjected to reversal. For example, an OPHI alarm will
have the displayed trip limit set to 100 - (output low limit).
If the OUTIND parameter setting is changed:
• from Direct, DirectDispInd, or ReverseDispInd to Reverse or
• from Reverse to Direct, DirectDispInd, or ReverseDispInd,
a return for the existing Output Alarm condition occurs and a new Output Alarm would
be sent.
WARNING
You cannot always reverse output (OP) resulting from changes you make to a
tuning constant gain (K), integral time (T1) or derivative time (T2) in an online
control loop.
You cannot undo a change in a tuning constant in an online control loop by simply
changing the constant back to its original value. The output (OP) does not jump back to
its original prior value just because you return the constant to its prior value. In this case,
you must put the loop in MANUAL mode and set the output (OP) to the desired value
before returning the loop to AUTO mode.
Timeout monitoring
If mode is CAScade, the PIDFF block performs timeout monitoring on SP - if a good SP
value is not received within a predefined time (TMOUTTIME), the PIDFF block invokes
timeout processing.
The maximum time between updates is specified by TMOUTTIME (in seconds)
Timeout processing
If mode is CAScade and SP times out, the PIDFF block does the following:
• Sets the input timeout flag (TMOUTFL)
• Keeps SP at its last good value.
• Changes the mode to a user-specified TMOUTMODE.
• Requests the primary to initialize.
The PIDFF block sets its cascade request flag (CASREQFL), if SP times out and sheds
to AUTOmatic mode. This indicates that the block is waiting to return to the CAScade
mode, and it will as soon as it brings a good SP value. When it receives a good SP value,
the block does the following:
• Changes the mode back to CAScade.
• Updates the SP.
• Clears CASREQFL.
You cannot set the CASREQFL. However, it can be cleared by setting the block's
MODE to MANUAL.
ATTENTION
If the input is from a connection in another controller in a peer-to-peer
architecture, the actual timeout time equals the configured TMOUTTIME
plus the CDA timeout time. The CDA timeout time equals four times the
configured CEE subscription rate. For example, if the CEE subscription rate
is 100 milliseconds and the TMOUTTIME is 5 seconds, the actual timeout
time for the block is 4 times 100ms plus 5s or 5.4 seconds.
Windup handling
When a windup condition is reached, the PIDFF block stops calculating the integral
term, but continues to calculate the proportional and derivative term.
• A windup condition exists if:
− PIDFF block has a secondary and the secondary is in windup.
− PIDFF block's output exceeds one of the user-specified output limits (OPHILM,
OPLOLM).
Windup processing
Every regulatory control type block maintains anti-reset windup status for its output
(ARWOP) and each of its initializable inputs (ARWNET). The following table lists the
possible values for ARWOP and ARWNET parameters.
ARWOP computation
The ARWOP indicates if the output (OP) can be raised or lowered. The PID-type
function blocks use ARWOP to restrict integral control. When ARWOP contains a value
other than Normal, the PID block stops integral control in the windup direction. Integral
control continues in the other direction, as does proportional and derivative control. But,
windup status has no impact on proportional and derivative control.
If a function block has a secondary, it fetches the secondary's windup status and
recomputes its ARWOP. The conditions within the function block, such as output being
at its high limit, also affect the ARWOP. The ARWOP is computed as follows, assuming
the block has only one output or that it is not a FANOUT block.
ARWNET computation
When ARWNET is HiLo, stores to SP are not limited, rather this is the status propagated
to the primary. The only limiting anti-reset windup status ever does is to stop integral
action in one or both directions on PID blocks. For any other regulatory control type
block, ARWNET is not used for any kind of limiting. The ARWNET is computed as
follows, assuming the block has only one output or that it is not a FANOUT block.
The CV is NaN
NORMAL HI HI
NORMAL LO LO
HI NORMAL HI
HI HI HI
HI LO HILO
HI HILO HILO
LO NORMAL LO
LO HI HILO
LO LO LO
LO HILO HILO
HILO HI HILO
HILO LO HILO
• If the override offset flag is Off and the PID is using either direct or reverse control
action, then:
• If the override offset flag is On and the PID is using direct control action, then:
• If the override offset flag is On and the PID is using reverse control action, then:
Where:
CVPID = full-value output of the PID block without the FF term (This is a
calculated value and not a user-visible parameter.)
K = Overall gain
PVP = PV in percent
SPP = SP in percent
ATTENTION
You can use SECINITOPT to ignore override requests from the secondary.
PIDFF parameters
REFERENCE - INTERNAL
Refer to Control Builder Components Reference for a complete list of the
parameters used with the PIDFF block.
where
Equation
As described in the previous section, a PID block when configured for GAP or non
linear gain will include a gain change component in CV calculation if LEGACYGAP is
set to the default value of FALSE. The PID calculation performed is as follows
CV (t) = CV(t-l) + K * d/dt[ E(t) + 1/ Tl | E(t) dt + T2 E(t)/dt ] +
[ E(t) + 1/ Tl | E(t) dt + T2 E(t)/dt ] * dK/dt
where
CV (t) = Calculated CV during the current execution cycle
CV(t-l) = CV at the end of the last execution cycle
K = Gain
T1 = Integral time
T2 = Derivative time
E(t) = Current error (PV -SP)
If LEGACYGAP is set TRUE, the CV calculation will exclude the gain change
component in the CV calculation and the will be as follows
CV (t) = CV(t-l) + K * d/dt[ E(t) + 1/ Tl | E(t) dt + T2 E(t)/dt ]
Besides this there are no other changes to the behavior of the PID function blocks as a
result of the new LEGACYGAP parameter.
Configuration
The LEGACYGAP configuration parameter will be displayed as a checkbox on the right
side in the algorithm tab of the forms for PID type blocks as shown in the figure below.
The parameter is typically configured before loading the PID blocks. The user (with
ENGRINEER access) may change the value after loading if the FB is inactive or the
block is in Manual mode.
Migration
When PID type function blocks are migrated from older releases to R300, the
LEGACYGAP parameter of PID type blocks will be set to the default value of FALSE.
The POSPROP block requires a process variable (PV) and a set point (SP) as its inputs.
The digital outputs are pulsed at time intervals specified by the cycle time parameter and
the pulse width is proportional to the error signal. It looks like this graphically:
Each POSPROP block supports the following user configurable attributes. The following
table lists the given name of the "Tab" in the parameter configuration form and then
briefly describes the attributes associated with that Tab. This data is only provided as a
quick document reference, since this same information is included in the on-line context
sensitive Help.
SetPoint • SP (SP) - Lets you specify an initial set point value. The
default value is 0.
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
Control Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Insertion Type Lets you include an insertion type from a CAB instances in
the block. See CAB insertion configuration considerations
for regulatory control blocks for more information
Function
The POSPROP block is typically used to step a valve open or closed, raise or lower a
rotary device, or move the plates of a pulp mill refiner together or apart.
The POSPROP block compares the error signal (PV - SP) with an error deadband for the
raise and lower directions at an interval based on the configurable cycle time parameter
(CYCLETIME). You can also configure the raise and lower deadband values that are
denoted as the parameters ERRORDBR and ERRORDBL, respectively.
The block generates a raise pulse, when the PV is less than the SP minus the raise error
deadband (ERRORDBR); or a lower pulse, when the PV is greater than the SP plus the
lower error deadband (ERRORDBL) to reduce the error.
The pulse duration determines the magnitude of a pulse - the longer the duration, the
bigger the pulse. The POSPROP block will not issue a raise or lower pulse that is longer
than the configured cycle time (CYCLETIME) or the respective maximum pulse time
parameter MAXPULSER or MAXPULSEL, whichever is smaller. The block uses the
following values in its pulse duration calculation.
• Error signal (PV - SP)
• Raise or lower gain setting (KR or KL)
• Raise or lower pulse stroke rate (RAISERATE or LOWERRATE)
• Additional raise or lower pulse time (RAISEDEADTM or LOWERDEADTM)
based on stiction compensation (STICTIONR or STICTIONL), when a motor starts
up; or backlash compensation (BACKLASHR or BACKLASHL), when a motor
changes direction.
• Minimum raise or lower pulse time (MINPULSER or MINPULSEL)
The calculation uses the additional pulse time and minimum pulse width parameters to
keep noise from initiating continuous changes to the final control element. This block
prevents instantaneous reversals by adding backlash compensation time (BACKLASHR
or BACKLASHL) before commanding direction changes.
The following figures show examples of position proportional control loops to maintain
a desired valve position using raise and lower pulse outputs or pulsetime output in
conjunction with a pulse length or pulse count block, respectively. In these examples, the
set point (SP) is the desired valve position and the PV is the actual valve position.
Position Proportional
Controller
SP RAISETIME
PV LOWERTIME
100% of scale
0% of scale
100% of scale
0% of scale
Required inputs
The required number of inputs is determined by the mode of the POSPROP block.
• If Mode is CAScade, two inputs are required - PV and SP.
• If Mode is AUTOmatic or MANual, only PV is required.
− SP is an initializable input; PV is non-initializable.
− PV must be pulled from another block; you cannot store to it - typically it is
connected to the output of an auxiliary or data acquisition (DATAACQ) block.
− If Mode is CAScade, SP is pulled from another block; if Mode is AUTOmatic, it
may be stored by the operator.
− The POSPROP block may have one primary or none, depending on whether SP
is configured or not; there is one primary per initializable input.
The optional raise and lower flag inputs (RAISELMFL and LOWERLMFL) may be set
externally to inhibit raise and lower pulses, respectively. These optional inputs can be
pulled from other function blocks.
Output
The POSPROP block has the following initializable outputs:
• RAISETIME = Raise pulse duration.
• LOWERTIME = Lower pulse duration.
• PULSETIME = Pulse duration.
You can connect RAISETIME and LOWERTIME outputs to DOCHANNEL blocks.
You must connect the PULSETIME output to a PULSELENGTH or PULSECOUNT
block whose output is then connected to a DOCHANNEL block. The PULSELENGTH
or PULSECOUNT block sends the pulse duration from the POSPROP block to the
DOCHANNEL block which generates device-specific ON/OFF commands.
(Note that you can connect the PULSETIME or RAISETIME output to the ONPULSE
or OFFPULSE parameter of a DOCHANNEL block to cause a pulse of desired time.
Since the ONPULSE and OFFPULSE parameters only accept positive values, you
cannot connect the LOWERTIME output to these parameters.)
Output ranges
The POSPROP block uses the maximum and minimum pulse parameters to define pulse
duration ranges and limits.
• MAXPULSER and MAXPULSEL define the maximum pulse time in the Raise and
Lower directions, respectively. The POSPROP block will not issue a Raise/Lower
pulse with a duration that exceeds these values. If the output and CYCLETIME are
greater than MAXPULSER/MAXPULSEL, the output is clamped to
MAXPULSER/MAXPULSEL.
• MINPULSER and MINPULSEL define the minimum pulse time in the Raise and
Lower directions, respectively. The POSPROP block will not issue a Raise/Lower
pulse with a duration that is less than these values. If the output is less than
MINPULSER/MINPULSEL, the output retains its old value.
(Note that the POSPROP block does not use these common regulatory control block
range and limit parameters: CVEUHI, CVEULO, OPHILM, OPLOLM, OPEXHILM,
and OPEXLOLM.)
Parameter Description
Normal Ramp Rate Normal ramp rate value in engineering units that you
(SPTVNORMRATE) enter. The value can be Not a Number (NaN) or greater
than zero. If value is NaN, it means a "step change" in the
SP, which is the same as a ramp time of zero.
Parameter Description
Max. Ramp Deviation Lets you specify a maximum deviation in engineering units
(SPTVDEVMAX) per minute allowed between PV and SP during ramping.
The value can be NaN or greater than zero. If value is
NaN, it means no ramp deviation checking is done.
You can configure these other SP ramping related parameters to appear as block pins or
monitoring parameters that can be viewed on the block during Control Builder
monitoring, as shown in the following figure. You can access these parameters to invoke
and monitor SP ramping while monitoring the control strategy through Control Builder
or the Point Detail display in Station.
Parameter Description
SPTV SP target value that you enter. You can only set SPTV
when the SPTVOPT is Enabled, the SPTVSTATE is Off or
Preset, and the block's mode is Auto or Manual. When you
set SPTV with the block's Control Module active, this
occurs:
• The block calculates a ramp time (SPTVTIME) .
Parameter Description
• Preset, or
• Run
The following table includes descriptions of the callouts in the figure above.
Callout Description
1 Block's mode must be Auto and SPTVSTATE must be Preset, before you
can start SP ramping by setting SPTVSTATE to Run with SPTV set to
desired value.
Callout Description
3 You can only set a value for SPTV and SPTVTIME, when:
• SPTVSTATE is Off or Preset, and
ATTENTION
• When SP ramping is Enabled, the SPTVSTATE must be Off before
you can make changes to the SP limits (SPHILM and SPLOLM).
Timeout monitoring
If mode is CAScade, the POSPROP block performs timeout monitoring on SP - if a good
SP value is not received within a predefined time (TMOUTTIME), the POSPROP block
invokes timeout processing.
The maximum time between updates is specified by TMOUTTIME (in seconds)
Timeout processing
If mode is CAScade and SP times out, the POSPROP block does the following:
• Sets the input timeout flag (TMOUTFL)
• Keeps SP at its last good value.
• Changes the mode to a user-specified TMOUTMODE.
• Requests the primary to initialize.
The POSPROP block sets its cascade request flag (CASREQFL), if SP times out and
sheds to AUTOmatic mode. This indicates that the block is waiting to return to the
CAScade mode, and it will as soon as it brings a good SP value. When it receives a good
SP value, the block does the following:
ATTENTION
If the input is from a connection in another controller in a peer-to-peer
architecture, the actual timeout time equals the configured TMOUTTIME
plus the CDA timeout time. The CDA timeout time equals four times the
configured CEE subscription rate. For example, if the CEE subscription rate
is 100 milliseconds and the TMOUTTIME is 5 seconds, the actual timeout
time for the block is 4 times 100ms plus 5s or 5.4 seconds.
Equations
The POSPROP block generates Raise and Lower pulses at a rate specified by the
configurable cycle time (CYCLETIME) parameter. It calculates the pulse duration at the
beginning of each cycle as follows.
• If PVP is less than (SPP - ERRORDBR) and the Raise limit flag (RAISELMFL) is
OFF, then issue a Raise pulse with a duration of:
• If PVP is greater than (SPP + ERRORDBL) and the Lower limit flag
(LOWERLMFL) is OFF, then issue a Lower pulse with a duration of:
Where:
EXTRAPULSETM = The extra pulse time leftover from the last control interval,
if you configured the Extra Pulse Time Option
(EXTRAPULSE) to be ON.
PVP = PV in percent.
SPP = SP in percent.
Control Initialization
The POSPROP block accepts initialization information from its three initializable
outputs: RAISETIME, LOWERTIME, and PULSETIME. If any output requests
initialization, the POSPROP block sets its INITMAN parameter to ON. When no output
requests initialization, the POSPROP block sets its INITMAN parameter to OFF. When
cycling resumes after initialization, the Raise and Lower outputs are both set to OFF (or
their normal states) and the cycle time is restarted.
The SP is set equal to the PV (subject to set point limits), if any of the following
conditions exist:
• Mode is MANual.
• The POSPROP block is being processed for the first time after being activated.
• The POSPROP block is a secondary and is going through one-shot initialization.
configuration form. This is the same as selecting disable as the setting for the
SECINITOPT parameter. The results of the SECINITOPT settings are as follows.
• If SECINITOPT equals Enable, it means the function block should accept
initialization request from the secondary.
• If SECINITOP equals Disable, it means the function block should ignore
initialization request from the secondary.
Windup processing
Every regulatory control type block maintains anti-reset windup status for its output
(ARWOP) and each of its initializable inputs (ARWNET). The following table lists the
possible values for ARWOP and ARWNET parameters.
ARWOP computation
The ARWOP indicates if the output (OP) can be raised or lowered. The PID-type
function blocks use ARWOP to restrict integral control. When ARWOP contains a value
other than Normal, the PID block stops integral control in the windup direction. Integral
control continues in the other direction, as does proportional and derivative control. But,
windup status has no impact on proportional and derivative control.
If a function block has a secondary, it fetches the secondary's windup status and
recomputes its ARWOP. The conditions within the function block, such as output being
at its high limit, also affect the ARWOP. The ARWOP is computed as follows, assuming
the block has only one output or that it is not a FANOUT block.
ARWNET computation
When ARWNET is HiLo, stores to SP are not limited, rather this is the status propagated
to the primary. The only limiting anti-reset windup status ever does is to stop integral
action in one or both directions on PID blocks. For any other regulatory control type
block, ARWNET is not used for any kind of limiting. The ARWNET is computed as
follows, assuming the block has only one output or that it is not a FANOUT block.
The CV is NaN
NORMAL HI HI
NORMAL LO LO
HI NORMAL HI
HI HI HI
HI LO HILO
HI HILO HILO
LO NORMAL LO
LO HI HILO
LO LO LO
LO HILO HILO
HILO HI HILO
HILO LO HILO
POSPROP parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the POSPROP block.
Each PULSECOUNT block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that Tab. This data is only provided
as a quick document reference, since this same information is included in the on-line
context sensitive Help.
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
Control Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Insertion Type Lets you include an insertion type from a CAB instances in
the block. See CAB insertion configuration considerations
for regulatory control blocks for more information
Function
The PULSECOUNT block is typically used in conjunction with a POSPROP block to
step a valve open or closed, raise or lower a rotary device, or move the plates of a pulp
mill refiner together or apart.
The POSPROP block feeds the PULSETIME input parameter to the PULSECOUNT
block. This parameter is an internal structure that contains the pulse width specification
(in seconds). It also contains a Serial Number that changes every time there is a new
pulse width value. The PULSECOUNT block checks for a change in the Serial Number
before reacting to the pulse width specification.
The following figure shows a sample of output pulses generated by the Pulse Count
control algorithm. Keep the following things in mind when viewing the following figure.
• The + PULSETIME or -PULSETIME come from the POSPROP block at the
beginning of a control interval.
• The control interval is a property of the connected POSPROP block.
• The individual pulses are generated in relation to the configured POPERIOD. The
number of pulses is determined as follows: Pulse Count = PULSETIME /
POPERIOD
• The PODIR only changes at the beginning of a control interval. The sample pulse
shown in the following figure has a configured Direction Change Delay
(PDELAYDIRCHG) of non-zero.
PORAISE
POLOWER
PO
PODIR
Required inputs
The PULSECOUNT block requires a pulse time (PULSETIME) input from another
block. This is usually supplied by a POSPROP block.
The POPERIOD input is user configurable in seconds.
The PDELAYDIRCHG input is user configurable in seconds.
The optional LOCALMAN input should come from another block in a logic strategy
where an ON condition means that the CEE is not controlling the output of the device. If
the LOCALMAN (Local Manual Initialization) is True, all the outputs of the
PULSECOUNT block are turned OFF. The back calculation (BCALCOUT),
initialization manual (INITMAN), and initialization request (INITREQ) outputs are
turned ON.
Output
The PULSECOUNT block has the following initializable outputs:
• PORAISE = Pulse output for Raise pulses. These pulses are generated if the pulse
width specified by the PULSETIME input is positive.
• POLOWER = Pulse output for Lower pulses. These pulses are generated if the pulse
width specified by the PULSETIME input is negative.
• PO = Pulse output for both Raise and Lower pulses. These pulses are generated as a
logical OR between the PORAISE and POLOWER pulses.
• PODIR = Direction for PO. This output is OFF for a Lower pulse and is ON for a
Raise pulse.
You normally connect PORAISE/POLOWER or PO/PODIR outputs in pairs to
DOCHANNEL blocks
The PULSECOUNT block has the following status outputs:
• INITMAN = Initialization manual. This output is turned ON, if the LOCALMAN
input is ON or the secondary of the PULSECOUNT block is requesting
initialization. It is turned OFF only if both of the requests turn OFF and the primary
of the PULSECOUNT block has received the request.
• INITREQ = Initialization request. This output is turned ON, if the LOCALMAN
input is ON or the secondary of the PULSECOUNT block is requesting
initialization. It is turned OFF only if both of the requests turn OFF and the primary
of the PULSECOUNT block has received the request.
PULSECOUNT parameters
REFERENCE - INTERNAL
Refer to Control Builder Components Reference for a complete list of the
parameters used with the PULSECOUNT block.
Each PULSELENGTH block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that Tab. This data is only provided
as a quick document reference, since this same information is included in the on-line
context sensitive Help.
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
Control Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Insertion Type Lets you include an insertion type from a CAB instances in
the block. See CAB insertion configuration considerations
for regulatory control blocks for more information
Function
The PULSELENGTH block is typically used in conjunction with a POSPROP block to
step a valve open or closed, raise or lower a rotary device, or move the plates of a pulp
mill refiner together or apart.
The POSPROP block feeds the PULSETIME input parameter to the PULSELENGTH
block. This parameter is an internal structure that contains the pulse width specification
(in seconds). It also contains a Serial Number that changes every time there is a new
pulse width value. The PULSELENGTH block checks for a change in the Serial Number
before reacting to the pulse width specification.
The following figure shows a sample of output pulses generated by the Pulse Length
control algorithm. Keep the following things in mind when viewing the following figure.
• The + PULSETIME or -PULSETIME come from the POSPROP block at the
beginning of a control interval.
• The control interval is a property of the connected POSPROP block.
• The PODIR only changes at the beginning of a control interval. The sample pulse
shown in the following figure has a configured Direction Change Delay
(PDELAYDIRCHG) of Zero (0).
+PULSETIME - PULSETIME
PORAISE
POLOWER
PO
PODIR
Time
Control Interval 1 Control Interval 2
Required inputs
The PULSELENGTH block requires a pulse time (PULSETIME) input from another
block. This is usually supplied by a POSPROP block.
The PDELAYDIRCHG input is user configurable in seconds.
The optional LOCALMAN input should come from another block in a logic strategy
where an ON condition means that the CEE is not controlling the output of the device. If
the LOCALMAN (Local Manual Initialization) is True, all the outputs of the
PULSELENGTH block are turned OFF. The back calculation (BCALCOUT),
initialization manual (INITMAN), and initialization request (INITREQ) outputs are
turned ON.
Output
The PULSELENGTH block has the following initializable outputs:
• PORAISE = Pulse output for Raise pulses. These pulses are generated if the pulse
width specified by the PULSETIME input is positive.
• POLOWER = Pulse output for Lower pulses. These pulses are generated if the pulse
width specified by the PULSETIME input is negative.
• PO = Pulse output for both Raise and Lower pulses. These pulses are generated as a
logical OR between the PORAISE and POLOWER pulses.
• PODIR = Direction for PO. This output is OFF for a Lower pulse and is ON for a
Raise pulse.
You normally connect PORAISE/POLOWER or PO/PODIR outputs in pairs to
DOCHANNEL blocks
The PULSELENGTH block has the following status outputs:
• INITMAN = Initialization manual. This output is turned ON, if the LOCALMAN
input is ON or the secondary of the PULSELENGTH block is requesting
initialization. It is turned OFF only if both of the requests turn OFF and the primary
of the PULSELENGTH block has received the request.
• INITREQ = Initialization request. This output is turned ON, if the LOCALMAN
input is ON or the secondary of the PULSELENGTH block is requesting
initialization. It is turned OFF only if both of the requests turn OFF and the primary
of the PULSELENGTH block has received the request.
PULSELENGTH parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the PULSELENGTH block.
The RAMPSOAK block has one analog input identified as a process variable (PV). The
block monitors the PV value and guarantees that its output (OP) will not deviate from the
input (PV) by more than the user configured limits.
Each RAMPSOAK block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that Tab. This data is only provided
as a quick document reference, since this same information is included in the on-line
context sensitive Help.
Output • High Limit (%) (OPHILM) - Lets you specify the output
high limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
to 500 and you enter a High Limit of 90%, the high limit
in engineering units is 90% times 450 or 405 + 50
(CVEULO) equals 455. This check is not applied for a
function block that is in the MANual mode. The default
value is 105%. (Note that you cannot change this value
through Monitoring mode after the configuration is
loaded in the Controller.)
• Low Limit (%) (OPLOLM) - Lets you specify the output
low limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
to 500 and you enter a Low Limit of 10%, the low limit in
engineering units is 10% times 450 or 45 + 50
(CVEULO) equals 95. This check is not applied for a
function block that is in the MANual mode. The default
value is -5%. (Note that you cannot change this value
through Monitoring mode after the configuration is
loaded in the Controller.)
• Extended High Limit (%) (OPEXHILM) - Lets you specify
the output extended high limit as a percent of the
Calculated Variable range (CVEUHI - CVEULO). For
example, If the CV range is 50 to 500 and you use the
default value of 106.9%, the extended high limit in
engineering units is 106.9% times 450 or 481.05 + 50
(CVEULO) equals 531.05. This check is not applied for a
function block that is in the MANual mode. The default
value is 106.9%. (Note that you cannot change this value
578 Experion LX Control Builder Components Theory R110
Honeywell February 2014
13. Regulatory Control
13.16. RAMPSOAK Block
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
Control Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Insertion Type Lets you include an insertion type from a CAB instances in
the block. See CAB insertion configuration considerations
Function
The RAMPSOAK block is typically used for automatic temperature cycling in furnaces
and ovens. It can also be used for automatic startup of units and for simple batch-
sequence control where the batch sequence is part of a process that is otherwise a
continuous process.
The RAMPSOAK block usually feeds its output (OP) to the set point of a PID block.
The PID block uses the PID algorithm to control a process variable (PV) according to the
set point versus time profile OP. The PV input to the RAMPSOAK block is normally the
same PV input used for the PID block.
The following figure shows a simple functional diagram of a PID loop with its set point
driven by the output of a RAMPSOAK block according to the configured ramp and soak
segments.
Ramp/Soak
Programmer PID Controller
OP SP
OP
PV PV
Ramp/Soak Profile
Soak Value 2
Soak Time 2
2 Ra
R ate Segment 4 m
OP Se p R
Soak Value 1 mp nt
3
gm at
Ra me en e 3
Soak Time1 g
Se t5
1
Start Time
gm ate
Segment 6
Ra
Event 1
Time
The RAMPSOAK block provides the following functions for a running ramp/soak
profile.
• Calculates its output based on whether the current segment is a ramp or a soak.
− If the current segment is a ramp, the block calculates the ramp output. If a
guaranteed ramp rate was requested, the block makes sure the output does not
deviate from the input by more than the user configured deviation
(MAXRAMPDEV[n]).
− If the current segment is a soak, the block calculates the soak output and updates
the soak timers. If a guaranteed soak was requested, the block makes sure that
the soak time does not transpire while the PV and CV are outside the user
configured deviation limits (MAXHISOAKDEV[n] and
MAXLOSOAKDEV[n]). The block stops the soak timer when the soak value
exceeds the user configured deviation. It restarts the timer when the soak value
returns to within limits.
• Updates all the events configured for the current profile. The block sets these timers
based on the user configured event parameters: EVENTSEGID[n,e],
EVENTBGNTIME[n,e], and EVENTENDTIME[n,e].
Required inputs
The RAMPSOAK block only requires a PV input for the guaranteed ramp option.
− PV is non-initializable.
− PV must be pulled from another block; you cannot store to it - typically it is
connected to the output of an auxiliary or data acquisition (DATAACQ) block.
Initializable outputs
"Initializable output" and "initializable input" are variable attributes, similar to data type
or access level. A variable with the "initializable" attribute has an associated
BACKCALC variable, and when a connection is created between an initializable input
and initializable output, you can also create a BACKCALC connection. Control Builder
automatically builds the required BACKCALC connections, so you don't have to create
them manually. These "implicit" build connections are "hidden" from view and the
related parameter pins are not exposed on the control chart.
Mode handling
The RAMPSOAK block supports the AUTOmatic and MANual modes.
ATTENTION
You must select MANual as the configuration setting for the MODE parameter
on the RAMPSOAK block's configuration form in the Control Builder Project
tree. Control Builder generates an error if you try to load a RAMPSOAK block
with a MODE configuration of AUTOmatic to the Controller. The MODE of the
RAMPSOAK block must be MANual after it is loaded to the Controller.
• You set the mode to AUTOmatic to start a ramp/soak profile. When the profile is
running, you cannot adjust the output (OP) or the profile variables such as ramp rate,
soak value, and soak time.
• You set the mode to MANual to stop a ramp/soak profile, including all timers. When
a profile is stopped, you can change the output (OP) and adjust the profile variables
including the current segment (CURSEGID) and the remaining soak time
(REMSOAKTIME), if the current segment is a soak. If you change the current
segment, the profile starts at the new segment when you change from MANual to
AUTOmatic mode. You cannot add or delete profiles, ramp/soak pairs or events
once a configuration is loaded into the Controller. Also, Control Builder does not
allow online changes in profile variables such as Rate, Soak Value, and Soak Time
Hold command
The hold command (HOLDCMD) parameter allows another function block or user
program to stop the profile until some user defined condition is met.
• When the HOLDCMD changes from OFF to ON, the profile stops, including all
timers.
• When the HOLDCMD changes from ON to OFF, the profile starts where it left off.
Profile statistics
Since the profile may be stopped or held for several reasons, the actual profile execution
may be quite different from the configured profile definition. The RAMPSOAK block
maintains the following execution profile statistic parameters.
• ACTRAMPRATE[n,s] - The actual rate for each ramp segment in engineering units
per minute.
• ACTSOAKVAL[n,s] - The actual end value for each ramp segment in engineering
units.
• ACTSOAKTIME[n,s] - The actual duration of each soak segment in minutes.
• ACTSTARTSEG[n] - The actual starting segment number for each profile.
• ACTSTARTOP[n] - The actual starting output (OP) value for each profile.
Where "n" is the profile number and "s" refers to the pair id.
You can also compare the graphical representation of the configured profile and the
actual profile through the Profile Graph and Active Profile Graph tabs in the block
configuration form, when monitoring operation through the Monitoring tab in Control
Builder.
Control initialization
The RAMPSOAK block brings initialization requests from its secondary through
BACKCALC. In addition, the secondary may propagate one-shot initialization requests
to this block.
• Note that SECINITOPT may be used to ignore initialization requests from the
secondary.
• If the secondary is requesting initialization, the RAMPSOAK block:
− initializes its output
CV = initialization value from the secondary
− sets initialization request parameters for its primary
Windup processing
Every regulatory control type block maintains anti-reset windup status for its output
(ARWOP) and each of its initializable inputs (ARWNET). The following table lists the
possible values for ARWOP and ARWNET parameters.
ARWOP computation
The ARWOP indicates if the output (OP) can be raised or lowered. The PID-type
function blocks use ARWOP to restrict integral control. When ARWOP contains a value
other than Normal, the PID block stops integral control in the windup direction. Integral
control continues in the other direction, as does proportional and derivative control. But,
windup status has no impact on proportional and derivative control.
If a function block has a secondary, it fetches the secondary's windup status and
recomputes its ARWOP. The conditions within the function block, such as output being
at its high limit, also affect the ARWOP. The ARWOP is computed as follows, assuming
the block has only one output or that it is not a FANOUT block.
ARWNET computation
When ARWNET is HiLo, stores to SP are not limited, rather this is the status propagated
to the primary. The only limiting anti-reset windup status ever does is to stop integral
action in one or both directions on PID blocks. For any other regulatory control type
R110 Experion LX Control Builder Components Theory 593
February 2014 Honeywell
13. Regulatory Control
13.16. RAMPSOAK Block
block, ARWNET is not used for any kind of limiting. The ARWNET is computed as
follows, assuming the block has only one output or that it is not a FANOUT block.
The CV is NaN
NORMAL HI HI
NORMAL LO LO
HI NORMAL HI
HI HI HI
HI LO HILO
HI HILO HILO
LO NORMAL LO
LO HI HILO
LO LO LO
LO HILO HILO
HILO HI HILO
HILO LO HILO
RAMPSOAK parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the RAMPSOAK block.
Each RATIOBIAS block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that Tab. This data is only provided
596 Experion LX Control Builder Components Theory R110
Honeywell February 2014
13. Regulatory Control
13.17. RATIOBIAS Block
as a quick document reference, since this same information is included in the on-line
context sensitive Help.
Output • High Limit (%) (OPHILM) - Lets you specify the output
high limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
to 500 and you enter a High Limit of 90%, the high limit
in engineering units is 90% times 450 or 405 + 50
(CVEULO) equals 455. This check is not applied for a
function block that is in the MANual mode. The default
value is 105%.
• Low Limit (%) (OPLOLM) - Lets you specify the output
low limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
to 500 and you enter a Low Limit of 10%, the low limit in
engineering units is 10% times 450 or 45 + 50
(CVEULO) equals 95. This check is not applied for a
function block that is in the MANual mode. The default
value is -5%.
• Extended High Limit (%) (OPEXHILM) - Lets you specify
the output extended high limit as a percent of the
Calculated Variable range (CVEUHI - CVEULO). For
example, If the CV range is 50 to 500 and you use the
default value of 106.9%, the extended high limit in
engineering units is 106.9% times 450 or 481.05 + 50
(CVEULO) equals 531.05. This check is not applied for a
function block that is in the MANual mode. The default
value is 106.9%.
• Extended Low Limit (%) (OPEXLOLM) - Lets you specify
the output extended low limit as a percent of the
Calculated Variable range (CVEUHI - CVEULO). For
example, If the CV range is 50 to 500 and you use the
default value of -6.9%, the extended low limit in
engineering units is -6.9% times 450 or -31.05 + 50
(CVEULO) equals 18.95. This check is not applied for a
600 Experion LX Control Builder Components Theory R110
Honeywell February 2014
13. Regulatory Control
13.17. RATIOBIAS Block
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
Control Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Insertion Type Lets you include an insertion type from a CAB instances in
the block. See CAB insertion configuration considerations
for regulatory control blocks for more information
Function
Lets you implement a form of ratio control by using this block between two PID blocks.
In this case, the output from one PID block is used as the X1 input to the RATIOBIAS
block and the output from the RATIOBIAS block is used as the SP input to the second
PID block.
Configuration example
The following figure and its companion callout description table show a sample
configuration that uses a RATIOBIAS block to form a ratio control loop for quick
reference. The view in the following figure depicts a configuration in Project mode.
The following table includes descriptions of the callouts in the figure above.
Callout Description
Callout Description
1 Use the PV parameter connection to carry data from the analog input to the
other block. The default PV connection is exposed, but the implicit/hidden
connection function automatically makes a connection to a value/status
parameter (PVVALSTS) when it is required.
2 Use the DATAACQ block to define input range values and provide alarm
monitoring on the analog input.
4 Use the REGCALC block output (OP) to provide the RT input based on
assigning expression 1 as its CV source. The default OP connection is
exposed, but the implicit/hidden connection function automatically makes a
connection to a value/status parameter (OPX/OPEUX) when it is required.
5 Use the PID block output (OP) to provide the X1 input. The default OP
connection is exposed, but the implicit/hidden connection function
automatically makes a connection to a value/status parameter
(OPX/OPEUX) when it is required.
If Mode is . . . Then,
Manual (MAN) the output can be set by the operator or a user program.
The X1 and RT inputs are ignored. The block continually
initializes both primaries, while in this mode.
Automatic (AUTO) the X1 input comes from another function block and the RT
input can be set by the operator or a user program. The
block continually initializes the RT primary, while in this
mode.
If Mode is . . . Then,
Cascade (CAS) both X1 and RT inputs come from other function blocks.
This block requests both primaries to initialize when the mode changes from CAScade to
MANual. This block requests only one primary to initialize when the mode changes from
CAScade to AUTOmatic. This block requests no primary to initialize when the mode
changes from MANual to CAScade. However, it always requests the X1 primary to
initialize first, and then initializes the RT based on whether or not the X1 initialization
was successful.
Required inputs
A RATIOBIAS block requires one or two inputs depending on the block's Mode, as
follows.
• Both X1 and RT are initializable inputs. This means the block can have one or two
primaries depending upon whether the RT input is required or not. There is one
primary for each initializable input.
• The X1 input must come from another function block. You cannot set this value.
• The RT input must come from another function block, if the Mode is Cascade. If the
Mode is Auto, you can set the value for RT or it can come from a user program.
− The operator is prevented from storing a RT value that is outside these limits; if
the primary or a user program attempts to store a value outside of the limits, this
block clamps it to the appropriate limit and sets the RT primary's windup status.
Initializable outputs
"Initializable output" and "initializable input" are variable attributes, similar to data type
or access level. A parameter with the "initializable" attribute has an associated
BACKCALC parameter, and when a connection is created between an initializable input
and initializable output, you can also create a BACKCALC connection. Control Builder
automatically builds the required BACKCALC connections, so you don't have to create
them manually. These "implicit" build connections are "hidden" from view and the
related parameter pins are not exposed on the control chart.
For example, if you connect OP from a RATIONBIAS block to SP on a PID block,
Control Builder automatically creates the BACKCALCOUT to BACKCALCIN
connection.
• The RATIOBIAS block has the following initializable outputs:
− OP = calculated output in percent.
− OPEU = calculated output in engineering units.
You may create a connection to OP or OPEU but not both. Therefore, this block may
have only one secondary. If you do not create a connection to OP or OPEU, then the
block does not have a secondary. Alternately, if you connect OP or OPEU to a non-
initializable input, then this block does not have a secondary. (Note that the default OP
connection pin is exposed on the blocks and the implicit/hidden connection function
automatically makes the appropriate value/status parameter (OPX/OPEUX) connection
when required. For example, if you connect the output from a RATIOBIAS block
(RATIOBIAS.OP) to the set point of a PID block (PIDA.SP), the implicit/hidden
connection is made to RATIOBIAS.OPX to provide value/status data.)
ATTENTION
Be sure you use a FANOUT block to make multiple output connections. We
recommend that you do not make multiple connections from a single
RATIOBIAS output.
If this block has a secondary, it gets the secondary's input range through BACKCALC
and sets its CV range to that. If it has no secondary, CVEUHI and CVEULO track the
X1 input range (XEUHI and XEULO).
ATTENTION
This block gets the secondary's input range regardless of SECINITOPT.
This means regardless of whether the secondary's initialization and
override data will be used.
OPHILM and OPLOLM define the normal high and low limits for OP, as a percent of
the CV range. These are user-specified values.
OP will be clamped to these limits if the algorithm's calculated result (CV) exceeds them,
or another function block or user program attempts to store an OP value that exceeds
them. However, the operator may store an OP value that is outside these limits.
OPHILM and OPLOLM define the extended high and low limits for OP, as a percent of
the CV range. These are user-specified values.
The operator is prevented from storing an OP value that exceeds these limits.
This block calculates CV using this equation:
• CV = X1 RT + OPBIAS.FIX + OPBIAS.FLOAT
Control initialization
The RATIOBIAS block brings initialization requests from its secondary through
BACKCALC. In addition, the secondary may propagate one-shot initialization requests
to this block. (Note that SECINITOPT may be used to ignore initialization requests from
the secondary.)
If the secondary is requesting initialization, the RATIOBIAS block:
• initializes its output:
− CV = initialization value from the secondary
• calculates initialization values for the X1 and RT primaries:
− INITVAL[1] = (CV - OPBIAS.FIX) / RT
− INITVAL[2] = (CV - OPBIAS.FIX) / INITVAL[1]
(If the calculated INITVAL[2] value exceeds either the high or low ratio limit
(RTHILM or RTLOLM), it is clamped to the limit.)
Where:
In Auto mode, the RT and BIAS values are set by the operator
or a user program.
In normal Auto mode operation, the RT and BIAS values are set by the operator or a user
program regardless of the RBOPTION selection.
In normal Cascade mode operation, the RT value is fetched from the upstream function
block and the BIAS value is set by the operator or a user program regardless of the
RBOPTION selection.
Output bias
The output bias (OPBIAS) is added to the algorithm's Calculated Value (CV) and the
result is stored in CV. CV is later checked against OP limits and, if no limits are
exceeded, copied to the output.
The OPBIAS is the sum of the user-specified fixed bias (OPBIAS.FIX) and a calculated
floating bias (OPBIAS.FLOAT). The purpose of the floating bias is to provide a
bumpless transfer when the function block initializes or changes mode.
• OPBIAS is recomputed under the following conditions to avoid a bump in the
output. (Note that the RATIOBIAS block only applies OPBIAS.FLOAT to the
output for the latter two conditions, when it is the first initializable block.)
− When the function block starts up (that is, goes Active).
− When the function block initializes (for example, the secondary requests
initialization).
− When the mode changes to Auto or Cascade.
• The following occurs when you set the OPBIAS value.
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the
entered value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
ATTENTION
When the function block goes Active or the Mode changes to Auto or
Cascade, OPBIAS and OPBIAS.FLOAT are recomputed.
• There are no limit checks applied when you set an OPBIAS or OPBIAS.FIX value.
However, after the total bias is added to CV, the result is compared against the
output limits and clamped, if necessary.
• You configure the value for the fixed bias (OPBIAS.FIX) and it is never overwritten
by the floating bias (OPBIAS.FLOAT). This means the total bias will eventually
equal the OPBIAS.FIX , if you configure OPBIAS.RATE to ramp down
OPBIAS.FLOAT.
• You may store to OPBIAS.FIX only if the function block is inactive or the MODE is
Manual; or if it is a PID or PIDFF function block with the CTLEQN set to E. When
you store to OPBIAS.FIX, the following occurs:
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the new
value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
• The OPBIAS.FLOAT is calculated as follows.
Where:
If OPBIAS.FLOAT is not zero, you can configure it to ramp down to zero through
the OPBIAS.RATE parameter.
• You configure the OPBIAS.RATE to apply a ramp rate to the OPBIAS.FLOAT. It is
only used when the OPBIAS.FLOAT is not zero. The OPBIAS.RATE is expressed
in Engineering Units per minute and may have the following values.
− Zero:
If OPBIAS.RATE is zero, a OPBIAS.FLOAT is calculated and bumpless
transfer is guaranteed. However, if OPBIAS.FLOAT is not zero, it will never
ramp down.
− Non-zero:
If OPBIAS.RATE is not zero, an OPBIAS.FLOAT is calculated and bumpless
transfer is guaranteed. If the OPBIAS.FLOAT is not zero, it is ramped to zero at
the rate you configured for the OPBIAS.RATE parameter.
The function block ramps the OPBIAS.FLOAT to zero by applying the
following calculation each time it executes.
OPBIAS.FLOAT = OPBIAS.FLOAT - (OPBIAS.RATE / cycles_per_Min)
Where:
− NaN:
When the OPBIAS.RATE is Not a Number (NaN), no OPBIAS.FLOAT is
calculated. This means a bump in the output will occur, if the primary does not
accept this block's initialization value.
Timeout monitoring
If mode is CAScade, the RATIOBIAS block performs time-out monitoring on X1 and
RT - if good X1 and RT values are not received within a predefined time
(TMOUTTIME), the RATIOBIAS block invokes timeout processing.
Timeout processing
• If RT times out, the RATIOBIAS block does the following:
− Holds RT at its last good value.
− Changes the mode to a user-specified TMOUTMODE.
− Requests the RT primary to initialize.
• If X1 times out, the RATIOBIAS block does the following:
− Sets the X1 value to NaN. This causes CV to go to NaN, which initializes the RT
and X1 primaries.
If RT times out and the block sheds to AUTO mode, it sets the Cascade Request Flag
(CASREQFL). When CASREQFL is set, it means the block is waiting to return to the
Cascade mode as soon as it gets a good RT value. You can disable the return to Cascade
mode by manually clearing the CASREQFL or changing the mode.
ATTENTION
If the input is from a connection in another controller in a peer-to-peer
architecture, the actual timeout time equals the configured TMOUTTIME
plus the CDA timeout time. The CDA timeout time equals four times the
configured CEE subscription rate. For example, if the CEE subscription rate
is 100 milliseconds and the TMOUTTIME is 5 seconds, the actual timeout
time for the block is 4 times 100ms plus 5s or 5.4 seconds.
Where:
ATTENTION
You can use SECINITOPT to ignore override requests from the secondary.
ATTENTION
The OUTIND parameter has no affect on the block's control operation. The
CTLACTN parameter on the Algorithm tab still supports the output direction of
the block, the OPTDIR parameter on the Main tab for the AOCHANNEL block
form applies the conversion of OP to OPFINAL. You can manipulate the
DIRECT/REVERSE selections for the OUTIND, CTLACTN, and OPTDIR
parameters to meet your process and operator needs.
OP 100.0 - Actual OP
The user store of an OP related parameter is intercepted and reversed when OUTIND
equals REVERSE. For example, a store of OPHILM = 80 produces OPLOLM = 100 -
80, so the OPHILM parameter get will then view OPHILM = 100 - 20.
ATTENTION
The swapping/reversal of values will not be done, if the block was loaded with
REVERSE OUTIND configured. The reversal of values will be done only on a
subsequent change to the OUTIND value, if appropriate.
For example: If a PID block is loaded with OPHILM = 95, OPLOLM = 10 and
OUTIND as REVERSE, the OPHILM and OPLOLM after load will still be 95
and 10, respectively.
OP Alarms considerations
When the OUTIND parameter value is set to REVERSE, the OP values displayed for the
high or low CEE Output Alarms are reversed. In the Alarm Summary display, the OP
values of the high alarms and the low alarms are swapped. The Output Alarms display
shall track the value of displayed output parameters. An OUTIND value of REVERSE,
shall show the limit and value subjected to reversal. For example, an OPHI alarm will
have the displayed trip limit set to 100 - (output low limit).
If the OUTIND parameter setting is changed:
• from Direct, DirectDispInd, or ReverseDispInd to Reverse or
• from Reverse to Direct, DirectDispInd, or ReverseDispInd,
a return for the existing Output Alarm condition occurs and a new Output Alarm would
be sent.
Windup handling
The RATIOBIAS block computes these three anti-reset windup status parameters.
• ARWOP
• ARWNET[1]
• ARWNET[2]
The ARWOP parameter indicates if OP is woundup. OP is woundup, if it is clamped or
the secondary is in windup. ARWOP is computed as follows. (The secondary's windup
status comes through BACKCALC.)
Windup processing
Every regulatory control type block maintains anti-reset windup status for its output
(ARWOP) and each of its initializable inputs (ARWNET). The following table lists the
possible values for ARWOP and ARWNET parameters.
ARWOP computation
The ARWOP indicates if the output (OP) can be raised or lowered. The PID-type
function blocks use ARWOP to restrict integral control. When ARWOP contains a value
other than Normal, the PID block stops integral control in the windup direction. Integral
control continues in the other direction, as does proportional and derivative control. But,
windup status has no impact on proportional and derivative control.
If a function block has a secondary, it fetches the secondary's windup status and
recomputes its ARWOP. The conditions within the function block, such as output being
at its high limit, also affect the ARWOP. The ARWOP is computed as follows, assuming
the block has only one output or that it is not a FANOUT block.
ARWNET computation
When ARWNET is HiLo, stores to SP are not limited, rather this is the status propagated
to the primary. The only limiting anti-reset windup status ever does is to stop integral
action in one or both directions on PID blocks. For any other regulatory control type
R110 Experion LX Control Builder Components Theory 621
February 2014 Honeywell
13. Regulatory Control
13.17. RATIOBIAS Block
block, ARWNET is not used for any kind of limiting. The ARWNET is computed as
follows, assuming the block has only one output or that it is not a FANOUT block.
The CV is NaN
NORMAL HI HI
NORMAL LO LO
HI NORMAL HI
HI HI HI
HI LO HILO
HI HILO HILO
LO NORMAL LO
LO HI HILO
LO LO LO
LO HILO HILO
HILO HI HILO
HILO LO HILO
RATIOBIAS parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the RATIOBIAS block.
Each RATIOCTL block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that Tab. This data is only provided
as a quick document reference, since this same information is included in the on-line
context sensitive Help.
Set Point • SP (SP) - Lets you specify an initial set point value. The
default value is 0.
• High Limit (SPHILM) - Lets you specify a high limit value
for the SP. If the SP value exceeds this limit, the block
clamps the SP to the limit value and sets the SP high
flag (SPHIFL). The default value is 100.
• Low Limit SPLOLM) - Lets you specify a low limit value
for the SP. If the SP value falls below this limit, the block
clamps the SP to the limit value and sets the SP low flag
(SPLOFL). The default value is 0.
• Mode (TMOUTMODE) - Lets you select the desired
MODE the block is to assume, if an initializable input
times out, which means the input has not been updated
within a designated timeout time. The selections are
AUTOmatic, BCAScade, CAScade, MANual, NONE, and
NORMAL. The default selection is MANual.
• Time (TMOUTTIME) - Lets you specify a time in
seconds that must expire before the block assumes that
its input update has timed out. The block must be in
CAScade mode for it to monitor its primary input for
timeout. The default setting is 0, which means the
timeout function is disabled.
If the input is from a connection in another controller in a
peer-to-peer architecture, the actual timeout time equals
the configured TMOUTTIME plus the CDA timeout time.
The CDA timeout time equals four times the configured
CEE subscription rate. For example, if the CEE
subscription rate is 100 milliseconds and the
TMOUTTIME is 5 seconds, the actual timeout time for
the block is 4 times 100ms plus 5s or 5.4 seconds.
• Enable Advisory SP Processing (ADVDEVOPT) - Lets
you specify whether or not the block is to generate a
deviation alarm when the PV deviates from a user
Output • High Limit (%) (OPHILM) - Lets you specify the output
high limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
to 500 and you enter a High Limit of 90%, the high limit
in engineering units is 90% times 450 or 405 + 50
(CVEULO) equals 455. This check is not applied for a
function block that is in the MANual mode. The default
value is 105%.
• Low Limit (%) (OPLOLM) - Lets you specify the output
low limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
to 500 and you enter a Low Limit of 10%, the low limit in
Identification Lets you view the template properties for the block. You
need the Template license to use this form.
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
Control Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Insertion Type Lets you include an insertion type from a CAB instances in
the block. See CAB insertion configuration considerations
for regulatory control blocks for more information
Function
The block calculates the target value of the controlled flow (OP) and the actual ratio
between the flows (PV) as outputs. OP is the value of the controlled flow, which will
maintain the target ratio between itself and the uncontrolled flow.
The RATIOCTL block provides four user-selectable methods for calculating the ratio
between the flows (PV). The target value for the controlled flow (OP) is calculated
according to the selected method for calculating PV.
The block applies a user-specified bias to the output. It does not apply a user-specified
gain. The bias may be fixed (stored manually or by a program) or external (fetched from
another function block).
The block also lets you specify a scale factor and bias for each flow. These values may
also be fixed or external.
Configuration example
The following figure shows a sample configuration that uses a RATIOCTL block to form
a ratio control loop for quick reference. The view in the following figure depicts a
configuration in Project mode.
The output of the RATIOCTL block is normally used as the set point of a PID, which
controls the controlled flow, X1.
water for each gallon of juice concentrate. This algorithm helps to produce different
concentrations of orange juice by controlling the ratio set point.
If Mode is . . . Then,
Manual (MAN) the block does not compute OP; it maintains the user-
specified OP value and ignores all input.
Note that the block whose MODE was changed does not
initialize.
Automatic (AUTO) The function block derives OP and the initializable input
(SP) may be stored by the operator or a user program.
Cascade (CAS) The function block fetches its intializable input (SP) from
the primary, and calculates OP. The primary may be on-
node or off.
Required inputs
• A RATIOCTL block requires these three inputs:
− X1 - the actual value of the controlled flow.
− X2 - the actual value of the uncontrolled flow
− SP - the target ratio between the controlled and uncontrolled flows.
• The SP is an initializable input. This means the block can have one primary
depending upon whether the SP input is configured or not. There is one primary for
each initializable input.
• The X1and X2 inputs must come from other function blocks. You cannot store to
them.
• If Mode is Cascade, SP is pulled from another function block. If Mode is Automatic,
it may be stored by the operator or a user program.
Initializable outputs
"Initializable output" and "initializable input" are variable attributes, similar to data type
or access level. A parameter with the "initializable" attribute has an associated
BACKCALC parameter, and when a connection is created between an initializable input
and initializable output, you can also create a BACKCALC connection. Control Builder
automatically builds the required BACKCALC connections, so you don't have to create
them manually. These "implicit" build connections are "hidden" from view and the
related parameter pins are not exposed on the control chart.
For example, if you connect OP from a RATIOCTL block to SP on a PID block, Control
Builder automatically creates the BACKCALCOUT to BACKCALCIN connection.
• The RATIOCTL block has the following initializable outputs:
− OP = calculated output in percent.
− OPEU = calculated output in engineering units.
You may create a connection to OP or OPEU but not both. Therefore, this block may
have only one secondary. If you do not create a connection to OP or OPEU, then the
block does not have a secondary. Alternately, if you connect OP or OPEU to a non-
initializable input, then this block does not have a secondary. (Note that the default OP
connection pin is exposed on the blocks and the implicit/hidden connection function
automatically makes the appropriate value/status parameter (OPX/OPEUX) connection
when required. For example, if you connect the output from a RATIOCTL block
(RATIOCTL.OP) to the set point of a PID block (PIDA.SP), the implicit/hidden
connection is made to RATIOCTL.OPX to provide value/status data.)
ATTENTION
Be sure you use a FANOUT block to make multiple output connections. We
recommend that you do not make multiple connections from a single
RATIOCTL output.
ATTENTION
This block gets the secondary's input range regardless of SECINITOPT.
This means regardless of whether the secondary's initialization and
override data will be used.
Control initialization
The RATIOCTL block brings initialization requests from its secondary through
BACKCALC. In addition, the secondary may propagate one-shot initialization requests
to this block. (Note that SECINITOPT may be used to ignore initialization requests from
the secondary.)
If the secondary is requesting initialization, the RATIOCTL block:
• initializes its output:
− CV = initialization value from the secondary
• Builds an initialization request for its primary based on CTLEQN selected as
follows:
B On
C On
D On
Where:
K1 = gain for X1
K2 = gain for X2
Equations
The RATIOCTL block provides four different equations for calculating the actual ratio
between the two flows (PV). The target value for the controlled flow (CV) is calculated
accordingly: - the CTLEQN parameter is used to specify the desired equation.
Equation A - For this equation, actual ratio = (controlled flow) / (uncontrolled flow).
Then:
Equation B - For this equation, actual ratio = (uncontrolled flow) / (controlled flow).
Then:
Equation C - For this equation, actual ratio = (controlled flow) / (controlled flow +
uncontrolled flow).
Then:
R110 Experion LX Control Builder Components Theory 641
February 2014 Honeywell
13. Regulatory Control
13.18. RATIOCTL (Ratio Control) Block
Equation D - For this equation, actual ratio = (uncontrolled flow) / (controlled flow +
uncontrolled flow).
Then:
Where:
Output bias
The output bias (OPBIAS) is added to the algorithm's Calculated Value (CV) and the
result is stored in CV. CV is later checked against OP limits and, if no limits are
exceeded, copied to the output.
The OPBIAS is the sum of the user-specified fixed bias (OPBIAS.FIX) and a calculated
floating bias (OPBIAS.FLOAT). The purpose of the floating bias is to provide a
bumpless transfer when the function block initializes or changes mode.
• OPBIAS is recomputed under the following conditions to avoid a bump in the
output.
− When the function block starts up (that is, goes Active).
− When the function block initializes (for example, the secondary requests
initialization).
− When the mode changes to Auto or Cascade.
• The following occurs when you set the OPBIAS value.
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the
entered value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
ATTENTION
When the function block goes Active or the Mode changes to Auto or
Cascade, OPBIAS and OPBIAS.FLOAT are recomputed.
• There are no limit checks applied when you set an OPBIAS or OPBIAS.FIX value.
However, after the total bias is added to CV, the result is compared against the
output limits and clamped, if necessary.
• You configure the value for the fixed bias (OPBIAS.FIX) and it is never overwritten
by the floating bias (OPBIAS.FLOAT). This means the total bias will eventually
equal the OPBIAS.FIX , if you configure OPBIAS.RATE to ramp down
OPBIAS.FLOAT.
• You may store to OPBIAS.FIX only if the function block is inactive or the MODE is
Manual; or if it is a PID or PIDFF function block with the CTLEQN set to E. When
you store to OPBIAS.FIX, the following occurs:
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the new
value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
• The OPBIAS.FLOAT is calculated as follows.
Where:
If OPBIAS.FLOAT is not zero, you can configure it to ramp down to zero through
the OPBIAS.RATE parameter.
• You configure the OPBIAS.RATE to apply a ramp rate to the OPBIAS.FLOAT. It is
only used when the OPBIAS.FLOAT is not zero. The OPBIAS.RATE is expressed
in Engineering Units per minute and may have the following values.
− Zero:
If OPBIAS.RATE is zero, a OPBIAS.FLOAT is calculated and bumpless
transfer is guaranteed. However, if OPBIAS.FLOAT is not zero, it will never
ramp down.
− Non-zero:
If OPBIAS.RATE is not zero, an OPBIAS.FLOAT is calculated and bumpless
transfer is guaranteed. If the OPBIAS.FLOAT is not zero, it is ramped to zero at
the rate you configured for the OPBIAS.RATE parameter.
The function block ramps the OPBIAS.FLOAT to zero by applying the
following calculation each time it executes.
Where:
− NaN:
When the OPBIAS.RATE is Not a Number (NaN), no OPBIAS.FLOAT is
calculated. This means a bump in the output will occur, if the primary does not
accept this block's initialization value.
Timeout monitoring
If mode is CAScade, the block performs time-out monitoring of the initializable input,
SP. - if good SP value is not received within a predefined time (TMOUTTIME), the
block invokes timeout processing as noted in the following section.
The maximum time between updates is specified by TMOUTTIME (in seconds)
Timeout processing
If MODE is Cascade and SP times-out, the RATIOCTL block does the following:
• Sets the "input timeout" flag (TMOUTFL)
• Holds SP at its last good value
• Changes the mode to a user-specified "timeout mode" (MODE = TMOUTMODE)
• Requests the SP primary to initialize (via BACKCALCOUT)
If SP times-out and the block sheds to Auto mode, it sets the Cascade Request flag
(CASREQFL). When CASREQFL is set, it means the block is waiting to return to the
Cascade mode, and will do so as soon as it fetches a good SP value.
• You may clear the CASREQFL but you cannot set it. This lets you disable the
automatic return to Cascade mode.
• If you change mode, the CASREQFL is cleared, which disables the return to
Cascade mode.
ATTENTION
If the input is from a connection in another controller in a peer-to-peer
architecture, the actual timeout time equals the configured TMOUTTIME
plus the CDA timeout time. The CDA timeout time equals four times the
configured CEE subscription rate. For example, if the CEE subscription rate
is 100 milliseconds and the TMOUTTIME is 5 seconds, the actual timeout
time for the block is 4 times 100ms plus 5s or 5.4 seconds.
ATTENTION
You can use SECINITOPT to ignore override requests from the secondary.
When the override status changes from selected to unselected, this block does the
following:
• Does not initialize its CV
• Computes a feedback value for the SP primary depending on the CTLEQN selected
as follows:
Where:
K1 = gain for X1
K2 = gain for X2
ATTENTION
The OUTIND parameter has no affect on the block's control operation. The
CTLACTN parameter on the Algorithm tab still supports the output direction of
the block, the OPTDIR parameter on the Main tab for the AOCHANNEL block
form applies the conversion of OP to OPFINAL. You can manipulate the
DIRECT/REVERSE selections for the OUTIND, CTLACTN, and OPTDIR
parameters to meet your process and operator needs.
OP 100.0 - Actual OP
The user store of an OP related parameter is intercepted and reversed when OUTIND
equals REVERSE. For example, a store of OPHILM = 80 produces OPLOLM = 100 -
80, so the OPHILM parameter get will then view OPHILM = 100 - 20.
ATTENTION
The swapping/reversal of values will not be done, if the block was loaded with
REVERSE OUTIND configured. The reversal of values will be done only on a
subsequent change to the OUTIND value, if appropriate.
For example: If a PID block is loaded with OPHILM = 95, OPLOLM = 10 and
OUTIND as REVERSE, the OPHILM and OPLOLM after load will still be 95
and 10, respectively.
OP Alarms considerations
When the OUTIND parameter value is set to REVERSE, the OP values displayed for the
high or low CEE Output Alarms are reversed. In the Alarm Summary display, the OP
values of the high alarms and the low alarms are swapped. The Output Alarms display
shall track the value of displayed output parameters. An OUTIND value of REVERSE,
shall show the limit and value subjected to reversal. For example, an OPHI alarm will
have the displayed trip limit set to 100 - (output low limit).
If the OUTIND parameter setting is changed:
• from Direct, DirectDispInd, or ReverseDispInd to Reverse or
• from Reverse to Direct, DirectDispInd, or ReverseDispInd,
a return for the existing Output Alarm condition occurs and a new Output Alarm would
be sent.
Windup handling
The RATIOBIAS block computes these three anti-reset windup status parameters.
• ARWOP
• ARWNET[1]
• ARWNET[2]
Windup processing
Every regulatory control type block maintains anti-reset windup status for its output
(ARWOP) and each of its initializable inputs (ARWNET). The following table lists the
possible values for ARWOP and ARWNET parameters.
ARWOP computation
The ARWOP indicates if the output (OP) can be raised or lowered. The PID-type
function blocks use ARWOP to restrict integral control. When ARWOP contains a value
other than Normal, the PID block stops integral control in the windup direction. Integral
control continues in the other direction, as does proportional and derivative control. But,
windup status has no impact on proportional and derivative control.
If a function block has a secondary, it fetches the secondary's windup status and
recomputes its ARWOP. The conditions within the function block, such as output being
at its high limit, also affect the ARWOP. The ARWOP is computed as follows, assuming
the block has only one output or that it is not a FANOUT block.
ARWNET computation
When ARWNET is HiLo, stores to SP are not limited, rather this is the status propagated
to the primary. The only limiting anti-reset windup status ever does is to stop integral
action in one or both directions on PID blocks. For any other regulatory control type
block, ARWNET is not used for any kind of limiting. The ARWNET is computed as
follows, assuming the block has only one output or that it is not a FANOUT block.
The CV is NaN
NORMAL HI HI
NORMAL LO LO
HI NORMAL HI
HI HI HI
HI LO HILO
HI HILO HILO
LO NORMAL LO
LO HI HILO
LO LO LO
LO HILO HILO
HILO HI HILO
HILO LO HILO
Error handling
The RATIOCTL block performs the following error checking:
• Check for Bad Control alarm conditions
• Check if X1 and X2 are valid:
− If X1 or X2 are bad (NaN), the block sets CV to NaN and PVSTS to Bad. Also,
the PV value is set to NaN.
− When X1 and X2 return to normal, the block initializes CV to the following:
RATIOCTL parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference</HH> for a complete list
of the parameters used with the RATIOCTLblock.
Each REGCALC block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that Tab. This data is only provided
as a quick document reference, since this same information is included in the on-line
context sensitive Help.
Input • High Limit (XEUHI) - Lets you specify the high input
range limit that represents 100% full scale input for all
the block inputs (X[1..6]). The default value is 100.
• Low Limit (XEULO) - Lets you specify the low input
range limit that represents 0 full scale input for all the
block inputs (X[1..6]). The default value is 0 (zero).
• Timeout Time (TMOUTTIME) - Lets you specify a time in
seconds that must expire before the block assumes that
its input update has timed out. The block must be in
CAScade mode for it to monitor its primary input for
timeout. The default setting is 0, which means the
timeout function is disabled.
If the input is from a connection in another controller in a
peer-to-peer architecture, the actual timeout time equals
the configured TMOUTTIME. For example, if the CEE
subscription rate is 100 milliseconds and the
TMOUTTIME is 5 seconds, the actual timeout time for
the block is 100ms plus 5s or 5.1 seconds.
• XK (XK[1..6]) - Lets you specify an individual gain value
for each of the six X inputs. The default value is 1.
• XB (XB[1..6]) - Lets you specify an individual bias value
for each of the six X inputs. The default value is 0.00,
that is, no bias is added.
Output • High Limit (%) (OPHILM) - Lets you specify the output
high limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
to 500 and you enter a High Limit of 90%, the high limit
in engineering units is 90% times 450 or 405 + 50
(CVEULO) equals 455. This check is not applied for a
function block that is in the MANual mode. The default
value is 105%.
• Low Limit (%) (OPLOLM) - Lets you specify the output
low limit as a percent of the Calculated Variable range
ATTENTION
Be aware that selecting NONE causes the CV
ATTENTION
Be aware that selecting NONE causes the
block to perform standard initialization using
the SECDATAIN.INITVAL as its initialization
value. A selection of NONE is usually
appropriate when the REGCALC block is
connected to an initializable input of its
secondary block.
ATTENTION
Be aware that selecting NONE causes the
block to perform standard override
initialization using SECDATAIN.ORFBVAL as
its initialization value. A selection of NONE is
usually appropriate when the REGCALC block
is connected to an initializable input of its
secondary block.
ATTENTION
Be aware that selecting NONE causes the
block to perform initialization using the
SECDATAIN.INITSTS as the initialization
FLAG. The initialization value depends on the
configuration of INITVALSRC. A selection of
NONE is usually appropriate when the
REGCALC block is connected to an
initializable input of its secondary block.
ATTENTION
Be aware that selecting NONE causes the
block to perform initialization using
SECDATAIN.INITVAL as the initialization
value. A selection of NONE is usually not
appropriate. For proper initialization of the
primary block, an initialization expression of
the following form must be written and
selected by INITVALSRC.
ATTENTION
Be aware that selecting NONE causes the
block to perform initialization using
SECDATAIN.ORFBVAL as the override
initialization value. A selection of NONE is
usually not appropriate. For proper override
initialization of the primary block, an override
initialization expression of the following form
must be written and selected by
ORFBVALSRC.
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
Control Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Insertion Type Lets you include an insertion type from a CAB instances in
the block. See CAB insertion configuration considerations
for regulatory control blocks for more information
Function
• Each expression can contain any valid combination of inputs, operators and
functions; and may perform arithmetic or logic operations.
• You can write expressions for calculating CV under normal, initialization and
override feedback conditions. Or, you can write expressions which produce
initialization and override feedback values for this block and its primaries.
• You can assign the result of an expression or an input to any assignable output,
which produces the same outputs as every other regulatory control block. You can
assign the same input to multiple outputs.
If Mode is . . . Then,
Manual (MAN) the output can be set by the operator or a user program.
The X1 input is ignored.
The initialization request occurs when the MODE changes from CAScade to MANual,
but not from MANual to CAScade.
Inputs
The REGCALC block can function without any inputs. The following inputs are optional
and they only accept real (Float 64) data types.
• X[1] - An initializable input that must come from another block, an operator cannot
set it.
• X[2] through X[6] general purpose inputs.
• XK[1..6] individually configurable gain value for each input.
• XB[1..6] individually configurable bias value for each input.
• XKB[1..6] individual inputs with gain and bias values applied to them.
• XWHIFL - An external windup high flag.
• XWLOFL - An external windup low flag.
Since X[1] is an initializable input, the block can have one primary. There is one
primary for each initializable input.
Initializable outputs
"Initializable output" and "initializable input" are variable attributes, similar to data type
or access level. A parameter with the "initializable" attribute has an associated
BACKCALC variable, and when a connection is created between an initializable input
and initializable output, you can also create a BACKCALC connection. Control Builder
automatically builds the required BACKCALC connections, so you do not have to
create them manually. These "implicit" build connections are "hidden" from view and the
related parameter pins are not exposed on the control chart.
For example, if you connect OP from a REGCALC block to SP on a PID block, Control
Builder automatically creates the BACKCALCOUT to BACKCALCIN connection.
• The REGCALC block has the following initializable outputs:
− OP = calculated output in percent.
− OPEU = calculated output in engineering units.
You may create a connection to OP or OPEU but not both. Therefore, this block may
have only one secondary. If you do not create a connection to OP or OPEU, then the
block does not have a secondary. Alternately, if you connect OP or OPEU to a non-
initializable input, then this block does not have a secondary. (Note that the default OP
connection pin is exposed on the blocks and the implicit/hidden connection function
automatically makes the appropriate value/status parameter (OPX/OPEUX) connection
when required.
For example, if you connect the output from a REGCALC block (REGCALC.OP) to the
set point of a PID block (PIDA.SP), the implicit/hidden connection is made to
REGCALC.OPX to provide value/status data.)
ATTENTION
Be sure you use a FANOUT block to make multiple output connections. We
recommend that you do not make multiple connections from a single
REGCALC output.
ATTENTION
This block gets the secondary's input range regardless of SECINITOPT.
This means regardless of whether the secondary's initialization and
override data will be used.
OPHILM and OPLOLM define the normal high and low limits for OP, as a percent of
the CV range. You must specify these values.
OP will be clamped to these limits if the algorithm's calculated result (CV) exceeds them,
or another function block or user program attempts to store an OP value that exceeds
them. However, the operator may store an OP value that is outside these limits.
OPEXHILM and OPEXLOLM define the extended high and low limits for OP, as a
percent of the CV range. You must specify these values.
The operator is prevented from storing an OP value that exceeds these limits.
Assignable outputs
You can assign expression results and/or inputs to the following parameters.
• CVSRC - CV output source selector.
• CVINITSRC - CVINIT source selector.
• CVORFBSRC - CVORFB source selector.
• INITREQSRC - INITREQ (initialization request flag) source selector.
• INITVALSRC - INITVAL (initialization value) source selector.
• ORFBVALSRC - ORFBVAL (override feedback value) source selector.
• ORFBSTSSRC - ORFBSTS (override feedback status) source selector.
For example, you can assign the result of the second expression to CVSRC and the result
of the fourth expression to CVINITSRC and CVORFBSRC. You may assign the same
input to multiple outputs. You may also assign inputs directly to outputs, such as
assigning X[1] and X[2] to INITVALSRC and INITREQSRC, respectively.
The assignable expression and input parameters are as follows:
C[1..8] - Expressions
CSTS[1..8] - Expression Status
X[1..6] - Inputs
XSTS[1..6] - Input Status
ATTENTION
The REGCALC block does perform data conversions, if the source and target
parameters are of different types. For example, if you assign the
INITREQSRC to X[2], the block converts the real type data from X[2] into
Boolean type data for INITREQ[1] that it sends to its primary. You must be
careful when making assignments that the resulting data conversions do not
make sense. For example, if you assign XSTS[1] to ORFBSTSSRC, the two
statuses are entirely different and they cause the block to produce
unexpected results.
Control initialization
The REGCALC block brings initialization requests from its secondary through
BACKCALC. In addition, the secondary may propagate one-shot initialization requests
to this block. (Note that SECINITOPT may be used to ignore initialization requests from
the secondary.)
If the secondary is requesting initialization, the REGCALC block:
• initializes its output:
• builds an initialization request for the designated primaries using the assignable
output parameters INITREQSRC and INITVALSRC. If you configure no
assignments for these parameters, the block behaves like other regulatory control
blocks, using the corresponding values brought from its secondary.
Be careful when making INITREQSRC and INITVALSRC assignments to avoid
producing the wrong results. For example, you assign the INITREQSRC parameter to
C[2], which produces a result of TRUE, and the REGCALC block's mode is CAScade
and its INITMAN parameter is OFF. Also, you have assigned CVSRC to C[1], which is
configured as "X[1] +10.0", and INITVALSRC to C[3], which is configured as this
block's CV. Assume at some moment that X[1] is 15.0 and it produces a C[1] of 25.0,
resulting in CV = INITVAL[1] = 25.0. The primary will initialize itself with the value
25.0. That is the next time the REGCALC block runs it receives an X[1] value of 25.0
from the primary, resulting in C[1] = CV = 35.0. Thus, each cycle that REGCALC runs,
its CV increments by 10.0, producing seemingly wrong results.
You can configure a REGCALC block to work like an AUTOMAN block by:
• Connecting X[1] for input from the primary.
• Assigning CVSRC to X[1] input.
• Configuring all other parameters like OPBIAS.RATE the same as you would for an
AUTOMAN block.
Output bias
The output bias (OPBIAS) is added to the algorithm's Calculated Value (CV) and the
result is stored in CV. CV is later checked against OP limits and, if no limits are
exceeded, it is copied to the output.
The OPBIAS is the sum of the user-specified fixed bias (OPBIAS.FIX) and a calculated
floating bias (OPBIAS.FLOAT). The purpose of the floating bias is to provide a
bumpless transfer when the function block initializes or changes mode.
• OPBIAS is recomputed under the following conditions to avoid a bump in the
output. (Note that the REGCALC block only applies OPBIAS.FLOAT to the output
for the later two conditions, when it is the first initializable block.)
− When the function block starts up (that is, goes Active).
− When the function block initializes (for example, the secondary requests
initialization).
− When the mode changes to Auto or Cascade.
• The following occurs when you set the OPBIAS value.
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the
entered value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
ATTENTION
When the function block goes Active or the Mode changes to Auto or
Cascade, OPBIAS and OPBIAS.FLOAT are recomputed.
• There are no limit checks applied when you set an OPBIAS or OPBIAS.FIX value.
However, after the total bias is added to CV, the result is compared against the
output limits and clamped, if necessary.
• You configure the value for the fixed bias (OPBIAS.FIX) and it is never overwritten
by the floating bias (OPBIAS.FLOAT). This means the total bias will eventually
equal the OPBIAS.FIX , if you configure OPBIAS.RATE to ramp down
OPBIAS.FLOAT.
• You may store to OPBIAS.FIX only if the function block is inactive or the MODE is
Manual; or if it is a PID or PIDFF function block with the CTLEQN set to E. When
you store to OPBIAS.FIX, the following occurs:
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the new
value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
• The OPBIAS.FLOAT is calculated as follows.
Where:
If OPBIAS.FLOAT is not zero, you can configure it to ramp down to zero through
the OPBIAS.RATE parameter.
• You configure the OPBIAS.RATE to apply a ramp rate to the OPBIAS.FLOAT. It is
only used when the OPBIAS.FLOAT is not zero. The OPBIAS.RATE is expressed
in Engineering Units per minute and may have the following values.
− Zero:
If OPBIAS.RATE is zero, an OPBIAS.FLOAT is calculated and bumpless
transfer is guaranteed. However, if OPBIAS.FLOAT is not zero, it will never
ramp down.
− Non-zero:
If OPBIAS.RATE is not zero, an OPBIAS.FLOAT is calculated and bumpless
transfer is guaranteed. If the OPBIAS.FLOAT is not zero, it is ramped to zero at
the rate you configured for the OPBIAS.RATE parameter.
Where:
− NaN:
When the OPBIAS.RATE is Not a Number (NaN), no OPBIAS.FLOAT is
calculated. This means a bump in the output occurs, if the primary does not
accept this block's initialization value.
• After initialization, the REGCALC block calculates the floating bias using the
following equation.
Where:
Timeout monitoring
If mode is CAScade, the REGCALC block performs timeout monitoring on X[1]- if
good X[1] value is not received within a predefined time (TMOUTTIME), the
REGCALC block invokes timeout processing.
The maximum time between updates is specified by TMOUTTIME (in seconds)
Timeout processing
If X[1] times out, the REGCALC block does the following:
• Sets the input timeout flag (TMOUTFL).
• Sets the input value to Bad (NaN).
• Requests the X[1] primary to initialize.
This block does not support mode shedding on timeout.
ATTENTION
If the input is from a connection in another controller in a peer-to-peer
architecture, the actual timeout time equals the configured TMOUTTIME
plus the CDA timeout time. The CDA timeout time equals four times the
configured CEE subscription rate. For example, if the CEE subscription rate
is 100 milliseconds and the TMOUTTIME is 5 seconds, the actual timeout
time for the block is 4 times 100ms plus 5s or 5.4 seconds.
status, override feedback value and an override offset flag. The status indicates if this
block is in the selected or unselected strategy (as determined by the OVRDSEL block).
The offset flag only applies to PID-type blocks.
When the override status changes from selected to unselected, the REGCALC block does
the following:
• Initializes its output:
If the ORFBVAL and ORFBSTS are not assigned and this block has a secondary, the
ORFBVAL and ORFBSTS received from the secondary are used to compute ORFBVAL
for the primary. When the override status from the secondary changes from selected to
unselected, this block does the following:
ATTENTION
You can use SECINITOPT to ignore override requests from the secondary.
You can customize the override feedback computation and propagation using the
following block parameters.
ORFBSTSSRC - If you make an ORFBSTSSRC parameter assignment, the REGCALC
block computes the override feedback status from the assignment and uses it for override
processing and propagation to the primary. If you do not make an assignment, the
REGCALC block uses the override status received from the secondary for override
processing, just like other regulatory control blocks do.
ORFBVALSRC - Like ORFBSTSSRC, if you make an ORFBVALSRC parameter
assignment, the REGCALC block computes the override feedback value for the primary
based on the assignment. Otherwise, the block uses the override status received from the
secondary for override processing , just like other regulatory blocks do.
ATTENTION
The OUTIND parameter has no affect on the block's control operation. The
CTLACTN parameter on the Algorithm tab still supports the output direction of
the block, the OPTDIR parameter on the Main tab for the AOCHANNEL block
form applies the conversion of OP to OPFINAL. You can manipulate the
DIRECT/REVERSE selections for the OUTIND, CTLACTN, and OPTDIR
parameters to meet your process and operator needs.
OP 100.0 - Actual OP
The user store of an OP related parameter is intercepted and reversed when OUTIND
equals REVERSE. For example, a store of OPHILM = 80 produces OPLOLM = 100 -
80, so the OPHILM parameter get will then view OPHILM = 100 - 20.
ATTENTION
The swapping/reversal of values will not be done, if the block was loaded with
REVERSE OUTIND configured. The reversal of values will be done only on a
subsequent change to the OUTIND value, if appropriate.
For example: If a PID block is loaded with OPHILM = 95, OPLOLM = 10 and
OUTIND as REVERSE, the OPHILM and OPLOLM after load will still be 95
and 10, respectively.
OP Alarms considerations
When the OUTIND parameter value is set to REVERSE, the OP values displayed for the
high or low CEE Output Alarms are reversed. In the Alarm Summary display, the OP
values of the high alarms and the low alarms are swapped. The Output Alarms display
shall track the value of displayed output parameters. An OUTIND value of REVERSE,
shall show the limit and value subjected to reversal. For example, an OPHI alarm will
have the displayed trip limit set to 100 - (output low limit).
If the OUTIND parameter setting is changed:
• from Direct, DirectDispInd, or ReverseDispInd to Reverse or
• from Reverse to Direct, DirectDispInd, or ReverseDispInd,
a return for the existing Output Alarm condition occurs and a new Output Alarm would
be sent.
Windup handling
The REGCALC block derives the ARWOP from a combination of the following
parameters and the secondary's windup status.
• CV
• XWHIFL
• XWLOFL
The following table summarizes how the block derives ARWOP for some given
conditions.
When the REGCALC block computes its ARWOP windup status for its primary
(ARWNET[1]), which is computed based on ARWOP, it will be propagated to the
primary just like other regulatory control blocks.
ATTENTION
The ARWNET[1] computation is independent of whether gain (K) is positive
or negative.
Windup processing
Every regulatory control type block maintains anti-reset windup status for its output
(ARWOP) and each of its initializable inputs (ARWNET). The following table lists the
possible values for ARWOP and ARWNET parameters.
ARWOP computation
The ARWOP indicates if the output (OP) can be raised or lowered. The PID-type
function blocks use ARWOP to restrict integral control. When ARWOP contains a value
other than Normal, the PID block stops integral control in the windup direction. Integral
control continues in the other direction, as does proportional and derivative control. But,
windup status has no impact on proportional and derivative control.
If a function block has a secondary, it fetches the secondary's windup status and
recomputes its ARWOP. The conditions within the function block, such as output being
at its high limit, also affect the ARWOP. The ARWOP is computed as follows, assuming
the block has only one output or that it is not a FANOUT block.
ARWNET computation
When ARWNET is HiLo, stores to SP are not limited, rather this is the status propagated
to the primary. The only limiting anti-reset windup status ever does is to stop integral
action in one or both directions on PID blocks. For any other regulatory control type
block, ARWNET is not used for any kind of limiting. The ARWNET is computed as
follows, assuming the block has only one output or that it is not a FANOUT block.
The CV is NaN
NORMAL HI HI
NORMAL LO LO
HI NORMAL HI
HI HI HI
HI LO HILO
HI HILO HILO
LO NORMAL LO
LO HI HILO
LO LO LO
LO HILO HILO
HILO HI HILO
HILO LO HILO
Expressions
You can write up to eight expressions, each expression can contain any valid
combination of inputs, operators, and functions. Table 2 lists the expression operators
and functions supported by this block for reference as well as some case sensitive strings
that can be used for special value constants in expressions.
ATTENTION
Do not use equality operands = and <> to compare FLOAT64 and FLOAT32
floating point values in expressions. Use inequality operands Less Than (<),
Less Than or Equal To (<=), Greater Than (>), or Greater Than or Equal To
(>=) instead.
Operators Description
Unary +-
Parenthesis ()
Array Syntax []
Unary Functions
Operators Description
LN Natural logarithm of a
number (log to the base of
e)
ABSTOD Takes an absolute time DTIMNUM Takes a delta TIME data type
data type and strips off the and returns a 64-bit float
year and date and returns representing the number of
a 64-bit float representing milliseconds.
the time of day in
milliseconds.
Operators Description
TOD Returns the current local TIMNUM Takes an Absolute TIME data
time of day as Time of Day type and returns a 64-bit float
data type representing the total number
of milliseconds since Jan 1,
1972.
UTCTOD Returns the current UTC UTCNOW Returns the current UTC date
time of day as Time of Day and time of day as an absolute
data type time data type
1
Be sure you specify the trigonometric functions cosine, sine, and tangent in radians and
not degrees.
PI PI (3.14159. . .)
E e (2.718. . .)
Parameters in Expressions
You must specify a parameter by its full tag name (for example,
"CM25.PumpASelect.PVFL", or "CM57.PID100.MODE"). In effect, tag names allow
expressions to have an unlimited number of inputs, and work with any data type.
However, do not use more than six parameter references in an expression.
Expression descriptor parameters (EXPRDESC[1..8]) are used with the expression
constant parameters (CONST[1..8]) for providing a short description for the expressions.
The EXPRDESC[1..8] parameter can be modified only during the strategy configuration,
and is available even if CONSTENABLE is set to “FALSE”.
The expression syntax has been expanded. Delimiters (') can be used in an expression
containing an external reference component. The format for the delimiter usage is as
follows:
• TagName.'text'
TagName is the name of the external reference component (i.e. an OPC Server). Text can
contain any characters, space, and special characters except for the delimiter character.
When entering this format, only the syntax and TagName are checked for accuracy. The
correct syntax of TagName-dot-delimiter-text-delimiter is verified and the TagName is
verified to be an external reference component. If either of these stipulations is incorrect,
an error is issued. The text between the delimiters is not checked. It is the users
responsibility to ensure that the text is something that the external reference component
will understand. If this text is incorrect, runtime errors will occur.
ATTENTION
When the expression is sent to the external reference component, the
delimiters are removed: TagName.'text' becomes TagName.text.
TIP
You can use the integer parameters YEAR, MONTH, DAY HOUR, MINUTE,
and SECOND that provide local date and time for the controller in all
expressions, just like other integer parameters.
ATTENTION
The constant values can be directly configured (using CONST[1..8]) in the
Calculator blocks and a short description for the expressions can also be
provided (using (EXPRDESC[1..8]).
The expression constant parameters (CONST[1..8]) are used with the expressions as
follows:
• An expression can be configured using the expression constants parameters
(CONST[1..8]).
Example:
CM1.CALC1.CONST[1] * CM1.CALC1.X[2] + CM2.REGCALCA.CV
Example:
CM1.CALC1.CONST[CM1.CALC1.X[1]] + CM1.CALC1.X[2]
The results of the expressions, which use the CONST [1...8] parameters, are affected if
you change the values of these parameters on the Constants tab.
Operator Description
:= Assignment - used only in the SCM Step Output blocks to assign the
results of an expression to a reference.
Example:
CM.block.mystringparam := CM.desc
+ Concatenation
Example:
CM.block.mystringparam + CM.desc
= Equal to
Example:
CM.block.mystringparam = CM.desc
Example:
Time constants
You can use the following valid time constants in expressions.
Operator Description
:= Assignment - used only in the SCM Step Output blocks to assign the
results of an expression to a reference. The data type in the
expression result must agree with the data type of the reference.
+ If both operands are of the same time data type the result is the
same data type. Delta time or Time of Day can be added to an
absolute time, which results in absolute time. Time of day can be
added to delta time, which results in a delta time. See the next
section Adding time data types. .
One operand can be a delta time or time of day data type and the
second operand must be a number. The result is a delta time data
type.
=, <>, <=, Compares two operands of type time. Both operands must be of the
>=, <, > same time data type.
1
The DAY, HOURS, MINS, SECS Operators are not case specific.
• NOW - MyCM.myblock.todparam
• ABSTOD(CEE01.CURRTIME)
The following are examples of invalid expressions.
• CEE01.CURRTIME + 2
• CEE01.CURRTIME > 5.0
REFERENCE - INTERNAL
Refer to the section Time Support in Experion LX System for more
information about time support in the system
REGCALC parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the REGCALC block.
Each REGSUMMER block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that Tab. This data is only provided
as a quick document reference, since this same information is included in the on-line
context sensitive Help.
Input • High Limit (XEUHI) - Lets you specify the high input
range limit that represents 100% full-scale input for the
block. The default value is 100.
• Low Limit (XEULO) - Lets you specify the low input
range limit that represents the 0 full-scale input for the
block. The default value is 0 (zero).
Output • High Limit (%) (OPHILM) - Lets you specify the output
high limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
to 500 and you enter a High Limit of 90%, the high limit
in engineering units is 90% times 450 or 405 + 50
(CVEULO) equals 455. This check is not applied for a
function block that is in the MANual mode. The default
value is 105%.
• Low Limit (%) (OPLOLM) - Lets you specify the output
low limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
to 500 and you enter a Low Limit of 10%, the low limit in
engineering units is 10% times 450 or 45 + 50
(CVEULO) equals 95. This check is not applied for a
function block that is in the MANual mode. The default
value is -5%.
• Extended High Limit (%) (OPEXHILM) - Lets you specify
the output extended high limit as a percent of the
Calculated Variable range (CVEUHI - CVEULO). For
example, If the CV range is 50 to 500 and you use the
default value of 106.9%, the extended high limit in
engineering units is 106.9% times 450 or 481.05 + 50
(CVEULO) equals 531.05. This check is not applied for a
function block that is in the MANual mode. The default
700 Experion LX Control Builder Components Theory R110
Honeywell February 2014
13. Regulatory Control
13.20. REGSUMMER (Regulatory Summer) Block
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Insertion Type Lets you include an insertion type from a CAB instances in
the block. See CAB insertion configuration considerations
for regulatory control blocks for more information
Template Defining Lets you view and define parameters for associated
templates.
Equation
CV is calculated as follows:
For 2 to 4 inputs:
CV = K * [XK(1) * X(1) + XK(2) * X(2) + XK(3) * X(3) + XK(4) * X(4)] +
OPBIAS
For one input:
CV = K * X1 + OPBIAS
where:
CV = Current full value of the output of this algorithm in EUs
K = Overall gain for CV
XK(1..4) = Individual gain for each input
OPBIAS = total output bias (that is, OPBIAS.FIX + OPBIAS.FLOAT)
X(1..4) = Current full values of each X-input in use.
Function
The REGSUMMER function block is typically used where two or more primary PIDs
are used to determine the set point of a secondary PID.
Configuration example
The following screen shot depicts the scenario wherein the REGSUMMER block is
used:
Inputs
The RegSummer block accepts up to four inputs -- X(1) through X(4).
• X(1) is an initializable input; all others are non-initializable. The X[1] input can be
connected to non-initializable inputs also. In this case there is no primary for this
block.
• The inputs must be pulled from other function blocks; the user cannot store in them.
R110 Experion LX Control Builder Components Theory 707
February 2014 Honeywell
13. Regulatory Control
13.20. REGSUMMER (Regulatory Summer) Block
• This block has one primary. (There is one primary per initializable input.)
• X[1] input connection is mandatory. If X[1] is not connected and the block is
loaded, an error will be raised during load time mentioning "At least input one needs
to be connected".
• NUMXINPT represents the number of input connections that has been made to this
block.
Outputs
The REGSUMMER block has the following initializable outputs:
• OP - Calculated output, in percent
• OPEU - Calculated output, in engineering units
ATTENTION
The user may create a connection to OP or OPEU, but not both i.e. only one
connection to the RegCtl block output should be made Therefore, this block
may have only one secondary. If the user does not create a connection to OP
or OPEU, then the block does not have a secondary. Alternately, if the user
connects OP or OPEU to a non-initializable input, then this block does not
have a secondary. If the block has a secondary, then the OPX or OPEUX is
the proper parameter to connect to RegCtl secondary. The "X" parameter is a
structure containing both the OP value and the OP status; it is critical to use
these parameters so that Initialization handshaking works properly. The
BACKCALCOUT or X1BACKCALOUT of secondary must be connected to the
BACKCALCIN of primary.
Output Ranges
• CVEUHI and CVEULO define the full range of CV, in engineering units.
• If this block has a secondary, it fetches the secondary's input range through
BACKCALC and sets its CV range to that. If it has no secondary, CVEUHI and
CVEULO track the X-input range (XEUHI and XEULO).
Note: This block fetches the secondary's input range regardless of SECINITOPT
(that is, regardless of whether the secondary's initialization and override data will be
used).
• The user has to set the CVEUHI and CVEULO such that it should be the same as
that of its secondaries XEUHI and XEULO respectively, when the secondary is
connected to RegSummer, else if there's no secondary, the CV ranges of
RegSummer block should follow its own XEU ranges. In case, the CVEU ranges
differ from the XEU ranges, then the results can be unexpected.
• OPHILM and OPLOLM define the normal high and low limits for OP, as a percent
of the CV range. These are user-specified values.
• OP will be clamped to these limits if the algorithm's calculated result (CV) exceeds
them, or another function block or user program attempts to store an OP value that
exceeds them. However, the operator may store an OP value that is outside these
limits.
• OPEXHILM and OPEXLOLM define the extended high and low limits for OP, as a
percent of the CV range. These are user-specified values.
• The operator is prevented from storing an OP value that exceeds these limits.
• OPTOL allows the user to configure a tolerance limit for the manually entered OP.
If the difference between new OP value and current OP value is greater the OPTOL
then confirmation is required from the user to store this new value.
Output bias
The user may specify a fixed bias to be added to the output. In addition, the function
block calculates a floating bias to ensure a bumpless transition after initialization or
mode change. For details, see the "Output Bias" section under Common Regulatory
Control Functions.
After initialization, this block calculates the floating bias as follows:
CV = initialization value from the secondary
where:
OPBIAS.FIX = fixed output bias
OPBIAS.FLOAT = floating output bias
Mode handling
This function block supports the Cascade and Manual modes:
• If MODE = Cascade, X[1] input must be pulled from another function block.
• If MODE = Manual, OP may be stored by the operator or a user program. (All
inputs are ignored.).
• The inputs X(2) to X(4) have to be pulled from other function blocks irrespective of
whether MODE is Cascade or Manual.
• This block requests all primaries to initialize after any mode-change.
Control initialization
Input X1 is an initializable input and initialization is accomplished with an internal
ramping bias. The Bias OPBIAS is made up of two components, OPBIAS.FIX and
OPBIAS.FLOAT, where OPBIAS.FIX is the operator entered bias and OPBIAS.FLOAT
is the internal bias component. The decay rate parameter OPBIAS.RATE specifies the
decay rate of the internal bias OPBIAS.FLOAT.
This block fetches initialization requests from its secondary through BACKCALC. In
addition, the secondary may propagate one shot initialization requests to this block.
Note: SECINITOPT may be used to ignore initialization requests from the secondary.
If the secondary is requesting initialization, this block:
• Initializes its output:
− If the initialization value received from the secondary is within the output limits
of this function block:
− CV = initialization value from the secondary
− Otherwise, CV is clamped to the appropriate limit.
Builds an initialization request for the X(1) primary as follows:
INITREQ = On
K*XK(1)
Where:
OPBIAS.FIX = Fixed output bias
K = Overall gain for CV
XK(1..4) = Individual gain for each input
INITREQ = initialization request flag for the X(1) primary
INITVAL = initialization value for the X(1) primary
When the cascade is broken, input X1 goes into initialization.
The initialization value to the primary is
K*XK(1)
When the cascade resumes, the internal ramping bias value OPBIAS.FLOAT is
calculated
value and an override offset flag. The status indicates if this block is in the selected or
unselected strategy (as determined by the Selector block). The offset flag only applies to
PID-type function blocks.
Note: SECINITOPT may be used to ignore override requests from the secondary.
When the override status changes from selected to unselected, this block does the
following:
• Calculates a feedback value for its primary:
primary feedback =
K*XK(1)
where:
OPBIAS.FIX = Fixed output bias
OPBIAS.FLOAT = Floating output bias
K = Overall gain for CV
XK(1..4) = Individual gain for each input
ATTENTION
The OUTIND parameter has no affect on the block's control operation. The
CTLACTN parameter on the Algorithm tab still supports the output direction of
the block, the OPTDIR parameter on the Main tab for the AOCHANNEL block
form applies the conversion of OP to OPFINAL. You can manipulate the
DIRECT/REVERSE selections for the OUTIND, CTLACTN, and OPTDIR
parameters to meet your process and operator needs.
OP 100.0 - Actual OP
The user store of an OP related parameter is intercepted and reversed when OUTIND
equals REVERSE. For example, a store of OPHILM = 80 produces OPLOLM = 100 -
80, so the OPHILM parameter will then view OPHILM = 100 - 20.
ATTENTION
The swapping/reversal of values will not be done, if the block was loaded with
REVERSE OUTIND configured. The reversal of values will be done only on a
subsequent change to the OUTIND value, if appropriate.
For example: If a PID block is loaded with OPHILM = 95, OPLOLM = 10 and
OUTIND as REVERSE, the OPHILM and OPLOLM after load will still be 95
and 10, respectively.
OP Alarms considerations
When the OUTIND parameter value is set to REVERSE, the OP values displayed for the
high or low CEE Output Alarms are reversed. In the Alarm Summary display, the OP
values of the high alarms and the low alarms are swapped. The Output Alarms display
shall track the value of displayed output parameters. An OUTIND value of REVERSE,
shall show the limit and value subjected to reversal. For example, an OPHI alarm will
have the displayed trip limit set to 100 - (output low limit).
If the OUTIND parameter setting is changed:
• from Direct, DirectDispInd, or ReverseDispInd to Reverse or
• from Reverse to Direct, DirectDispInd, or ReverseDispInd,
a return for the existing Output Alarm condition occurs and a new Output Alarm would
be sent.
Windup processing
Every regulatory control type block maintains anti-reset windup status for its output
(ARWOP) and each of its initializable inputs (ARWNET). The following table lists the
possible values for ARWOP and ARWNET parameters.
ARWOP computation
The ARWOP indicates if the output (OP) can be raised or lowered. The PID-type
function blocks use ARWOP to restrict integral control. When ARWOP contains a value
other than Normal, the PID block stops integral control in the windup direction. Integral
control continues in the other direction, similar to proportional and derivative control.
But, windup status has no impact on proportional and derivative control.
If a function block has a secondary, it fetches the secondary's windup status and
recomputes its ARWOP. The conditions within the function block, such as output being
at its high limit, also affect the ARWOP. The ARWOP is computed as follows, assuming
the block has only one output or that it is not a FANOUT block.
ARWNET computation
When ARWNET is HiLo, stores to SP are not limited, rather this is the status propagated
to the primary. The only limiting anti-reset windup status does is to stop integral action in
one or both directions on PID blocks. For any other regulatory control type block,
ARWNET is not used for any kind of limiting. The ARWNET is computed as follows,
assuming the block has only one output or that it is not a FANOUT block.
The CV is NaN
REGSUMMER parameters
REFERENCE - INTERNAL
Refer to Control Builder Components Reference for a complete list of the
parameters used with the REGSUMMER block.
If this block can communicate with both sources, it always selects the remote source. If it
loses communications with the remote, it switches to the backup source; and when
communications are restored, it automatically switches back to the remote.
You may force the unselected input to track the selected input through the TRACKING
option:
• If TRACKING is On, this block continually initializes the unselected input. That is,
on each cycle, it requests the unselected primary to initialize and set its output to the
selected input value.
• If TRACKING is Off, this block does not initialize the unselected input.
This block provides bumpless switching by applying a floating bias to the output,
regardless of whether TRACKING is On or Off.
Each REMCAS block supports the following user configurable attributes. The following
table lists the given name of the "Tab" in the parameter configuration form and then
briefly describes the attributes associated with that Tab. This data is only provided as a
quick document reference, since this same information is included in the on-line context
sensitive Help.
Output • High Limit (%) (OPHILM) - Lets you specify the output
high limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, if the CV range is 50
to 500 and you enter a High Limit of 90%, the high limit
in engineering units is 90% times 450 or 405 + 50
(CVEULO) equals 455. This check is not applied for a
function block that is in the MANual mode. The default
value is 105%.
• Low Limit (%) (OPLOLM) - Lets you specify the output
low limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, if the CV range is 50
to 500 and you enter a Low Limit of 10%, the low limit in
engineering units is 10% times 450 or 45 + 50
(CVEULO) equals 95. This check is not applied for a
function block that is in the MANual mode. The default
value is -5%.
• Extended High Limit (%) (OPEXHILM) - Lets you specify
the output extended high limit as a percent of the
Calculated Variable range (CVEUHI - CVEULO). For
example, if the CV range is 50 to 500 and you use the
default value of 106.9%, the extended high limit in
engineering units is 106.9% times 450 or 481.05 + 50
(CVEULO) equals 531.05. This check is not applied for a
function block that is in the MANual mode. The default
value is 106.9%.
• Extended Low Limit (%) (OPEXLOLM) - Lets you specify
the output extended low limit as a percent of the
Calculated Variable range (CVEUHI - CVEULO). For
example, If the CV range is 50 to 500 and you use the
default value of -6.9%, the extended low limit in
engineering units is -6.9% times 450 or -31.05 + 50
(CVEULO) equals 18.95. This check is not applied for a
function block that is in the MANual mode. The default
value is -6.9%.
• Rate of Change Limit (%) (OPROCLM) - Lets you
specify a maximum output rate of change limit for both
the positive and negative directions of the output in
percent per minute. This lets you prevent an excessive
rate of change in the output so you can match the slew
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
Control Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Insertion Type Lets you include an insertion type from a CAB instances in
the block. See CAB insertion configuration considerations
for regulatory control blocks for more information.
Function
This block receives two input values (X1 and X2), as shown in the following figure. X1
comes from the remote source and X2 comes from the backup or local source. The block
performs timeout monitoring on both inputs, and the function block normally operates in
the Cascade mode. Under normal conditions, this block passes input from the remote
source to the output, without change. When the remote input times out, this block
automatically switches to the backup source, and changes the mode to Backup Cascade.
If both inputs timeout, this function block sets CV to NaN, which forces "Bad Control"
processing.
It does not matter where the sources for X1 and X2 reside.
Set by operator
or user program
Remote
SP PID1
DATAACQ
P1 PV PV OP
X1 REMCAS2
Set by operator AOC4
OP
or user program X2 OP
Local/Backup
SP PID3
DATAACQ
P1 PV PV OP
Configuration example
The following figure (Views A and B) and its companion callout description table show
a sample configuration that uses a REMCAS block to form a cascade control loop with a
backup primary loop for quick reference. The views in the following figure depict loaded
configurations in the Monitoring mode.
The following table includes descriptions of the callouts in Views A and B of the figure
above.
Callout Description
Callout Description
3 Use the parameter connector function to connect the output (OP) from this
loop to the input (X1) of the REMCAS_1 block in another Control Module
(CM). See callout 9 in View B for the parameter connector to the X1 pin.
The default OP connection is exposed, but the implicit/hidden connection
function automatically makes a connection to a value/status parameter
(OPX/OPEUX) when it is required.
4 Typically, the Analog Input Channel (AIC) block supplying the input for the
backup/local primary loop (PID_BACKUP) is field wired to the same
location as the AIC for the remote primary loop (PID_PRIMARY).
5 Use the PV parameter connection to carry data and status from the analog
input to the PID block. The default PV connection is exposed, but the
implicit/hidden connection function automatically makes a connection to a
value/status parameter (PVVALSTS) when it is required.
8 With the Tracking option enabled, the output (OP) of the PID_BACKUP
block always equals the value being sent by the PID_PRIMARY, while the
PID_PRIMARY is being used for control.
Callout Description
Inputs
The REMCAS block requires two inputs - X1 and X2. X1 comes from the remote
source and X2 is from the backup or local source.
• X1 and X2 are both initializable inputs.
• X1 and X2 must be pulled from other function blocks; they cannot be stored
manually.
• This block has two primaries. (There is one primary per initializable input.)
Input descriptors
You can define a descriptor (name) of up to 15 characters for each input. The descriptors
reside in the XDESC parameter, and when an input is selected, the corresponding
descriptor is copied to SELXDESC.
SELXDESC is automatically updated when SELXINP changes.
Outputs
The REMCAS block has the following initializable outputs:
• OP = Calculated output, in percent.
ATTENTION
The OUTIND parameter has no affect on the block's control operation. The
CTLACTN parameter on the Algorithm tab still supports the output direction of
the block, the OPTDIR parameter on the Main tab for the AOCHANNEL block
form applies the conversion of OP to OPFINAL. You can manipulate the
DIRECT/REVERSE selections for the OUTIND, CTLACTN, and OPTDIR
parameters to meet your process and operator needs.
OP 100.0 - Actual OP
The user store of an OP related parameter is intercepted and reversed when OUTIND
equals REVERSE. For example, a store of OPHILM = 80 produces OPLOLM = 100 -
80, so the OPHILM parameter get will then view OPHILM = 100 - 20.
ATTENTION
The swapping/reversal of values will not be done, if the block is loaded with
REVERSE OUTIND configured. The reversal of values will be done only on a
subsequent change to the OUTIND value, if appropriate.
For example: If a PID block is loaded with OPHILM = 95, OPLOLM = 10 and
OUTIND as REVERSE, the OPHILM and OPLOLM after load will still be 95
and 10, respectively.
OP Alarms considerations
When the OUTIND parameter value is set to REVERSE, the OP values displayed for the
high or low CEE Output Alarms are reversed. In the Alarm Summary display, the OP
values of the high alarms and the low alarms are swapped. The Output Alarms display
shall track the value of displayed output parameters. An OUTIND value of REVERSE,
shall show the limit and value subjected to reversal. For example, an OPHI alarm will
have the displayed trip limit set to 100 - (output low limit).
If the OUTIND parameter setting is changed:
• from Direct, DirectDispInd, or ReverseDispInd to Reverse or
• from Reverse to Direct, DirectDispInd, or ReverseDispInd,
a return for the existing Output Alarm condition occurs and a new Output Alarm would
be sent.
• REGCTL OP 0% translated to 4 mA
by the AO, corresponding to the valve
closed
• REGCTL OP 100% translated to 20
mA by the AO, corresponding to the
valve open
• Unpowered state of AO results in 0
mA and valve closed
• REGCTL OP 0% translated to 20 mA
by the AO, corresponding to the valve
closed
• REGCTL OP 100% translated to 4 mA
by the AO, corresponding to the valve
open
• Unpowered state of AO results in 0
mA and valve open
• REGCTL OP 0% translated to 4 mA
by the AO, corresponding to the valve
open
• REGCTL OP 100% translated to 20
mA by the AO, corresponding to the
valve closed
• Unpowered state of AO results in 0
mA and valve open
Mode handling
This block supports the Cascade, Backup Cascade, and Manual modes:
• If the remote source (X1) is the currently selected input, the MODE is CAScade
• If the backup source (X2) is the currently selected input, the MODE is Backup
CAScade
• If the MODE is MANual, an operator or user program may store OP. In this case,
X1 and X2 are ignored.
Regarding mode-changes:
• This block requests both primaries to initialize after any mode-change except
MANual to CAScade and CAScade to Backup CAScade.
Timeout monitoring
If the MODE is CAScade or Backup CAScade, this block performs timeout monitoring
on both inputs (X1 and X2). If either input value is not updated within a predefined
time(TMOUTTIME), the block invokes timeout processing as outlined in the following
section.
The maximum time between updates is specified by TMOUTTIME (in seconds)
Timeout processing
If the MODE is CAScade and an input times out, this block does the following :
• If X1 times out, but X2 is good, the block:
− sets the "input timeout" flag (TMOUTFL)
− sets the MODE to Backup Cascade
− sets the currently selected input (SELXINP) to X2
− requests the X1 primary to initialize
• If X2 times out, but X1 is good, the block:
− requests the X2 primary to initialize
If X1 is good, then the MODE is CAScade and X1 is already the currently selected
input.
• If both inputs timeout, the block:
− sets CV to NaN, which forces a "Bad Control" condition. You specify what
actions to take on Bad Control through the BADCTLOPT parameter.
− sets the currently selected input (SELXINP) to None
− requests both primaries to initialize
If X1 times out, and the block sheds to Backup Cascade, it sets the Cascade Request flag
(CASREQFL). When CASREQFL is set, it means the block is waiting to return to the
Cascade mode, and will do so as soon as it gets a good X1 value.
Processing notes on CASREQFL:
• This block only sets CASREQFL if the original mode was Cascade, the X1 input
times out, and TMOUTMODE = Backup Cascade.
• You cannot set the CASREQFL. However, it can be cleared by setting the block's
MODE to MANUAL.
If the MODE was Cascade and it changed due to timeout, the block does the following
the next time it receives data from a primary:
• If SELXINP is X2, and X1 is good, (that is, X1 just changed from bad to good) , the
block:
− sets SELXINP to X1
− changes MODE to Cascade
Input switching
You may force the unselected input to track the selected input through the TRACKING
option:
• If TRACKING is On, this block continually initializes the unselected input. That is,
on each cycle, it requests the unselected primary to initialize and set its output to the
selected input value.
• If TRACKING is Off, this block does not initialize the unselected input.
When TRACKING is Off, this block propagates changes in windup status and overrides
feedback data to both inputs. When TRACKING is On, it only propagates to the selected
input (because the unselected input is in the initialized state).
For Override Processing, the Override Status from the Override Selector secondary block
is propagated only to the selected primary of the REMCAS block regardless of whether
the TRACKING option is Off or On. See the following Override Feedback Processing
section for more details.
This block provides bumpless switching by applying a floating bias to the output,
regardless of whether TRACKING is On or Off.
Equations
The REMCAS block computes CV as follows:
Where:
Output bias
The output bias (OPBIAS) is added to the algorithm's Calculated Value (CV) and the
result is stored in CV. CV is later checked against OP limits and, if no limits are
exceeded, it is copied to the output.
The OPBIAS is the sum of the user-specified fixed bias (OPBIAS.FIX) and a calculated
floating bias (OPBIAS.FLOAT). The purpose of the floating bias is to provide a
bumpless transfer when the function block initializes or changes mode.
• OPBIAS is recomputed under the following conditions to avoid a bump in the
output. (Note that the REMCAS block only applies OPBIAS.FLOAT to the output
for the later two conditions, when it is the first initializable block.)
− When the function block starts up (that is, goes Active).
− When the function block initializes (for example, the secondary requests
initialization).
− When the mode changes to Cascade.
• The following occurs when you set the OPBIAS value.
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the
entered value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
ATTENTION
When the function block goes Active or the Mode changes to Cascade,
OPBIAS and OPBIAS.FLOAT are recomputed.
• There are no limit checks applied when you set an OPBIAS or OPBIAS.FIX value.
However, after the total bias is added to CV, the result is compared against the
output limits and clamped, if necessary.
• You configure the value for the fixed bias (OPBIAS.FIX) and it is never overwritten
by the floating bias (OPBIAS.FLOAT). This means the total bias will eventually
equal the OPBIAS.FIX , if you configure OPBIAS.RATE to ramp down
OPBIAS.FLOAT.
• You may store to OPBIAS.FIX only if the function block is inactive or the MODE is
Manual; or if it is a PID or PIDFF function block with the CTLEQN set to E. When
you store to OPBIAS.FIX, the following occurs:
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the new
value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
• The OPBIAS.FLOAT is calculated as follows.
Where:
If the primary accepts this block's initialization request, then CV + OPBIAS.FIX should
be the same as CVINIT and OPBIAS.FLOAT will be zero. In most cases,
OPBIAS.FLOAT will be zero. However, if the primary does not accept this block's
initialization request because the primary is a FANOUT block or it was configured to
ignore initialization, then OPBIAS.FLOAT value will not be zero.
If OPBIAS.FLOAT is not zero, you can configure it to ramp down to zero through the
OPBIAS.RATE parameter.
• You configure the OPBIAS.RATE to apply a ramp rate to the OPBIAS.FLOAT. It is
only used when the OPBIAS.FLOAT is not zero. The OPBIAS.RATE is expressed
in Engineering Units per minute and may have the following values.
− Zero:
If OPBIAS.RATE is zero, an OPBIAS.FLOAT is calculated and bumpless
transfer is guaranteed. However, if OPBIAS.FLOAT is not zero, it will never
ramp down.
− Non-zero:
If OPBIAS.RATE is not zero, an OPBIAS.FLOAT is calculated and bumpless
transfer is guaranteed. If the OPBIAS.FLOAT is not zero, it is ramped to zero at
the rate you configured for the OPBIAS.RATE parameter.
Where:
NaN:
When the OPBIAS.RATE is Not a Number (NaN), no OPBIAS.FLOAT is calculated.
This means a bump in the output will occur, if the primary does not accept this block's
initialization value.
Control Initialization
This block brings initialization requests from its secondary through BACKCALCIN. In
addition, the secondary may propagate one-shot initialization requests to this block.
You may use SECINITOPT to ignore initialization requests from the secondary.
If the secondary is requesting initialization, this block:
• initializes its output:
INITREQ[1] = On
INITVAL[1] = CV - OPBIAS.FIX
INITREQ[2] = On
INITVAL[2] = CV - OPBIAS.FIX
Where:
unselected strategy (as determined by the Selector block). The offset flag only applies to
PID-type function blocks.
You may use SECINITOPT to ignore override requests from the secondary.
When the override status changes from selected to unselected, this block does the
following:
• Computes a feedback value for the selected primary:
Windup processing
Every regulatory control type block maintains anti-reset windup status for its output
(ARWOP) and each of its initializable inputs (ARWNET). The following table lists the
possible values for ARWOP and ARWNET parameters.
ARWOP computation
The ARWOP indicates if the output (OP) can be raised or lowered. The PID-type
function blocks use ARWOP to restrict integral control. When ARWOP contains a value
other than Normal, the PID block stops integral control in the windup direction. Integral
control continues in the other direction, as does proportional and derivative control. But,
windup status has no impact on proportional and derivative control.
If a function block has a secondary, it fetches the secondary's windup status and
recomputes its ARWOP. The conditions within the function block, such as output being
at its high limit, also affect the ARWOP. The ARWOP is computed as follows, assuming
the block has only one output or that it is not a FANOUT block.
ARWNET computation
When ARWNET is HiLo, stores to SP are not limited, rather this is the status propagated
to the primary. The only limiting anti-reset windup status ever does is to stop integral
action in one or both directions on PID blocks. For any other regulatory control type
746 Experion LX Control Builder Components Theory R110
Honeywell February 2014
13. Regulatory Control
13.21. REMCAS (Remote Cascade) Block
block, ARWNET is not used for any kind of limiting. The ARWNET is computed as
follows, assuming the block has only one output or that it is not a FANOUT block.
The CV is NaN.
NORMAL HI HI
NORMAL LO LO
HI NORMAL HI
HI HI HI
HI LO HILO
HI HILO HILO
LO NORMAL LO
LO HI HILO
LO LO LO
LO HILO HILO
HILO HI HILO
HILO LO HILO
REMCAS parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the REMCAS block.
You may force the unselected inputs to track the selected input through the TRACKING
option:
• If TRACKING is On, this block continually initializes the unselected inputs. That
is, on each cycle, it requests the unselected primaries to initialize and set their
output to the selected input value.
• If TRACKING is Off, this block does not initialize the unselected inputs.
This block provides bumpless switching by applying a floating bias to the output,
regardless of whether TRACKING is On or Off.
Each SWITCH block supports the following user configurable attributes. The following
table lists the given name of the "Tab" in the parameter configuration form and then
briefly describes the attributes associated with that Tab. This data is only provided as a
quick document reference, since this same information is included in the on-line context
sensitive Help.
Input • High Limit (XEUHI) - Lets you specify the high input
range limit that represents 100% full scale input for all
Output • High Limit (%) (OPHILM) - Lets you specify the output
high limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, if the CV range is 50
to 500 and you enter a High Limit of 90%, the high limit
in engineering units is 90% times 450 or 405 + 50
(CVEULO) equals 455. This check is not applied for a
function block that is in the MANual mode. The default
value is 105%.
• Low Limit (%) (OPLOLM) - Lets you specify the output
low limit as a percent of the Calculated Variable range
(CVEUHI - CVEULO). For example, If the CV range is 50
to 500 and you enter a Low Limit of 10%, the low limit in
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
Control Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Insertion Type Lets you include an insertion type from a CAB instances in
the block. See CAB insertion configuration considerations
for regulatory control blocks for more information
Function
This block lets you select one input from as many as eight, and outputs from the selected
value. It provides these three methods for selecting an input:
• Equation A. You store the number of the input to be selected to SELXINP.
• Equation B. You set one of the selection flags (SELXFL[1..8]) to On. Each flag
corresponds to an input. The block turns all of the other flags Off and updates
SELXINP.
• Equation C. You set or reset one of the selection flags (SELXFL[1..8]). The block
does not change any of the other flags. Instead, it scans all flags in ascending order
(1 to 8) and selects the first one that is On.
You can use this block to assign a different primary to a secondary. The example
configuration shown in the following figure has five primary PID blocks connected to a
SWITCH block. The active primary is selected by turning ON the corresponding
SELXFL[1..5] input or storing the appropriate number to the SELXINP input, depending
on the SWITCH block equation selected. The SELXINP parameter requires an integer
data type and is usually set by an operator. The default SELXINP value is 1 and you
cannot change it until the Control Module containing the SWITCH and primary blocks is
activated at least once in the Monitoring mode.
Please note that the configuration shown in the following figure is incomplete and is
intended to only give you an idea of the general construction of a typical SWITCH block
configuration.
You can also use multiple SWITCH blocks to assign a primary to a different secondary.
The example configuration shown in the following figure uses a FANOUT block to
provide the output from a primary PID block to two SWITCH blocks. One SWITCH
block for each secondary. To select one of the secondaries, you must turn ON the same
SELXFL input or store the same number to the SELXINP input on each SWITCH block.
Please note that the configuration shown in the following figure is incomplete and is
intended to only give you an idea of the general construction of a typical multiple
SWITCH blocks configuration.
Inputs
The SWITCH block accepts up to eight inputs - X[1] through X[8].
• X[1] through X[8] are initializable inputs.
• The inputs must be pulled from other function blocks; you cannot store them.
• This block may have two to eight primaries, depending on the number of inputs that
are configured. (There is one primary per initializable input.)
Input descriptors
This block lets you define a 15-character descriptor (name) for each X-input. The
descriptors resides in the XDESC parameter, and when an input is selected, the
corresponding descriptor is copied to SELXDESC.
Initializable Outputs
"Initializable output" and "initializable input" are variable attributes, similar to data type
or access level. A variable with the "initializable" attribute has an associated
BACKCALC variable, and when a connection is created between an initializable input
and initializable output, you can also create a BACKCALC connection. Control Builder
automatically builds the required BACKCALC connections, so you don't have to create
them manually. These "implicit" build connections are "hidden" from view and the
related parameter pins are not exposed on the control chart.
For example, if you connect OP from a SWITCH block to SP on a PID block, Control
Builder automatically creates the BACKCALCOUT to BACKCALCIN connection.
• OP = Calculated output, in percent.
• OPEU = Calculated output, in engineering units.
You may create a connection to OP or OPEU but not both. Therefore, this block may
have only one secondary. If you do not create a connection to OP or OPEU, then the
block does not have a secondary. Alternately, if you connect OP or OPEU to a non-
initializable input, then this block does not have a secondary. (Note that the default OP
connection pin is exposed on the blocks and the implicit/hidden connection function
automatically makes the appropriate value/status parameter (OPX/OPEUX) connection
when required.
For example, if you connect the output from a SWITCH block (SWITCH.OP) to the set
point of a PID block (PIDA.SP), the implicit/hidden connection is made to
SWITCH.OPX to provide value/status data.)
Mode handling
This block supports the Cascade and Manual modes:
• If MODE = Cascade, all inputs are pulled from other function blocks.
• If MODE = Manual, OP may be stored by the operator or user program; inputs are
ignored.
Regarding mode-changes:
• This block requests all primaries to initialize when mode changes from CAScade to
MANual.
Timeout monitoring
If MODE is Cascade, this block performs timeout monitoring on all inputs (X[1..8]). If
an input value is not updated within a predefined time(TMOUTTIME), the block invokes
timeout processing as described in the next section.
The maximum time between updates is specified by TMOUTTIME (in seconds).
Timeout processing
If MODE is Cascade and an input times out, this block does the following :
• Sets the "input timeout" flag (TMOUTFL)
• Sets the input value to Bad (NaN)
• Requests the input's primary to initialize
ATTENTION
This block does not support mode shedding on timeout.
Equations
The SWITCH block supports three methods for selecting an input - Equation A, B or C.
You configure this method through the parameter CTLEQN:
• Equation A: You select an input by storing to SELXINP. (SELXINP identifies the
input to be selected.) When SELXINP is updated, equation A:
− updates all selection flags (SELXFL[1..8]) accordingly. That is, it sets the flag
for the selected input to On, and turns all others Off.
− copies the selected input's descriptor to SELXDESC.
− calculates CV as follows:
Where:
• Equation B: You select an input by setting one of the selection flags (SELXFL[1..8])
to On. When this occurs, equation B turns all of the other flags Off.
Following a store to any selection flag, equation B:
− turns all other selection flags Off,
− updates SELXINP and SELXDESC, and
− calculates CV as noted above for Equation A.
Equation B prevents you from storing to SELXINP.
• Equation C: You can set one selection flag On without causing the others to be
turned Off. You may store On or Off to any flag and the others are not affected.
Following a store to any selection flag, equation C:
− scans all flags in ascending order - from SELXFL[1] to SELXFL[8],
− selects the first input whose flag is On depending on following conditions:
SELX SELX SELX SELX SELX SELX SELX SELX Given Selection Flag States
FL[1] FL[2] FL[3] FL[4] FL[5] FL[6] FL[7] FL[8] Select Input...
On NA NA NA NA NA NA NA X[1]
Off On NA NA NA NA NA NA X[2]
SELX SELX SELX SELX SELX SELX SELX SELX Given Selection Flag States
FL[1] FL[2] FL[3] FL[4] FL[5] FL[6] FL[7] FL[8] Select Input...
BADINPTOP = IncludeBad:
T(i)
CV is set to NaN,
BADINPTOP = IgnoreBad
T(i)
An attempt is made to automatically switch to the next
input. If a good input is found, then the Swith selection
changes to this input; if a good input is not found, then CV
is set to NaN and the selected input does not change.
Based on the configured equation, the SWITCH block automatically switches to the next
input as follows:
• Equations A and B: The next input is the next highest-input according to input
number. For example, the next input for input # 1, X[1], is input #2, X[2]; the next
input for X[2] is X[3], and so on; the next input for the last used input of the block is
X[1] - if 5 inputs are used with the Switch, then the next input for X[5] is X[1].
• Equation C: The Switch block will only automatically switch to an input whose
SELXFL(i) is On. The same "next" order is used with Equations A and B.
Bypass processing
You may explicitly ignore bad inputs when Equation C is selected as the control
equation. The following parameter supports this:
BADINPTOPT - Bad Input Option
Indicates if the block should include bad inputs (NaN) in the selection process.
BADINPTOPT has the following options:
• IgnoreBad (Ignore bad inputs)
• IncludeBad (Include bad inputs)
For this block, a bad input will cause CV to go bad. This means Bad Control.
Input switching
You may force the unselected inputs to track the selected input through the TRACKING
option:
• If TRACKING is On, this block continually initializes the unselected input. That is,
on each cycle, it requests the unselected primary to initialize and set its output to the
selected input value.
• If TRACKING is Off, this block does not initialize the unselected input.
When TRACKING is Off, this block propagates changes in windup status to all inputs.
However, for the unselected inputs, the Function Block Override Status (FBORSTS)
parameter value is always “NotCon” irrespective of whether TRACKING is On or Off.
When TRACKING is On, it only propagates to the selected input (because the
unselected input is in the initialized state).
For Override Processing, the Override Status is propagated to only the selected primary
of the SWITCH block regardless of whether the TRACKING option is Off or On. See
the following Override Feedback Processing section for more details.
This block provides bumpless switching by applying a floating bias to the output,
regardless of whether TRACKING is On or Off.
Output bias
The output bias (OPBIAS) is added to the algorithm's Calculated Value (CV) and the
result is stored in CV. CV is later checked against OP limits and, if no limits are
exceeded, it is copied to the output.
The OPBIAS is the sum of the user-specified fixed bias (OPBIAS.FIX) and a calculated
floating bias (OPBIAS.FLOAT). The purpose of the floating bias is to provide a
bumpless transfer when the function block initializes or changes mode.
• OPBIAS is recomputed under the following conditions to avoid a bump in the
output. (Note that the SWITCH block only applies OPBIAS.FLOAT to the output
for the latter two conditions, when it is the first initializable block.)
− When the function block starts up (that is, goes Active).
− When the function block initializes (for example, the secondary requests
initialization).
− When the mode changes to Cascade.
• The following occurs when you set the OPBIAS value.
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the
entered value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
ATTENTION
When the function block goes Active or the Mode changes to Cascade,
OPBIAS and OPBIAS.FLOAT are recomputed.
• There are no limit checks applied when you set an OPBIAS or OPBIAS.FIX value.
However, after the total bias is added to CV, the result is compared against the
output limits and clamped, if necessary.
• You configure the value for the fixed bias (OPBIAS.FIX) and it is never overwritten
by the floating bias (OPBIAS.FLOAT). That is, the total bias will eventually equal
the OPBIAS.FIX , if you configure OPBIAS.RATE to ramp down
OPBIAS.FLOAT.
• You may store to OPBIAS.FIX only if the function block is inactive or the MODE is
Manual; or if it is a PID or PIDFF function block with the CTLEQN set to E. When
you store to OPBIAS.FIX, the following occurs:
− The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the new
value.
− The floating bias (OPBIAS.FLOAT) is set to zero.
• The OPBIAS.FLOAT is calculated as follows.
768 Experion LX Control Builder Components Theory R110
Honeywell February 2014
13. Regulatory Control
13.22. SWITCH Block
Where:
If OPBIAS.FLOAT is not zero, you can configure it to ramp down to zero through
the OPBIAS.RATE parameter.
• You configure the OPBIAS.RATE to apply a ramp rate to the OPBIAS.FLOAT. It is
only used when the OPBIAS.FLOAT is not zero. The OPBIAS.RATE is expressed
in Engineering Units per minute and may have the following values.
− Zero:
If OPBIAS.RATE is zero, a OPBIAS.FLOAT is calculated and bumpless
transfer is guaranteed. However, if OPBIAS.FLOAT is not zero, it will never
ramp down.
− Non-zero:
If OPBIAS.RATE is not zero, an OPBIAS.FLOAT is calculated and bumpless
transfer is guaranteed. If the OPBIAS.FLOAT is not zero, it is ramped to zero at
the rate you configured for the OPBIAS.RATE parameter.
− The function block ramps the OPBIAS.FLOAT to zero by applying the
following calculation each time it executes.
Where:
NaN:
When the OPBIAS.RATE is Not a Number (NaN), no OPBIAS.FLOAT is calculated.
This means a bump in the output will occur, if the primary does not accept this block's
initialization value.
Error handling
If a selected input is bad, this block sets the CV to Bad (NaN), and leaves the Mode
unchanged.
When the selected input is again good, this block recalculates CV, and requests the
primary to initialize.
Control initialization
This block brings initialization requests from its secondary through BACKCALC. In
addition, the secondary may propagate one-shot initialization requests to this block.
You may use SECINITOPT to ignore initialization requests from the secondary.
If the secondary is requesting initialization, this block:
• initializes its output:
INITREQ(s) = On
INITVAL(s) = CV - OPBIAS.FIX
where:
• If TRACKING is On, this block also builds an initialization request for the
unselected primaries as follows:
INITREQ(n) = On
INITVAL(n) = CV - OPBIAS.FIX
where:
ATTENTION
The OUTIND parameter has no affect on the block's control operation. The
CTLACTN parameter on the Algorithm tab still supports the output direction of
the block, the OPTDIR parameter on the Main tab for the AOCHANNEL block
form applies the conversion of OP to OPFINAL. You can manipulate the
DIRECT/REVERSE selections for the OUTIND, CTLACTN, and OPTDIR
parameters to meet your process and operator needs.
OP 100.0 - Actual OP
The user store of an OP related parameter is intercepted and reversed when OUTIND
equals REVERSE. For example, a store of OPHILM = 80 produces OPLOLM = 100 -
80, so the OPHILM parameter get will then view OPHILM = 100 - 20.
ATTENTION
The swapping/reversal of values will not be done, if the block was loaded with
REVERSE OUTIND configured. The reversal of values will be done only on a
subsequent change to the OUTIND value, if appropriate.
For example: If a PID block is loaded with OPHILM = 95, OPLOLM = 10 and
OUTIND as REVERSE, the OPHILM and OPLOLM after load will still be 95
and 10, respectively.
OP Alarms considerations
When the OUTIND parameter value is set to REVERSE, the OP values displayed for the
high or low CEE Output Alarms are reversed. In the Alarm Summary display, the OP
values of the high alarms and the low alarms are swapped. The Output Alarms display
shall track the value of displayed output parameters. An OUTIND value of REVERSE,
shall show the limit and value subjected to reversal. For example, an OPHI alarm will
have the displayed trip limit set to 100 - (output low limit).
If the OUTIND parameter setting is changed:
• from Direct, DirectDispInd, or ReverseDispInd to Reverse or
• from Reverse to Direct, DirectDispInd, or ReverseDispInd,
a return for the existing Output Alarm condition occurs and a new Output Alarm would
be sent.
Windup processing
Every regulatory control type block maintains anti-reset windup status for its output
(ARWOP) and each of its initializable inputs (ARWNET). The following table lists the
possible values for ARWOP and ARWNET parameters.
ARWOP computation
The ARWOP indicates if the output (OP) can be raised or lowered. The PID-type
function blocks use ARWOP to restrict integral control. When ARWOP contains a value
other than Normal, the PID block stops integral control in the windup direction. Integral
control continues in the other direction, as does proportional and derivative control. But,
windup status has no impact on proportional and derivative control.
If a function block has a secondary, it fetches the secondary's windup status and
recomputes its ARWOP. The conditions within the function block, such as output being
at its high limit, also affect the ARWOP. The ARWOP is computed as follows, assuming
the block has only one output or that it is not a FANOUT block.
ARWNET computation
When ARWNET is HiLo, stores to SP are not limited, rather this is the status propagated
to the primary. The only limiting anti-reset windup status ever does is to stop integral
action in one or both directions on PID blocks. For any other regulatory control type
block, ARWNET is not used for any kind of limiting. The ARWNET is computed as
follows, assuming the block has only one output or that it is not a FANOUT block.
The CV is NaN
NORMAL HI HI
NORMAL LO LO
HI NORMAL HI
HI HI HI
HI LO HILO
HI HILO HILO
LO NORMAL LO
LO HI HILO
LO LO LO
LO HILO HILO
HILO HI HILO
HILO LO HILO
SWITCH parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the SWITCH block.
ATTENTION
The ROC block can only be used with C300 Controllers.
CTUD (Counter Counts the inputs values Lets you configure the algorithm to start
Up/Down) Block functioning according to the status of
the count on level flag (CNTLVLFL).
LEADLAG Block Provide lead and lag Provides lead and lag compensation to
compensation a change in input value calculation for
corresponding change in PV.
ROC (Rate of Limits the rate of input Provides computational block intended
Change) Block and provides the output for use on the input side of function
variable based on the blocks for limiting the input variable to
rate trip limits the block (typically SP).
Input Processing Auxiliary blocks get input data from other function blocks.
Input processing gets this data, checks that its valid, and
updates the appropriate block parameters.
Algorithm Calculation This involves calculations that are unique to each block.
The result or output is stored in PV.
Function
The AUXCALC block evaluates user-defined expressions and conditions to compute the
desired output and status for the control strategy.
As shown in the following figure, the block may bring values from up to six inputs and
determines their statuses in every execution cycle of the Control Module. It evaluates up
to eight expressions and determines their statuses. It derives values for PV and PV status
based on the configuration choices for the PVSRC and PVSTSSRC block parameters.
You can enter expression strings and configure PV and PV status selections at build time
before the CM is loaded. The block performs syntax checking and conversion of the
expression string during entry. If any errors are detected, they are displayed to inform
you of the problem. You must re-enter the string to correct the error. You can only enter
an expression in the Project tab during block configuration. You cannot change an
expression online in Monitoring tab.
The block checks and accepts other configuration parameters when the Control Module
is active. If there are any invalid entries, it generates appropriate error messages to help
identify the cause.
Calculate Expressions
and Derive Their Statuses
Configuration example
The following figure shows a sample configuration that uses an AUXCALC block to
provide square root characterization for the analog input. The AIC block always provides
values in the range of 0 to 100. You can use the AUXCALC block to provide range
conversion, if required. In this example, expression number 1 is configured as follows
and C[1] is assigned to the PV output. The view in the following figure depicts a loaded
configuration in Monitoring mode.
• exprn# 1 is: SQRT(PIDLOOP1.AUXCALC2.P[1])
Input
This function block accepts as many as six inputs (P[1..6]):
• All inputs are optional.
• Must fetch all inputs from other function blocks.
• The number of process input connections are equal to the number of inputs; the
default is 1.
Output
This block produces the following outputs:
• PV and its status, PVSTS
• As many as eight expression results (C[1] through C[8]) and their statuses
Expressions
You can write up to eight expressions, each expression can contain any valid
combination of inputs, operators, and functions. You can also write a short descriptive
text for each expression. Table 1(Expressions) in the REGCALC block section lists the
expression operators and functions supported by this block for reference.
Parameters in Expressions
You must specify a parameter by its full tag name (for example.
"CM25.PumpASelect.PVFL", or "CM57.PID100.MODE"). In effect, tag names allow
expressions to have an unlimited number of inputs, and work with any data type.
However, do not use more than six parameter references in an expression.
Expression descriptor parameters (EXPRDESC[1..8]) are used with the expression
constant parameters (CONST[1..8]) for providing a short description for the expressions.
The EXPRDESC[1..8] parameter can be modified only during the strategy configuration,
and is available even if CONSTENABLE is set to “FALSE”.
The expression syntax has been expanded. Delimiters (') can be used in an expression
containing an external reference component. The format for the delimiter usage is as
follows:
• TagName.'text'
TagName is the name of the external reference component (that is, an OPC Server). Text
can contain any characters, space, and special characters except for the delimiter
character.
When entering this format, only the syntax and TagName are checked for accuracy. The
correct syntax of TagName-dot-delimiter-text-delimiter is verified and the TagName is
verified to be an external reference component. If either of these stipulations is incorrect,
an error is issued. The text between the delimiters is not checked. It is the users
responsibility to ensure that the text is something that the external reference component
understands. If this text is incorrect runtime errors occurs.
ATTENTION
When the expression is sent to the external reference component, the
delimiters are removed: TagName.'text' becomes TagName.text.
TIP
You can use the integer parameters YEAR, MONTH, DAY HOUR, MINUTE,
and SECOND that provide local date and time for the controller in all
expressions, just like other integer parameters.
ATTENTION
The constant values can be directly configured (using CONST[1..8]) in the
Calculator blocks and a short description for the expressions can also be
provided (using (EXPRDESC[1..8]).
The expression constant parameters (CONST[1..8]) are used with the expressions as
follows:
• An expression can be configured using the expression constants parameters
(CONST[1..8]).
Example:
CM1.CALC1.CONST[1] * CM1.CALC1.X[2] + CM2.REGCALCA.CV
Example:
CM1.CALC1.CONST[CM1.CALC1.X[1]] + CM1.CALC1.X[2]
The results of the expressions, which use the CONST [1...8] parameters, are affected if
you change the values of these parameters on the Constants tab.
Assignable Outputs
Produces these outputs according to the values you assign to them.
• PV and its status PVSTS
• Up to eight expression results (C[1] to C[8]) and their statuses
You can assign an input, expression, result, or status value to PV and PVSTS through
block configuration. For example, you may assign the result of the second
expression(C[2]) to PV. You may also assign inputs directly to outputs; for example,
P[1] can be assigned to PV, and P[2] can be assigned to PVSTS.
AUXCALC parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the AUXCALC block.
Function
The AUXSUMMER block uses the following equation to calculate the PV value based
on up to ten configured inputs.
PV = CPV {((C [1] P[1]) + D [1] ) + ... ((C [i] P[i] )+ D [i] )} + DPV
i = 1 to 10
The AUXSUMMER block brings values from other function blocks and determines their
statuses in every execution cycle of the Control Module. It evaluates up to ten inputs and
determines their statuses. It derives values for PV and PV status based on its calculation
of the inputs and the configuration entries for the overall PV scale factor (CPV) and
overall PV bias factor (DPV) parameters.
You can also choose to disable an input (PENABLE[1..10]) and define a substitute value
(PSUB[1..10]) for the disabled input.
Configuration parameters
The following table provides a summary of the AUXSUMMER specific parameters that
you can configure through the Main tab of the block's properties form in Control
Builder. You must have an access level of at least Engineer to enter or modify values for
these parameters. The table does not include descriptions of the common parameters
such as block name and description.
PV Display Format PVFORMAT Lets you define the decimal format to be used
to display the PV value. The choices are D0
(None), D1 (One), D2 (Two), or D3 (Three).
The default value is D1.
Overall Scaling CPV Lets you define the scaling factor to be applied
Factor for PV to the PV value to meet your process
requirements. This parameter can be changed
at any time and can be changed by another
block in the same Control Module or another
one, if desired. The default value is 1.
Overall Bias for PV DPV Lets you define the bias factor to be applied to
the PV value to meet your process
requirements. This parameter can be changed
at any time and can be changed by another
block in the same Control Module or another
one, if desired. The default value is 0.
Input Description PDESC[1..10] Lets you define a specific description for each
input. This parameter can only be changed in
the Project mode in Control Builder before the
block is loaded or re-loaded.
Enable/Disable PENABLE[1..10] Lets you enable or disable a given input for the
Switch block. This parameter can be changed at any
time and can be changed by another block in
the same Control Module or another one, if
desired. The default value is Enabled or On.
Scaling Factor for C[1..10] Lets you define a scaling factor for the given
Inputs input to meet your calculation requirements.
This parameter can be changed at any time
and can be changed by another block in the
same Control Module or another one, if
desired. The default value is 1.
Bias Values for D[1..10] Lets you define the bias value to be applied to
Inputs the corresponding input (P[1..10]). This
parameter can be changed at any time and can
be changed by another block in the same
Control Module or another one, if desired. The
default value is 0.
Configuration example
The following figure shows a sample configuration that uses an AUXSUMMER block to
fetch three separate inputs and calculate a PV value for a NUMERIC block.
You can use the AUXSUMMER block to find the rate at which a component of a raw
product is entering a process unit by summing the proportion of the component in each
of several input streams and by multiplying the stream flow rates.
This block can also be used to calculate net heat loss by finding the difference between
the heat inputs and heat outputs. The difference can be obtained by using a negative scale
factor. Other possible uses are mass-balance, heat-balance, and inventory calculations.
Input
This function block accepts as many as ten inputs (P[1…10]).
• At least one input (P[i]) must be configured for the block to operate.
• All inputs must be fetched from other function blocks.
• The number of process input connections (NUMPINPT) that can be made to other
blocks is equal to the number of inputs. The default is 1.
Output
This block produces the following outputs:
• PV and its status, PVSTS.
Error handling
If the status of at least one input is bad, the block sets PVSTS to Bad and PV to NaN. If
PENABLE[i] is disabled, then the input P[i] equals the value configured for the PSUB[i]
parameter.
Even if there are no inputs with a bad value (NaN), and the status of at least one of the
inputs is Uncertain, the block sets PVSTS to Uncertain.
If at least one input is not connected, the following error message will be returned while
loading At least Input one needs to be connected.
AUXSUMMER parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the AUXSUMMER block.
Function
The CTUD block is an up-down counter function block. The counter of the CTUD block
can change its state in either direction (Up or Down) depending on the configuration of
Count Up Flag (CNTUPFL) and Count Down Flag (CNTDNFL) parameter.
Internal counter value pre-load and comparison operations depends on a valid IN
(ININT32/INFLOAT64) configuration if the input is fed through a wired connection.
The Count Up Flag and Count Down Flag are evaluated as edge trigger or level trigger
quantities depending on the value configured for the Count On Level flag (CNTLVLFL)
parameter.
The CTUD Block supports pause (PAUSEFL), load (LOADFL) and reset (RESETFL)
operation for the counter.
ATTENTION
Counter equation selection (CNTEQN): Equation A is selected as the default
equation. You can select any equation based on your control strategy
requirements.
Inputs
CTUD block accepts the following input format.
• Integer 32
• Float 64
• Boolean
• Enumeration
By default, FLOAT64 input format is supported.
Input fetched or INCLAMPOPT FLOAT64 value Value for Value for limit
tried to store status Counter load checking
(INFLOAT64) operation
ATTENTION
If RESETFL and LOADFL flags are set to “TRUE” at the block execution time,
the internal counter value is set to zero.
Outputs
The output can be fetched through a wired connection or read directly by a program.
Counter output values are available in Float64 and Integer32 formats. Float 64 value is
the floating point equivalent of the 32 bit integer internal count.
Edge Trigger
If the CNTLVLFL flag is set to “FALSE”, the counter evaluates the count inputs
(CNTUPFL or CNTDNFL) as edge-triggered quantities. CTUD activates a trigger
increment when a positive edge transition on the CNTUPFL is detected. CTUD activates
a trigger decrement when a positive edge transition on the CNTDNFL is detected. The
counter value is unchanged until the next transition occurs.
The following is an example configuration figure for edge-triggered count.
The following diagram displays how the transition occurs in case of edge-trigger.
ATTENTION
Input edge detection on the count up and count down inputs are not enabled
until the second execution cycle following the initialization. Therefore, the
reload of a CM containing a CTUD block with an unchanged input state of “1”
Level Trigger
If the CNTLVLFL flag is set to “TRUE”, the counter evaluates the count inputs
(CNTUPFL or CNTDNFL) as level-triggered quantities. CTUD counter value
increments when the CNTUPFL is set to “TRUE.”. The counter value decrements when
the CNTDNFL is set to “TRUE.” The count input flag (CNTDNFL or CNTUPFL) is
cleared after the block execution. This allows for the recognition of individual
asynchronous value stores from programs, SCMs, CABs, or the Push block in between
counter block executions. The level value from wired input connections is fetched and
recognized each block execution even though Control Builder displays the “cleared”
input value.
ATTENTION
For wired connections, a visual mismatch or value mismatch between the
sourcing end of the connection and the receiving end of the connection for
up-down flags (CNTDNFL/ CNTUPFL) can be observed.
The following diagram displays how the transition occurs in case of level trigger.
Supported algorithms
The CTUD block supports the following algorithms.
Equation A Equation B
Equation C Equation D
Equation E Equation F
Equation G Equation H
The internal counter overflow, underflow, and rollover behavior is governed by which
counter algorithm has been specified.
ATTENTION
The CTUD excludes a gap between zero and IN (INT32/FLOAT64) value for
the following scenarios.
The following figure displays the gap excluded between zero and the IN
values for the Equation D and H.
D OUT == IN OUT == 0
H OUT == 0 OUT == IN
Example
If the counter is using the Equation A and the output is 2,147,483,647, the QUFL flag is
set to “TRUE” and QDFL flag is set to “FALSE”. The following figure displays the
counter function blocks output flag status.
designed to accommodate interrelated parameters without warnings for valid data load in
anticipation of following related information, as displayed in the table.
Input Parameters
ININT32 0
INFLOAT64 0.0
Count Flags
Configuration parameters
Output Flags
Output parameters
OUTINT32 0
OUTFLOAT64 NaN
CTUD parameters
REFERENCE – INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the CTUD block.
Each DEADTIME block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that Tab. This data is only provided
as a quick document reference, since this same information is included in the on-line
context sensitive Help.
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
the Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
the Control Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in the Control Builder.
Function
The DEADTIME block is typically used in a feedforward control loop. It provides its
delayed PV output as the input to a LEADLAG block which feeds its output to the
feedforward (FF) input of the PIDFF block. This helps condition the control response to
the actual process characteristics.
The cutoff feature with the variable dead time lets you simulate conditions like the
stopping of a conveyor belt. If the flow or speed value the P2 input represents drops
below the value you configured for the CUTOFF.LM parameter, the value of the delayed
P1 input goes to zero. When P2 again exceeds the Cut Off Limit value, the delayed P1
input resumes a value.
Input
The block requires one or two inputs depending on the type of delay action selected.
• If delay type is Fixed or Variable, P1 must be brought from another block.
• If delay type is Variable, P2 must also be brought from another block.
Output
The block produces an output value (PV), a status (PVSTS), and a status flag
(PVSTSFL).
PV status
PV status (PVSTS) may have one of the following values:
• Bad - which means that PV is NaN (Not a Number).
• Normal - which means PV is OK.
• Manual - which means P1 source (for example, DATAACQ block) is in manual PV
source.
• Uncertain - which means that PV is OK but P1 or P2 status is uncertain.
The following Boolean flags (typically used with Logic and Alarm blocks) also reflect
the value of PVSTS:
• PVSTSFL.BAD - if PVSTS = Bad, this flag is on; otherwise it is off.
• PVSTSFL.NORM - if PVSTS = Normal, this flag is on; otherwise it is off.
• PVSTSFL.MAN - if PVSTS = Manual, this flag is ON; otherwise it is off.
• PVSTSFL.UNCER - if PVSTS = Uncertain, this flag is on; otherwise it is off.
Error handling
If the P1 input status (P1STS) or the P2 input status (P2STS) is Uncertain, this block sets
PV status (PVSTS) to Uncertain.
If the P1 input status (P1STS) or the P2 input status (P2STS) is Bad, this block sets the
PV status (PVSTS) to Bad and the PV output to NaN.
Delay type
The DEADTIME block gives you choice of either a Fixed or Variable delay type.
• For the Fixed delay, a change in the input value (P1) is delayed by the user
configured delay time (DELAYTIME) as follows.
Where:
• For the Variable delay, a change in the P1 input value is delayed by a time period,
which varies as the inverse of the P2 input value. A combination of the P2 value, the
scaling factors (C1, C2) and the bias values (D1, D2) determines the variable time
period as follows.
DPt = 0
Otherwise:
And:
Where
D2 = Bias for P2
Delay table
The block uses a delay table (DELAYTABLE) to produce the desired delays in the P1
input. It stores and shifts P1 values through the table at a rate that is calculated to
produce the desired deadtime. The following information is used to derive the table-shift
rate.
• The sample rate of the P1 input value. This is the execution rate of the block.
• The delay time (DELAYTIME). For Fixed delay, delay time is user configured. For
Variable delay, the delay time is derived from the P2 input.
• The number of entries (NUMLOC) to use in the delay table. The table has a
maximum of 60 entries. You can change the number of entries by configuring the
desired smaller value through the Delay Table Size (NUMLOC) entry in the block's
configuration form.
The following relationship exists between DELAYTIME, Period (FB execution period in
minutes) and NUMLOC.
In the simplest case, where the scaling factors C1 and C2 equal 1 and the bias factors D1
and D2 equal 0, the variable delay time input signal P2 has the following limits.
In all other cases, use the scaling and bias factors to make sure the calculated delay time
remains within the range defined above.
ATTENTION
• Using delays greater than two minutes or reducing the delay table size,
will distort the input signal as it appears at the PV output. Input signals
with high frequency content will cause samples to be missed, even at the
maximum sample rate, resulting in reduced output fidelity.
• When the delay time exceeds the product of the sample rate and the
delay table size, the input value, which lies between other sampled
inputs, is interpolated. This means the PV output is either a true sampled
value or an interpolated value.
Restart condition
When this block experiences a Restart condition, all the entries in the delay table are set
equal to P1. The PV status is set to Normal and the PV is calculated as follows.
PV = CPV P1 + DPV
When the INITREQ parameter is True, the block's algorithm produces the same result as
the Restart condition.
DEADTIME parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the DEADTIME block.
Function
The ENHAUXCALC block evaluates user-defined expressions and conditions to
compute the desired output and status for the control strategy.
As shown in the following figure, the block may bring values from up to 10 inputs and
determines their statuses in every execution cycle of the Control Module. It evaluates up
to eight expressions and determines their statuses. It derives values for PV and PV status
based on the configuration choices for the PVSRC and PVSTSSRC block parameters.
An input switch parameter (PENABLE[1..10]) lets you enable or disable each
corresponding input (P[1..10]). You can also configure a scaling factor (CP[1..10] for
each corresponding input (P[1..10] to provide a corresponding scaled input (PP[1..10]).
The scaled input is computed as follows.
• If PENABLE = 0 (Disable), then:
Where: i = 1 to 10
A configurable input substitute parameter (PSUB[1..10]) lets you define an input value
to be substituted for a corresponding disabled input (P[1..10])/scaled input (PP[1..10]).
The logic works as follows.
• If PENABLE = 1 (Enable), then:
P[i] = PSUB[I]
Where: i = 1 to 10
A configurable input description parameter (PDESC[1..10]) lets you type your own
descriptive text for each corresponding input (P[1..10]).
You can enter expression strings and configure PV and PV status selections at build time
before the CM is loaded. The block performs syntax checking and conversion of the
expression string during entry. If any errors are detected, they are displayed to inform
you of the problem. You must re-enter the string to correct the error. You can only enter
an expression in the Project tab during block configuration. You cannot change an
expression online in the Monitoring tab.
The block checks and accepts other configuration parameters when the Control Module
is active. If there are any invalid entries, it generates appropriate error messages to help
identify the cause.
Calculate Expressions
and Derive Their Statuses
Configuration parameters
The following table provides a summary of the ENHAUXCALC specific parameters that
you can configure through the Main tab of the block's properties form in Control
Builder. You must have an access level of at least Engineer to enter or modify values for
these parameters. The table does not include descriptions of the common parameters
such as block name and description.
Input Description PDESC[1..10] Lets you type your own description for each
input.
Scaled Input PP[1..10] Lets you use a scaled input value in your
expressions. This is a read-only parameter with
a NaN value in the Project tab.
Input
This function block accepts as many as ten inputs (P[1..10]):
• All inputs are optional.
• Must fetch all inputs from other function blocks.
• The number of process input connections are equal to the number of inputs; the
default is 1.
Output
This block produces the following outputs:
• PV and its status, PVSTS
• As many as eight expression results (C[1] through C[8]) and their statuses
Expressions
You can write up to eight expressions, each expression can contain any valid
combination of inputs, operators, and functions. You can also write a short descriptive
text for each expression. Table 1(Expressions) in the REGCALC block section lists the
expression operators and functions supported by this block for reference.
Parameters in Expressions
You must specify a parameter by its full tag name (for example.
"CM25.PumpASelect.PVFL", or "CM57.PID100.MODE"). In effect, tag names allow
expressions to have an unlimited number of inputs, and work with any data type.
However, do not use more than six parameter references in an expression. Also, the size
of each expression in the ENHAUXCALC block is limited to 255 characters. If the size
of the expression exceeds 255 characters, the following message appears.
You do not need to associate the PENABLE[1..10] parameter with the corresponding
input (p[1..10]) explicitly in an expression.
ATTENTION
When the expression is sent to the external reference component, the
delimiters are removed: TagName.'text' becomes TagName.text.
• You can mix and nest all operators and functions (including conditional
assignments) in any order as long as types match or can be converted.
• You can use blanks between operators and parameter names, but they are not
required.
• You can use all data types in expressions, including enumerations. They are all
treated as numeric types.
TIP
You can use the integer parameters YEAR, MONTH, DAY HOUR, MINUTE,
and SECOND that provide local date and time for the controller in all
expressions, just like other integer parameters.
ATTENTION
The constant values can be directly configured (using CONST[1..8]) in the
Calculator blocks and a short description for the expressions can also be
provided (using (EXPRDESC[1..8]).
The expression constant parameters (CONST[1..8]) are used with the expressions as
follows:
• An expression can be configured using the expression constants parameters
(CONST[1..8]).
Example:
CM1.CALC1.CONST[1] * CM1.CALC1.X[2] + CM2.REGCALCA.CV
Example:
CM1.CALC1.CONST[CM1.CALC1.X[1]] + CM1.CALC1.X[2]
The results of the expressions, which use the CONST [1...8] parameters, are affected if
you change the values of these parameters on the Constants tab.
Example 1
Example 2
In this case, if an input is disabled, the corresponding substitute value is used in the
expressions.
Example 1
PP[1]*2+P[2]
Here
Example 2
MIN(PP[10],P[2],C[1])
Example 3
Example 4
SQRT(PP[5])
Assignable Outputs
Produces these outputs according to the values you assign to them.
• PV and its status PVSTS
• Up to eight expression results (C[1] to C[8]) and their statuses
You can assign an input, expression, result, or status value to PV and PVSTS through
block configuration. For example, you may assign the result of the second
expression(C[2]) to PV. You may also assign inputs directly to outputs; for example,
P[1] can be assigned to PV, and P[2] can be assigned to PVSTS.
ENHAUXCALC parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the ENHAUXCALC block.
The ENHGENLIN block processes the input value (P1) based on the linearization
segment table selected by the ACTLINSEG parameter. The number of configured
linearization segment tables is defined by NUMLINSEG parameter.
The block compares the input value (P1) with each segment based on a coordinate pair.
ATTENTION
ENHGENLIN block has two dimensional input (IN[i][j]) and output (OUT[i][j])
parameters.
n = represents the number of segment in the active curve. The “n” value is
determined by NUMSEGS [ACTLINSEG].
When it finds a segment that intersects with the input, the block displays the respective
output value (PV) as follows:
• If P1 is exactly equal to the input value at the beginning of any segment (that is, P1
= IN[i][j], for j in the range of 0 to n, where i = ACTLINSEG-1 and n= NUMSEGS
[i]):
PV = OUT[i][j]
• If P1 is less than IN value in the first linearization point (IN[i][0]), the first segment
is extrapolated:
• If P1 is greater than the IN value in the last linearization point (IN[i][n]), the last
segment is extrapolated:
• If P1 is within the configured range, the smallest j value is used where IN[i][j] is less
than P1 and the linearized value is interpolated:
where:
IN[i][j] = input value at the beginning of the intersecting segment.
IN[i + 1][j + 1] = input value at the end of the intersecting segment
OUT[i][j]= output value at the beginning of the intersecting segment
OUT[i + 1][j + 1] = output value at the end of the intersecting segment
ACTLINSEG = number of active linearization segment table for the curve based on
number of segment tables in which user has configured the segment coordinates.
Function
The ENHGENLIN block is used to characterize functions of a single parameter, such as
heat transfer vs. flow rate, or efficiency as a function of load. It is particularly useful
when the relationship of the input to engineering units is empirically determined.
The ENHGENLIN block support a maximum of 4 input-output relationship curves,
allowing the selection of one of them for PV calculation. The ACTLINSEG parameter is
used to select the input-output relationship curve in the block and to control the run-time.
The VIEWLINSEG parameter is used for Control Builder (CB) access of the tables. The
ENBTUNE parameter enables the tuning of input and output co-ordinates in the
Monitoring View.
The linearization segments collectively define an input-output relationship curve on a
single linearization segment table, which is represented with values of IN and OUT
parameters. The IN and OUT parameter values of the linearization segment table selected
by the ACTLINSEG parameter are used for PV calculation. If the ACTLINSEG
parameter is used as a block pin, a TYPECONVERT block is used in cascade with
ENHGENLIN block to provide an integer input to ACTLINSEG parameter.
822 Experion LX Control Builder Components Theory R110
Honeywell February 2014
14. Auxiliary Functions
14.7. ENHGENLIN (Enhanced General Linearization) Block
Note: The IN/OUT parameter values can be edited only through the TEMPIN and
TEMPOUT parameter values when the system is running. TEMPIN and TEMPOUT
parameter is enabled when ENBTUNE parameter is “ON”.
If you try to modify the IN/OUT parameter value when the CM is ACTIVE and CEE is
RUN, an error follows: “ENBTUNE parameter must be used to change IN/OUT
parameter values”.
A single ENHGENLIN block is similar with four GENLIN blocks by providing 4 input-
output relationship curves. The ENHGENLIN block provides only one output for inputs
rather the GENLIN blocks provide 4 outputs.
Configuration Parameters
A summary of the ENHGENLIN block specific parameter is explained in the following
table. You must have the access level as “OPERATOR” or “ENGINEER” to enter or
configure or modify these parameter values from the Main tab of the Control Builder
(CB). This table does not include the description of the common block parameters such
as block description, engineering unit, and so on.
Input Co ordinate IN [INDEX1] Lets you to type the input values for
[INDEX2] the linearization segment table.
Output Co ordinate OUT [INDEX1] Lets you to type the output values for
[INDEX2] the linearization segment table.
Input
Two input values are required:
• P1 must be fetched from another function block.
• ACTLINSEG parameter value must be given by the user or it can be fetched from
the TYPECONVERT block.
Output
• PV.
• Boolean flag (PVSTSFL.BAD) set by PV to indicate to other function blocks, that
this block's PV status is bad.
Error Handling
• The ENHGENLIN block modifies the PVSTSFL.BAD status to ON if the following
conditions are satisfied:
− P1input status (P1STS) is Bad.
− Any of the involved linearization segment table segment co-ordinates (IN [ ] [ ]
or OUT [ ] [ ]) contains NaN (Not a Number). The active linearization segment
table is selected using ACTLINSEG parameter. The first segments are involved
as defined in NUMSEGS [ACTLINSEG] parameter.
• The Control Module containing the ENHGENLIN block cannot change the
EXECSTATE status to ACTIVE, if the following conditions are satisfied:
− Any of the segment co-ordinates (IN [ ] [ ] or OUT [ ] [ ]) contains NaN in the
NUMSEGS range of the two coordinate arrays.
− The IN [ ][ ] parameter values are not in ascending order. The values must be
monotonically strictly increasing.
− The OUT [][] parameters values are not in ascending order.
The logic explained in the figure is replaced using a single ENHGENLIN block.
TIP
The usage scenario presented here is to explain the ENHGENLIIN block
concept. The number of turbine control valves and the characteristics are
different for each turbine.
There are different Non Linearization Relations between the percentages of generated
Load with the percentage of Valve opening for different sequences. The sequence curve
varies based on the operation sequence selection by the OPERATOR.
There are two different modes of Governor Valve (GV) operations performed by the
ENHGENLIN block.
• Full Arc mode of governing (Uniform Operations)
• Partial Arc mode of governing (Sequence Operations)
The relation between the load percentage and the Governor Valves opening is gradually
increases and it is listed in the following table.
X – Co-ordinates Y – Co-ordinates
-1 -1
0 0
12.5 11.6
35.65 17.6
56.37 23
68.94 26.5
79.5 30
85.16 32.43
91.23 37.83
95.3 46.36
98.56 62.92
100 101
101 101
The sequences and the related operation of the Governor Valves operation with respect
to the load are explained in the following table.
• GV2 is opened 0%
• GV4 is opened 0%
• GV1 is opened 0%
The co-ordinates for the Governor Valves for each sequence are explained in the
following table.
For Governor Valves 1:
-1 -1 -1 -1 -1 -1
52 -1 36 0 70 0
-1 -1 -1 -1 -1 -1
70 -1 52 0 36 0
-1 -1 -1 -1 -1 -1
36 -1 70 0 52 0
X - COR Y - COR
-1 -1
0 -1
8.9 12.55
17.825 17.6
X - COR Y - COR
34.47 26.5
42.58 32.43
45.62 37.83
47.65 46.36
48.665 54.21
49.23 62.92
50 100
100 101
101 102
ENHGENLIN parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the GENLIN block.
ATTENTION
The ENHGENLIN block is typically applicable in the C300 (50ms CEE)
controllers.
The parameters for a FLOWCOMP block should be fetched from another function block,
by block wiring or through a parameter connector.
At every execution cycle the parameter will be fetched to calculate the compensation
term and compensated flow.
Function
The FLOWCOMP block uses the following basic equation to calculate a compensated
flow value as its output.
The FLOWCOMP block offers five different equations for calculating the flow
compensation term (COMPTERM). There is one equation for liquids, one for steam, and
three for gases and vapors. Each equation may require different inputs. For example,
depending on which gases and vapors equation you choose, one requires temperature and
pressure measurements, another requires temperature, pressure and specific gravity, and
a third requires temperature, pressure and molecular weight.
Configuration parameters
The following table provides a summary of the FLOWCOMP specific parameters that
you can configure through the Main tab of the block's properties form in Control
Builder. You must have an access level of at least an Engineer to enter or modify values
for these parameters. The table does not include descriptions of the common parameters
such as block name and description.
PV Display Format PVFORMAT Lets you define the decimal format to be used
to display the PV value. The choices are D0
(None), D1 (One), D2 (Two), or D3 (Three).
The default value is D1.
Overall Scaling CPV Lets you define the overall scaling factor to be
Factor for PV applied to the PV value to meet your process
requirements. The default value is 1.
Compensation Term COMPHILM Lets you define a high limit for the flow
High Limit compensation term The default value is 1.25.
Compensation Term COMPLOLM Lets you define a low limit for the flow
Low Limit compensation term. The default value is 0.8.
PV Equation Type PVEQN Lets you select the flow compensation equation
type the block is to use. The default value is
EQA (Equation A).
Bad Comp Term BADCOMPTERM.PR Lets you specify the priority level for a bad
Alarm Priority COMPTERM alarm. The default value is LOW.
Bad Comp Term BADCOMPTERM.SV Lets you specify the severity level for a bad
Alarm Severity COMPTERM alarm. The default value is 0.
Alarm Filter Cycles MAXCYCLE Lets you specify the number of filter cycles
before a bad COMPTERM alarm is generated.
The default value is 0. If the value is NaN, the
COMPTERM is frozen at its last good value for
indefinite period.
Zero Ref. for P0 Lets you specify the zero pressure reference
Pressure value for equations that require it. The default
value is 0.
Input
The PV Equation Type (PVEQN) selection determines the number of inputs that the
FLOWCOMP block requires as outlined in the following table. All inputs must be
fetched from other function blocks.
Output
This block produces the following outputs:
• PV and its status, PVSTS
You can configure the COMPTERM parameter as an output pin on the FLOWCOMP
block for connection to another block.
Equations
The FLOWCOMP block uses the following basic equation.
Where:
Equation A
Used for mass-flow or volumetric flow compensation of liquids.
• If PVCHAR = SQUAREROOT, then:
Equation B
Used primarily for mass-flow compensation of gases and vapors.
• If PVCHAR = SQUAREROOT, then:
Equation C
Used for mass-flow compensation of gases and vapors.
• If PVCHAR = SQUAREROOT, then:
Equation D
Used typically for volumetric-flow compensation of gases and vapors.
• If PVCHAR = SQUAREROOT, then:
Equation E
Used for mass-flow compensation of steam.
• If PVCHAR = SQUAREROOT, then:
Symbol definitions
Where:
G = Specific gravity
MW = Molecular weight
P = Pressure (input)
T = Temperature (input)
Error handling
If the status of any input is bad, the FLOWCOMP block handles the situation as
explained in the Alarm handling section below.
If there are no bad inputs, but the status of one or more inputs is Uncertain, the
FLOWCOMP block sets PVSTS to Uncertain.
If you do not connect the required inputs to the FLOWCOMP block for the selected PV
Equation Type (PVEQN), the error message All required Inputs Not Connected will be
displayed when you try to load the FLOWCOMP block.
Alarm behavior
The logic used for BAD COMPTERM behavior is as follows.
If any of the inputs used in the configured PV Equation Type for computing
COMPTERM goes BAD, then:
• If Cycle is less than MAXCYCLE or MAXCYCLE = NaN, then:
− Freeze the COMPTERM to last good value
− Set PVSTS to UNCERTAIN
• If MAXCYCLE = NaN
Where:
MAXCYCLE Is the configured number of alarm filter cycles during which the last
good value for the COMPTERM is to be held before becoming
NaN.
You can view the alarm with the highest priority through the HIALM.TYPE parameter
on the monitoring faceplate of the FLOWCOMP block. When the FLOWCOMP block is
in BADCOMPTERM alarm, the HIALM.TYPE indicates BADCOMPTERM. In this
case, HIALM.PR and HIALM.SV parameters are updated with BADCOMPTERM.PR
and BADCOMPTERM.SV parameter data, respectively.
Alarm example
In case of EQNA, if Specific Gravity (G) is BAD for longer than acceptable number of
cycles (MAXCYCLE cycles) then BADCOMPTERM alarm will be raised.
842 Experion LX Control Builder Components Theory R110
Honeywell February 2014
14. Auxiliary Functions
14.9. GENLIN (General Linearization) Block
Fail-Safe values
If any of the input status signals F Status, X Status, P Status, T Status, Q Status, G
Status, and MW Status become BAD, the corresponding input values are set to NaN.
There are no fail-safe values for these variables
FLOWCOMP parameters
REFERENCE - INTERNAL
Refer to Control Builder Components Reference for a complete list of the
parameters used with the FLOWCOMP block.
Each time the GENLIN block runs, it compares the input value (P1) with each segment
based on a coordinate pair - starting with the first and continuing until it finds a segment
that intersects with the input. When that segment is found, the block derives the output
(PV) as follows:
• If P1 is exactly equal to the input value at the beginning of any segment (that is, P1
= IN[i], for i in the range of 0 to NUMSEGS):
PV = OUT[i]
• If P1 intersects the first segment (that is, P1 < IN[1]):
OUT(1) - OUT(0)
PV = * [P1 - IN(0)] + OUT(0)
IN(1) - IN(0)
• If P1 intersects the last segment (that is, P1 > IN[i] for i = NUMSEGS - 1)):
OUT(NUMSEGS) - OUT(i)
PV = * [P1 - IN(i)] + OUT(i)
IN(NUMSEGS) - IN(i)
• If P1 intersects any other segment (that is, IN[i] < P1 < IN[i + 1] for i =1 to
NUMSEGS -2):
OUT(i + 1) - OUT(i)
PV = * [P1 - IN(i)] + OUT(i)
IN(i + 1) - IN(i)
where:
IN[i] = input value at the beginning of the intersecting segment.
IN[i + 1] = input value at the end of the intersecting segment
OUT[i] = output value at the beginning of the intersecting segment
OUT[i + 1] = output value at the end of the intersecting segment
NUMSEGS = total number of segments in the curve based on 2 to 13 user defined
coordinate pairs.
ATTENTION
• The first and last segments are treated as if they are infinitely
extended. So if P1 is less than IN[0] or greater than IN[NUMSEGS],
PV is computed by assuming that the slope in the appropriate segment
continues to the intersecting point.
Function
The GENLIN block is typically used to provide a linearized PV (in engineering units) for
a sensor with nonlinear characteristics. The GENLIN block can also be used to
characterize functions of a single parameter, such as heat transfer versus flow rate, or
efficiency as a function of load. It is particularly useful when the relationship of the input
to engineering units is empirically determined.
Inputs
The GENLIN block requires one input value (P1):
• P1 must be brought from another function block.
• P1STS represents the status of P1.
Outputs
The GENLIN block produces the following output:
• PV and its status, PVSTS. It also sets Boolean flags PVSTSFL to reflect the status
of PVSTS for logical use.
Error handling
• If P1STS is Uncertain, the GENLIN block sets PVSTS to uncertain.
• If P1STS is Bad, or if any of the segment coordinates (IN[i] or OUT[i]) contains
NaN (Not a Number), this block sets PVSTS to Bad.
• If any of the segment coordinates (IN[i] or OUT[i]) contains NaN (not a Number,
the Control Module that contains the GENLIN block will not be allowed to go
Active (EXECSTATE = Active).
GENLIN parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the GENLIN block.
Each LEADLAG block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that Tab. This data is only provided
as a quick document reference, since this same information is included in the on-line
context sensitive Help.
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
the Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
the Control Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
Function
The LEADLAG block is typically used in a feedforward control loop. It provides its
compensated PV output as the input to the feedforward (FF) input of the PIDFF block.
This helps condition the control response to the actual process characteristics.
Input
The block requires one input. P1 must be brought from another block.
Output
The block produces an output value (PV), a status (PVSTS), and a status flag
(PVSTSFL).
PV status
PV status (PVSTS) may have one of the following values:
• Bad - which means that PV is NaN (Not a Number)
• Normal - which means PV is OK.
• Manual - which means P1 source (for example, DATAACQ block) is in manual PV
source.
• Uncertain - which means that PV is OK but P1 status is uncertain.
The following Boolean flags (typically used with Logic and Alarm blocks) also reflect
the value of PVSTS:
• PVSTSFL.BAD - if PVSTS = Bad, this flag is on; otherwise it is off.
• PVSTSFL.NORM - if PVSTS = Normal, this flag is on; otherwise it is off.
• PVSTSFL.MAN - if PVSTS = Manual, this flag is ON; otherwise it is off.
• PVSTSFL.UNCER - if PVSTS = Uncertain, this flag is on; otherwise it is off.
Error handling
If the P1 input status (P1STS) is Uncertain, this block sets PV status (PVSTS) to
Uncertain.
If the P1 input status (P1STS) is Bad, this block sets the PV status (PVSTS) to Bad and
the PV output to NaN.
Equation
The LEADLAG block applies the following equation.
LAG1TIME = First order lag time constant (If 0, no first order lag)
LAG2TIME = Second first order lag time constant (If 0, no second order lag).
Restart condition
When this block experiences a Restart condition, the lead-lag dynamics are set to a
steady state and the PV is calculated as follows.
PV = CPV P1 + DPV
When the INITREQ parameter is True, the block's algorithm produces the same result as
the Restart condition.
LEADLAG parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the LEADLAG block.
The Rate of Change block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that tab.
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
the Control Builder.
Configuration Lets you select the available parameters that appear on the
Parameters face of the function block in the Project tab in the Control
Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in the Control Builder.
Template Defining Lets you view and define parameters for associated
templates.
Function
• Limits the rate of input and provides the output variable based on the rate trip limits.
• Limits the rate of change of output to the specified rate trip limit when the input
variation is greater than the rate trip limit in either direction. The output is changed
at the specified rate limit until the value is equal to the input variable.
• Uses the PVROCBYPASSFL parameter to BYPASS the rate trip limit.
• Provides a Bad PV alarm based on the status of the output.
• Rate limit is not applied and PV is set to P1 if the rate limits are NaN.
• For an invalid input (=NAN), rate limiting is not done and the output is NaN.
ATTENTION
• The ROC block is basically a Math block.
Predecessor Block
The ROC block receives three FLOAT type inputs. The input P1 receives input from
other function blocks. An Engineer has access to the two ROC limits. The following
figure illustrates a logic using a NUMERIC block and an ROC block.
Execution
If the input variation is more than the specified limit, the output is limited to the change
specified using PVROCLM (Rate of Change's Trip Point) and it is applicable to input
variation in either direction. For each block execution cycle, the output is incremented by
the rate of change until the output is equal to the original input. PVROCPOSFL indicates
if the limit is exceeded in the positive direction and PVROCNEGFL indicates if the limit
is exceeded in the negative direction. If P1= NAN, rate limiting is not done and PV is set
to NaN and PVROCPOSFL and PVROCNEGFL are reset. If the limit is NaN, then limit
is not applied and PV is set to P1.
Configuration examples
User scenario 1
The following configuration is recommended if the input has to be rate limited in the
positive direction at the rate of 60 EUs/min.
PVROCPOSLM = 60
PVROCNEGLM = NaN
PVEULO = 0
PVEUHI = 100
User scenario 2
The following configuration is recommended if the input has to be rate limited in the
negative direction at the rate of 60 EUs/min.
PVROCPOSLM = NaN
PVROCNEGLM = 60
PVEULO = 0
PVEUHI = 100
Inputs
• P1 - Process Input 1.
• PVROCPOSLM - PV Rate of Change limit in the positive direction.
• PVROCNEGLM - PV Rate of Change limit in the negative direction.
Outputs
• PVROCPOSFL - This flag turns ON when rate limiting is done in the positive
direction.
• PVROCNEGFL - This flag turns ON when rate limiting is done in the negative
direction.
• PV - Output of ROC.
• BADPVFL - This flag is set when a bad input is received at the block.
Error handling
• Access lock and index are verified during Load and Store of the block's parameters.
• If the positive limit is greater than span in EUs/min or less than 0, then a
"LimitOrRangeCrossover" Error is reported.
ATTENTION
BADPVALM.FL and BADPVFL parameters essentially provide the same
functionality of indicating a bad PV. Either of the two parameters may be used
to achieve the functionality.
ROC parameters
REFERENCE
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the Rate of Change block.
Function
This function block supports the following methods for selecting an input:
Method Processing
MIN Select the input with the minimum value. Ignored inputs are excluded.
MAX Select the input with the maximum value. Ignored inputs are excluded.
AVG Calculate the average of the inputs. Ignored inputs are excluded.
MUX Select an input based on the Multiplex value; that is, act as a multiplexer.
Inputs are not ignored.
Configuration parameters
The following table provides a summary of the SIGNALSEL specific parameters that
you can configure through the MAIN tab of the block's properties form in Control
Builder. The table does not include descriptions of the common parameters such as block
name and description.
Median Option for Middle MEDOPT Lets you select the operation to
Two Inputs perform with the middle two inputs
when even number of inputs is
valid. This parameter is enabled
only when SELMETHOD is MED.
Boolean Mux Selection SELXFL Lets you set the selection flags for
flags. Boolean Mux selection.
Rate for Bumpless PVRATE Lets you set the rate of change
Transfer per minute to provide bumpless
transfer of PV value.
Ignore Time IGNORTM Lets you set the time limit beyond
which inputs that are outside the
IGNORLM value will be ignored.
Deviation Alarm Trippoint DEVALM.TP Lets you set the trip point for the
deviation alarm.
Deviation Alarm Time DEVALM.TM Lets you set the time in seconds
after which a deviation alarm will
be declared. if the lowest and
highest input values exceed the
deviation trip point
Deviation Alarm Priority DEVALM.PR Lets you set the priority of the
deviation alarm.
Deviation Alarm Severity DEVALM.SV Lets you set the severity of the
deviation alarm.
Deviation Alarm DEVALM.DB Lets you set the deadband for the
Deadband deviation alarm.
Configuration examples
Case 1:
Here, as shown in the figure above the block is configured for "Middle Two Inputs
(MEDOPT): MIN".
Hence, the selected input shall be the Minimum of the middle two input values (P[1] and
P[3]) which is P1. Hence P1 is selected and PV of SIGNALSEL is 9, the value of P[1].
Case 2:
If the block were configured for "Middle Two Inputs (MEDOPT): MAX", then
following parameters would be
PV: 11
PVSTS: UNCERTN
SELIN: Select P3
Now, maximum of the middle two input values (P[1] and P[3]) is selected. Hence P3 is
selected and PV is 11, the value of P[3]. PVSTS is UNCERTN because P[3] is the
selected input and the status of P[3] is uncertain.
Case 3:
If the block were configured for "Middle Two Inputs (MEDOPT): AVG", then following
parameters would be
PV: 10
PVSTS: UNCERTN
SELIN: None
Now average of the middle two input values (P[1] and P[3]) is selected. Hence none is
selected and PV is 10. PVSTS is UNCERTN because selected input is an average of
P[1] and P[3], one of which (P[3]) has status as uncertain.
Case 4:
Say input P[3] goes Bad. Now only three (odd) inputs are valid and hence the middle
value (P[1]) of the three is taken as the PV directly whatever be the MEDOPT
(applicable only for even number of valid inputs). The strategy would look as below
Case 5:
Say input P[1], P[3], P[4] are ignored, then the respective IGNORDFL[ ] parameters are
set. Now only one input is valid and CURINPT goes less than the NMIN and hence the
blocks output is set to Bad and SELIN is None.
Case 6:
Now, the user could override the selection using force-select, that is, both FRCPERM
and FRCREQ are set, then the input denoted by the FRCSEL shall be the selected input.
The user can force-select ignored inputs also.
If the block is configured with Selection Method = MUX and BOOLMUX= On, it would
function as follows.
Input
• This function block accepts between two to six selectable inputs, P[1] through P[6].
Minimum two inputs are required (P[1] and P[2]).
• All inputs shall be fetched from other function blocks.
• If less than two inputs are connected a warning "At least two inputs needs to be
connected" shall be given during load and activation of the block shall be prevented.
• If the total number of valid inputs goes less than the configurable parameter
Minimum Valid Inputs(NMIN) value, then the output of the block shall go bad.
• The NMIN parameter applies only to the following selection methods: MIN, MAX,
MED, or AVG and is not applicable if the selection method is MUX or Force
selection is performed.
Ignore Inputs
The function block always ignores Bad inputs, such as NaN, which are connected to any
upstream block. Unconnected inputs do not participate in the selection processing. In
addition, the user may choose to ignore the "n" highest (IGNORHI) or/and "m" lowest
(IGNORLO) inputs. These values can be from Logic blocks and user programs may also
store to it, so the number of ignored inputs may be dynamic.
• If all the inputs are ignored, output shall go Bad.
• If the total number of inputs to be ignored (n+m) is equal to or greater than the total
number of connected inputs, a warning message "IGNORHI+IGNORLO should be
less than the number of connected inputs" shall be given during load and activation
of the block shall be prevented. During running state for the same above case, a non-
critical error with the same error message is displayed and the previous value of
IGNORHI or IGNORLO (whichever is configured) is retained.
The user may also choose to ignore inputs that are outside a user-specified ignore limits.
TIP
If there are only two remaining inputs, and the difference between them
exceeds the ignore limit, the block's output (PV) is set to NaN.
The IGNORHI, IGNORLO and ignore limit checking shall not be applicable for the
MUX selection method.
Output
• This auxiliary PV block shall have output PV and its status PVSTS.
• It shall have a parameter SELIN denoting which input, if any has been selected as
the output.
• The block shall have the following output flags.
− One flag denoting if any of the inputs is ignored or not (IGNORD).
− Individual flags for each input indicating if it was ignored (IGNORDFL[1…6]).
Selection Methods
This function block supports the following methods for selecting an input:
Method Processing
MIN Select the input with the minimum value. Ignored inputs are excluded.
MAX Select the input with the maximum value. Ignored inputs are excluded.
Method Processing
AVG Calculate the average of the inputs. Ignored inputs are excluded.
ATTENTION
The selection method that the block has to use is specified during
configuration. During runtime, the selection method can be changed only if
the block is inactive.
MIN
• The output (PV) gets the minimum value of all the valid (not ignored) inputs.
• The selected input shall be the input that has this minimum value.
• If two or more inputs have the minimum value then the selected input would be the
input with the highest index. For instance, if P[2] and P[5] have the minimum value
then the selected input would be P[5].
MAX
• PV gets the maximum value of all the valid inputs.
• The selected input shall be the input that has this maximum value.
• If two or more inputs have the maximum value then the selected input would be the
input with the highest index. For instance, if P[2] and P[5] have the maximum value
then the selected input would be P[5].
AVG
• PV shall be the average of only the valid inputs.
• The selected input shall be None because PV is a calculated value and not any input
by itself.
MED
• All the valid inputs are arranged in ascending order and median value is taken as
PV.
• If odd number of valid inputs is present then the middle value will be the PV and the
selected input shall be the respective input.
• If even number of valid inputs is present then the PV shall be any one of the
following depending on the parameter 'Median Option for Middle Two Inputs
(MEDOPT)'.
• If MEDOPT is MIN, then PV shall be the minimum of the middle two values and
the respective input shall be selected input.
• If MEDOPT is MAX, then PV shall be the maximum of the middle two values and
the respective input shall be selected input.
• If MEDOPT is AVG, then PV shall be the average of the middle two values and
selected input shall be none because average is computed.
TIP
While arranging in ascending order, if two inputs have same value; then the
input that comes first in order 1 to 6 precedes the other.
MUX
• A Boolean flag BOOLMUX is employed to choose between Integer Mux selection
and Boolean Mux selection. If the flag is set to On, Boolean selection will be
performed, otherwise Integer selection will performed.
• In Integer Mux selection, a control signal MUXSEL (multiplex-selector) is required,
which shall be user configurable or fetched from other function block, or user
programs could also store it.
• If the fetched or configured MUXSEL value goes invalid, such as greater than the
number of process inputs ,then the previous valid value of MUXSEL is retained and
the respective input remains selected.
• If the fetched or configured MUXSEL is valid, but the input corresponding to
MUXSEL is not connected, then the PV value goes bad (NaN) and the respective
unconnected input remains selected.
• In Boolean Mux selection, the SELXFL[1..6] flags are scanned from 1 to 6 and the
block selects an input whose corresponding SELXFL flag is first On.
• If the Boolean selected input is not connected, then the PV value goes bad (NaN)
and SELIN will have the index of unconnected input.
• And, if none of the SELXFL flag is on (but only the BOOLMUX is on and
SELMETHOD is Mux), then the PV value goes bad (NaN) and SELIN's value will
be None.
• Bad inputs may also be selected.
• Ignoring of Inputs and deviation alarming are not applicable for MUX. Also, the
deviation alarm state should return to normal.
• PV gets the value of the selected input.
• If the value of the input denoted by the control signal is Bad, then the PV also goes
Bad.
Force-Select
• The operator or a user program may override the selection method and "force select"
a particular input.
• Force-select may override only the following selection methods: MIN, MAX, MED,
or AVG and is not applicable if the selection method is MUX.
• If the force selected input is not connected, then the PV value goes Bad (NaN) and
the respective unconnected input remains selected
• Ignore Inputs, Ignore limit checking, NMIN and deviation alarming are not
applicable during force selection. Also, the deviation alarm state should return to
normal.
Ramping rate is specified in rate of change per minute. PV shall ramp at this rate to the
new value. If the ramp rate is zero, bumping occurs. Ramping can be disabled by setting
ramp rate to NaN.
Deviation Alarming
• The SIGNALSEL block may be configured to generate an alarm, if the range
between the lowest and highest inputs exceeds the deviation trip point
(DEVALM.TP) for more than a specified time.
• If the deviation trip point is set to be NaN, deviation alarming is disabled; and if it is
set to be greater than or equal to zero, deviation alarming is enabled.
• Once deviation alarm is triggered, a deviation alarm flag is set. When the alarm goes
off, the flag is reset.
Error handling
The SIGNALSEL block sets PV state to Uncertain under any of the following
conditions:
• An input selection is forced and the status of that input is Uncertain.
• The selection method is MIN, MAX, or MUX, and the status of the selected input is
Uncertain.
• The selection method is AVG, and the status of any input is Uncertain.
• The selection method is MED and the status of the selected middle input (odd
number of valid inputs) or any of the middle two inputs (even number of valid
inputs) is Uncertain.
The block sets the PV state to Manual under any of the following conditions:
• An input selection is forced and the status of that input is Manual.
• The selection method is MIN, MAX, or MUX, and the status of the selected input is
Manual.
• The selection method is AVG, and the status of any input is Manual.
• The selection method is MED and the status of the selected middle input (odd
number of valid inputs) or any of the middle two inputs (even number of valid
inputs) is Manual.
PV becomes NaN and PV state becomes Bad under either of the following conditions:
• Forced selection is in effect, and the status of that input is Bad.
• The number of valid inputs goes less than NMIN (Minimum Valid Inputs) value.
Except when force-selected or selection method is MUX, inputs with a Bad status are
ignored.
• Cycle time counters used for DEVALM.TM and IGNORTM parameters are reset so
that the counting starts from the beginning when the SIGNALSEL block goes to
active again.
SIGNALSEL parameters
REFERENCE - INTERNAL
Refer to Control Builder Components Reference for a complete list of the
parameters used with the SIGNALSEL block.
You specify a target value for the accumulator, and up to four trip points, which are
"near" and "nearer to" the target value. The TOTALIZER block sets status flags to
indicate when the accumulator value is near (and nearer to) the user-specified target
values. A trapezoidal-integration method of accumulation is used to improve accuracy.
Accumulation proceeds even when the target value is exceeded. An external operator or
program command is required to stop the block from further accumulating.
Function
The TOTALIZER block is typically used to accumulate total flows. For situations where
the flow transmitter may not be precisely calibrated near the zero-flow value, a zero-flow
cutoff feature is provided such that when P1 is below the cutoff value it clamps to zero.
Configuration example
The following figure and its companion callout description table show a sample
configuration that uses a TOTALIZER block in a flow control loop for quick reference.
The view in the following figure depicts a loaded configuration in Monitoring mode.
The following table includes descriptions of the callouts in the figure above.
Callout Description
1 Use the PV parameter connection to carry data and status from the analog
input, DATAACQ, and TOTALIZER blocks to the PID block. The default PV
connection is exposed, but the implicit/hidden connection function
automatically makes a connection to a value/status parameter
(PVVALSTS) when it is required.
Callout Description
2 When monitoring, you can use the COMMAND parameter on the block to
issue Start, Stop, or Reset command. You must configure COMMAND as a
monitoring parameter through the block configuration form.
You can also use logic inputs to STARTFL, STOPFL, and RESETFL pins
on the block to initiate Start, Stop, and Reset commands, respectively.
3 When the accumulated value (PV) reaches the accumulated target value
(ACCTV), the accumulated target value flag (ACCTVFL) turns ON.
4 In this example, the following values were configured for the Trip Points 1
to 4 through the parameter configuration form based on a configured target
value of 100.
• Trip Point 1 (ACCDEV.TP[1] = 10
• ACCDEV.FL[2] turns ON at PV = 80
• ACCDEV.FL[3] turns ON at PV = 70
• ACCDEV.FL[4] turns ON at PV = 60
Input
The TOTALIZER block requires one input (P1):
• P1 is the value to be accumulated - the input value may be Real, Integer, or Boolean,
but is always stored as a real number.
• P1 must be brought from another block.
R110 Experion LX Control Builder Components Theory 875
February 2014 Honeywell
14. Auxiliary Functions
14.13. TOTALIZER Block
Outputs
The TOTALIZER block produces the following outputs:
• The accumulated value (PV) and its status (PVSTS).
• Flags, indicating if the accumulated value has reached the user-specified target value
or one of the accumulator deviation trip points (ACCTVFL and ACCDEV.FL [1-
4]).
TOTALIZER states
The TOTALIZER block has two possible states: Stopped and Running. The STATE
parameter identifies the current state and the following parameters may be used to
change the state:
• COMMAND: The operator or a user program may command the accumulator to
Start, Stop, or Reset by storing it to the COMMAND parameter. Since COMMAND
is a write-only parameter, its displayed value does not reflect the last entered
command.
Totalizer must be reset using the reset pin before the totalizer can start counting.
Otherwise P1 will have a good value, but PV will remain at zero.
When the TOTALIZER receives a reset command, it copies the current value of
PV to OLDAV (old accumulation value), and then sets PV equal to
RESETVAL. This allows other system functions using the totalized value to
reset the TOTALIZER without losing any "accumulation".
• CMDATTR: Specifies who may store it to COMMAND (that is, either the operator
or a user program through another function block). CMDATTR is used to prevent
the operator from inadvertently changing the accumulator while it is under program
control and allows the operator to override a program.
Possible choices are:
− Operator - only the operator may store it to COMMAND.
− OtherFB- only a program through another function block may store to
COMMAND; the operator may override the program by setting CMDATTR =
Operator.
• STARTFL (Start Flag): Allows either a Logic block or user-written program to store
it to COMMAND.
− Off-to-On transitions cause the TOTALIZER state to change to Running.
• STOPFL (Stop Flag): Allows either a Logic block or user-written program to store
to COMMAND.
− Off-to-On transitions cause the TOTALIZER state to change to Stop.
• RESETFL (Reset Flag): Allows either a Logic block or user-written program to
store to COMMAND.
− Off-to-On transitions cause the TOTALIZER to be reset.
a trip point. For example, if the user sets ACCTV = 50 and ACCDEV.TP[1] = 10, the
TOTALIZER block sets ACCDEV.FL[1] to ON when PV is greater than or equal to 40.
Equations
PVEQN is a user-configured parameter, which specifies how the TOTALIZER should
handle bad inputs and warm restarts. One of the following equations is specified using
PVEQN:
The following table summarizes block actions associated with a given PVEQN handling
option relative to the accumulator state and the input status.
Running (STATE = Use zero if input is Sets the input value (P1) to zero
RUNNING) and the input bad. and sets PVSTS to Uncertain.
status (P1STS) is BAD When the input status (P1STS)
returns to normal, PVSTS
remains Uncertain until a Reset
command is received.
Running (STATE = Use last good value if Sets the input value (P1) to its
RUNNING) and the input input is bad. last good value and sets PVSTS
status (P1STS) is BAD to Uncertain.
When the input status (P1STS)
returns to normal, PVSTS
remains Uncertain until a Reset
command is received.
Running (STATE = Stop if the input is Sets the input value (P1) to NaN
RUNNING) and the input bad. (Not a Number) and sets PVSTS
status (P1STS) is BAD to Bad.
When the input status (P1STS)
returns to normal, PVSTS
remains Bad until the operator
restarts the accumulation.
Running (STATE = Stop after a warm Sets the accumulated value (PV)
RUNNING) restart. to NaN (Not a Number), sets
PVSTS to Bad, and stops the
accumulation. The operator must
intervene to restart the
accumulator.
Where:
Error handling
• PVSTS is set to UNCERTAIN when:
− The status of the input (P1STS) is Uncertain.
− The input status is Bad and the "use zero" or "use last good value if input is bad"
option is configured (Equation A, B, D, or E).
− The TOTALIZER block is in warm restart and the "continue" option is
configured (Equation A, B, or C).
• PV is set to NaN (Not a Number) and PVSTS is set to Bad, when:
− The status of the input (P1STS) is Bad and the "stop if input is bad" option is
configured (Equation C or F).
− The TOTALIZER block is in warm restart and the "stop" option is configured
(Equation D, E, or F).
• When PVSTS is Bad, the TOTALIZER block sets ACCTVFL and ACCDEV.FL[1-
4] to Off.
ATTENTION
When the input status returns to normal, a Reset command is needed to
return PVSTS to Normal.
TOTALIZER parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the TOTALIZER block.
Each DATAACQ block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that Tab. This data is only provided
as a quick document reference, since this same information is included in the on-line
context sensitive Help.
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
Control Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Insertion Type Lets you include an insertion type from a CAB instances in
the block. See CAB insertion configuration considerations
Parameter Description
PVAUTO Filtered and clamped value of the Process Input Value (P1)
PVAUTOSTS Status of the filtered and clamped value of the Process Input
1 (PVAUTO)
• If you insert multiple CAB programs at the same point, the order in which the
insertions are configured determines their execution order. During configuration, the
ORDERINCM parameter of the inserted CAB instance changes automatically to
match that of the calling DATAACQ block and the INSERTION parameter of the
inserted CAB instances is set to TRUE.
• CAB instances configured for insertion execute only when they are called during
DATAACQ block execution and are not executed as part of the normal Control
Module execution.
• CAB instances configured for insertion should normally have no outside pin
connections configured. If you need to share CAB instance data with blocks other
than the one with inserted CAB programs, you can use parameter connectors or
direct wire connections to configured pin connections for custom data parameters on
the CAB instance. See the Pin connections to inserted CAB instances section for
more information.
• The Control Builder application will not allow you to configure the same CAB
instance as an insertion by more than one DATAACQ block.
Post Clamping and Filtering (Post_Clampfilt) Provides the capability of implementing custom
source selection strategies and bypass the built
source selection. The final value is stored in
PV. The CAB program should also set PVSTS,
PVEXHIFL, and PVEXLOFL parameters to the
appropriate states.
Post Alarm Processing (Post_Alarmproc) Provides the capability of modifying the built-in
alarm processing.
If your application calls for inserted CAB instances to share data with blocks other than
the calling block, you can configure pin connections for custom data parameters on the
CAB instance. If pin connections are configured, be aware that the data transfer operates
as follows:
• Pin connections always transfer data into a CAB insertion program just before
execution of the calling block.
• Pin connections always transfer data out of a CAB insertion program just before
execution of the block that is pulling the CAB custom data parameter (CDP).
Callout Description
Callout Description
containing the daca block.
If the CAB_1 instance is not used for an insertion point and the
INSMASTER parameter is turned Off or set to False, it is included in
the Control Module execution list and runs normally during each
cycle. In this case, no tag name appears in the Insertion Point
(INSMASTER) field on the block's configuration form and the CAB
must be re-configured for an Access Level of PROGRAM.
Failure Scenario
If the CAB_1 program does not run till completion and returns a non-normal status, the
following action takes place:
• The value of PVAUTO and PV are set to NaN.
Callout Description
Callout Description
True.
If any of the programs CAB_1A, CAB_2A or CAB_3A return a non normal status, the
following actions are taken.
• PVAUTO and PV are set to NAN.
• The BADPV and any other alarms detected during the current cycle is processed
Callout Description
3 The CAB instances named CAB_1A and CAB_2A are added to the
Control Module containing the daca block.
Callout Description
both CAB instances are turned On or set to True.
Failure Scenario
If either CAB_1A or CAB_2A program does not run till completion and returns a non-
normal status, the following action takes place:
• The value of PVAUTO and PV are set to NaN.
Input
The DATAACQ block requires one process input value - P1. P1 must be brought from
another block.
PVEXHILM and PVEXLO.LM define the high and low limits of P1 in engineering
units.
• If P1 clamping is desired (P1CLAMPOPT = Enable), the DATAACQ block clamps
the input within the range defined by PVEXHILM and PVEXLOLM.
P1 status
You must configure the DATAACQ block to bring P1 from another block. Typically, the
other block is an AI Channel block. If the P1 source provides a value and status, the
DATAACQ block fetches both; otherwise it fetches the value only and derives a status
from that.
• If the P1 source provides a value and status, the status (P1STS) may have one of the
following values:
− BAD - value is NaN (Not a Number)
− Normal - value is OK.
− Manual - value is OK, but was stored by an operator (at the source block)
− Uncertain - value is OK, but was stored by a user-program (at the source block)
• If the P1 source provides a value only, the block derives P1STS as follows:
− If P1 is NaN (Not a Number), then: P1STS = Bad.
− Otherwise, P1STS = Normal.
• If P1 cannot be fetched (for example, due to a communications error), P1 is set to
NaN and P1STS is set to Bad.
PV Characterization
You can configure the PV Characterization option to have the DATAACQ block provide
one of the following conversion functions.
• LINEAR: Converts P1 to Engineering Units based on the 0 to 100 input span (100)
and the configured PV span in Engineering Units (PVEUHI - PVEULO). The linear
conversion is calculated as follows.
where:
For example, If you want to convert the P1 input to a range of 0 to 1200 degrees,
configure PVEULO as "0" and PVEUHI as "1200". In this case, if P1 input is 50%,
P1EU equals (50 / 100) (1200 - 0) + 0 or 0.5 1200 equals 600 degrees.
• SQUARE ROOT: Applies a square root calculation to the P1 input such that 100%
of span equals 1.0. Then, convert the square root value to Engineering Units based
on the configured PV span in Engineering Units (PVEUHI - PVEULO). The Square
Root conversion is calculated as follows.
− For P1 input greater than or equal to zero (0):
For example, If you want to convert the P1 input to a range of 0 to 1200 gallons per
hour, configure PVEULO as "0" and PVEUHI as "1200". In this case, if P1 input is 40%,
P1EU equals the square root of (40 / 100) (1200 - 0) + 0 or 0.632 1200 equals 758.4
gallons per hour.
• NONE: Applies no conversion to the P1 input.
Input filtering
The P1 FILTTIME parameter indicates if P1 should be filtered. If a non-zero filter time
(P1FILTTIME) is specified, a first-order filter is applied to P1EU and the result is stored
in an intermediate parameter called FilteredP1 (not a visible parameter). As long as
FilteredP1 is within PV limits, it is copied to PVAUTO.
• FilteredP1 is computed as follows:
where:
• Actual input value is stored in P1; the linear or square root converted P1 in EU is
stored in P1EU, and the filtered and clamped result is stored in PVAUTO.
• Status of the filtered/clamped value is stored in PVAUTOSTS.
• If P1 is bad (NaN), the block stops filtering and sets PVAUTO to NaN. When P1
returns to good, the block sets FilteredP1LAST equal to the new P1EU, and starts
filtering again.
• P1FILTTIME may have a value of 0 to 1440 minutes (or fractions thereof). Given a
single-step change in P1:
− FilteredP1 = 63.2% of P1EU after P1FILTTIME.
− FilteredP1 = 86.5% of P1EU after 2 P1FILTTIME.
− FilteredP1 = 95.0% of P1EU after 3 P1FILTTIME.
− FilteredP1 = approximately 100% of P1EU after 10 P1FILTTIME.
Input clamping
The P1CLAMPOPT parameter is used to clamp a filtered P1 within PV high/low limits
(PVEXHILM and PVEXLOLM). If filtering is not configured, then P1CLAMPOPT is
used to clamp P1 as follows:
• If P1CLAMPOPT = Enable, the block clamps the filtered P1 to the PV limits and
stores the result in PVAUTO. If the filtered input is outside the PV limits:
− P1 = Actual input value
− P1STS = Normal
− PVAUTO = Exceeded limit
− PVAUTOSTS = Uncertain (because the value was clamped)
Output
The DATAACQ block produces an output value (PV) and status (PVSTS) as well as a
status flag (PVSTSFL).
PV source selection
PVSOURCE (which may be changed by the operator or user program) provides the
following values to specify where the block's output should come from:
• AUTO (Automatic) - indicates that PVAUTO is used as the PV (where PVAUTO
contains the clamped and filtered value of P1) and PVSTS tracks PVAUTOSTS.
• MAN (Manual) - indicates that the operator may enter the PV and:
− sets PVSTS to Manual.
− rejects any attempts by the operator to store a value that exceeds the PV limits
(PVEXHILM and PVEXLOLM.
PV status
PV status (PVSTS) may have one of the following values:
• Bad - which means that PV is NaN (Not-a-Number).
• Normal - which means PV is OK.
• Manual - which means that PV is OK, but was stored by an operator.
• Uncertain - which means that PV is OK but was stored by a program.
The following Boolean flags (typically used with Logic and Alarm blocks) also reflect
the value of PVSTS:
• PVSTSFL.BAD - if PVSTS = Bad, this flag is on; otherwise it is off.
• PVSTSFL.NORM - if PVSTS = Normal, this flag is on; otherwise it is off.
• PVSTSFL.MAN - if PVSTS = Manual, this flag is ON; otherwise it is off.
• PVSTSFL.UNCER - if PVSTS = Uncertain, this flag is on; otherwise it is off.
Alarm processing
The DATAACQ block may be configured to generate an alarm when PV exceeds one of
the following trip points for more than a specified time:
• PV High trip point (PVHIALM.TP) - if PV exceeds this trip point for more than
PVHIALM.TM seconds, a PV High alarm is generated and the PV High alarm flag
(PVHIALM.FL) is set.
ATTENTION
• The rate-of-change trip point is specified in EUs per minute.
ATTENTION
• The rate-of-change trip point is specified in EUs per minute.
The following parameters also apply to each of the previously specified alarms:
• Alarm Filter Time (PVHIALM.TM, PVHHALM.TM, etc.) - Prevents input spikes
from causing alarms. PV will only be alarmed if it consistently exceeds the trip
point for more than xxxALM.TM seconds.
Note: This parameter does not apply to the Rate-of-Change alarms (i.e., there is no
ROCNEGALM.TM or ROCPOSALM.TM parameter).
• Alarm Deadband Value (PVHIALM.DB, PVHHALM.DB, etc.) - Note that alarm
deadband is not supported for Rate-of-Change alarms.
Prevents recurring alarms and returns-to-normal due to a noise when PV is near the
trip point. The deadband is applied to the return-to-normal. For example, if PV is in
high alarm (PVHIALM.FL = On), it must return to a value of PVHIALM.DB below
the high trip point before it is considered "normal"; and if it is in low alarm, it must
return to a value of PVLOALM.DB above the low trip point.
• Alarm deadband units (PVHIALM.DBU, PVHHALM.DBU, etc.) - Indicates if the
corresponding alarm deadband (xxxALM.DB) is in percent or engineering units.
PV significant-change alarming
If PV is between the high and high-high alarm trip points and continues to rise, the
following parameters may be used to reannunciate the high alarm:
• PV High Significant-Change Trip Point (PVHISIGCHG.TP) - reannunciates the
high alarm when PV is between the PV high and high-high limits (PVHIALM.TP
and PVHHALM.TP) and keeps rising.
When PV falls below the high alarm trip point (and deadband), the count is reset to
zero.
Similarly, if PV is between the low and low-low alarm trip points and continues to
decrease, the following parameters may be used to reannunciate the low alarm:
• PVLOSIGCHG.TP - the PV Low Significant-Change Trip Point.
R110 Experion LX Control Builder Components Theory 905
February 2014 Honeywell
15. Data Acquisition Functions
15.1. DATAACQ (Data Acquisition) Block
Bad PV alarm
The DATAACQ block may be configured to generate a "Bad PV" alarm if PV = NaN
(Not a Number).
• The Bad PV alarm priority and severity parameters (BADPVALM.PR and
BADPVALM.SV) are configurable.
• Setting BADPVALM.PR to No Action disables alarming.
DATAACQ parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the DATAACQ block.
Each DEVCTL block supports the following user configurable attributes. The following
table lists the given name of the "Tab" in the parameter configuration form and then
briefly describes the attributes associated with that Tab. This data is only provided as a
quick document reference, since this same information is included in the on-line Context
Sensitive Help.
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that you want to
Parameters appear on the face of the function block in the Project tab in
Control Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Function
The DEVCTL block allows manipulation of sets of digital outputs and interprets
corresponding feedback of digital inputs. Operation consists of transmitting the
commands represented by the state parameter OP (the Commanded Output State),
monitoring PV (the Current Active State), and producing alarms based on various
configurations such as whether or not the PV has achieved the state commanded in OP.
You can red tag a DEVCTL block. Refer to the About Red Tagging section for more
information.
ATTENTION
Refer to the Sequential Control Module User Guide for more information on
The following figures are a graphic representation of the DEVCTL block's major
functions and associated parameters.
Batch Level 1
Driver
NUMDINPTS Input
Processing PVAUTO
DI[1 ... 4] GPVAUTO
DIVALSTS[1...4]
PV
PVSRCOPT PV GPV
PVSOURCE Processing
PVFL[0..2]
DIPVMAP[0..16] NULLPVFL
INBETFL
NUMSTATES
STATETEXT[0...6] Output
SAFEOP Processing MODE
OPDOMAP[0..2][1..3]
MOMSTATE OP
OPCMD[0..2] GOP
MODEATTR OPFINAL
NORMMODEATTR GOPFINAL
SEALOPT
INITMAN
INITDOWN DO [1 ... 3]
INITOPOPT
LOCALMAN PO [1 ... 3]
SAFEREDTAG
REDTAG
NUMDOPTS
PULSEWIDTH[1...3]
BADPVALM.PR
BADPVALM.SV PV Alarm BADPVALM.FL
CMDDISALM.TM(0..2) Processing CMDDISALM.FL
CMDDISALM.PR
UNCMDALM.FL
CMDDISALM.SV
CMDFALALM.FL
CMDFALALM.TM(0..2)
CMDFALALM.PR
CMDFALALM.SV
BYPPERM
BYPASS
MAINTOPT
Maintenance NUMTRANS(0..2)
MAXTRANS Statistics STATETIME(0..2)
MAXTIME NUMSIOVRD
RESETFL
Configuration examples
• Status Output - The following figure and its companion callout description table
show a sample configuration that uses a DEVCTL block to command two status
outputs. The view in the following figure depicts a loaded configuration in
Monitoring mode.
The following table includes descriptions of the callouts in the figure above.
Callout Description
1 Use the PVFL parameter connection to carry data from the DICHANNEL
block to the DEVCTL block.
In device control, the inputs provide the feedback that the commanded
action has or has not taken place.
Callout Description
2 You can use an appropriate interlock logic to activate the safety interlock
function.
3 You can command the device through the output (OP), which shows the
state names you configured for the block through Control Builder.
• Pulse Output - The following figure and its companion callout description table
show a sample configuration that uses a DEVCTL block to command two on pulse
outputs. The view in the following figure depicts a loaded configuration in
Monitoring mode.
The following table includes descriptions of the callouts in the figure above.
Callout Description
1 Use the PVFL parameter connection to carry data from the DICHANNEL
block to the DEVCTL block.
In device control, the inputs provide the feedback that the commanded
action has or has not taken place.
Callout Description
2 You can use an appropriate interlock logic to activate the safety interlock
function.
4 You can command the device through the output (OP), which shows the
state names you configured for the block through Control Builder.
Inputs
May have from 0 to 4 inputs (DI [1 .. 4]). Each input is a Boolean value, which may
represent the state of any other block output or a field DICHANNEL (Digital Input
Channel) block.
• The NUMDINPTS parameter determines how many DI inputs are active. When this
parameter is 0 (zero), the other inputs and PV parameters have no meaning.
• Depending upon what is providing the input, the DI[1..4] connection may be
identified as a DIX[1..4] connection. The DIX is an internal parameter that is not
visible to users. It is equivalent to a DI parameter with status (BadPV). The Control
Builder determines whether an input is DI or DIX when it is created. The internal
DIXCONNECTED[1..4] parameter is set to ON, if the corresponding DI[1..4] input
is connected as a DIX type.
ATTENTION
You must assign inputs and outputs in consecutive order without gaps. For
example, if the block is to have two inputs and two outputs, you must
assign the inputs to DI[1] and DI[2] and the outputs to DO[1] and DO[2].
Assigning inputs and outputs in any other combination, results in an invalid
block configuration.
Outputs
May have from 0 to 3 outputs (DO [1 .. 3]). Each output may be Boolean or pulsed (On
Pulse or Off Pulse). Each output is a Boolean value, which may be connected to any
other block parameter or to a field DOCHANNEL (Digital Output Channel) block.
• An output to any connection except to a DOCHANNEL block is a Boolean output
(DO [1 .. 3]) only.
• The DOCHANNEL (DOC) block may connect three different inputs to a DEVCTL
block (output). However, only one of these inputs can be connected for any single
DOC.
− DOC.SO may be connected to DO [1 .. 3].
− DOC.ONPULSE may be connected to pulsed outputs PO [1 .. 3].
− DOC.OFFPULSE may be connected to pulsed outputs PO [1 .. 3].
• The NUMDOUTS parameter determines how many DO/PO outputs are active.
When this parameter is 0 (zero), the other outputs and OP parameters have no
meaning.
• The internal POCONNECTED[1..3] parameter is set to ON when the respective
PO[1..3] is configured as a block pin and connected to a DOC.ONPULSE or
DOC.OFFPULSE input. This lets the DEVCTL block know what output is used.
• You can configure an individual PULSEWIDTH for each PO[1..3]. The setting
range is between 0.000 and 60 seconds with a resolution of 1 millisecond.
ATTENTION
• For pulsed outputs (ONPULSE and OFFPULSE), only one of these
inputs may be connected for any one DOCHANNEL block.
• You may only connect a DO[1..3] or a PO[1..3] for any one output, but
not both.
CAUTION
In a peer-to-peer strategy, always locate the DOCHANNEL block
associated with a DEVCTL block output in the same CEE. If you use a
parameter connector to connect the DEVCTL block output to a
DOCHANNEL block included in a CM in another CEE, be aware that this
configuration may cause "bumps" in the output.
States
A "state" represents the present condition of a device. For example, Run and Stop could
represent the "states" of a two-state motor, with Stop being the safe or failsafe state. A
three-state motor could have the states of Run, Stop, and Reverse. Open and Close could
represent the states of a valve. You can configure your given device states through the
State Assignments tab of the DEVCTL block configuration form. This lets you associate
states with Boolean combinations of process feedback inputs from the field. Each input
combination is assign to a specific state. The PV parameter represents the present state of
a device in the DEVCTL block.
You can also configure the number of output states as two or three through the State
Assignments tab. These output states are mapped to specific combinations of digital
outputs. These outputs command the field device to the associated state, such as Run or
Stop. The OP parameter represents the commanded state or the device state commanded
by an operator. The DEVCTL block transmits the OP, monitors the PV, and produces
alarms based on the State Assignment configurations, which represent whether or not the
process feedback has achieved the state commanded in OP.
• Safe - Stands for SAFEOP. If an external FB issues a Safe command to GOP, the
internal value is set to the designated SAFEOP.
• S0 -Represents settable output State 0.
• S1 - Represents settable output State 1.
• S2 - Represents settable output State 2.
The STATETEXT[0..6] parameter is an array of 12-character string parameters
corresponding to the members of the generic state enumerations listed above. This allows
the various State Parameters to have labels unique to each state. :You can assign your
own name for a given STATETEXT[0..6] descriptor through the State Name field on the
State Assignments tab in the block configuration form. The following table lists the
default name for a given STATETEXT[0..6] and shows the corresponding generic states
enumeration.
STATETEXT[4] State0 S0
STATETEXT[5] State1 S1
STATETEXT[6] State2 S2
0 Stop S0
1 Run S1
The (bad) state refers to the status that is part of a DIX type input. This represents a
failure in the associated DICHANNEL block. If the DIXCONNECTED[1..4] parameter
for this input is OFF, this state cannot occur.
0 0 Moving Inbet
1 0 Open SO
0 1 Closed S1
1 1 Fault Null
The (bad) state refers to the status that is part of a DIX type input. This represents a
failure in the associated DICHANNEL block. If the DIXCONNECTED[1..4] parameter
for this input is OFF, this state cannot occur.
state combinations as well as the configured state names and the related
GENSTAT_ENM and DIPVMAP[0..15] for reference.
0 0 Fault Null
1 0 Stop S0
0 1 Run S1
1 1 Run S1
The (bad) state refers to the status that is part of a DIX type input. This represents a
failure in the associated DICHANNEL block. If the DIXCONNECTED[1..4] parameter
for this input is OFF, this state cannot occur.
0 0 Stop S0
1 0 Run S1
0 1 Reverse S2
1 1 Fault Null
The (bad) state refers to the status that is part of a DIX type input. This represents a
failure in the associated DICHANNEL block. If the DIXCONNECTED[1..4] parameter
for this input is OFF, this state cannot occur.
0 0 0 0 Fault Null
1 0 0 0 Fault Null
1 1 0 0 Fault Null
1 0 1 0 Valve1 Open S1
0 1 1 0 Val1&2 Close S0
1 1 1 0 Fault Null
0 0 0 1 Fault Null
1 0 0 1 Fault Null
1 0 1 0 Valve2 Open S2
1 1 0 1 Fault Null
0 0 1 1 Fault Null
1 0 1 1 Fault Null
0 1 1 1 Fault Null
1 1 1 1 Fault Null
The (bad) state refers to the status that is part of a DIX type input. This represents a
failure in the associated DICHANNEL block. If the DIXCONNECTED[1..4] parameter
for this input is OFF, this state cannot occur.
DI to PV state map
The DIPVMAP[0..15] is the parameter array used to make the actual state assignments
for PVAUTO as summarized in the tables for the previous examples. Each element of
DIPVMAP[0..15] represents one combination of the input values. DIPVMAP[0..15] is
same type of STATTEXT[0..6]. It cannot be assigned to the Active and Safe GENSTAT
enumerations and the default state is Bad.
Stop S0 0
Run S1 1
combinations. The following table summarizes the output state combinations as well as
the configured state names and the related GENSTAT_ENM for reference.
DO[1] DO[2]
Close S0 1 0
Open S1 0 1
DO[1] DO[2]
Stop S0 0 0
Run S1 1 0
Reverse S2 0 1
Since you can assign outputs to any state. It is possible to have more than one output on
for a given state. The following table summarizes the output state combinations as well
as the configured state names and the related GENSTAT_ENM for reference.
DO[1] DO[2]
Stop S0 0 0
Run S1 1 0
Reverse S2 1 1
If you have three outputs instead of two, there are eight possible combinations that can
be assigned to three states. The following table summarizes the output state combinations
as well as the configured state names and the related GENSTAT_ENM for reference.
Stop S0 1 0 0
Run S1 0 1 0
Reverse S2 0 0 1
ATTENTION
Output combinations are not necessarily the same as the input feedback
combinations for the same state.
Momentary state
The Momentary State (MOMSTATE) parameter lets you configure states as being
momentary. This is like providing push-button operation. When the operator commands
a new output state (OP), the selected momentary state is active for only a Fixed Time
or as long as the operator request the value. Once the operator ceases requesting the
value and the internal timeout occurs, the DEVCTL block returns to the Safe Output
State (SAFEOP).
• For containing CM periods 5 seconds. Momentary States are 5 seconds for all
possible CM periods.
Local manual
The local manual (LOCALMAN) parameter is an input flag to support an interface to a
local HAND/OFF/AUTO (also called HAND/OFF/REMOTE) switch on the field
device. You can hard wire the AUTO position of the switch to a digital input. You can
then have the state of the digital input stored to the LOCALMAN pin added to the
DEVCTL block through a DICHANNEL connection. Since the control system may not
have control over the field device when the HAND/OFF/AUTO switch is not in the
AUTO position, the LOCALMAN parameter provides feedback of the switch position.
When the LOCALMAN parameter is ON, the OP state tracks the PV state, if it is a
settable state. If PV is in a non-settable state, OP will be set to SAFEOP. This assures
that the last commanded state agrees with the present value of the feedback state, when
the LOCALMAN is turned OFF. You cannot directly command the OP (GOP) while the
LOCALMAN is ON.
You cannot access LOCALMAN, if the DEVCTL block has no inputs or no outputs
connected. Since PV is illegal for no inputs and OP is illegal for no outputs,
LOCALMAN has no meaning for these conditions.
Permissive interlocks
PI[0..2]are Permissive Interlocks which are inputs that may be connected to an external
function block to determine whether the operator and/or user program are allowed to
change the commanded output (OP) of the DEVCTL block to a specific state. Permissive
Interlocks themselves never cause OP to change.
• For OP to be changed to the desired state, the corresponding Permissive Interlock
parameter must be set to ON.
• The Permissive Interlocks are all defaulted to ON, thereby allowing permission to all
the states - they must be individually set to OFF to prevent access to the
corresponding OP state.
Override Interlocks
OI[0..2] are Override Interlocks which, when active, force the commanded output (OP)
to a respective state regardless of the condition of the Permissive Interlocks. OP cannot
be commanded to a different state when an Override Interlock is active.
• Override Interlocks may be connected to other block outputs or may be directly set
by an operator if MODEATTR = OPERATOR and the block is inactive.
• Override Interlock parameters are all defaulted to OFF, thereby disabling all the
Override Interlocks. They must be set to ON to force OP to go to any specific state.
If the Override Interlock forces OP to go to a momentary state, it stays in that state
as long as the interlock remains ON and then switches back to the original state
when the Override Interlock is reset to OFF.
• SI has a higher priority than any of the Override Interlocks; the priorities of the
Override Interlocks themselves are determined by the state assigned to SAFEOP as
follows:
− If SAFEOP = State 0, then priority is SI, OI[0], OI[1], OI[2]
− If SAFEOP = State 1, then priority is SI, OI[1], OI[0], OI[2]
Alarms
An available set of PV state alarms may be configured to represent disagreements
between the Commanded Output State (OP) and the Current Active State (PV). A Safety
Override Interlock Alarm is also available. Each of these alarms possesses all the
standard attributes of system alarms.
• Command Fail Alarm - generated when the Current Active State (PV) fails to
change from an original value to any other value within a configurable time interval
after the OP parameter is commanded.
− You can configure the feedback time (CMDFALALM.TM[0..2) for each state
through the Alarms tab on DEVCTL block configuration form. The value of OP
just commanded determines which CMDFALALM.TM[0..2] is active. The
CMDFALALM.TM[0..2] setting range is 0 to 1000 seconds. Setting a given
CMDFALALM.TM[0..2] parameter to 0 disables the alarm for the associated
state[0..2]. The alarm function is also automatically disabled, if there are no
inputs or no outputs. CMDFALALM.TM[0..2] changes from or to 0, require
CM InActive or CEE Idle.
ATTENTION
The CMDFALALM.TM[0..2] setting must be less than the
CMDDISALM.TM[0..2] setting for the same state[0..2].
• Bad PV Alarm - generated whenever the Current Active State (PV) is detected to be
a NULL (or bad) state.
• Command Disagree Alarm - generated when the Commanded Output State (OP) is
changed and the actual input state (PV) does not change accordingly within a
specified feedback time.
ATTENTION
For device in a BAD state, the PV Value of a DEVCTL block refreshes only
when the CMD disagree or CMD fail timer is finished. So, the PV value is not
correct during a transition state. However, if you configure an INBET (In
Between) status, this status is directly written to the PV output without waiting
for the timeout defined by CMD disagree.
− You can configure the feedback time (CMDDISALM.TM[0..2) for each state
through the Alarms tab on DEVCTL block configuration form. The value of OP
just commanded determines which CMDDISALM.TM[0..2] is active. The
CMDDISALM.TM[0..2] setting range is 0 to 1000 seconds. Setting a given
CMDDISALM.TM[0..2] parameter to 0 disables the alarm for the associated
state[0..2]. The alarm function is also automatically disabled, if there are no
inputs or no outputs. CMDDISALM.TM[0..2] changes from or to 0, require CM
InActive or CEE Idle.
− This alarm condition returns to normal when the input PV state becomes equal to
the OP state. The alarm is not generated for momentary commanded states.
• Uncommanded Change Alarm - generated if the actual input state (PV) changes but
has not been commanded to change (unless it is a bad PV). This alarm is configured
whenever the Command Disagree Alarm is configured.
− This alarm condition returns to normal when the input PV state becomes equal to
the commanded OP state. The alarm is not generated for momentary
commanded states.
• Off Normal Alarm - This alarm is enabled when OPREQ is set to any value other
than Null. It uses the difference between OPREQ and PV. The off normal alarm flag
(OFFNRMALM.FL) is active when the PV cannot match the Output Request. The
off-normal condition means that the eventual PV does not match the OP which was
commanded by the higher level function. The OFFNRMALM.FL is used to reflect
this requirement.
− The higher level function, such as a Sequential Control Module (SCM), can tell
that something is wrong by reading the OFFNRMALM.FL. This flag value can
Seal-In option
The Seal-In option is used to clear output commands when the process feedback state
(PV) cannot follow the commanded output state (OP) as detected by the Command
Disagree or Uncommanded Change alarms. If enabled, when the condition is detected,
field output destinations are set to the Safe Output State (SAFEOP), but OP is not
altered. You can observe OPFINAL to determine what state was actually commanded to
the output destinations. The OPFINAL is displayed in reverse video while monitoring
Control Builder if it differs from OP. OPFINAL is set equal to OP on the next store to
OP, which clears the "seal" condition.
• Seal-In option and Momentary state are mutually exclusive. The Momentary state
has to be None to configure the Seal-In option.
• You can configure the seal-in option through the SEALOPT (Enable/Disable)
parameter.
• When you enable the SEALOPT, any Momentary State selection is negated .
OP Initialization Option
The parameter INITOPOPT is used to configure OP Initialization option. It is an
enumeration of NORMALOPT, SAFEOPOPT or HOLDOPOPT. The default value is
NORMALOPT.
• INITOPOPT = NORMALOPT, perform normal initialization as described below in
Initialization Manual Condition with Safety Override Interlock, Override Interlocks,
LocalMan, and OP Initialization.
• INITOPOPT = SAFEOPOPT, OP is set to SAFEOP
• INITOPOPT = HOLDOPOPT, initialization will not be performed. OP remains the
last value.
When the INITMAN parameter transitions from ON to OFF, the Device Control FB
provides an output value OP as follows:
• If the Safety Interlock is active, the OP is set to SAFEOP;
• Otherwise, if any of the Override Interlocks are active and not bypassed, the OP is
set to the highest priority Override Interlock;
• Otherwise, if LocalMan is ON, OP tracks PV, if PV is in a settable state (State0,
State1, or State2). If PV is in an unsettable state (Null or InBetween), or PV does not
exist, OP is set to SafeOP;
• Otherwise, if OP Initialization is configured as HOLDOPOPT, OP value depends on
the LEGACYINITOPT parameter value;
− If LEGACYINITOPT = ENABLE, the OP remains on the last value. When the
Device Control recovers from the initialization manual condition, the output is
not sent to the output point unless an Override Interlock or Safety Interlock is
active and not bypassed.
ATTENTION
If INITOPOPT=HOLDOPOPT and LEGACYINITOPT = ENABLE, the state of
the output field device might not match the state of the OPFINAL parameter
after recovery from initialization is complete. There can be a mismatch
between the Device Control output value and the output device state that
requires operator’s intervention to correct this mismatch. Therefore, there
may be uncertainty in the validity of the field device state after recovering
from initialization.
For more information on the LEGACYINITOPT parameter, refer to the Control Builder
Parameter Reference guide.
TIP
Note that the INITREQ is used differently in DevCtl block than in other blocks,
such as DOC, AOC, or RegCtl.
Maintenance Statistics
The DEVCTL block collects a set of Maintenance Statistics which are enabled by
configuring MAINTOPT = ON.
The following parameters can be configured to provide suggested maximums. No
operations are rejected due to the values of these parameters. These MAXxxx parameters
are useful as references for comparison with the actual measured statistics.
• MAXTRANS [0 .. 2] - maximum number of transitions of PV to each state. Useful
to compare these values to NUMTRANS [0 .. 2].
• MAXTIME [0 .. 2] - maximum number of hours of PV accumulated in each state.
Useful to compare these values to STATETIME [0 .. 2].
The statistics collected include:
• NUMTRANS [0 .. 2] - accumulated number of transitions of PV to each state (since
the last statistics reset).
• STATETIME [0. 2] - accumulated time of PV in each state (since the last statistics
reset).
Output requests
Whenever an external FB attempts to change the commanded state OP, the DEVCTL
block uses the OP request mechanism. The OP request (OPREQ/GOPREQ) differs from
direct access an operator uses to the commanded state OP. The OPREQ is a string in the
same manner as OP, and GOPREQ is the enumeration GENSTAT_ENM, which is the
same as GOP.
There is no direct access to OPREQ when MODEATTR is PROGRAM. It may be
changed as part of a control request from an SCM. When MODEATTR is OPERATOR,
an operator can change OPREQ, but this does not block a control request. This means a
program store to OPREQ cannot be rejected, and no error is returned. The FB retains the
stored value until it is overwritten, except in certain non-stored cases when the level 1
drivers are active. OPREQ acts like a repeated attempt to store to OP. The OPREQ is
always active unless it is Null. This means the OPREQ will continue to attempt stores
even if attributes, such as interlocks, become active and block changes to OP. Thus, once
the attributes blocking change to OP have reset OPREQ stores the commanded state to
OP.
Output command
The block provides a Boolean command capability through an array of Boolean inputs
(OPCMD[0..2]. When the mode attribute (MODEATTR) is Program and the SCM
option (SCMOPT) is None, you can use an output from a Logic type block to set the
requested output state (OPREQ) through the given Boolean input command
(OPCMD[0..2]). When the given OPCMD[0..2] is set to ON, the block sets the OPREQ
to the corresponding state. In this case, the OPCMD[0] corresponds to state0,
OPCMD[1] corresponds to state1, and OPCMD[2] corresponds to state2. When more
than one of the Boolean inputs (OPCMD[0..2] are ON, the OPREQ is set according to
the following priority.
• If SAFEOP is SO, the priority is OPCMD[0], OPCMD[1], OPCMD[2].
• If SAFEOP is S1, the priority is OPCMD[1], OPCMD[0], OPCMD[2].
• If SAFEOP is S2, the priority is OPCMD[2], OPCMD[0], OPCMD[1].
If an SCM commands the device by sending a Null type of request to GOP and there are
active OPCMDs (this is possible when SCMOPT = NONE, MODEATTR = Program,
and SCM OPTYPE = NULL), the OPCMD has higher priority. An SCM store to GOP
will be rejected, if any of the OPCMD[0..2] elements are active (one or more
OPCMD[0..2] members are ON). An SCM can only get control, when all OPCMD[0..2]
elements are OFF.
ATTENTION
It is not recommended to use step outputs of type S_IEC, N_IEC, or R_IEC
with destination parameters that are inputs to flip-flops or other bistable,
monostable blocks, or logic configurations. Examples are OPCMD[0..2] of
DEVCTL and S and R of LOGIC:RS. Although these configurations are
technically supported and show a predictable behavior, the resulting behavior
may be non-intuitive and confusing to operators (example: using an N_IEC
output on OPCMD[1] will result in OP-behavior similar to what would be
expected from an S_IEC output if directly controlling a parameter such as
OP). Therefore, this practice is not considered a good engineering practice.
DEVCTL parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the DEVCTL block.
The configuration of the LOGICINITOPT parameter for the Control Module determines how the
2OO3 block output DISCREP responds as a result of block state transitions such as activate,
warm start, cold start or RAM Retention Restart (RRR). The delay timing starts fresh whenever a
state transition occurs. Disagreement in inputs causes DISCREP to go to On state only if it
persists throughout the DELAY interval following a state transition. The following table
summarizes the possible DISCREP action for a given LOGICINITOPT configuration.
We recommend that you use the default value of PULSEEXPIRED for the LOGICINITOPT
parameter of the Control Module for all new logic applications.
• Then, OUT = ON
If BADINACT is configured
as HoldLast, then
OUT[1..8] is set equal to
LASTIN[1..8]
ATTENTION
The CONTACTMON block can only be used with C300 Controllers.
DELAY Provides the ability to delay The OUT always follows the
the output (OUT) response to input (IN) action by a
the given input (IN) by a sample cycle time.
sample cycle time.
DEADBAND1 and
DEADBAND2 must satisfy
the following constraint::
0 <= DEADBAND1 <=
DEADBAND2
The configuration of the LOGICINITOPT parameter for the Control Module determines how the
FTRIG block OUT responds as a result of block state transitions such as activate, warm start, cold
start or RAM Retention Restart (RRR). The following table summarizes the possible OUT action
for a given LOGICINITOPT configuration.
We recommend that you use the default value of PULSEEXPIRED for the LOGICINITOPT
parameter of the Control Module for all new logic applications. The LOGICINITOPT configuration
of PULSEREADY is supported for migration purposes only.
IN
OUT
Maximum Maximum
Pulsewidth Pulsewidth
The configuration of the LOGICINITOPT parameter for the Control Module determines how the
MAXPULSE block OUT responds as a result of block state transitions such as activate, warm
start, cold start or RAM Retention Restart (RRR). The following table summarizes the possible
OUT action for a given LOGICINITOPT configuration.
We recommend that you use the default value of PULSEEXPIRED for the LOGICINITOPT
parameter of the Control Module for all new logic applications. The LOGICINITOPT configuration
of PULSEREADY is supported for migration purposes only.
IN
OUT
Minimum Minimum
Pulsewidth Pulsewidth
The configuration of the LOGICINITOPT parameter for the Control Module determines how the
MINPULSE block OUT responds as a result of block state transitions such as activate, warm start,
cold start or RAM Retention Restart (RRR). The following table summarizes the possible OUT
action for a given LOGICINITOPT configuration.
We recommend that you use the default value of PULSEEXPIRED for the LOGICINITOPT
parameter of the Control Module for all new logic applications. The LOGICINITOPT configuration
of PULSEREADY is supported for migration purposes only.
The configuration of the LOGICINITOPT parameter for the Control Module determines how the
MVOTE block output DISCREP responds as a result of block state transitions such as activate,
warm start, cold start or RAM Retention Restart (RRR). The delay timing starts fresh whenever a
state transition occurs. Disagreement in inputs causes DISCREP to go to On only if it persists
throughout the DELAY interval following a state transition. The following table summarizes the
possible DISCREP action for a given LOGICINITOPT configuration.
We recommend that you use the default value of PULSEEXPIRED for the LOGICINITOPT
parameter of the Control Module for all new logic applications. The LOGICINITOPT configuration
of PULSEREADY is supported for migration purposes only.
DEADBAND1 and
DEADBAND2 must satisfy
the following constraint::
0 <= DEADBAND1 <=
DEADBAND2
The configuration of the LOGICINITOPT parameter for the Control Module determines how the
nooN block OUT responds as a result of block state transitions such as activate, warm start, cold
start or RAM Retention Restart (RRR). The following table summarizes the possible OUT action
for a given LOGICINITOPT configuration.
We recommend that you use the default value of PULSEEXPIRED for the LOGICINITOPT
parameter of the Control Module for all new logic applications.
− If IN = ON, then:
OUT = OFF.
− If IN = OFF, then
OUT = ON.
IN
OUT
The configuration of the LOGICINITOPT parameter for the Control Module determines how the
OFFDELAY block OUT responds as a result of block state transitions such as activate, warm
start, cold start or RAM Retention Restart (RRR). The following table summarizes the possible
OUT action for a given LOGICINITOPT configuration.
PULSEEXPIRED ON ON
We recommend that you use the default value of PULSEEXPIRED for the LOGICINITOPT
parameter of the Control Module for all new logic applications. The LOGICINITOPT configuration
of PULSEREADY is supported for migration purposes only.
IN
OUT
ON Delay ON Delay
Time Time
The configuration of the LOGICINITOPT parameter for the Control Module determines how the
ONDELAY block OUT responds as a result of block state transitions such as activate, warm start,
cold start or RAM Retention Restart (RRR). The following table summarizes the possible OUT
action for a given LOGICINITOPT configuration.
PULSEEXPIRED ON ON
We recommend that you use the default value of PULSEEXPIRED for the LOGICINITOPT
parameter of the Control Module for all new logic applications.
IN
OUT
Pulsewidth Pulsewidth
The configuration of the LOGICINITOPT parameter for the Control Module determines how the
PULSE block OUT responds as a result of block state transitions such as activate, warm start,
cold start or RAM Retention Restart (RRR). The following table summarizes the possible OUT
action for a given LOGICINITOPT configuration.
We recommend that you use the default value of PULSEEXPIRED for the LOGICINITOPT
parameter of the Control Module for all new logic applications. The LOGICINITOPT configuration
of PULSEREADY is supported for migration purposes only.
N Bits N Bits
Rotate Rotate
Out Rotate Left In
N Bits N Bits
Rotate Rotate
In Rotate Right Out
The configuration of the LOGICINITOPT parameter for the Control Module determines how the
RTRIG block OUT responds as a result of block state transitions such as activate, warm start,
cold start or RAM Retention Restart (RRR). The following table summarizes the possible OUT
action for a given LOGICINITOPT configuration.
We recommend that you use the default value of PULSEEXPIRED for the LOGICINITOPT
parameter of the Control Module for all new logic applications.
The configuration of the LOGICINITOPT parameter for the Control Module determines how the
TRIG block OUT responds as a result of block state transitions such as activate, warm start, cold
start or RAM Retention Restart (RRR). The following table summarizes the possible OUT action
for a given LOGICINITOPT configuration.
We recommend that you use the default value of PULSEEXPIRED for the LOGICINITOPT
parameter of the Control Module for all new logic applications.
Parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the named logic function block.
You can only use the CHGEXEC block with blocks that are qualified to run under
change driven execution. Most of the PControl Execution Environment (CEE) blocks are
not qualified to do this, as shown in the list of qualified blocks in the following section.
The CHGEXEC block resides in the LOGIC library in the Library tab of Control Builder
and is represented graphically in the control drawing as shown in the following
illustration.
Optimize Control Module CHGEXEC receives a set of Boolean inputs and identifies if
performance when used and when they change. If any input has changed since the
exclusively for logic last execution cycle, the CM containing the CHGEXEC block
computation. runs to completion in normal fashion. If none of the inputs
have changed, the CM exits immediately after the CHGEXEC
block completes, leaving the subsequent blocks within the CM
Create Control Module logic Using CHGEXEC to create CM logic strategies that execute
strategies to execute most of most of their logic by exception, reduces the average
their logic by exception. processing power consumed by the strategy.
Vary the control module's When ordinary CMs are scheduled to run continuously, it is
processing load. relatively easy to judge the controller processing load and risk
of CEE cycle overruns. In contrast, the processing load for a
CM using a CHGEXEC block can vary greatly depending on
whether the input state has changed since the last execution
cycle or not.
ATTENTION
Change driven control strategies that are improperly designed could cause
the whole controller to malfunction due to excessive cycle overruns.
Application engineers are responsible for managing the entire load profile of
the controller, when deploying CHGEXEC control strategies.
Qualified Block Types You can only use the block types listed in the following
section within the context of change driven execution.
Consistent Input Data Do not use logic gates to directly access input data that is
monitored for change. Read data from the output pins on the
CHGEXEC block instead.
Multiple CHGEXEC blocks in Most change driven configurations only work with single
same Control Module CHGEXEC defined within the parent CM. The only exception
would be when two CHGEXEC blocks are placed in the same
CM to expand the number of change detected inputs. See the
Cascading within a CM Example section for more information.
Increased Processing Weight Using a CHGEXEC block within a logic strategy always adds
processing weight to the CM. The execution of the CHGEXEC
block itself and the data flow processing of its input
connections add a load that is not present when a CHGEXEC
block is not used.
ATTENTION
Support for the periodic auto-trigger does not allow the CHGEXEC block to be
used with blocks other than those listed as qualified in the following table.
Blocks that are not qualified will malfunction under change driven execution
despite the support of auto-trigger.
Neither Control Builder nor the CEE prevent application engineers from
CAUTION using unqualified blocks in a change driven configuration. Application
engineers are responsible using only qualified blocks with the
CHGEXEC block. Failure to follow this guideline can lead to
unpredictable results in the operation of control strategies.
DEVCTL Library
LOGIC Library
2OO3 Yes
AND Yes
CHECKBAD Yes
DELAY Yes The DELAY block, as well as the edge trigger blocks (TRIG,
FTRIG, RTRIG) have semantics that fit most naturally within
continuously executing CMs. In the case of DELAY, the
Boolean input is delayed until next execution. In the case of
the edge trigger blocks an edge at the input causes a level at
the output which lasts until next execution. When applying
these blocks within a change driven CM, application
engineers should consider carefully whether they will deliver
the behavior desired.
EQ Yes
FTRIG Yes See comment above for the DELAY block type.
GE Yes
GT Yes
LE Yes
LIMIT Yes
LT Yes
MAX Yes
MIN Yes
MINPULSE Yes See comment above for the MAXPULSE block type.
MUX Yes
MUXREAL Yes
MVOTE Yes
NAND Yes
NE Yes
NOON Yes See comment above for the MAXPULSE block type.
NOR Yes
NOT Yes
OFFDELAY Yes See comment above for the MAXPULSE block type.
ONDELAY Yes See comment above for the MAXPULSE block type.
OR Yes
PULSE Yes See comment above for the MAXPULSE block type.
QOR Yes
ROL Yes
ROR Yes
RS Yes
RTRIG Yes See comment above for the DELAY block type.
SEL Yes
SELREAL Yes
SHL Yes
SHR Yes
SR Yes
STARTSIGNAL Yes
TRIG Yes See comment above for the DELAY block type.
WATCHDOG Yes See comment above for the MAXPULSE block type.
XOR Yes
Utility Library
FLAG Yes
FLAGARRAY Yes
MESSAGE Yes
NUMERIC Yes
NUMERICARRAY Yes
PUSH Yes See comment above for the MAXPULSE block type.
TEXTARRAY Yes
TIMER Yes See comment above for the MAXPULSE block type.
TYPECONVERT Yes
TIP
You can test CM strategies employing CHGEXEC blocks either on simulation
platforms or controller platforms. With any CM, the CMs with CHGEXEC
blocks do not need to be modified in any way when moved between
controllers and simulators.
DATA[1..32] An indexed parameter of type Boolean which receives the inputs to the
CHGEXEC block. Values within the DATA[ ] array are compared to
values from the last execution to determine whether the CM should exit
or run to completion. DATA[ ] supports up to 32 inputs.
LASTDATA[1..32 ] An indexed parameter of type Boolean holding the value of the input
array, DATA[ ], that was captured during the last execution cycle.
CHGINDEX An integer valued output parameter which gives the index of the first
input, in increasing order, where change was detected. CHGINDEX
holds a non-zero value for one cycle following an input change. It goes to
zero after the first cycle where there is no input change. CHGINDEX
shows zero after auto-trigger execution where there was no input
change.
Consideration Description
Consideration Description
Block Execution Order of block execution must be deliberately assigned for any CM
Order strategy, but especially for CHGEXEC strategies. Often the CHGEXEC
runs as the first block within a CM, with computational logic following.
The ORDERINCM values would be chosen accordingly. This is shown in
the Control Module figures above.
It is not required to have the CHGEXEC execute as the first block within
a CM. But any logic preceding the CHGEXEC would execute once every
CM period and would not benefit from the change driven execution. The
CHGEXEC instance and its position within the block execution order
determines where the CM exits if there has been no change of inputs.
Control Module When a change-driven logic strategy is split across CMs, execution order
Execution Order of the CMs must still be deliberately assigned. ORDERINCEE would be
set up so that secondary followed primary as shown in the Control
Module figures above.
EXITOPT Setting For cascades between CMs, EXITOPT is set to EXITONEQU for both
the primary CHGEXEC and the secondary CHGEXEC. This is shown in
the Control Module figures above.
Secondary Control Be careful when building CHGEXEC cascades across CMs. In some
Module Output strategies, it may save time to have the secondary CM connect to
Connections outputs from the primary CM without first passing those values through
the secondary's CHGEXEC. This should work as long as:
• the primary and secondary execute with the same PERIOD and
PHASE and
• no I/O or peer data is used without passing it explicitly through the
secondary's CHGEXEC.
Strategy defects can arise from using I/O or peer data which is not
guaranteed to have the same value as that which triggered the change
execution. See the Importance of Using Consistent Input Data section for
more information
Cascades that Cross Be careful when using CHGEXEC cascades that cross CEE boundaries.
CEE Boundaries In general, if a CHGEXEC pulls the TRIGGER parameter from a
CHGEXEC in a different CM, then the two CMs must be in the same
CEE. If CHGEXEC cascade must cross CEE boundaries, then the
secondary should not use the TRIGGER output from the primary. It
Consideration Description
should explicitly pass all output data from the primary through the
CHGEXEC.
ATTENTION
The following figure shows the leading CHGEXEC with only two data
elements, which is inaccurate. A second CHGEXEC is introduced to support
additional inputs only after those of the first had been exhausted.
to parameters outside the CM or to I/O within the CM. The output DATA[ ] will be
referenced by downstream logic within the CM.
Human Input Commands In some cases, logic control strategies are designed to
process not only IO inputs and Boolean inputs from other
strategies, but Boolean commands from human operators.
Design practice would normally dictate that human inputs
enter a change-driven strategy through the CHGEXEC
instance just like any other kind of input data. However,
operator inputs do not need to be processed at a time scale
faster than human actions. Instead, a response time on the
order of seconds is sufficient. CHGEXEC auto-trigger allows
application engineers to design change driven logic
strategies without the need to take human input commands
through the CHGEXEC instances.
Upper Limit On Time Out Delays Periodic auto-trigger does not provide a reliable time tick for
blocks whose execution is gated by a CHGEXEC. Timing
blocks such as MAXPULSE and ONDELAY use an internal
clock as their time base rather than relying on the periodicity
of their own execution. However, CHGEXEC support for
auto-trigger does put an upper limit on how much time can
pass after a time out has expired and before the block
reacts. Timing logic blocks listed as qualified in section
Blocks Qualified for Use with CHGEXEC Block can be used
within change driven strategies as long as a time out
response on the order of seconds is sufficiently fast.
ATTENTION
• In all cases where a CM is allowed to execute to completion because of a
state change. This happens regardless of the EXITOPT configuration.
EXITOPT has no impact on executions driven by state changes.
Activation of Unchanged until Unchanged until Changes state on On first cycle CM and
Parent CM inputs are pulled set equal to first cycle of children start
on first cycle of DATA[ ] on first execution. executing. CHGEXEC
See Note 1 execution. cycle of Changes state overrides change
CEE Unchanged until Unchanged until Changes state on On first cycle CM and
Execution inputs are pulled set equal to first cycle of children start
Start on first cycle of DATA[ ] on first execution. executing. CHGEXEC
execution. cycle of overrides change
See Note 2 execution. See Note 4 detection to allow CM
See Note 5 to run to completion
regardless of whether
or not DATA[ ] has
changed.
Notes:
− Warm Restart changes CEESTATE from Idle to Run when EXECSTATE of parent CM is Active.
− RAM Retention Restart when CEESTATE is Run and EXECSTATE of parent CM is Active.
4. In the case of transition Activation of Parent CM, the TRIGGER parameter emits a full pulse (both the
positive going edge and the negative going edge) over the course of the first two execution cycles. This
is to insure that for any cascaded CHGEXECs in different CMs, the downstream (secondary) CM is
guaranteed to execute at least once when the upstream (primary) CM executes. Since the state of
LASTDATA[ i] in the downstream CM could be On or Off the TRIGGER must emit both edges.
In the case of transition CEE Execute Start, forcing both edges is not necessary. Each CHGEXEC within
the CEE will allow its parent CM to run to completion as a result of the CEE-wide state transition.
5. If CHGEXEC is used heavily within a CEE it is possible for cycle overruns to occur as a result of CEE
Execute Start transitions (Cold Restart, Warm Restart or RAM Retention Restart). These transitions
force all CHGEXEC CMs to run to completion during the first execution of each CEE cycle. After all
cycles have executed no more overruns occur within a properly balanced CEE configuration. CEE will
not report any alarms as a result of start up transition overruns.
Stage Description
Stage Description
implementation is closely coupled.
3 Make sure no CMs of interest have inputs which can change during the
course of the test.
4 Make sure other control strategies are completely unchanging during the
course of the test. Other strategies may be loaded and active. But they may
not be loaded or unloaded while the test is in progress. Similarly no strategies
may be activating or inactivated during the test.
5 Identify which cycle to monitor for load effects. If the CMs of interest all
execute at the fastest period, then CPUCYCLEAVG[40] provides the best
information. If the CMs do not execute at the fast period then
CPUCYCLEAVG[40] cannot be used. Instead identify one cycle (called
CYCLE here) where all CMs of interest execute and monitor that. For
example, if the CMs of interest have a PERIOD of 1 second and a PHASE of
3 then CYCLE could be either 3 or 23.
7 Set STATSRESET to ON. Note that STATSRESET will never show a value of
ON. But setting it to ON causes statistics parameters to reinitialize.
Stage Description
The CHECKBOOL inputs and outputs are of type value/status. The CHECKBOOL
block is capable of connecting eight sets of input and output value/status pairs. However,
the default block configuration assumes only one connection pair. The block utilizes an
input status parameter INSTS[n] to determine the validity of the input IN[n]. If the status
value is valid, the logic block simply passes its received input value/status though to its
associated output value/status.
In the event a BADINACT condition is detected, the CHECKBOOL block uses three
additional parameters to determine when and how long OUT[n] is to be held at the
configured BADINACT value. The Inactive Input Detection Threshold Time
(INACTINDETTM) parameter specifies the amount of time that must expire before the
block determines if it should take the configured Bad Input Action. During this time, the
inputs status must be continually INACTIVE during this detection time for the action to
be taken. When the input is INACTIVE for less than this time, no action is taken. If the
input goes INACTIVE again the time starts counting over. The other two parameters are
Bad Input Detection Threshold Time (BADINDETTM[n]) and Bad Input Action
Minimum Time (BADINACTMINTM[n]). The BADINDETTM[n] parameter
determines how long the block will delay before the configured action. The
BADINACTMINTM[n] establishes the minimum time the action will be provided on
OUT. Once this minimum time expires, the output value/status is only set to the input
value/status when the input status is valid. While invalid, the bad action will continue to
be provided on OUT.
The following scenarios define the CHECKBOOL block operation for both valid and
invalid input data. In each of the scenarios, it is assumed that the CHECKBOOL block is
connected to a device which is capable of supplying it the proper input data ( IN[1] and
INSTS[1]) and the CHECKBOOL block is sending this data to a block which requires
validated data downstream. Neither the upstream and downstream blocks nor their
connections have been shown. Only the operations within the CHECKBOOL block and
its actions on both input and output data will be discussed here. Also, only one
input/output pair is shown for each CHECKBOOL block, but each block can handle up
to eight input/output pairs.
CheckBool Scenario 1
In this scenario the user has configured the block for immediate Inactive input detection
with no minimum time for bad action on bad-to-good recovery. The output will track the
input no delay. OUTSTS will be UNCERTAIN while the BADINACT is in effect.
CheckBool Scenario 2
In this scenario, the user has configured the block with a 2 second bad detection period
and no minimum time for bad action on bad-to-good recovery. This configuration forces
a 2 second delay when an INSTS is "BAD". Once the Bad Input Detection Threshold
Time has elapsed, the output values will track those of the input.
CheckBool Scenario 3
In this scenario the user has configured the block with a 2 sec Inactive Input Detection
Threshold and a 4 sec minimum time for bad action on Inactive-to-good recovery. In this
configuration an "INACTIVE" INSTS is not acted upon until the 2 sec
INACTINDETTM has elapsed. If at the end of this time the block still has an INSTS of
"INACTIVE", the output will be set to BADINACT ("OFF") and will be held at that
value until the Bad Input Action Minimum Time of 4 sec has expired.
CheckBool Scenario 4
In this scenario, the user has configured the block with a 2 second bad detection period
and a 4 second minimum time for bad action on bad-to-good recovery. In this
configuration a "BAD" INSTS is not acted upon until the 2 second BADINDETTM has
elapsed. If at the end of this time the block still has an INSTS of "BAD", the output will
be set to BADINACT ("OFF") and will be held at that value until the Bad Input Action
Minimum Time of 4 seconds has expired.
Function
• Enables alarm generation whenever the state of both inputs is same or different
based on the NORMAL state configuration.
Predecessor Block
The input to the Contact Monitoring block can be any block with a digital output. NOT
of the XOR of these inputs is the output of the block.
Execution
When a Contact Monitoring block is configured as in the preceding illustration, the
digital inputs are supplied to the block using an arrayed IN parameter. The output of the
block is a NOT of the XOR of the inputs to the block. The possible combinations are
listed in the following table:
ON ON ON OFF OFF
The alarm is generated based on the NORMAL parameter and the priority and severity of
the alarm are configurable. When STATETEXT[0] is configured as OFF and
STATETEXT[1] as ON, the possible combinations are listed in the following table:
ON OFF ON State1 No
X X X None No
DIV Division 60
MOD (x MOD y) 60
NEG -(x) 50
POW (x^y) 60
SUB Subtraction 60
The block also displays the good and bad values as ROLLAVGBAD=1 and
ROLLAVGOK=3
ATTENTION
When the collection buffer is filled with the maximum number of samples
(3800), the new sample overwrites the oldest sample in the buffer.
parameter value remains at “0.” However, the Control Module’s remaining functions
are unaffected.
Refer to the Control Builder Parameter Reference document for more information on the
parameters.
• Estimated user memory (RAM) is 112 bytes per instance. (This size is reflected in
the block size information).
• Estimated code size (firmware) is 3100 bytes. (This size is not reflected in the block
size information).
• Auxiliary memory usage is variable when loaded based on user sample
configuration of 8 to 30400 bytes per instance. (This size is not reflected in block
size information).
The user memory tool displays the memory per instance. The auxiliary memory is 8
times the RollavgSz for the number of additional bytes for a block.
ATTENTION
The following blocks can only be used with C300 Controllers.
Support HT motor drive HTMOTOR (HT Used to define inputs and interlocks
control requirements Motor Drive for conventional HTMOTOR drive.
Control) Block
Support LT motor drive LTMOTOR (LT Used to define inputs and interlocks
control requirements Motor Drive for conventional LTMOTOR drive.
Control) Block
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that appear on the
Parameters face of the function block in the Project tab in Control
Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Template Defining Lets you view and define parameters for associated
templates.
Function
• This block provides the capability for a group of same type of equipments
depending upon the equipment status.
• This block provides the Group Capability and Group Runback Rate for the
configured number of equipments.
• The block accepts configurable number of equipments' input status and desired unit
load set point.
• The block provides a configurable parameter NUMBEROFEQP which represents
the number of equipments used for input connection to the block.
• The block enables the user to configure equipment OFF state Capability Value
(OFFCAP) and ON state Capability Value (ONCAP) for individual equipment.
• The block is capable of generating a Safe output flag when the load setpoint input
status bad or all equipment on/off status are bad.
• The block has the capability to generate alarm for Run back Active when out
capability is less than unit load set point.
ATTENTION
Ensure that the OFFCAP value is configured less than the ONCAP value. If
the OFFCAP value is greater than the ONCAP value, the ONCAP value is not
stored.
If the Group Capability block is connected through another block and the
OFFCAP is greater than the ONCAP value, the ONCAP value is not stored
(Also, there is no error message.)
This block provides the Group Capability and Group Runback Rate of the configured
number of equipments. The block accepts configurable number of equipments' status
inputs and desired unit load set point. This block provides two analog and one discrete
output.
The possible blocks in the downstream are:
• Auxcalc - (Most often used) - OUTCAP and ROCLM to P1
• Signalsel - (Often used) - OUTCAP and ROCLM to P1
Both blocks support PSTS. But OUTCAP is generated internally. ROCLM depends on
LOADSP. AUXCALC and SIGSEL sets it output to NaN, only if all the Inputs (p1-p6)
are BAD. Therefore there is no absolute need to provide the STS from this block, but
there is a need to handle NaN.
• Blocks from Regctl suite (RATIOBIAS) uses OPROCLM and OPHILM.
These two parameters do not have STS, but need to handle NaN as OPHILM can clamp
to low or HI limit based on input value range.
The possible blocks in Upstream are identified as:
• DigAcq (PVFL) or Digital Inpits - For DI
• Blocks from Regctl suite (AUTOMAN - Uses OP) for LOADSP
Predecessor Block
The input IN of this block can be from any block with digital output. The input LOADSP
of this block can be from any Regulation Control block like AUTOMAN, SWITCH or
RATIOBIAS.
Successor Block
The outputs OUTCAP and ROCLM of this block can be connected to any block with
analog input (for example, LOGIC:MIN). The output RUNBKACTFL of this block can
be connected to any block with digital input (for example, LOGIC:OR).
Configuration examples
User Scenario 1: The predecessor block for DI input can be a DIGACQ block or DI Channel
Block. The predecessor block for LOADSP input can be the AUTOMAN Block. The successor
block for OUTCAP and ROCLM can be SIGNALSEL block. The successor block for
RUNBKACTFL and SAFEOPTRIGFL can be LOGIC: OR block. This is a common scenario.
Inputs
• LOADSP - Load Set point
• DI[1..10]
Outputs
• OUTCAP - Output capability
1030 Experion LX Control Builder Components Theory R110
Honeywell February 2014
19. Power Generation Functions
19.2. GRPCAPRBK (Group Capability and Runback) Block
Error handling
• An Error is reported when a user enters a higher OFFCAP value than ONCAP value
of equipment. An error is also reported when the OFFCAP value equals the ONCAP
value of equipment. The block reports an error when the default values of ONCAP
is not changed The ONCAP and OFFCAP parameters report an error when ONCAP
and OFFCAP values are changed to NaN.
• This block supports the invalid index check and Access level checks for all
parameters specific to the block.
• On CM inactivation or CEE state IDLE, all output values are set to default values.
• If LOADSP status is BAD , then:
− The ROCLM Output is retained at the last value if ROCLMOPT= LASTVAL is
selected. If ROCLMOPT = SAFEVAL, the user selected value is substituted for
ROCLM.
− The RUNBKACTFL is set to FALSE.
• If all the DISTS of the Configured Number of Equipment are BAD, then:
− ROCLM is retained at the last value if ROCLMOPT= LASTVAL is selected. If
ROCLMOPT = SAFEVAL, the user selected value is substituted for ROCLM.
− The RUNBKACTFL is set to FALSE.
− OUTCAP is retained at the last value if CAPVALOPT = LASTVAL is selected.
If ROCLMOPT = SAFEVAL, the user selected value is substituted for
OUTCAP.
• In case, LOADSPSTS is BAD or all the DISTS of the Configured Number of
Equipment are BAD, the SAFEOPTRIGFL is set to TRUE and a corresponding
alarm is generated.
• OFFCAP[], ONCAP[] and RBROCLM parameters are not allowed to be
changed/edited when the CM is active.
• If there is more than one block per CM, the number of blocks per display depends
on the configuration on the first block. A maximum of six blocks per display are
R110 Experion LX Control Builder Components Theory 1031
February 2014 Honeywell
19. Power Generation Functions
19.3. HTMOTOR (HT Motor Drive Control) Block
possible. If more than six blocks per display is configured, the details of the first six
blocks are displayed along with an error message.
ATTENTION
• SAFEOPALM.FL and SAFEOPTRIGFL parameters essentially provide
the same functionality of raising the safe output alarm flag in a Group
Capability block. Either of the two parameters may be used to achieve
the functionality.
GRPCAPRBK parameters
REFERENCE
Refer to the Control Builder Components Reference for parameter details for
the Group Capability and Runback Function block.
The following diagram illustrates the START logic flow for an HT Motor block.
The following diagram illustrates the STOP logic flow for an HT Motor block.
The following diagram illustrates the TRIP logic flow for an HT Motor block.
Each HT Motor Control block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that tab.
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that appear on the
Parameters face of the function block in the Project tab in Control
Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Template Defining Lets you view and define parameters for associated
templates.
Function
• The HT Motor Control block has two inputs, two states, and two outputs.
• Provides PV Source Selection; PV has 2 basic states such as RUN and STOP and an
additional BAD state.
• Provides latched and pulsed outputs.
• Provides Initialization, Local Manual and Redtagging.
• Provides BADPV, Command Disagree, Equipment Safety, Uncommanded Change,
Command Fail, and Interlock trip alarms.
• Provides PV change of state event.
• Provides Permissive and Override Interlocks for each state.
• Provides Seal In option.
• The Safety Interlock enforces the defined safe state.
• Provides predefined Safe State.
Configuration examples
Scenario 1:
The following scenario depicts the implementation of an HT Motor block in a Control
Strategy with Auto Start/Stop, Equipment trips, Local Start/Stop and MCC inputs:
Callout Description
1 Use the PV parameter connection to carry MCC inputs (MTR, MTS) from
the DICHANNEL block to the HT Motor block.
In HT Motor block, the MCC inputs (MTR, MTS) provide the feedback
that the commanded action has or has not taken place.
Use the PV parameter connection to carry MCC trip inputs (MTT, LRR)
and breaker status inputs (BKS, BKR) from the DICHANNEL block to the
HT Motor block.
2 Use the PV parameter connection to carry Remote switch input from the
Callout Description
DI channel block to the HT Motor block.
3 Use the PV parameter connection to carry Local switch input from the DI
channel block to the HT Motor block.
4 Use the PVFL parameter connection of the Dig Acq block to carry
vibration trip inputs from the DI channel block to the HT Motor through
the Dig Acq block.
5 You can command the device through the output (OP) directly, provided
the MODEATTR is Operator, Remote switch is ON and the local switch is
OFF.
Scenario 2
The following scenario depicts the implementation of an HT Motor block in a Control
Strategy with Safety, Override, and Permissive logic and MCC Inputs.
Callout Description
1 Use the PV parameter connection to carry MCC inputs (MTR, MTS) from
the DICHANNEL block to the HT Motor block.
In HT Motor block, the MCC inputs (MTR, MTS) provide the feedback
that the commanded action has or has not taken place.
Use the PV parameter connection to carry MCC trip inputs (MTT, LRR)
and breaker status inputs (BKS, BKR) from the DICHANNEL block to the
HT Motor block.
3 You can command the device through the output (OP) directly, provided
the MODEATTR is Operator, Remote switch is ON and the local switch is
OFF.
Scenario 3
The following scenario depicts the implementation of an HT Motor block in a Control
Strategy with Equipment trips and UCP Start/Stop logic and MCC Inputs.
Callout Description
1 Use the PV parameter connection to carry MCC inputs (MTR, MTS) from
the DICHANNEL block to the HT Motor block.
In HT Motor block, the MCC inputs (MTR, MTS) provide the feedback
that the commanded action has or has not taken place.
Use the PV parameter connection to carry MCC trip inputs (MTT, LRR)
and breaker status inputs (BKS, BKR) from the DICHANNEL block to the
HT Motor block.
Callout Description
2 Use the PVFL parameter connection of the Dig Acq block to carry
vibration trip inputs from the DI channel block to the HT Motor through
the Dig Acq block.
Input, UCP REL, UCP START, UCP STOP from the DI channel block to
the HT Motor block.
4 You can command the device through the output (OP) directly, provided
the MODEATTR is Operator, Remote switch is ON and the local switch is
OFF.
Inputs
The HT Motor block can have two inputs. Each input is a Boolean value, representing
the state of another block output or a field DICHANNEL (Digital Input Channel) block.
The inputs which are physically wired into the system and brought to this block through
Channel blocks are termed as Hard inputs. The Soft inputs normally operate from
displays or other function blocks.
Hard Inputs: MTT, MTR, MTS, LRR, BKS, BKT, BKR, WDGTEMPTRIP,
VIBRTRIP, BRNGTEMPTRIP, LOCALSWITCH, REMOTESWITCH,
LOCALSTART, LOCALSTOP, UCPREL, UCPSTART, UCPSTOP, SEQSTART,
SEQSTOP, AUTOSTART, AUTOSTOP, RESETFIRSTUP, BKTBYPASS
Soft Inputs: PORUNCONNECTED, POSTOPCONNECTED, RUNPULSEWIDTH,
STOPPULSEWIDTH, PI[0], PI[1], OI[0], OI[1], TRKNUMTRANS,
TRKNUMSIOVRD, TRKSTATETIME, RESETFL.
Outputs
The HT Motol Control block may have two outputs. Each output can be latched or
pulsed (On Pulse or Off Pulse). Each output is a Boolean value, which can be connected
Error handling
• LOCALSTART can be initiated only when 'Other FB' access lock, Operator mode
and Local/Remote selection switch is at LOCAL.
• AUTOSTART can be initiated only when access lock in not 'Other FB' and
local/remote switch is at REMOTE.
R110 Experion LX Control Builder Components Theory 1061
February 2014 Honeywell
19. Power Generation Functions
19.3. HTMOTOR (HT Motor Drive Control) Block
States
A "state" represents the current condition of a device. In the case of HT Motor, RUN and
STOP represent the two states, with Stop being the safe or failsafe state. Each input
combination is assigned to a specific state and this mapping is fixed. The PV parameter
represents the current state of the HT Motor.
The output states are mapped to specific combinations of digital outputs. These outputs
command the field device to the associated state - RUN or STOP. The OP parameter
represents the commanded state or the device state commanded by an operator. The
block transmits the OP, monitors the PV, and produces alarms based on the State
Assignment configurations, which represent whether or not the process feedback has
achieved the state commanded in OP.
STATETEXT[4] STOP S0
STATETEXT[5] RUN S1
STATETEXT[6] NOCOMMAND S2
LocalStart LOCAL
UCPStart REMOTE
LocalStop LOCAL
UCPStop
ConsoleStop OPER
Ignore
Check
Local manual
The local manual (LOCALMAN) parameter is an input flag to support an interface to a
local HAND/OFF/AUTO (also called HAND/OFF/REMOTE) switch on the field
device. You can hard wire the AUTO position of the switch to a digital input. The state
of the digital input can be stored to the LOCALMAN pin added to the HT Motor block
through a DICHANNEL connection. The control system cannot have control over the
field device when the HAND/OFF/AUTO switch is not in AUTO position, the
LOCALMAN parameter provides feedback of the switch position.
When the LOCALMAN parameter is ON, the OP state tracks the PV state, if it is a
settable state. If PV is in a non-settable state, OP is set to STOP. This ensures that the
last commanded state agrees with the current value of the feedback state, when the
LOCALMAN is turned OFF. You cannot directly command the OP (GOP) if
LOCALMAN is ON.
You cannot access LOCALMAN, if the HT Motor block has no inputs or no outputs
connected. PV is illegal for no inputs and OP is illegal for no outputs, and therefore
LOCALMAN has no meaning for these conditions.
When LOCALMAN is ON, the OP and OPFINAL follow PV (if it is in a settable state).
The digital outputs CmdRun/Stop will follow OPFINAL.
ATTENTION
LOCALMAN can be used, when the LT Motor commands are commanded by
Local, and controlled directly from the MCC and not from the DCS.
Permissive interlocks
PI[0..1]are Permissive Interlocks inputs that can be connected to an external function
block to determine whether the operator and/or user program are allowed to change the
commanded output (OP) of the HT Motor block to a specific state. Permissive Interlocks
themselves never cause OP to change.
• For OP to be changed to the desired state, the corresponding Permissive Interlock
parameter must be set to ON.
• The Permissive Interlocks are all defaulted to ON, thereby allowing permission to all
the states - they must be individually set to OFF to prevent access to the
corresponding OP state.
Override Interlocks
OI[0..1] are Override Interlocks which, when active, force the commanded output (OP)
to a respective state regardless of the condition of the Permissive Interlocks. OP cannot
be commanded to a different state when an Override Interlock is active.
• Override Interlocks may be connected to other block outputs or may be directly set
by an operator if MODEATTR = OPERATOR and the block is inactive.
• Override Interlock parameters are all defaulted to OFF, thereby disabling all the
Override Interlocks. They must be set to ON to force OP to go to any specific state.
If the Override Interlock forces OP to go to a momentary state, it stays in that state
as long as the interlock remains ON and then switches back to the original state
when the Override Interlock is reset to OFF.
• SI has a higher priority than any of the Override Interlocks; the priorities of the
Override Interlocks are determined by the state assigned to predefined SAFEOP that
is STOP and the priority is SI, OI[0], OI[1].
Alarms
An available set of PV state alarms may be configured to represent disagreements
between the Commanded Output State (OP) and the Current Active State (PV). A Safety
Override Interlock alarm is also available. Each of these alarms possesses all the standard
attributes of system alarms.
• Command Fail alarm - generated when the Current Active State (PV) fails to change
from an original value to any other value within a configurable time interval after
the OP parameter is commanded.
− You can configure the feedback time (CMDFALALM.TM[0..1) for each state
through the Alarms tab on HT Motor block configuration form. The value of OP
just commanded determines which CMDFALALM.TM[0..1] is active. The
CMDFALALM.TM[0..1] setting range is 0 to 1000 seconds. Setting a given
CMDFALALM.TM[0..1] parameter to 0 disables the alarm for the associated
state[0..1]. The alarm function is automatically disabled, if there are no inputs or
no outputs. CMDFALALM.TM[0..1] changes from or to 0, require CM InActive
or CEE Idle.
ATTENTION
• The CMDFALALM.TM[0..1] cannot be configured if
CMDDISALM.TM[0..1] has not been configured.
• Bad PV alarm - generated whenever the Current Active State (PV) is detected to be
a NULL (or bad) state.
• Command Disagree alarm - generated when the Commanded Output State (OP) is
changed and the actual input state (PV) does not change accordingly within a
specified feedback time.
− The feedback time (CMDDISALM.TM[0..1) for each state has to be configured
on the Alarms tab on HT MOTOR block configuration form. The value of OP just
commanded determines which CMDDISALM.TM[0..1] is active. The
CMDDISALM.TM[0..1] setting range is 0 to 1000 seconds. Setting a given
CMDDISALM.TM[0..1] parameter to 0 disables the alarm for the associated
state[0..1]. The alarm function is automatically disabled, if there are no inputs or
no outputs. CMDDISALM.TM[0..1] changes from or to 0, require CM InActive
or CEE Idle.
− This alarm condition returns to NORMAL when the input PV state becomes equal
to the OP state.
• Uncommanded Change alarm - generated if the actual input state (PV) changes but
has not been commanded to change (unless it is a bad PV). This alarm is configured
whenever the Command Disagree alarm is configured.
− This alarm condition returns to NORMAL when the input PV state becomes equal
to the commanded OP state.
• Off Normal alarm - This alarm is generated whenever PV does not match OPREQ, if
OPREQ is not Null.
• Override Interlock alarms - When the alarm is enabled and the active interlock
causes an OP state change, an alarm is generated.
• Safety Override Interlock alarm - When the alarm is enabled and the active interlock
causes an OP state change, an alarm is generated.
If a real-time conflict exists between a Safety Override Interlock alarm configured to
alarm and a PV alarm condition, such as Uncommanded Change alarm, interlock action
1068 Experion LX Control Builder Components Theory R110
Honeywell February 2014
19. Power Generation Functions
19.3. HTMOTOR (HT Motor Drive Control) Block
(setting of the output state and related alarm notification) always occurs regardless of the
effect of the other alarm.
Seal-in option
The seal-in option is used for clearing output commands when the process feedback state
(PV) cannot follow the commanded output state (OP) as detected by the Command
Disagree or Uncommanded Change alarms. If enabled, when the condition is detected,
field output destinations are set to the Safe Output State (STOP), but OP is not altered.
Observe OPFINAL to determine what state was actually commanded to the output
destinations. The OPFINAL is displayed in reverse video while monitoring Control
Builder if it differs from OP. OPFINAL is set equal to OP on the next store to OP, which
clears the "seal" condition.
• You can configure the seal-in option through the SEALOPT (Enable/Disable)
parameter.
ATTENTION
To configure Seal-in option, ensure that the CM is inactive and
CMDDISALM.TM [0..1] is configured.
FIRSTUP functionality
The HT Motor block has an inbuilt FIRSTUP logic which enables the FIRSTUPACTED
flag on detecting a valid input transition. The firstup detected is not reset on restarting
the motor; it has to be reset manually through RESETFIRSTUP. The inputs that are
scanned for FIRSTUP detection include MTTACTED, WDGTEMPTRIPACTED,
VIBRTRIPACTED, BRNGTEMPTRIPACTED, LOCALSTOPACTED,
UCPSTOPACTED, SEQSTOPACTED, AUTOSTOPACTED, OIACTED, SIACTED,
LRRACTED.
OP initialization option
The parameter INITOPOPT is used to configure OP Initialization option. It is an
enumeration of NORMALOPT, SAFEOPOPT or HOLDOPOPT. The default value is
NORMALOPT.
• INITOPOPT = NORMALOPT, perform normal initialization as described in the
ensuing section on Initialization Manual Condition with Safety Override Interlock,
Override Interlocks, LocalMan, and OP Initialization.
• INITOPOPT = SAFEOPOPT, OP is set to SAFEOP.
• INITOPOPT = HOLDOPOPT, initialization is not performed. OP remains at the last
value.
Maintenance statistics
The HT MOTOR block collects a set of maintenance statistics which are classified into
three categories which are enabled by enable options - TRKSIOVRD,
TRKNUMTRANS, TRKSTATETIME.
The following maintenance statistics are collected:
• NUMTRANS[0,1] - Number of transitions of PV to each state. This can be enabled
provided TRKNUMTRANS is enabled.
Output requests
Whenever an external FB attempts to change the commanded state OP, the HT MOTOR
block uses the OP request mechanism. The OP request (OPREQ/GOPREQ) differs from
direct access an operator uses to the commanded state OP. The OPREQ is a string in the
same manner as OP, and GOPREQ is the enumeration GENSTAT_ENM, which is the
same as GOP.
There is no direct access to OPREQ when MODEATTR is PROGRAM. It can be
changed as part of a control request from SCM. When MODEATTR is OPERATOR, an
operator can change OPREQ, but this does not block a control request. This means a
program store to OPREQ cannot be rejected, and no error is returned. The FB retains the
stored value until it is overwritten, except in certain non-stored cases when the level 1
drivers are active. OPREQ acts like a repeated attempt to store to OP. The OPREQ is
always active unless it is Null. This means the OPREQ continues to attempt stores even
if attributes, such as interlocks, become active and block changes to OP. Thus, once the
attributes blocking change to OP the reset OPREQ stores the commanded state to OP.
Output command
The block provides Boolean command capability through an array of Boolean inputs
(AUTO START/STOP, UCP START/STOP, LOCAL START/STOP, SEQ
START/STOP).
• When the mode attribute (MODEATTR) is Program and the SCM option
(SCMOPT) is None, an output from a Logic block can be used to set the requested
output state (OPREQ) through the given Boolean input command (AUTO
START/STOP, SEQ START/STOP).
ATTENTION
• UCP START/STOP, SEQ START/STOP, LOCAL START/STOP work on
OFF to ON transitions. So, there is no priority for them.
• UCP STOP and CONSOLE STOP ignore the switches for its operation.
• Since BKT and BKS are complimentary inputs, the HT motor can be
commanded only when either one of them is ON.
HTMOTOR parameters
REFERENCE
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the Drive Control block.
h = ( H (ρRef - ρS ) - DP ) / (ρW - ρS )
• ρRef: Density of water in wet leg (This computation uses the Water Leg temperature)
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Configuration Lets you select the available parameters that appear on the
Parameters face of the function block in the Project tab in Control
Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Template Defining Lets you view and define parameters for associated
templates.
Function
• The Drum Level Computation function block computes the drum level from the
measured DP, Pressure and other field specific constants.
• The block has an algorithm for generating steam and water density from the given
pressure input as long as the pressure input is good.
• The Level Status (PV) becomes bad when one of the input's status becomes bad and
PV is not be computed.
• Enables the user to select ENGUNIT for DP, Pressure, WETLEGTEMP, and drum
level.
Block Configuration
By default, the PRSLOPE is set to 1 and PRBAIS is set to 0, the DPSLOPE is set to 1,
DPBIAS is set to 0.
Predecessor Block
Successor Block
The output of the Drum Level Computation block has a direct connectivity to a DACA
block.
Inputs
• DP - Differential Pressure of the drum.
• PRESSURE - Pressure input parameter.
Outputs
• PV - Drum level.
• PVP - Drum level in %
• DENSTEAM - Density of steam in drum
Error handling
• The Level Status (PVSTS) becomes bad when one of the input's status becomes bad
and PV is not computed and PV takes a NaN. If any of the input status is not bad,
then PV is calculated and the status is updated appropriately.
• The block limits the range of Wet leg Temperature input. The permissible range that
can be entered is 0 to 70 Deg C (or 32 to 158 Deg F).
• The PRESSURE and DP parameters do not accept negative values.
• If PVSTS is bad, PV is not computed and assigned with a NaN.
• If the inputs go to NaN, PV is not calculated and assigned with a NaN.
• The block requires PVEUHI to be greater than PVEULO. If PVEUHI is attributed to
a value lower than PVEULO, an error message is reported during configuration and
the input value is rejected.
• Parameters PVEULO, PVEUHI, DPSLOPE, DPBIAS, PRSLOPE, and PRBIAS can
be changed from the Monitoring side when CM is inactive. If the value of these
parameters is changed when CM is active, an error is reported during configuration
and the input value is rejected.
LEVELCOMP parameters
REFERENCE
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the Drum Level Computation block.
and Process inputs have to hover around this one single input pin by employing OR or
AND blocks for multiplexing. The LT Motor Control function block (LTMOTOR),
available under the POWERGEN library is derived from the Device Control block in
Experion LX (DEVCTL) customized to meet the LT Motor Drive control requirements
found in power plants. It accepts inputs and interlocks pertaining to a conventional
LTMOTOR drive's MCC and is capable of controlling the drive through outputs
governed by predetermined logic.
The LT Motor Control function block is graphically represented as follows.
Each LT Motor Control block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that Tab.
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that appear on the
Parameters face of the function block in the Project tab in Control
Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Template Defining Lets you view and define parameters for associated
templates.
Function
• The LT Motor function block has two inputs, two states, and two outputs.
• Allows PV source selection (PVSRC) as RUN, STOP or faulty (BAD) state.
• Provides latched and pulsed outputs.
• Provides Initialization, Local Manual and Redtagging.
• Provides BADPV, Command Disagree, Equipment Safety, Uncommanded Change,
Command Fail, and interlock trip alarms.
• Provides PV Change of state event.
• Provides Permissive and Override Interlocks for each state.
• Provides Seal In option.
• Enables the Safety Interlock to enforce the defined safe state.
• Provides an explicitly configured Safe State.
• Provides generic State parameters defined as consistent data types.
Configuration examples
Scenario 1:
The following scenario depicts the implementation of an LT Motor block in a Control
Strategy with Auto Start/Stop, Local Start/Stop logic and MCC inputs.
Callout Description
In the LT Motor block, the MCC inputs (MTR, MTS) provide the feedback
that the commanded action has or has not taken place.
Use the PV parameter connection to carry MCC trip input (MTT) from the
DICHANNEL block to the LT Motor block.
2 Use the PV parameter connection to carry Remote switch input from the
DI channel block to the LT Motor block.
3 Use the PV parameter connection to carry Local switch input from the DI
channel block to the LT Motor block.
Callout Description
commanded by Local Start, Local Stop provided the Remote switch is
OFF, the local switch is ON and MODEATTR is in PROGRAM.
4 You can command the device through the output (OP) directly, provided
the MODEATTR is Operator, Remote switch is ON and the local switch is
OFF.
Scenario 2
The following scenario depicts the implementation of an LT Motor block in a Control
Strategy with Safety, Override and permissive inputs and MCC inputs.
Callout Description
1 Use the PV parameter connection to carry MCC inputs (MTR, MTS) from
the DICHANNEL block to the LT Motor block.
In the LT Motor block, the MCC inputs (MTR, MTS) provide the feedback
that the commanded action has or has not taken place.
3 You can command the device through the output (OP) directly, provided
the MODEATTR is Operator, Remote switch is ON and the local switch is
OFF.
Scenario 3
The following scenario depicts the implementation of a LT Motor block in a Control
Strategy with UCP Start/Stop logic and MCC Inputs.
Callout Description
1 Use the PV parameter connection to carry MCC inputs (MTR, MTS) from
the DICHANNEL block to the LT Motor block.
In the LT Motor block, the MCC inputs (MTR, MTS) provide the feedback
that the commanded action has or has not taken place.
Use the PV parameter connection to carry MCC trip input (MTT) from the
DICHANNEL block to the LT Motor block.
Callout Description
3 You can command the device through the output (OP) directly, provided
the MODEATTR is Operator, Remote switch is ON and the local switch is
OFF.
Inputs
An LT Motor block can have two boolean inputs which can represent the state of another
block output or a field DICHANNEL (Digital Input Channel) block.
The inputs which are physically wired into the system and brought to this block via a
Channel blocks are termed as Hard inputs. The Soft inputs normally operate from
displays or other function blocks.
Hard Inputs: MTT, MTR, MTS, LRR, BKS, BKT, BKR, LOCALSWITCH,
REMOTESWITCH, LOCALSTART, LOCALSTOP, UCPREL, UCPSTART,
UCPSTOP, SEQSTART, SEQSTOP, AUTOSTART, AUTOSTOP
Soft Inputs: PORUNCONNECTED, POSTOPCONNECTED, RUNPULSEWIDTH,
STOPPULSEWIDTH, PI[0,1], OI[0,1], TRKNUMTRANS, TRKNUMSIOVRD,
TRKSTATETIME, RESETFL
Outputs
An LT Motor Control function block may have two outputs. Each output can be latched
or pulsed (On Pulse or Off Pulse). Each output is a Boolean value, which can be
connected to any other block parameter or to a field DOCHANNEL (Digital Output
Channel) block.
• An output to any connection except a DOCHANNEL block is a Boolean output
only.
• The DOCHANNEL (DOC) block can connect two different inputs to a drive control
block (output). However, only one of these inputs can be connected for a single
DOC.
• DOC.SO can be connected to the latched outputs like CmdRun and CmdStop.
• DOC.ONPULSE can be connected to pulsed outputs PORun and POStop.
• DOC.OFFPULSE can be connected to pulsed outputs PORun and POStop.
Error handling
• LOCALSTART can be initiated only when access lock is 'Other FB', mode is
Operator and Local/Remote selection switch is at local.
• AUTOSTART can be initiated only when access lock in not 'Other FB' and
local/remote switch is at remote.
• SEQSTART can be initiated only when the mode is at Program.
• UCPSTART can be initiated only when access lock is not OtherFB and UCP
RELEASE is available.
• RUNTIME, STARTTIME, TRIPTIME do not accept a value less than 0 or more
than 96000.
• TRKTRIPTIME, TRKRUNTIME, TRKSTOPTIME requires Engineer Access lock.
• For the LT Motor FB, if both feedback status is ON and OFF, a fault status is
flagged and output generation is not processed.
States
A "state" represents the current condition of a device. In the case of an LT Motor, RUN
and STOP represent the two states, with STOP being the safe or failsafe state. Each input
combination is assigned to a specific state and this mapping is fixed. The PV parameter
represents the current state of the LT Motor.
The output states are mapped to specific combinations of digital outputs. These outputs
command the field device to the associated state, such as RUN or STOP. The OP
parameter represents the commanded state or the device state commanded by an
operator. The block transmits the OP, monitors the PV, and produces alarms based on the
state assignment configurations, which represent whether or not the process feedback has
achieved the state commanded in OP.
• Inbet - Represents an in between state and could be designated MOVPV for moving
PV.
• Active - Refers to momentary state settings for a two-state device. It is defined as
not SAFEOP of State 0 and State 1 and illegal for 3 state configurations. For
example, if SAFEOP is designated as State 0 (S0), State 1 (S1) is considered the
active state. If S1 is the SAFEOP, S0 is considered the active state. An external FB
could issue the Active command to GOP and the state is set to the not SAFEOP of
S0 or S1, accordingly.
• Safe - Stands for SAFEOP. If an external FB issues a Safe command to GOP, the
internal value is set to the designated SAFEOP.
− S0 -Represents settable output State 0 (STOP).
− S1 - Represents settable output State 1 (RUN).
The STATETEXT[0..6] parameter is an array of 12-character string parameters
corresponding to the members of the generic state enumerations. This allows the various
State parameters to have labels unique to each state. The following table lists the default
name for a given STATETEXT[0..6] and shows the corresponding generic states
enumeration.
STATETEXT[4] STOP S0
STATETEXT[5] RUN S1
STATETEXT[6] NOCOMMAND S2
LocalStart LOCAL
UCPStart REMOTE
LocalStop LOCAL
UCPStop
ConsoleStop OPER
Ignore
Check
Local manual
The local manual (LOCALMAN) parameter is an input flag to support an interface to a
local HAND/OFF/AUTO (also called HAND/OFF/REMOTE) switch on the field
device. You can hard wire the AUTO position of the switch to a digital input. You can
then have the state of the digital input stored to the LOCALMAN pin added to the LT
Motor block through a DICHANNEL connection. The control system cannot have
control over the field device when the HAND/OFF/AUTO switch is not in the AUTO
position, the LOCALMAN parameter provides feedback of the switch position.
When the LOCALMAN parameter is ON, the OP state tracks the PV state, if it is a
settable state. If PV is in a non-settable state, OP is set to STOP. This ensures that the
last commanded state agrees with the current value of the feedback state, when the
LOCALMAN is turned OFF. You cannot directly command the OP (GOP) while the
LOCALMAN is ON.
The LOCALMAN cannot be accessed, if the LT Motor block has no inputs or no outputs
connected. PV is illegal for no inputs and OP is illegal for no outputs, and therefore
LOCALMAN has no meaning for these conditions.
When LOCALMAN is ON, the OP and OPFINAL follow PV (if it is in a settable state).
The digital outputs CmdRun/Stop follows OPFINAL.
ATTENTION
LOCALMAN can be used, when the LT Motor commands are commanded by
Local, and controlled directly from the MCC and not from the DCS.
Permissive interlocks
PI[0..1]are Permissive Interlocks which are inputs that can be connected to an external
function block determine whether the operator and/or user program are allowed to
change the commanded output (OP) of the LT Motor block to a specific state. Permissive
Interlocks themselves never cause OP to change.
• For OP to be changed to the desired state, the corresponding Permissive Interlock
parameter must be set to ON.
• The Permissive Interlocks are all defaulted to ON, thereby allowing permission to all
the states - they must be individually set to OFF to prevent access to the
corresponding OP state.
Override Interlocks
OI[0..1] are Override Interlocks which, when active, force the Commanded Output (OP)
to a respective state regardless of the condition of the Permissive Interlocks. OP cannot
be commanded to a different state when an Override Interlock is active.
• Override Interlocks can be connected to other block outputs or can be directly set by
an operator if MODEATTR = OPERATOR and the block is inactive.
• Override Interlock parameters are all defaulted to OFF, thereby disabling all the
Override Interlocks. They must be set to ON to force OP to go to any specific state.
If the Override Interlock forces OP to go to a momentary state, it stays in that state
as long as the interlock remains ON and then switches back to the original state
when the Override Interlock is reset to OFF.
• SI has a higher priority than any of the Override Interlocks; the priorities of the
Override Interlocks are determined by the state assigned to predefined SAFEOP that
is STOP and the priority is SI, OI[0], OI[1].
Alarms
An available set of PV state alarms can be configured to represent disagreements
between the Commanded Output State (OP) and the Current Active State (PV). A Safety
Override Interlock alarm is also available. Each of these alarms possesses all the standard
attributes of system alarms.
• Command Fail alarm - generated when the Current Active State (PV) fails to change
from an original value to any other value within a configurable time interval after
the OP parameter is commanded.
− You can configure the feedback time (CMDFALALM.TM[0..1) for each state
through the Alarms tab on LT Motor block configuration form. The value of OP
just commanded determines which CMDFALALM.TM[0..1] is active. The
CMDFALALM.TM[0..1] setting range is 0 to 1000 seconds. Setting a given
CMDFALALM.TM[0..1] parameter to 0 disables the alarm for the associated
state[0..1]. The alarm function is automatically disabled, if there are no inputs or
no outputs. CMDFALALM.TM[0..1] changes from or to 0, require CM InActive
or CEE Idle.
ATTENTION
• The CMDFALALM.TM[0..1] cannot be configured if
CMDDISALM.TM[0..1] has not been configured.
• Bad PV alarm - generated whenever the Current Active State (PV) is detected to be
a NULL (or bad) state.
• Command Disagree alarm - generated when the Commanded Output State (OP) is
changed and the actual input state (PV) does not change accordingly within a
specified feedback time.
− You can configure the feedback time (CMDDISALM.TM[0..1) for each state
through the Alarms tab on LT MOTOR block configuration form. The value of
OP just commanded determines which CMDDISALM.TM[0..1] is active. The
CMDDISALM.TM[0..1] setting range is 0 to 1000 seconds. Setting a given
CMDDISALM.TM[0..1] parameter to 0 disables the alarm for the associated
state[0..1]. The alarm function is automatically disabled, if there are no inputs or
no outputs. CMDDISALM.TM[0..1] changes from or to 0, require CM InActive
or CEE Idle.
− This alarm condition returns to NORMAL when the input PV state becomes equal
to the OP state.
• Uncommanded Change alarm - generated if the actual input state (PV) changes but
has not been commanded to change (unless it is a bad PV). This alarm is configured
whenever the Command Disagree alarm is configured.
− This alarm condition returns to NORMAL when the input PV state becomes equal
to the commanded OP state.
− Off Normal alarm - This alarm is generated whenever PV does not match
OPREQ, if OPREQ is not Null.
• Override Interlock alarms - When the alarm is enabled and the active interlock
causes an OP state change, an alarm is generated.
• Safety Override Interlock alarm - When the alarm is enabled and the active interlock
causes an OP state change, an alarm is generated.
If a real-time conflict exists between a Safety Override Interlock alarm configured to an
alarm and a PV alarm condition, such as Uncommanded Change alarm, interlock action
(setting of the output state and related alarm notification) always occurs regardless of
effects of the other alarm.
Seal-in option
The seal-in option is used for clearing output commands when the process feedback state
(PV) cannot follow the commanded output state (OP) as detected by the Command
Disagree or Uncommanded Change alarms. If enabled, when the condition is detected,
field output destinations are set to the Safe Output State (STOP), but OP is not altered.
You can observe OPFINAL to determine what state was actually commanded to the
output destinations. The OPFINAL is displayed in reverse video while monitoring
Control Builder if it differs from OP. OPFINAL is set equal to OP on the next store to
OP, which clears the "seal" condition.
• You can configure the seal-in option through the SEALOPT (Enable/Disable)
parameter.
ATTENTION
To configure Seal-in option, ensure that the CM is inactive and
CMDDISALM.TM [0..1] is configured.
OP initialization option
The parameter INITOPOPT is used to configure OP Initialization option. It is an
enumeration of NORMALOPT, SAFEOPOPT or HOLDOPOPT. The default value is
NORMALOPT.
• INITOPOPT = NORMALOPT, perform normal initialization as described in the
ensuing section on Initialization Manual Condition with Safety Override Interlock,
Override Interlocks, LocalMan, and OP Initialization.
• INITOPOPT = SAFEOPOPT, OP is set to SAFEOP
Maintenance statistics
The LT MOTOR block collects a set of Maintenance Statistics which are classified into
three categories which are enabled by their respective enable options such as,
TRKSIOVRD, TRKNUMTRANS, TRKSTATETIME.
The maintenance statistics collected include:
• NUMTRANS[0,1] - Number of transitions of PV to each state. This can be enabled
provided TRKNUMTRANS is enabled.
• NUMALLTRANS - Number of all PV transitions. This can be enabled provided
TRKNUMTRANS is enabled.
• RUNTIME, STOPTIME, TRIPTIME - Accumulated number of hours, the LT Motor
is in RUN, STOP and TRIP state respectively. This can be enabled provided
TRKSTATETIME is enabled.
• NUMSIOVRD - accumulated number of safety interlock trips, which result in OP
changing state (after the last statistics reset). This can be enabled provided
TRKSIOVRD is enabled.
The statistics are accumulated after the most recent reset. The operator can reset the
statistics of LT MOTOR block anytime irrespective of Redtagging, unlike the DEVCTL
block.
Output requests
Whenever an external FB attempts to change the commanded state OP, the LT MOTOR
block uses the OP request mechanism. The OP request (OPREQ/GOPREQ) differs from
direct access an operator uses to the commanded state OP. The OPREQ is a string in the
same manner as OP, and GOPREQ is the enumeration GENSTAT_ENM, which is the
same as GOP.
There is no direct access to OPREQ when MODEATTR is PROGRAM. It can be
changed as part of a control request from an SCM. When MODEATTR is OPERATOR,
an operator can change OPREQ, but this does not block a control request. This means a
program store to OPREQ cannot be rejected, and no error is returned. The FB retains the
stored value until it is overwritten, except in certain non-stored cases when the level 1
drivers are active. OPREQ acts like a repeated attempt to store to OP. The OPREQ is
always active unless it is Null. This means the OPREQ continues to attempt stores even
if attributes, such as interlocks, become active and block changes to OP. Thus, once the
attributes blocking change to OP have reset OPREQ stores the commanded state to OP.
Output command
The block provides a Boolean command capability through an array of Boolean inputs
(AUTO START/STOP, UCP START/STOP, LOCAL START/STOP, SEQ
START/STOP).
• When the mode attribute (MODEATTR) is Program and the SCM option
(SCMOPT) is None, you can use an output from a Logic type block to set the
requested output state (OPREQ) through the given Boolean input command
(AUTO START/STOP, SEQ START/STOP).
ATTENTION
• UCP START/STOP, SEQ START/STOP, LOCAL START/STOP work on
OFF to ON transitions. So, there is no priority for them.
• UCP STOP and CONSOLE STOP ignore switches for its operation.
LTMOTOR parameters
REFERENCE
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the Drive Control block.
The Main - IBV Logic block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that tab.
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that appear on the
Parameters face of the function block in the Project tab in Control
Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Template Defining Lets you view and define parameters for associated
templates.
Function
• Receives a command from OPER or PROGRAM, processes it and schedules the
command to the IBV and Main valve with a predetermined logic built into it.
• Triggers an open sequence failure alarm in case an OPEN command fails to open the
Main valve.
• Triggers a close sequence failure alarm in case a CLOSE command fails to close
Main valve.
• Triggers a BADPV alarm in case the IBV open feedback or Main close feedback is
in BAD state.
• Commands the Drive Control blocks for further operation of Main and IBV valve.
• Generates an extra event for IBVFEEDBACKTIMOUT and
MAINFEEBACKTIMOUT whichever applicable along with the OPENSEQFAIL
and CLOSESEQFAIL to indicate the actual cause of the alarm.
Inputs
• OPENSEQ - Open Sequence command from PROGRAM to the valve system.
• CLOSESEQ - Close Sequence command from PROGRAM to the valve system.
• IBVOPENFDBK - IBV open feed-back switch.
• MAINCLOSEFDBK - Main valve close-feedback switch.
Outputs
• OPENIBV\CLOSEIBV - Open/Close command to IBV drive control.
• OPENMAIN\CLOSEMAIN - Open/Close command to Main Valve drive control.
Control logic
The following figure illustrates the control logic of the Main-IBV function block:
The details of the Control logic illustration are described in the following table:
Path Description
ATTENTION
• SCM writes directly to OPENSEQ and CLOSESEQ from SCM
Expressions.
• Operator can take control of Valve Damper/ Drive/ Dev ctl by changing
mode attribute to operator whenever required for bypassing the
MAINIBV.
ATTENTION
• The OPEN IBV command is withdrawn as soon as the OPEN IBV
Error handling
• Displays an error for invalid input index while loading or accessing parameters.
• Verifies parameter access level during download and accessing.
• Limits the range of DELAY input for the user. Only a positive value can be entered
for DELAY on the Project and Monitoring side.
• Reports an error during download if the input value for OPENTIMEOUT or
CLOSETIMEOUT is zero on the project side.
MAINIBV parameters
REFERENCE
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the Main-IBV Logic block.
The Solenoid Valve Control function block (SOLENOID), available under the
POWERGEN library is graphically represented as follows:
Each Solenoid Valve Control block supports the following user configurable attributes.
The following table lists the given name of the "Tab" in the parameter configuration
form and then briefly describes the attributes associated with that tab.
Output • Safe Output State (SAFEOP) - Lets you select the state
that defines the block in a safe state. The default is S0
(CLOSE). S1 (OPEN) can be configured by the user.
• Init OP After Load (INITOPAFTLD) - Lets you specify the
state to which the digital outputs have to be set after a
Load. Selections are DEFAULT, OPEN and CLOSE.
Both digital outputs are set to OFF in DEFAULT mode.
• OP Initialization Option (INITOPOPT) - The parameter
INITOPOPT is used to configure OP Initialization option.
Lets you specify the state in which OP is set when
INITMAN transitions from ON to OFF. It is an
enumeration of NORMALOPT, SAFEOPOPT or
HOLDOPOPT. The default value is NORMALOPT.
• Seal-in Option (SEALOPT) - Lets you clear the output
commands when the process feedback state cannot
follow the commanded output state. Selections are
DISABLED and ENABLED. If ENABLED, the field output
destinations are set to SAFEOP but OP is not altered.
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that appear on the
Parameters face of the function block in the Project tab in Control
Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Template Defining Lets you view and define parameters for associated
templates.
Function
• The solenoid valve has two inputs, three states, and one output.
• Allows PV source selection (PVSRC) as OPEN, CLOSE, INBET or faulty (BAD)
state.
• Provides latched outputs.
• Provides Initialization, Local Manual and Redtagging.
• Provides BADPV, Command Disagree, SafetyInterlock , Uncommanded Change
and Command Fail, Override Interlock alarms.
• Allows PV change of state event.
R110 Experion LX Control Builder Components Theory 1133
February 2014 Honeywell
19. Power Generation Functions
19.7. SOLENOID (Solenoid Valve Drive Control) Block
Configuration examples
Scenario 1:
The following scenario depicts the implementation of a Solenoid Valve Control block in
a Control Strategy with Auto Open/Close, Remote Switch, Local Open/Close logic and
MCC inputs.
Callout Description
1 Use the PVFL parameter connection to carry MCC inputs from the
DICHANNEL block to the Solenoid Valve block.
In the Solenoid valve block, the MCC inputs (LTO, LTC) provide the
feedback if the valve is open or close.
2 Use the PV parameter connection to carry Remote switch input from the
DI channel block to the Solenoid Valve block.
3 Use the PV parameter connection to carry Local switch input from the DI
channel block to the Solenoid Valve block.
4 You can command the device through the output (OP) directly, provided
the MODEATTR is Operator, Remote switch is ON and the local switch is
1138 Experion LX Control Builder Components Theory R110
Honeywell February 2014
19. Power Generation Functions
19.7. SOLENOID (Solenoid Valve Drive Control) Block
Callout Description
OFF.
Scenario 2:
The following scenario depicts the implementation of a Solenoid Valve Control block in
a Control Strategy with Safety, Override and permissive inputs and MCC inputs.
Callout Description
1 Use the PVFL parameter connection to carry MCC inputs from the
DICHANNEL block to the Solenoid Valve block.
In the Solenoid Valve block, the MCC inputs (LTO, LTC) provide the
feedback if the valve is open or close.
3 You can command the device through the output (OP) directly, provided
the MODEATTR is Operator, Remote switch is ON and the local switch is
OFF.
Scenario 3:
The following scenario depicts the implementation of a Solenoid Valve Control block in
a Control Strategy with UCP Open/Close logic and MCC inputs.
Callout Description
1 Use the PVFL parameter connection to carry MCC inputs from the
DICHANNEL block to the Solenoid Valve block.
In the Solenoid Valve block, the MCC inputs (LTO, LTC) provide the
feedback if the valve is open or close.
3 You can command the device through the output (OP) directly, provided
the MODEATTR is Operator, Remote switch is ON and the local switch is
OFF.
Inputs
The inputs which are physically wired to the system and brought to this block through a
Channel blocks are termed as Hard input. The Soft inputs normally operate from displays
or other function blocks.
• Hard Inputs: LTO, LTC, LOCALSWITCH, REMOTESWITCH, LOCALOPEN,
LOCALCLOSE, UCPREL, UCPOPEN, UCPCLOSE, SEQOPEN, SEQCLOSE,
AUTOOPEN, AUTOCLOSE
• Soft Inputs: PI[0], PI[1], QI[0], QI[1], TRKNUMTRANS, TRKNUMSIOVRD,
RESETFL
Outputs
The output parameters are: CMPOPEN, OP, PV, NUMTRANS[0,1], NUMSIOVRD
Error handling
• LOCALOPEN/LOCALCLOSE can be initiated only when 'Other FB' access lock,
Operator mode and Local/Remote selection switch is in local.
• AUTOOPEN/AUTOCLOSE can be initiated only when access lock in not 'Other
FB' and local/remote switch is at remote.
• SEQOPEN/SEQCLOSE can be initiated only when the mode is in 'Program.'
• UCPOPEN/UCPCLOSE can be initiated only when access lock is not 'Other FB' and
UCP release is available.
• For the drive control blocks (except Valve and damper), if both feedback status is
ON or OFF, a fault status is flagged and output generation is not processed.
• If the feedback status is bad, an alarm is raised and there is no output generation.
States
A "state" represents the current condition of a device. In the case of a Solenoid valve,
OPEN and CLOSE represent the two states, where failsafe can be configured. Each input
combination is assigned to a specific state and this mapping is fixed. The PV parameter
represents the current state of the Solenoid valve.
The output states are mapped to specific combinations of digital outputs. These outputs
command the field device to the associated state, such as OPEN or CLOSE. The OP
parameter represents the commanded state or the device state commanded by an
operator. The block transmits the OP, monitors the PV, and produces alarms based on the
state assignment configurations, which represent whether or not the process feedback has
achieved the state commanded in OP.
• Safe - Stands for SAFEOP. If an external FB issues a Safe command to GOP, the
internal value is set to the designated SAFEOP.
• S0 -Represents settable output State 0 (CLOSE).
• S1 - Represents settable output State 1 (OPEN).
• S2 - Represents settable output State 2 .
The STATETEXT[0..6] parameter is an array of 12-character string parameters
corresponding to the members of the generic state enumerations. This allows the various
State parameters to have labels unique to each state. The following table lists the default
Solenoid name for a given STATETEXT[0..6] and shows the corresponding generic
states enumeration.
STATETEXT[4] CLOSE S0
STATETEXT[5] OPEN S1
STATETEXT[6] NOCOMMAND S2
LocalOpen LOCAL
UCPOpen
ConsoleOpen OPER
LocalClose LOCAL
UCPClose
ConsoleClose OPER
Ignore
Check
If Safe OP = OPEN then UCPOpen and Console Open will ignore switches.
Local manual
The local manual (LOCALMAN) parameter is an input flag to support an interface to a
local HAND/OFF/AUTO (also called HAND/OFF/REMOTE) switch on the field
device. You can hard wire the AUTO position of the switch to a digital input. You can
then have the state of the digital input stored to the LOCALMAN pin added to the
Solenoid Valve block through a DICHANNEL connection. The control system cannot
have control over the field device if the HAND/OFF/AUTO switch is not in the AUTO
position, the LOCALMAN parameter provides feedback of the switch position.
When the LOCALMAN parameter is ON, the OP state tracks the PV state, if it is a
settable state. If PV is in a non-settable state, OP is set to SAFEOP. This ensures that the
last commanded state agrees with the current value of the feedback state, when the
LOCALMAN is turned OFF. You cannot directly command the OP (GOP) while the
LOCALMAN is ON.
You cannot access LOCALMAN, if the Solenoid Valve block does not have any
inputs/outputs connected. PV is illegal for no inputs and OP is illegal for no outputs, and
therefore LOCALMAN has no meaning for these conditions.
When LOCALMAN is ON, the OP and OPFINAL follow PV (if it is in a settable state).
The digital outputs CmdOpen/CmdClose will follow OPFINAL.
ATTENTION
LOCALMAN can be used for the above purpose, when the Solenoid Valve
Commands are Commanded by Local, controlled directly from MCC and not
through DCS.
Permissive interlocks
PI[0..1]are Permissive Interlocks which are inputs that can be connected to an external
function block to determine whether the operator and/or user program are allowed to
change the commanded output (OP) of the Solenoid Valve block to a specific state.
Permissive Interlocks themselves never cause OP to change.
• To change OP to the desired state, the corresponding Permissive Interlock parameter
must be set to ON.
• The Permissive Interlocks of all states of Solenoid are ON by default, thereby
allowing permission to all the states - they must be individually set to OFF to
prevent access to the corresponding OP state.
Override Interlocks
OI[0..1] are Override Interlocks which, when active, force the commanded output (OP)
to a respective state regardless of the condition of the Permissive Interlocks. OP cannot
be commanded to a different state when an Override Interlock is active.
• Override Interlocks can be connected to other block outputs or can be directly set by
an operator if MODEATTR = OPERATOR and the block is inactive.
• Override Interlock parameters are all default OFF in case of Solenoided, thereby
disabling all the Override Interlocks. They must be set to ON to force OP to go to
any specific state. If the Override Interlock forces OP to go to a momentary state, it
stays in that state as long as the interlock remains ON and then switches back to the
original state when the Override Interlock is reset to OFF.
• SI has a higher priority than any of the Override Interlocks; the priorities of the
Override Interlocks are determined by the state assigned to configurable SAFEOP:
• If SAFEOP is SO, the priority is SI, OI[0], OI[1].
• If SAFEOP is S1, the priority is SI, OI[1], OI[0].
• When BYPASS is ON, OP can be changed regardless of the state of the Override
and Permissive Interlocks.
• When BYPASS is reset to OFF, existing Override Interlocks (if any) take effect
immediately.
• BYPASS does not affect the Safety Override Interlock (SI).
• When BYPPERM is OFF, BYPASS is OFF by default in case of Solenoid and is
read-only.
Alarms
An available set of PV state alarms may be configured to represent disagreements
between the Commanded Output State (OP) and the Current Active State (PV). A Safety
Override Interlock alarm is also available. Each of these alarms possesses all the standard
attributes of system alarms.
• Command Fail alarm - It is generated when the Current Active State (PV) fails to
change from an original value to any other value within a configurable time interval
after the OP parameter is commanded.
− You can configure the feedback time (CMDFALALM.TM[0..1]) for each state
through the Alarms tab on Solenoid Valve block configuration form. The value of
OP just commanded determines which CMDFALALM.TM[0..1] is active. The
CMDFALALM.TM[0..1] setting range is 0 to 1000 seconds. Setting a given
CMDFALALM.TM[0..1] parameter to 0 disables the alarm for the associated
state[0..1]. The alarm function is automatically disabled, if there are no inputs or
no outputs. CMDFALALM.TM[0..1] changes from or to 0, require CM InActive
or CEE Idle.
ATTENTION
• The CMDFALALM.TM[0..1] cannot be configured if
CMDDISALM.TM[0..1] has not been configured.
• Bad PV alarm - It is generated whenever the Current Active State (PV) is detected to
be a NULL (or bad) state.
• Command Disagree alarm - It is generated when the Commanded Output State (OP)
is changed and the actual input state (PV) does not change accordingly within a
specified feedback time.
R110 Experion LX Control Builder Components Theory 1151
February 2014 Honeywell
19. Power Generation Functions
19.7. SOLENOID (Solenoid Valve Drive Control) Block
Seal-in option
The seal-in option is used for clearing output commands when the process feedback state
(PV) cannot follow the commanded output state (OP) as detected by the Command
Disagree or Uncommanded Change alarms. If enabled, when the condition is detected,
field output destinations are set to the Safe Output State (SafeOP), but OP is not altered.
You can observe OPFINAL to determine what state was actually commanded to the
output destinations. The OPFINAL is displayed in reverse video while monitoring
Control Builder if it differs from OP. OPFINAL is set equal to OP on the next store to
OP, which clears the "seal" condition.
• You can configure the seal-in option through the SEALOPT (Enable/Disable)
parameter.
ATTENTION
To configure Seal-in option, ensure that the CM is inactive and
CMDDISALM.TM [0..1] is configured.
OP initialization option
The parameter INITOPOPT is used to configure OP Initialization option. It is an
enumeration of NORMALOPT, SAFEOPOPT or HOLDOPOPT. The default value for
Solenoid is NORMALOPT.
• INITOPOPT = NORMALOPT, perform normal initialization as described in the
ensuing section on Initialization Manual Condition with Safety Override Interlock,
Override Interlocks, LocalMan, and OP Initialization.
• INITOPOPT = SAFEOPOPT, OP is set to SAFEOP.
• INITOPOPT = HOLDOPOPT, initialization is not performed. OP remains at the last
value.
Maintenance statistics
The Solenoid Valve block collects a set of Maintenance Statistics which are classified
into three categories which are enabled by their respective enable options such as,
TRKSIOVRD, TRKNUMTRANS.
The maintenance statistics collected include:
• NUMTRANS[0,1] - Number of transitions of PV to each state. This can be enabled
provided TRKNUMTRANS is enabled.
• NUMTRANS - Number of all PV transitions. This can be enabled provided
TRKNUMTRANS is enabled.
• NUMSIOVRD - accumulated number of safety interlock trips, which results in OP
changing state (after the last statistics reset). This can be enabled provided
TRKSIOVRD is enabled.
The statistics are accumulated after the most recent reset. The operator can reset the
statistics of Solenoid Valve Control block anytime irrespective of redtagging,
Output requests
Whenever an external FB attempts to change the commanded state OP, the Solenoid
Valve block uses the OP request mechanism. The OP request (OPREQ/GOPREQ)
differs from direct access an operator uses to the commanded state OP. The OPREQ is a
string in the same manner as OP, and GOPREQ is the enumeration GENSTAT_ENM,
which is the same as GOP.
There is no direct access to OPREQ when MODEATTR is PROGRAM. It can be
changed as part of a control request from an SCM. When MODEATTR is OPERATOR,
an operator can change OPREQ, but this does not block a control request. This means a
program store to OPREQ cannot be rejected, and no error is returned. The FB retains the
stored value until it is overwritten, except in certain non-stored cases when the level 1
drivers are active. OPREQ acts like a repeated attempt to store to OP. The OPREQ is
always active unless it is NULL. This means the OPREQ continues to attempt stores
even if attributes, such as interlocks, become active and block changes to OP. Thus, once
the attributes blocking change to OP have reset OPREQ stores the commanded state to
OP.
Output command
The block provides a Boolean command capability through an array of Boolean inputs
(AUTO OPEN/CLOSE, UCP OPEN/CLOSE, LOCAL OPEN/CLOSE, SEQ
OPEN/CLOSE).
• When the mode attribute (MODEATTR) is Program and the SCM option
(SCMOPT) is None, you can use an output from a Logic type block to set the
requested output state (OPREQ) through the given Boolean input command (AUTO
OPEN/CLOSE, SEQ OPEN/CLOSE).
• Similarly, you can command the Solenoid Valve block through LOCAL
OPEN/CLOSE, UCP OPEN/CLOSE provided the following conditions are met:
− Both LOCAL and UCP commands ignore MODEATTR.
− LOCAL OPEN/CLOSE depends on the LOCAL SWITCH which should be ON.
− UCP CLOSE ignores the LOCAL/REMOTE SWITCH condition provided
SAFEOP is configured to CLOSE.
− UCP OPEN ignores the LOCAL/REMOTE SWITCH condition provided
SAFEOP is configured to OPEN.
• Similarly, you can command the Solenoid Valve block through Console
OPEN/CLOSE provided the following conditions are met:
− MODEATTR should be OPER.
− Console CLOSE ignores the LOCAL/REMOTE SWITCH condition provided
SAFEOP is configured to CLOSE.
− Console OPEN ignores the LOCAL/REMOTE SWITCH condition provided
SAFEOP is configured to OPEN.
If an SCM commands the Solenoid Valve block by sending a Null type of request to
GOP and there are active OPCMDs such as AUTO OPEN/CLOSE, UCP OPEN/CLOSE,
LOCAL OPEN/CLOSE. (this is possible when SCMOPT = NONE, MODEATTR =
Program, and SCM OPTYPE = NULL), the OPCMD has higher priority. An SCM store
to GOP is rejected; if any of the OPCMD elements are active (one or more OPCMD
members are ON). An SCM can gain control, only when all OPCMD elements are OFF.
The Solenoid Valve can also be commanded by SCM through SEQ OPEN/CLOSE when
SCM option is FIXED and MODEATTR is PROGRAM.
ATTENTION
• UCP OPEN/CLOSE, SEQ OPEN/CLOSE, LOCAL OPEN/CLOSE work
on OFF to ON transitions. So, there is no priority for them.
SOLENOID parameters
REFERENCE
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the Drive Control block.
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that appear on the
Parameters face of the function block in the Project tab in Control
Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Template Defining Lets you view and define parameters for associated
templates.
Function
• The Valve/Damper block has four inputs, three states, and two outputs.
• Allows PV source selection (PVSRC) as OPEN, CLOSE, INBET or faulty (BAD)
state.
• Provides latched and pulsed outputs.
• Provides Initialization, Local Manual and Redtagging.
• Provides BADPV, Command Disagree, SafetyInterlock, Uncommanded Change and
Command Fail, Override Interlock alarms.
• Provides PV change of state event.
• Provides Permissive and Override Interlocks for each state.
• Provides interlock trip alarms.
• Provides a seal-in option.
• Provides a Safety Interlock that enforces the defined safe state.
• Predefines Safe State as NoCommand.
• Provides generic state parameters defined as consistent data types.
• Initialization has OPFINAL based configuration.
• Provides Boolean command option.
• Provides batch level one driver option.
• Provides OFF NORMAL alarm associated with requested OP.
• Provides alarm when Torque switch Open or Torque switch Close are detected.
• Withdraws command when feedback is achieved to command initiate.
You can red tag a VALVEDAMPER block. Refer to About Red Tagging section for
more information.
digital output. The output of the block can be connected to DO or further connected to
subsequent logic, if necessary.
Configuration examples
Scenario 1:
The following scenario depicts the implementation of a Valve/Damper block in a control
strategy with Auto Open/Close, Remote Switch, Local Open/Close logic and MCC
inputs.
Callout Description
1 Use the PVFL parameter connection to carry MCC inputs from the
DICHANNEL block to the Valve/Damper block.
In the Valve/Damper block, the MCC inputs (LTO, LTC, TSO, TSC)
provide the feedback if the valve is open or close.
Use the PV parameter connection to carry MCC trip input (MTT) from the
DICHANNEL block to the Valve/Damper block.
2 Use the PV parameter connection to carry Remote switch input from the
DI channel block to the Valve/Damper block.
Callout Description
ON, the local switch is OFF and MODEATTR is in PROGRAM.
3 Use the PV parameter connection to carry Local switch input from the DI
channel block to the Valve/Damper block.
4 You can command the device through the output (OP) directly, provided
the MODEATTR is Operator, Remote switch is ON and the local switch is
OFF.
Scenario 2:
The following scenario depicts the implementation of a Valve/Damper block in a control
strategy with safety, override and permissive inputs and MCC inputs.
Callout Description
1 Use the PVFL parameter connection to carry MCC inputs from the
DICHANNEL block to the Valve/Damper block.
In the Valve/Damper block, the MCC inputs (LTO, LTC, TSO, TSC)
provide the feedback if the valve is open or close.
Use the PV parameter connection to carry MCC trip input (MTT) from the
DICHANNEL block to the Valve/Damper block.
3 You can command the device through the output (OP) directly, provided
the MODEATTR is Operator, Remote switch is ON and the local switch is
Callout Description
OFF.
Scenario 3:
The following scenario depicts the implementation of a Valve/Damper block in a control
strategy with UCP Open/Close logic and MCC inputs.
Callout Description
1 Use the PVFL parameter connection to carry MCC inputs from the
DICHANNEL block to the Valve/Damper block.
In the Valve/Damper block, the MCC inputs (LTO, LTC, TSO, TSC)
provide the feedback if the valve is open or close.
Use the PV parameter connection to carry MCC trip input (MTT) from the
DICHANNEL block to the Valve/Damper block.
Callout Description
3 You can command the device through the output (OP) directly, provided
the MODEATTR is Operator, Remote switch is ON and the local switch is
OFF.
Inputs
The inputs which are physically wired to the system and brought to the block through
channel blocks are termed as hard inputs. The soft inputs normally operate from displays
or other function blocks.
• Hard Inputs: MTT, LTO, LTC, TSO, TSC, WTS, LOCALSWITCH,
REMOTESWITCH, LOCALOPEN, LOCALCLOSE, UCPREL, UCPOPEN,
UCPCLOSE, SEQOPEN, SEQCLOSE, SEQNOCOMMAND AUTOOPEN,
AUTOCLOSE, AUTONOCOMMAND
• Soft Inputs: POCLOSECONNECTED, POOPENCONNECTED,
OPENPULSEWIDTH, CLOSEPULSEWIDTH, TRKNUMTRANS,
TRKNUMSIOVR, TRKOPENFEEDBKTIME, TRKCLOSEFEEDBKTIME,
RESETFL, PO [0..2], OI[0..2], TSENABLED, TSFORPROT.
Outputs
The output parameters are: POOPEN, POCLOSE, CMDOPEN, CMDCLOSE, OP, PV,
NUMTRANS[0,1,2], NUMALLTRANS, NUMSIOVRD, OPENFEEDBKTIME,
CLOSEFEEDBKTIME
Limit Switches
The following are some of the behavior of Limit switches:
• The LTO switch feedback is used to withdraw the OPEN command irrespective of
TSEnabled.
• An OPEN command cannot be issued if LTO is already ON.
• If TSO feedback is received before the LTO feedback, it is an indication of an
abnormality and a TSO alarm is raised and OPEN command is withdrawn provided
TSForProt is ON.
Error handling
• LOCALOPEN/LOCALCLOSE can be initiated only when access lock is 'Other FB',
Operator mode and Local/Remote selection switch is LOCAL.
• AUTOOPEN/AUTOCLOSE can be initiated only when access lock in not 'Other
FB' and local/remote switch is in REMOTE.
• SEQOPEN/SEQCLOSE can be initiated only when the mode is in PROGRAM.
• UCPOPEN/UCPCLOSE can be initiated only when access lock is not Other FB and
UCP release is available.
• OPENFEEDBKTIME, CLOSEFEEDBKTIME does not accept a value less than 0
or more than 96000.
• TRKOPENFEEDBKTIME, TRKCLOSEFEEDBKTIME requires AppDev Access
lock.
• For Valve/Damper, both OFF status are valid state (In-between). Both ON is flagged
and output is not generated.
States
A "state" represents the current condition of a device. In a Valve/Damper block, OPEN,
CLOSE, and INBETWEEN represent the three states, where the failsafe state is
predefined as NOCOMMAND. Each input combination is assigned to a specific state
and this mapping is fixed. The PV parameter represents the current state of the
Valve/Damper.
The output states are mapped to specific combinations of digital outputs. These outputs
command the field device to the associated state, such as OPEN, CLOSE, or
NOCOMMAND. The OP parameter represents the commanded state or the device state
commanded by an operator. The block transmits OP, monitors PV, and produces alarms
based on the state assignment configurations, which represent whether or not the process
feedback has achieved the state commanded in OP.
STATETEXT[4] NOCOMMAND S0
STATETEXT[5] OPEN S1
STATETEXT[6] CLOSE S2
LocalOpen LOCAL
UCPOpen REMOTE
LocalClose LOCAL
UCPClose REMOTE
Ignore
Check
Local manual
The local manual (LOCALMAN) parameter is an input flag to support an interface to a
local HAND/OFF/AUTO (also called HAND/OFF/REMOTE) switch on the field
device. The AUTO position of the switch can be hard wired to a digital input. The state
of the digital input can then be configured to store to the LOCALMAN pin added to the
Valve/Damper block through a DICHANNEL connection. The control system may not
have control over the field device when the HAND/OFF/AUTO switch is not in the
AUTO position.
The LOCALMAN parameter provides feedback about the switch position. When the
LOCALMAN parameter is ON, the OP state tracks the PV state, if it is in a settable state.
If PV is in a non-settable state, OP is set to SAFEOP. This ensures that the last
commanded state agrees with the current value of the feedback state, when the
LOCALMAN is turned OFF. The OP (GOP) cannot be commanded directly when
LOCALMAN is ON.
You cannot access LOCALMAN, if the Valve/Damper block does not have any inputs or
outputs connected. PV is illegal for no inputs and OP is illegal for no outputs, and
therefore LOCALMAN is of no consequence in such a condition.
When LOCALMAN is ON, the OP and OPFINAL follow PV (if it is in a settable state).
The digital outputs CmdOpen/CmdClose will follow OPFINAL.
ATTENTION
LOCALMAN can be used for the above purpose, when the Valve/Damper is
Commanded by Local, Controlled directly from MCC and not through DCS.
Permissive interlocks
PI[0..2]are Permissive Interlocks which are inputs that can be connected to an external
function block to determine whether the operator and/or user program are allowed to
change the commanded output (OP) of the Valve/Damper block to a specific state.
Permissive Interlocks themselves never cause OP to change.
• To change the state of OP, the corresponding Permissive Interlock parameter should
be set to ON.
• The Permissive Interlocks of all states of the Valve/Damper are ON by default,
thereby allowing permission to all the states; they must be individually set to OFF to
prevent access to the corresponding OP state.
Override Interlocks
OI[0..2] are Override Interlocks which, when active, force the commanded output (OP)
to its respective state regardless of the condition of the Permissive Interlocks. OP cannot
be commanded to a different state when an Override Interlock is active.
• Override Interlocks can be connected to other block outputs or can be directly set by
an operator if MODEATTR = OPERATOR and the block is inactive.
• Override Interlock parameters, by default are OFF, thereby disabling the Override
Interlocks. They must be set to ON to force OP to a specific state. If the Override
Interlock forces OP to go to a momentary state, it stays in that state as long as the
interlock remains ON and then switches back to the original state when the Override
Interlock is reset to OFF.
• SI has a higher priority than any of the Override Interlocks; the priorities of the
Override Interlocks are determined by the state assigned to a predefined SAFEOP
that is NOCOMMAND and the priority is SI, OI[0], OI[1], OI[2].
Alarms
An available set of PV state alarms can be configured to represent disagreements
between the commanded output state (OP) and the current active state (PV). A Safety
Override Interlock alarm is also available. Each of these alarms possesses all the standard
attributes of system alarms.
• Command Disagree alarm - It is generated when the commanded output state (OP)
changes and the actual input state (PV) does not change accordingly within a
specified feedback time.
− You can configure the feedback time (CMDDISALM.TM[1..2) for each state
from the Alarms tab on the Valve/Damper block configuration form. The value of
OP just commanded determines which CMDDISALM.TM[1..2] is active. The
CMDDISALM.TM[1..2] setting range is 0 to 1000 seconds. Setting a given
CMDDISALM.TM[1..2] parameter to 0 disables the alarm for the associated
state[1..2]. The alarm function is automatically disabled in the absence of
inputs/outputs. CMDDISALM.TM[1..2] changes from or to 0, provided the CM
is InActive or CEE Idle.
− This alarm condition returns to NORMAL when the input PV state becomes equal
to the OP state.
• Command Fail alarm - generated when the current active state (PV) fails to change
from an original value to any other value within a configurable time interval after
the OP parameter is commanded.
− The feedback time (CMDFALALM.TM[1..2) for each state can be configured
through the Alarms tab on the Valve/Damper block configuration form. The value
of OP just commanded determines which CMDFALALM.TM[1..2] is active. The
CMDFALALM.TM[1..2] setting range is 0 to 1000 seconds. Setting a given
CMDFALALM.TM[1..2] parameter to 0 disables the alarm for the associated
state[1..2]. The alarm function is automatically disabled in the absence of
inputs/outputs. CMDDISALM.TM[1..2] changes from or to 0, provided the CM
is InActive or CEE Idle.
ATTENTION
• The CMDFALALM.TM[1..2] cannot be configured if
CMDDISALM.TM[1..2] has not been configured.
• Bad PV alarm - This alarm is generated whenever the current active state (PV) is
detected as NULL (or bad) state.
• Uncommanded Change alarm - This alarm is generated if the actual input state (PV)
changes but has not been commanded to change (unless it is a bad PV). This alarm is
configured whenever the Command Disagree alarm is configured.
− This alarm condition returns to NORMAL when the input PV state becomes equal
to the commanded OP state.
• Off Normal alarm - This alarm is generated whenever PV does not match OPREQ, if
OPREQ is not Null.
• Override Interlock alarms - When the alarm is enabled and the active override
interlock causes an OP state change, an alarm is generated.
• Safety Override Interlock alarm - When the alarm is enabled and the active safety
interlock causes an OP state change, an alarm is generated.
If a real-time conflict exists between a Safety Override Interlock Alarm configured to
alarm and a PV alarm condition, such as Uncommanded Change Alarm, interlock action
(setting of the output state and related alarm notification) always occurs regardless of
effects of the other alarm.
Seal-in option
The seal-in option is used for clearing output commands when the process feedback state
(PV) cannot follow the commanded output state (OP) as detected by the Command
Disagree or Uncommanded Change alarms. If enabled, when the condition is detected,
field output destinations are set to the Safe Output State (NOCOMMAND), but OP is not
altered. You can observe OPFINAL to determine what state was actually commanded to
the output destinations. The OPFINAL is displayed in reverse video while monitoring
Control Builder if it differs from OP. OPFINAL is set equal to OP on the next store to
OP, which clears the "seal" condition.
• The seal-in option is configured through the SEALOPT (Enable/Disable) parameter.
ATTENTION
To configure Seal-in option, ensure that CM is inactive and CMDDISALM.TM
[1..2] is configured.
OP initialization option
The parameter INITOPOPT is used to configure OP Initialization option. It is an
enumeration of NORMALOPT, SAFEOPOPT or HOLDOPOPT. The default value for
Valve/Damper is NORMALOPT.
• INITOPOPT = NORMALOPT, perform normal initialization as described in the
ensuing section on Initialization Manual Condition with Safety Override Interlock,
Override Interlocks, LocalMan, and OP Initialization.
1190 Experion LX Control Builder Components Theory R110
Honeywell February 2014
19. Power Generation Functions
19.8. VALVEDAMPER (Valve/Damper Drive Control) Block
Maintenance statistics
The Valve/Damper block collects a set of maintenance statistics classified into three
categories which are enabled by their respective enable options such as, TRKSIOVRD,
TRKNUMTRANS, TRKOPENFEEDBKTIME, TRKCLOSEFEEDBKTIME.
The maintenance statistics collected include:
• NUMTRANS[0..2] - Number of transitions of PV to each state. This can be enabled
provided TRKNUMTRANS is enabled.
• NUMALLTRANS - Number of all PV transitions. This can be enabled provided
TRKNUMTRANS is enabled.
• NUMSIOVRD - accumulated number of safety interlock trips, which results in OP
changing state (after the last statistics reset). This can be enabled provided
TRKSIOVRD is enabled.
• OPENFEEDBKTIME - Amount of time taken in seconds to receive the OPEN
feedback after the valve is commanded to OPEN state. This can be enabled provided
TRKOPENFEEDBKTIME is enabled.
• CLOSEFEEDBKTIME- Amount of time taken in seconds to receive the CLOSE
feedback after the valve is commanded to CLOSE state. This can be enabled
provided TRKCLOSEFEEDBKTIME is enabled.
The statistics are accumulated after the most recent reset. The operator can reset the
statistics of Valve/Damper block anytime irrespective of Redtagging, unlike the
DEVCTL block.
Output requests
Whenever an external FB attempts to change the commanded state OP, the
Valve/Damper block uses the OP request mechanism. The OP request
(OPREQ/GOPREQ) differs from direct access an operator uses to the commanded state
OP. The OPREQ is a string in the same manner as OP, and GOPREQ is the enumeration
GENSTAT_ENM, which is the same as GOP.
There is no direct access to OPREQ when MODEATTR is PROGRAM. It can be
changed as part of a control request from an SCM. When MODEATTR is OPERATOR,
an operator can change OPREQ, but this does not block a control request. This means a
program store to OPREQ cannot be rejected, and no error is returned. The FB retains the
stored value until it is overwritten, except in certain non-stored cases when the level 1
drivers are active. OPREQ acts like a repeated attempt to store to OP. The OPREQ is
always active unless it is Null. This means the OPREQ continues to attempt stores even
if attributes, such as interlocks, become active and block changes to OP. Thus, once the
attributes blocking change to OP have reset OPREQ stores the commanded state to OP.
Output command
The block provides a Boolean command capability through an array of Boolean inputs
(AUTO OPEN/CLOSE, AUTONOCMD, UCP OPEN/CLOSE, LOCAL OPEN/CLOSE,
SEQ OPEN/CLOSE, SEQNOCMD).
• When the mode attribute (MODEATTR) is Program and the SCM option
(SCMOPT) is None, you can use an output from a Logic type block to set the
requested output state (OPREQ) through the given Boolean input command (AUTO
OPEN/CLOSE, AUTONOCMD) provided REMOTE SWITCH is ON.
• Similarly, you can command the Valve/Damper block through LOCAL
OPEN/CLOSE, UCP OPEN/CLOSE provided the following conditions are met:
− Both LOCAL and UCP commands ignore MODEATTR.
− LOCAL OPEN/CLOSE depends on the LOCAL SWITCH which should be ON.
− UCP CLOSE/OPEN depends on REMOTE SWITCH which should be ON.
• Similarly, you can command the Valve/Damper block through Console
OPEN/CLOSE provided the following conditions are met:
− MODEATTR should be OPER.
− Console OPEN/CLOSE depends on REMOTE SWITCH which should be ON.
If an SCM commands the Valve/Damper block by sending a Null type of request to GOP
and there are active OPCMDs such as AUTO OPEN/CLOSE, UCP OPEN/CLOSE,
LOCAL OPEN/CLOSE. (this is possible when SCMOPT = NONE, MODEATTR =
PROGRAM, and SCM OPTYPE = NULL), the OPCMD has higher priority. An SCM
store to GOP is rejected; if any of the OPCMD elements are active (one or more
OPCMD members are ON). An SCM can gain control, only when all OPCMD elements
are OFF.
The Valve/Damper can also be commanded by SCM through SEQ OPEN/CLOSE when
SCM option is FIXED and MODEATTR is PROGRAM.
ATTENTION
• UCP OPEN/CLOSE, SEQ OPEN/CLOSE, LOCAL OPEN/CLOSE work
on OFF to ON transitions. So, there is priority for them.
VALVEDAMPERparameters
REFERENCE
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the Drive Control block.
ATTENTION
The ALMWINDOW, ANNPANEL, DIGACQ, and FIRSTOUT block can only be
used with C300 Controllers.
Provides first out logic FIRSTOUT (First Used to define configurable inputs to
identification for digital Out Detection) be scanned for first out function with
input transition Block alarm capability.
Store a single two-state FLAG Block Used to define two separate states
value (for example, Running/Stopped,
Push the value of various PUSH Block Used to push the value of different
data types. data types to the output destination.
Store multiple text strings TEXTARRAY Used to store up to 120 text strings for
Block use in a control strategy.
Time process events or TIMER Block Used to keep track of elapsed time
create known delays. during a process and provides
indication when elapsed time reaches
predefined limit.
Each Alarm Window block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that tab.
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that appear on the
Parameters face of the function block in the Project tab in Control
Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Template Defining Lets you view and define parameters for associated
templates.
Function
The Alarm Window function block accepts Boolean inputs (1 to 16) and performs the
configured sequence. It provides one alarm output (ALMOUT) and group status output
(FLSHSTAT).
Inputs
The ALMIN[] input pins of the block receive Boolean values from the alarm inputs.
The NUMIN input parameter decides the number of alarm inputs that can be connected
to the block.
Outputs
The FLSHSTAT output is given to the ANNWINDOW block. This pin receives the
RESET and ACK status of the ANNPANEL block through a hidden connection.
Alarms
Ringback sequence
The following is an illustration of the Alarm window state machine:
Following is the state transition table of the Alarm window state machine
Following is the state transition table of the Alarm window state machine Manual Reset:
LampState Events
Following is the state transition table of the Alarm window state machine Automatic
Reset:
LampState Events
{LampState =
LampSteady}
Error handling
• The block displays an error when an invalid index or access lock is received during
loading of the block.
• If the user tries to store a value more than 16 for the NUMIN parameter, an error
"Invalid Value" is displayed.
• The parameter NUMIN cannot be changed from the Monitoring side.
• Access level check is done at the time of loading the block as well as during a
parameter write.
• An error is generated if we try to write the block description after the alarm window
is connected to an alarm panel.
ALMWINDOW parameters
REFERENCE
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the Alarm Annunciator-Alarm Window block.
Each Annunciator Panel block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that tab.
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that appear on the
Parameters face of the function block in the Project tab in Control
Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Template Defining Lets you view and define parameters for associated
templates.
Function
This function block accepts FLSHSTAT from the Alarm Window function block and
provides Lamp output for the annunciation windows with synchronized lamp flash
sequence and the hooter annunciation. This block accepts the TEST input, which forces
the entire Lamp out to glow steadily. This block establishes hidden connection with the
Alarm window function block to pass the RESET and ACK parameter values.
Configuration Example
ATTENTION
Ensure that the Control Module containing the ANNPANEL block is
configured for an Execution Period of 100 milliseconds or faster. The flashing
rate of the annunciator panel only works as expected when the block is
placed in a 100 millisecond or faster CM.
The ALMWINDOW blocks are connected to the ANNPANEL block as shown in the
following block diagram.
The ALMWINDOW blocks receive alarm inputs from other logics. The ALMWINDOW
block's FLSHSTAT parameter is connected to the ANNPANEL block's FLSHSTAT
inputs. The ACK and RESET signals are propagated by the ANNPANEL to all the
ALMWINDOW blocks through hidden connections.
The LAMPOUT and OUTHORN parameters of the ANNPANEL are connected to DO
channels.
Inputs
The FLSHSTAT[] takes its input from the AlmWindow block's FLSHSTAT[] outputs.
Additionally, a hidden connection is established through this pin to transfer the RESET
and ACK status to the ALMWINDOW block.
The ACK input receives the operator alarm acknowledgement. This pin usually receives
the input from a digital input channel block.
The RESET input receives the operator alarm reset. This pin usually receives the input
from a digital input channel block.
The LAMPTEST input receives the operator lam test signal. This pin usually receives the
input from a digital input channel block.
ATTENTION
If there are more than 32 inputs, two Alarm panel blocks can be combined to
achieve the same functionality.
Outputs
The LAMPOUT output is the output to the DO channel.
The OUTHORN1 and OUTHORN2 outputs are the hooter outputs which are connected
to DO channels.
Error Handling
• The block displays an error when an invalid index or access lock is received during
loading of the block.
• If the user tries to store a value more than 32 for the NUMANNUNWIN parameter,
than an error "Invalid Value" appears.
• Access level check is done at the time of loading the block as well as during a
parameter write.
ANNPANEL parameters
REFERENCE
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the Alarm Annunciator - Alarm Panel block.
The Digital Acquisition block supports the following user configurable attributes. The
following table lists the name of the "Tab" in the parameter configuration form with a
brief description of the attributes associated with that tab.
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that appear on the
Parameters face of the function block in the Project tab in Control
Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Template Defining Lets you view and define parameters for associated
templates.
Function
• Enables better utilization of processor computing and memory resources.
• Supports alarm generation when the current process variable state differs from the
configured NORMAL state.
Block configuration
• By default, the PVSRCOPT parameter is set to ONLYAUTO and PVSOURCE is set
to AUTO.
• The PVSOURCE parameter is disabled when PVSRCOPT is set to 0
(ONLYAUTO). It can be changed if PVSRCOPT is set to 1 (ALL).
Predecessor block
• A predecessor block is not required if PVSOURCE is set to MAN.
• If PVSOURCE is set to SUB, any block with a digital output can be a predecessor.
Configuration Scenario
PVFL can be exposed as an input pin. This enables the Digital acquisition block to use a
PVFL parameter connection to carry inputs from another FB when PVSOURCE is SUB
as in the following illustration:
Inputs
• IN - Input parameter
Outputs
• PV - Current selected input based on the PVSOURCE selection
• PVFL - Actual State Flag
• INVPVFL - Inverted State Flag
• Depending on the value of PVSRCOPT and PVSOURCE, the output is set to one of
the following input values:
PVSRCOPT PVSOURCE PV
• The PVFL and PV parameters always match. When the PVSOURCE parameter is
changed to MAN, the value of PVFL/PV does not change and retains the last value.
The value can be changed as needed.
• If the input to the DigAcq block goes bad and PVSOURCE is AUTO, a BAD PV
alarm is generated in the Dig Acq block and the same status is communicated to
subsequent blocks since PVSTS is an enumeration.
Error handling
• The Digital Acquisition block reports errors when a parameter is accessed with a
privilege lower than the expected access level.
• The Digital Acquisition block provides PVSTATUS based on the PVOURCE.
If PVSOUCE is
− Manual - kManValSts.
− SCM - kUncertainValSts.
− Auto - kNormalValSts.
• If the CM is inactive or CEE is IDLE, the block holds the last legal value.
• If there is more than one block in a CM, the number of blocks per display depends
on the configuration on the first block. However, you can have a maximum of six
blocks per display. If more than six blocks per display is configured, the details of
the first six blocks are displayed along with an error message.
DIGACQ parameters
REFERENCE
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the Digital Acquisition block.
The EXECTIMER block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that tab.
Template Defining Lets you view and define parameters for associated templates.
Function
EXECTIMER is used by creating two instances. One instance marks the beginning of a
time interval, that is, the “BEGTIME” instance. The other instance marks the end of a
time interval, that is, the “ENDTIME” instance. The output parameter
BEGTIME.TIMEOUT is then connected to the input parameter ENDTIME.TIMEIN.
With this configuration, any module, block, group of modules, or group of blocks which
execute between the two EXECTIMER instances is included in the time measurement.
Block ordering must be deliberately controlled when using EXECTIMER. When
measuring execution time of basic blocks, the BEGTIME instance and ENDTIME
instance are placed within the same CM. The ORDERINCM configuration of these two
instances is set up to include or exclude from the measurement other blocks within the
same CM.
When measuring execution time of modules, the BEGTIME instance and ENDTIME
instance are placed within different CMs, that is, “CM_BEGTIME” and
“CM_ENDTIME”. The ORDERINCEE configuration of these two CM instances is
setup to include or exclude from the measurement other CMs within the same CEE.
EXECTIMER is supported on the following platforms.
• C300
• SIMC300
Input
The input parameter is ENDTIME.TIMEIN. There is no input for the BEGTIME
instance that serves to mark the beginning of a time interval.
Output
The output parameter is BEGTIME.TIMEOUT. There is no output for the ENDTIME
instance that serves to mark the end of a time interval.
EXECTIMER Parameters
REFERENCE – INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the EXECTIMER function block.
EXECTIMER Example
EXECTIMER block can be used in any module, block, group of modules, or group of
blocks.
Block ordering must be deliberately controlled when using EXECTIMER. When
measuring execution time of basic blocks, the BEGTIME instance and ENDTIME
instance are placed within the same CM. The ORDERINCM configuration of these two
instances is set up to include or exclude from the measurement, other blocks within the
same CM as displayed in the following figure.
In case of a group of modules, the BEGTIME instance and ENDTIME instance are
placed in the CMs as displayed in the following figure. The ODERINCEE value for each
CM is selected to cause execution in the order listed. Measurements can include any
number of CMs or SCMs.
Limitations
As with any simple time measurement, the readings given by EXECTIMER can be
skewed by intervening interrupts or higher priority tasks. This effect is often not
significant. If it is significant, reduce the effect by using the REJFACTOR parameter.
When used in a C300, EXECTIMER works well but has a limitation similar to that of
other measurements techniques, such as CPUCYCLEAVG[40]. EXECTIMER only
covers the explicit block execution time. Other CPU effects which may scale with block
properties, such as CPU consumed by redundancy communications, is not included in
the measurement. Load effects which accumulate outside the execution interval for a
block can only be measured by using large configurations and differencing techniques
based on CPUFREEAVG.
Exactly two instances of EXECTIMER are required for each timing measurement to be
made. That is, it is not possible to place an EXECTIMER instance in the middle of a
longer interval of interest and have it serve as both; the ENDTIME instance for an
EXECTIMER which precedes it; and the BEGTIME instance for an EXECTIMER
instance which follows it.
The timing measurements that EXECTIMER can perform are confined to a single CEE.
While it can be used to measure the execution timing of blocks that might be involved in
peer communication, OPC communication, or IO communication, EXECTIMER cannot
be used for any of the following purposes.
• Measuring timing effects between EEs.
• Measuring timing effects between an EE and IO.
• Measuring timing effects between an EE and an OPC server.
Any attempt to connect the TIMEOUT and TIMEIN parameters of EXECTIMER
instances which are not assigned to the same CEE yields meaningless data and hence
should not be attempted.
The First Out Detection block supports the following user configurable attributes. The
following table lists the given name of the "Tab" in the parameter configuration form and
then briefly describes the attributes associated with that tab.
Transition Monitoring Lets you configure the transition monitoring status of the
block.
Block Pins Lets you select the available parameters that you want to
expose as input/output pins on the function block graphic in
Control Builder.
Configuration Lets you select the available parameters that appear on the
Parameters face of the function block in the Project tab in Control
Builder.
Monitoring Parameters Lets you select the available parameters that you want to
appear on the face of the function block in the Monitoring
tab in Control Builder.
Template Defining Lets you view and define parameters for associated
templates.
Function
• Provides the First Out function. A First Out logic enables the identification of the
digital input signal that was first to transition from NORMAL state, among a set of
digital inputs connected to the block. The set of digital inputs connected to the block
is scanned in ascending order and once a transition (from NORMAL state) is
detected, First Out is flagged and further scanning is stopped for the rest of the
cycles until a Reset.
• Provides an output which is an OR of all NORMAL state inputs and it goes high if
any input goes to ABNORMAL state. It resets when all inputs come back to
NORMAL state.
• Provides an alarm once a First Out is detected. If a single input transitions from
NORMAL state, the input that caused the alarm is identified and its description
(INDESC[*]) is used for alarm. In case of multiple input transitions in a single
cycle, the alarm description is as defined in the MULTIINPTDESC (Multiple Input
description field).
• Enables you to reset the First Out flag using a raising edge pulse input only when all
inputs come back to NORMAL state.
Block Pins
The input pins are located at the top or the left, and output pins at the bottom or the right.
For ease of use, the input pins are exposed at the left and output pins are exposed at the
right of the block. Any parameter can be exposed as a block pin, input, output, or both,
as appropriate.
By default, eight inputs are exposed. However, more inputs can be exposed during
configuration. To perform this, the following I/O pin connections are required:
• IN[1] - IN[8] Inputs
• RESET Input
• FIRSTOUTACTED Output
Therefore, these parameters are exposed through block pins in the default state. The
following parameters are exposed in the FB panel in monitoring view.
• NUMDINPUTS
• INPUTACTED[1] - INPUTACTED[8]
• FIRSTOUTINPUT
1228 Experion LX Control Builder Components Theory R110
Honeywell February 2014
20. Utility Functions
20.6. FIRSTOUT (First Out Detection) Block
NUMDINPUTS
FIRSTOUT FB uses NUMDINPTS parameter which obtains the value from the Main
configuration form. The range of NUMDINPTS is 1-24. If user configured
NUMDINPTS data in the Main configuration form is invalid, an error message is
displayed during configuration and download.
Inputs
The First Out block accepts a set of related digital input and detects the input that first
transitioned from the configured NORMAL state. Usually, this block is associated with
critical equipment. Usually, equipment's or a drive's protection interlocks and stop
command are connected as input to the First-out block. When an input signal transitions
from NORMAL state, the output flag of the First Out logic is raised. In addition, the
input responsible for the First Out flag is recorded. The recording is locked until a reset
is applied to the block.
OI[*], PI[*], OPCMD[*], and SI are the recommended signals for a DEVCTL block.
The output signals are used to indicate the conditions responsible for a drive to trip,
enabling the operator to analyze the exact reason for the trip to take corrective action.
Execution
• The number of inputs can be restricted during configuration. By default, eight inputs
are allowed.
• After download and activation, the block initializes current inputs in the current
cycle and history inputs in the last cycle to OFF, and reads all inputs in an ascending
order during one life cycle. If a First Out input is not detected, the block processes
the inputs by using the following procedure.
− If there is a change from OFF to ON (the history input in the last cycle is OFF and
current input in this cycle is ON), the block raises the First Out flag and identifies
the input that caused the output flag of the First Out Logic to be raised. The block
also provides an alarm. The status is held until a reset command is issued to the
block to reset all inputs and output flag and alarm. The input scan is limited to the
number of configured inputs.
− If any of the inputs transition from the last cycle, the INPUTACTED is turned
ON.
− The history inputs of the last cycle (equal to the values of current inputs in this
cycle) are updated.
− In the absence of a change, the control exits.
− Transition monitoring (TRANSMON) can be enabled by a user with Engineer
access. If FIRSTOUT has already acted, TRANSMON cannot be enabled.
However, if TRANSMON is enabled before FIRSTOUT acted, it continues to
monitor upto 64,534 cycles and capture the list of inputs that became
ABNORMAL in each cycle.
Reset
Reset can take effect only when FIRSTUPACTED is ON (First Out input is detected,
and the output flag of the First Out Logic is raised) and all the inputs are in the
NORMAL state. Then, on a rising edge, the reset is affected. When FIRSTUPACTED is
OFF, OFF-to-ON transition of RESET input is ignored for performance.
INPUTACTED[*] OFF
FIRSTOUTINPUT None
FIRSTUPACTED OFF
Inputs
• IN [1..24] - Boolean inputs whose transitions are monitored.
Outputs
• FIRSTOUTACTED - This flag is set when there is an input transition from its
configured NORMAL state.
• INPUTACTED[1..24] - Indicates whether the corresponding input has transitioned
causing a First Out action.
• FIRSTOUTINPUT - This is an enumeration that indicates the input that triggered
First Out.
• OREDOUT - It is an OR of all NORMAL state inputs and it goes high if any input
goes to ABNORMAL state. It resets when all inputs come back to NORMAL state.
Error handling
• This block checks and reports for invalid input indexes while loading or accessing
parameters.
• The SR parameter cannot be edited on the monitoring side. A string input to the SR
parameter results in an error message being reported during configuration and the
input string is rejected.
• Parameter Access level is checked.
• The block limits the range of NUMDINPUTS to 0 to 24 on the project side. If the
input value for NUMDINPUTS is greater than 24 or less than 0, an error is reported
during configuration and the input value is rejected.
REFERENCE
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the First Out Detection block.
Function
Used to define two separate states (for example, Running/Stopped, Off/On) to indicate
status of a particular input.
• There are 2 user-configurable state descriptors, STATETEXT[0] and
STATETEXT[1] which are used to describe STATE0 and STATE1 respectively.
• Current state of flag can be changed/read using PVFL (Boolean) or using PV (either
STATETEXT[0] or STATETEXT[1]).
• Block also supports:
− configurable access lock which determines who can write a value to the block
(such as operator, engineer, or other function block).
Input/Output
The block has one output flag (PVFL). But, all block pin parameters are available to be
exposed and connected to using Control Builder graphical connections.
FLAG parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the FLAG function block.
Function
Used to define two separate states (Off/On) to indicate status of a particular input.
• Number of flag values (NFLAG) is user configurable.
• Current state of flags can be changed/read using flag value (PVFL[n]) (Boolean).
• Block also supports configurable access lock which determines who can write a
value to the block (such as an operator, engineer, or other function block).
Input/Output
The block has up to 1000 output flags(PVFL[n]). But, all block pin parameters are
available to be exposed and connected to using Control Builder graphical connections.
FLAGARRAY parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the FLAGARRAY function block.
Function
When a client triggers a given send flag (SENDFL[n]) input, the corresponding message
(MESSAGE[n]) is sent to the Message and the Event Summary displays in the Station
application.
For information only type (INFO) messages, the client trigger sets the corresponding
SENDFL[n] to True. Since the SENDFL[n] is a pulse trigger, it is automatically set to
False during the next execution cycle. This means the MESSAGE block is ready to send
the same message again in the next cycle.
For confirmation type (CONFIRM) messages, the client trigger pulses the corresponding
SENDFL[n] to send the MESSAGE[n] to the Server. The client of the MESSAGE block
checks for the confirmed parameter (CONFIRMED[n]) to be set to True. The
CONFIRMED[n] parameter indicates whether the MESSAGE block has received a
confirmation.
A message can be confirmed only by acknowledging it twice through the Message
Summary display in Station. This action sets the CONFIRMED[n] parameter true (ON).
If the CONFIRM[n] parameter is set through the Monitoring mode, an operator must still
acknowledge the message through the Message Summary display to remove it from the
display.
The CONFIRM[n] parameter can be configured as a block input pin and/or a monitoring
parameter that appears on the face of the block in the Monitoring mode. That is, a client
block or an operator, depending upon application requirements, can trigger it.
The MESSAGE[n] and MSGTYPE[n] parameters can also be configured as block input
pins and/or monitoring parameters. However, the MESSAGE[n], MEANINGPRI[n], and
MEANINGSEC[n] parameters cannot be changed online in the monitoring mode. It is
possible to change the MSGTYPE[n] and MINLVLSECSIG[n] parameters online in the
Monitoring mode should the application requirements change with an access level of
Engineer or greater.
Input/Output
The block has up to 16 inputs (SENDFL[0..15]) and 16 outputs (CONFIRMED[0..15]),
depending on the message types configured.
MESSAGE parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the MESSAGE function block.
Function
Used to store up to 8 bytes of a floating point value within defined upper and lower
limits for use in a control strategy.
• Configurable high and low limits are also provided.
• Also supports a configurable access lock which determines who can write a value to
the block (such as operator, engineer, other function block).
Input/Output
The block has one output (PV). But, all block pin parameters are available to be exposed
and connected using Control Builder graphical connections.
NUMERIC parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
Function
The NUMERICARRAY block outputs (PV[n]) can be used as source parameters to
provide predefined analog constants to other function blocks. A bad numeric output
parameter typically has the value NaN (Not-a-Number).
The block supports these user configurable attributes.
• A configurable Access Lock (ACCLOCK) which determines who can write a value
to the block (such as operator, engineer, or other function block).
• A configurable PV Format (PVFORMAT) which lets you select the decimal format
to be used to display the PV[n] values. The selections are D0 for no decimal place (-
XXXXXX.), D1 for one decimal place (-XXXXX.X), D2 for two decimal places (-
XXXX.XX), and D3 for three decimal places (-XXX.XXX). The default selection is
D1 for one decimal place.
• A configurable Number of Numeric Values (NNUMERIC) which lets you specify
the desired number of numeric values to be supported.
Input/Output
The block has up to 200 outputs (PV[n]), depending on the number of numeric values
(NNUMERIC) configured. But, all block pin parameters are available to be exposed and
connected to using Control Builder graphical connections.
NUMERICARRAY parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the NUMERICARRAY function block.
Function
The function block fetches the input when it is scheduled to run and stores the output in
the same execution cycle after the type conversion. If data type conversion is not
necessary, then none will be done.
Execution Status
The status of input fetching is reflected in the following parameter:
• Overall Execution Status (EXECSTS)
The EXECSTS provide information on how successful the block is in fetching the input.
EXECSTS can have the following values:
• OK – Successful, that is when fetching of inputs as well as the conversion was done
without any error or clamping.
• CLAMPWARNING - Function completed, but with some limitation (for example,
value clamped after data conversion). This provides information on how successful
the block was in type conversion. After fetching good data, if the block had to clamp
the input during type conversion, EXECSTS will be CLAMPWARNING.
• BADINPUT - This happens when the connection to input block is lost or it is simply
bad data.
• INBLKMISSING - This happens when the block detects that there is no input
connection made to any of the inputs of the PUSH block
Store Status
The status of output store is reflected in the following parameter:
• Store status (STORESTS)
The STORESTS provide information on how successful the block is in storing the input.
STORESTS can have the following values:
• STOREOK – Successful, that is the store to destination was successful.
• STOREPENDING - This is an intermediate status when the store is made to a
destination, which is in a peer controller. Until the block actually gets store request,
the status is STOREPENDING.
• STOREFAIL - If the output destination block rejects the store, the push block
displays the STOREFAIL status. The reason for failure may be very block specific.
When the store fails, the PUSH block retries the store immediately in the next
execution cycle. If this store also fails, then the store is not tried for two cycles. This
continues until the time goes to 6 secs. After that the store is not made until 6
seconds are over. Thus there is exponential increase in time between any two failed
stores. This is required to save precious peer-to-peer communication resources.
• DATATYPERR - This is used if the output store could not be made because of
some error in CL/CB where connection of parameters between different data types is
allowed. This is also the store status if there is no output connection configured on
the PUSH block.
PUSH parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the PUSH function block.
Function
The TEXTARRAY block outputs (STR[n]) can be used to provide predefined text
strings to other function blocks.
The block supports these user configurable attributes.
• A configurable Access Lock (ACCLOCK) which lets you define who can write a
value to the block (such as operator, engineer, or other function block).
• A configurable Number of String Values (NSTRING) which lets you specify the
desired number of string values (up to 120) to be supported.
• A configurable Character Length of String Values which lets you specify the
number of characters (8, 16, 32, or 64) allowed in the strings.
The TEXTARRAY block supports a maximum size of 960 two-byte characters. The
following table shows the maximum data combinations that you can configure through
NSTRING and STRLEN values. Illegal combinations of NSTRING and STRLEN
values, those requiring more than 960 two-byte characters of data, will be rejected.
15 64 [1. .15]
30 32 [1. .30]
60 16 [1. .60]
Input/Output
The block has up 120 output strings (STR[n]), depending on the number of string values
(NSTRING) configured. But, all block pin parameters are available to be exposed and
connected to using Control Builder graphical connections.
TEXTARRAY parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the TEXTARRAY function block.
Function
Used to keep track of elapsed time during a process and provides indication when
elapsed time reaches predefined limit. The TIMEBASE can be configured to represent
seconds, minutes, or cycles (number of execution cycles).
Input/Output
The block has one Status Output (SO). But, all parameters are available to be exposed
and connected to using Control Builder graphical connections.
Commands
Commands are sent to the timer in one of two ways:
• By the operator, using the COMMAND parameter.
• Through connections to the parameters STARTFL, STOPFL, RESETFL, and
RESTARTFL.
You can give a Reset command any time, even if the TIMER is not running, and it will
always be executed. However, the Stop command is only valid while the TIMER is
running. For example, giving a Stop command directly after a Reset command is not
allowed.
The Start and Restart commands are not interchangeable. A Start command is only
executed after a prior Reset, when the timer is starting from the beginning (PV = 0).
Similarly, a Restart command is only executed after a prior Stop command, which froze
the timer when it was running (PV usually = non-zero).
When more than one of the Boolean command parameters is set at the same time, the
following priority is used:
• RESETFL - highest priority
• STOPFL
• RESTARTFL
• STARTFL - lowest priority
For example, when both RESETFL and STARTFL are ON, the TIMER executes the
Reset command and nothing else happens until RESETFL goes Off. This leaves the
STARTFL as the only Boolean command ON, at which time the TIMER is started.
If you use both methods for issuing commands to the TIMER at the same time, the same
priority described above for the flags also applies for the commands. For example, if
STARTFL is ON and a Stop command is given (through COMMAND), the Stop
command is executed and all lower priority command flags are automatically turned
OFF.
TIMER parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the TIMER function block.
Function
The TYPECONVERT block is used to connect one input parameter to one or many
output parameters with different data types. For example, a Boolean input
(IN.BOOLEAN) can be converted to a 32-bit integer (OUT.INT32), a 64-bit floating
point number (OUT.FLOAT64), and an enumeration (OUT.ENUM) outputs. The
general Control Builder configuration rule about only connecting parameters of the same
data types for block inputs and outputs still applies. The TYPCONVERT block reads the
input value and only provides the converted output when the block connected to its
output runs.
R110 Experion LX Control Builder Components Theory 1245
February 2014 Honeywell
20. Utility Functions
20.15. TYPECONVERT Block
You identify the source parameter by wiring it to the IN.xx pins of the
TYPECONVERT block during configuration. For example, connecting
CM1.DEVCTL.GPV and CM1.PID1.OP to the same TYPECONVERT block is not
allowed. The Control Module block load fails, if such a situation exists at the load time.
Continuing with this example, the IN.ENUM might be connected to
CM1.DEVCTL.GPV and the OUT.FLOAT64 connected to CM1.EQ.IN(1), where GPV
is the generic state Enumeration representation of a Device Control block's PV, IN(1) is
the first input of an Equal comparison block (data type of Real), and CM1 is the Control
Module block that contains the DEVCTL and EQ blocks. The TYPECONVERT block
fetches the GPV Enumeration when it runs, and converts the value to a Real number
when the EQ function block runs and tries to fetch this value.
Continuing with the above example, you can connect CM1.DEVCTL.GPV to IN.ENUM
pin. Connecting this pin to any other pin is rejected by the Control Builder application.
Type conversions are supported for all possible combinations of the four supported data
types. For example, Boolean-to-Integer, Boolean-to-Real, Boolean-to-Enumeration, and
so on. Conversions from a particular data type to the same data type, such as Integer-to-
Integer, are supported; but you do not need to use the TYPECONVERT block in these
cases.
The block supports these user configurable attributes.
• A configurable Threshold Value (THRESHOLD) which lets you define how the
Boolean value is to be interpreted for a 32- or 64-bit floating point to Boolean
conversion. If the floating point input (IN.FLOAT32/IN.FLOAT64) value is greater-
than or equal-to the configured THRESHOLD, the Boolean output
(OUT.BOOLEAN) is turned ON, otherwise, it is OFF.
• A configurable Truncate Option (TRUNCATEOPT) which lets you specify whether
the converted integer value is to be truncated or rounded for a 32- or 64-bit floating
point to 32-bit integer conversion. For example, if the 64-bit floating point input
(IN.FLOAT64) is 3.57, a rounded 32-bit integer output OUT.INT32) value would
be 4 and a truncated OUT.INT32 value would be 3. If the IN.FLOAT64 value were
3.49, the rounded OUT.INT32 value would also be 3.
• A configurable Value OFF mapped to Enumeration (BOOLVALUEOFF) which lets
you select a given enumeration to be mapped to a Boolean (ENUMBOOLMAP[n])
value of OFF.
• A configurable Value ON mapped to Enumeration (BOOLVALUEON) which lets
you select a given enumeration to be mapped to a Boolean (ENUMBOOLMAP[n])
value of ON.
• An Enumeration to Boolean Map scroll box lets you configure a given enumeration
(ENUMBOOLMAP[n]) to OFF or ON.
• An Enumeration Text scroll box lets you configure up to 12 characters for a given
Self Defining Enumeration output (OUT.SDENUM[n]).
Execution status
The block's execution status (EXECSTS) parameter monitors how successful the block is
in fetching the input and can have the following values.
• OK - Successful (When fetching of inputs as well as the conversion was done
without any error or clamping.).
• CLAMPWARNING - Function completed, but with some limitation (for example,
value clamped after data conversion). This provides information on how successful
the block was in type conversion. After fetching good data, if the block had to clamp
the input during type conversion, EXECSTS will be CLAMPWARNING.
• BADINPUT - This happens when the connection to input block is lost or it is
simply bad data.
• INBLKMISSING - This happens when the block detects that there is no input
connection made to any of the inputs of the PUSH block.
ATTENTION
The TYPECONVERT block does not use BADINPUT EXECSTS when the
block is in Inactive or in IDLE state.
Input/Output
The block has up to nine inputs and nine outputs. The pins for the four most common
inputs (IN.BOOLEAN, IN.INT32, IN.FLOAT64, IN.ENUM) and outputs
(OUT.BOOLEAN, OUT.INT32, OUT.FLOAT64, OUT.ENUM) are exposed by default.
But, all block pin parameters are available to be exposed and connected to using Control
Builder graphical connections.
TYPECONVERT parameters
REFERENCE - INTERNAL
Refer to the Control Builder Components Reference for a complete list of the
parameters used with the TYPECONVERT function block.
REFERENCE - INTERNAL
Refer to the Sequential Control User's Guide for all information pertaining to
the Sequential Control function in Experion LX system.