Control Builder Components Theory: Experion PKS

Experion PKS
Control Builder Components Theory
EPDOC-XX16-en-431E
April 2018
Release 431
Document Release Issue Date
EPDOC-XX16-en-431E 431 0 April 2018
Disclaimer
This document contains Honeywell proprietary information. Information contained herein is to be used solely
for the purpose submitted, and no part of this document or its contents shall be reproduced, published, or
disclosed to a third party without the express permission of Honeywell International Sàrl.
While this information is presented in good faith and believed to be accurate, Honeywell disclaims the implied
warranties of merchantability and fitness for a purpose and makes no express warranties except as may be stated
in its written agreement with and for its customer.
In no event is Honeywell liable to anyone for any direct, special, or consequential damages. The information
and specifications in this document are subject to change without notice.
Copyright 2018 - Honeywell International Sàrl
2 www.honeywell.com
Contents
1 About This Document .......................................................................................................................... 27

2 Control Builder Components .............................................................................................................. 29
2.1 Control Builder Underlying Concepts .............................................................................................................. 30
2.1.1 In the beginning or the Single-Loop Controller Reference ............................................................... 30
2.1.2 Experion architecture - partitioned functionality ............................................................................... 31
2.1.3 Blocks for building process control operations ................................................................................. 32
2.1.4 Naming convention- independent versus dependent ......................................................................... 33
2.1.5 Full or expanded tag name ................................................................................................................. 34
2.1.6 Parameter names ................................................................................................................................ 34
2.1.7 Naming restrictions and conventions ................................................................................................. 36
2.1.8 Parameter data types .......................................................................................................................... 36
2.1.9 Data flow -- active versus passive ..................................................................................................... 36
2.1.10 Active and passive connectors ......................................................................................................... 37
2.1.11 Cascade loop connections ................................................................................................................ 37
2.1.12 Data pull or push .............................................................................................................................. 38
2.2 Control Capacity and Performance ................................................................................................................... 39
2.2.1 Control network capacity ................................................................................................................... 39
2.2.2 C200/C200E configuration options ................................................................................................... 40
2.2.3 C200/C200E Redundancy ................................................................................................................. 41
2.2.4 C200/C200E communication performance ....................................................................................... 41
2.2.5 C200E Whole Array Transfer Performance ...................................................................................... 43
2.2.6 C200/C200E processing resources .................................................................................................... 43
2.2.7 C200/C200E Memory Resources and Block Configuration ............................................................. 44
2.2.8 C300 configuration options ............................................................................................................... 44
2.2.9 C300 Redundancy .............................................................................................................................. 45
2.2.10 C300 communication performance .................................................................................................. 45
2.2.11 C300 processing resources ............................................................................................................... 47
2.2.12 C300 Memory Resources ................................................................................................................ 48
2.2.13 ACE configuration options .............................................................................................................. 48
2.2.14 ACE communication performance .................................................................................................. 48
2.2.15 ACE processing resources ............................................................................................................... 50
2.2.16 ACE Memory Resources ................................................................................................................. 50
2.3 I/O Capacity and Performance .......................................................................................................................... 51
2.3.1 C200/C200E IO capacity ................................................................................................................... 51
2.3.2 C300 IO capacity ............................................................................................................................... 52
2.3.3 IO Unit load factors ........................................................................................................................... 53
2.4 Function Block Execution Schedules ............................................................................................................... 55
2.4.1 Schedule consideration differences ................................................................................................... 55
2.4.2 Control Module and Sequential Control Module FBs schedule ........................................................ 55
2.4.3 CM Component Function Block scheduling ..................................................................................... 58
2.4.4 IOM FB schedule ............................................................................................................................... 60
2.4.5 CPM, ACE, and CEE FBs schedule .................................................................................................. 61
2.4.6 Cycle overruns ................................................................................................................................... 61
2.5 Block Configuration Load Considerations ....................................................................................................... 62
2.5.1 Data categories ................................................................................................................................... 62
2.5.2 Container and self-standing blocks load versus states ....................................................................... 62
3
CONTENTS
2.5.3 Load error messages .......................................................................................................................... 63

2.5.4 RAM Retention Start Up (RRSU) ..................................................................................................... 63
2.6 Memory Usage for CEE on C200/C200E, C300 or ACE ................................................................................ 65
2.6.1 C200/C200ECEE Processing and Memory Models .......................................................................... 65
2.6.2 C300 CEE Processing and Memory Models ..................................................................................... 67
2.6.3 ACE CEE Processing and Memory Models ...................................................................................... 71
2.7 CPU Utilization for CEE on CPM .................................................................................................................... 73
2.8 CEE Standard Control Blocks .......................................................................................................................... 74
2.9 Control Component Library (CCL) Blocks ...................................................................................................... 78
3 Control Module Independence ............................................................................................................ 79
3.1 Module Independence for Flexible Modification ............................................................................................. 80
3.2 CM Independence and Hypothetical Controller Comparison .......................................................................... 81
3.2.1 Hypothetical controller structure ....................................................................................................... 81
3.2.2 Coupling effects in hypothetical controller ....................................................................................... 81
3.3 CEE Architecture .............................................................................................................................................. 83
3.3.1 CEE controller structure .................................................................................................................... 83
3.3.2 Program and Data Partitioning .......................................................................................................... 83
3.3.3 Native program and custom program partitioning ............................................................................. 84
3.3.4 Regulated Base Cycle ........................................................................................................................ 84
3.3.5 Coupling effects in CEE-based controller ......................................................................................... 85
3.4 Validation of Control Module Independence .................................................................................................... 87
3.5 Resource Coupling Across Different Platforms ............................................................................................... 88
4 Relative References ............................................................................................................................. 89
4.1 About Relative References ............................................................................................................................... 90
4.2 Relative References structure rules .................................................................................................................. 91
4.2.1 How relative reference matching function works .............................................................................. 91
4.3 Display options for relative references ............................................................................................................. 93
4.3.1 How short name display option works .............................................................................................. 93
4.4 Control Builder functions supporting relative references ................................................................................. 95
4.5 Control Builder blocks supporting expressions ................................................................................................ 96
4.6 Example of TRANSITION block using relative references ............................................................................. 97
4.6.1 A container reference from a chart .................................................................................................... 97
4.6.2 A reference to a parameter on the same block from a form .............................................................. 97
4.6.3 A reference to a parameter on a different block in the same CM ...................................................... 98
4.6.4 Expression display interaction ........................................................................................................... 98
4.7 Example of parameter connector using relative references .............................................................................. 99
4.7.1 A reference to a parameter on a different block in the same CM ...................................................... 99
4.7.2 Parameter connector display interaction ............................................................................................ 99
4.8 Example of other parameters using relative references .................................................................................. 100
4.8.1 A reference to a parameter on a basic block of the CM .................................................................. 100
4.8.2 Other parameters display interaction ............................................................................................... 101
4.9 Bulk Builder and Bulk Editor support ............................................................................................................ 102
5 Peer-to-Peer Functionality ................................................................................................................. 103
5.1 Basic Peer-to-Peer Design Concepts .............................................................................................................. 104
5.1.1 Data flow models ............................................................................................................................. 104
5.1.2 Peer environments and subscription periods ................................................................................... 105
5.1.3 Software Architecture for CPM/CEE .............................................................................................. 105
5.1.4 A word about ACE/CEE architecture .............................................................................................. 106
5.1.5 Peer-to-peer communication between CEE and non-CEE points ................................................... 107
5.1.6 Peer-to-peer communication between ACE/C300 and EHPM points ............................................. 107
5.1.7 Guidelines for configuring peer-to-peer communication between CEE and non-CEE points ........ 108
5.1.8 Renaming non-CEE point/data type change consideration in configuration ................................... 110
5.1.9 Designing control strategy for failsafe control ................................................................................ 111
4 www.honeywell.com
CONTENTS
5.1.10 Runtime peer-to-peer behavior between CEE and non-CEE point ............................................... 113
5.1.11 Runtime peer-to-peer behavior between CEE and Experion Server points ................................... 113
5.2 Initiator Rate - Calculation ............................................................................................................................. 115
5.2.1 Configuration without peer environment table ................................................................................ 115
5.2.2 Configuration with peer environment table ..................................................................................... 115
5.3 Implications for Control Builder Configuration ............................................................................................. 118
5.3.1 Multiple CPMs and ACEs ............................................................................................................... 118
5.3.2 CEE execution and subscription rates .............................................................................................. 118
5.3.3 Function block support .................................................................................................................... 118
5.3.4 Peer-to-peer connections and DEF and REF blocks ........................................................................ 119
5.3.5 Peer-to-peer configuration example ................................................................................................. 119
5.3.6 Peer-to-peer configuration guidelines .............................................................................................. 122
5.3.7 Example to illustrate peer-to-peer configuration for non-CEE points ............................................. 122
6 Time Support in Experion System .................................................................................................... 125
6.1 Date and Time Synchronization ..................................................................................................................... 126
6.2 C300 and Series C Fieldbus Interface Module Time Synchronization .......................................................... 127
6.2.1 BOOTP Mechanism and Multiple Clusters ..................................................................................... 127
6.3 Time Configuration Considerations ................................................................................................................ 128
6.3.1 Time Data Types in Control Execution Environment (CEE) Blocks .............................................. 128
6.3.2 Time Data Types in User Algorithms and Displays ........................................................................ 128
6.3.3 C200/C200E, Application Control Environment (ACE) Time Parameters ..................................... 129
6.3.4 Custom Algorithm Block (CAB) on ACE Time Functions ............................................................. 130
6.4 Examples of Time Usage in CAB and SCM .................................................................................................. 131
6.4.1 Example - Custom Algorithm Block (CAB) writes Time CDP ...................................................... 131
6.4.2 Example - Custom Algorithm Block (CAB) reads Time CDP ........................................................ 131
6.4.3 6.4.3 Example - Sequence Control Module (SCM) waits for a specified Time .............................. 132
6.4.4 Example - Sequence Control Module (SCM) records Time of process command .......................... 132
7 Cold and Warm Restart Functionality .............................................................................................. 133
7.1 Overview ......................................................................................................................................................... 134
7.1.1 CEE Initial Startup ........................................................................................................................... 134
7.1.2 CEE Restarts .................................................................................................................................... 134
7.1.3 CEE Restart Behaviors .................................................................................................................... 134
7.2 Planning .......................................................................................................................................................... 136
7.2.1 Invariant or Variant Restart Behaviors ............................................................................................ 136
7.2.2 Blocks with Invariant Restart Behavior ........................................................................................... 136
7.2.3 Blocks with Variant Restart Behavior .............................................................................................. 138
7.3 Configuration of Restart Behaviors ................................................................................................................ 140
7.3.1 CEE Block ....................................................................................................................................... 140
7.3.2 Control Module (CM) ...................................................................................................................... 140
7.3.3 Control Module Function Blocks .................................................................................................... 141
7.3.4 Logic Blocks .................................................................................................................................... 141
7.3.5 Sequential Control Module (SCM) .................................................................................................. 142
7.3.6 Summary Of SCM Restart Behavior ............................................................................................... 144
7.3.7 Supporting SCM Functionalities ..................................................................................................... 145
7.3.8 SCM Blocks ..................................................................................................................................... 146
7.4 Warm and Cold Restart Behaviors of Cascades ............................................................................................. 147
7.4.1 Definitions ....................................................................................................................................... 147
7.4.2 Regulatory Cascades ........................................................................................................................ 147
7.4.3 CEE to CEE Cascades ..................................................................................................................... 148
7.4.4 CEE to Legacy Cascade when Node hosting Primary is restarted .................................................. 150
7.4.5 CEE to EHPM FTE Cascade ........................................................................................................... 151
7.4.6 CEE to Legacy Cascade when Node hosting Secondary is restarted .............................................. 151
7.4.7 RegCtl Cascades when Node hosting the Primary is restarted ........................................................ 151
5
CONTENTS
7.4.8 Cascades through UCNIF: UCNOUT/EUCNOUT ......................................................................... 152

7.5 Operations ....................................................................................................................................................... 153
7.5.1 CEE Function Block ........................................................................................................................ 153
7.5.2 ACE Function Block ........................................................................................................................ 153
7.5.3 CPM Function Block ....................................................................................................................... 153
8 External OPC Server Support ........................................................................................................... 155
8.1 OPC Data Access ............................................................................................................................................ 156
8.1.1 OPC Server function block .............................................................................................................. 156
8.1.2 OPC client/server data flow ............................................................................................................. 156
8.2 OPC Data References ..................................................................................................................................... 157
8.2.1 OPC Data Name Syntax .................................................................................................................. 157
8.2.2 Parameter connectors only ............................................................................................................... 157
8.2.3 OPC references in expressions ........................................................................................................ 158
8.2.4 OPC references in SCM Alias table ................................................................................................ 158
8.2.5 Validation of OPC references .......................................................................................................... 159
8.3 OPC Data Type Conversions .......................................................................................................................... 160
8.3.1 Gets conversions .............................................................................................................................. 160
8.3.2 General data conversion considerations .......................................................................................... 161
8.3.3 Stores conversions ........................................................................................................................... 162
8.4 ACE interface to TPS system as OPC server ................................................................................................. 164
9 System Namespace Workaround ..................................................................................................... 165
9.1 Inter-Cluster Communication ......................................................................................................................... 166
9.2 Using the Inter Cluster Gateway for Communication between Experion Clusters ........................................ 167
9.2.1 Inter Cluster Gateway configuration guidelines .............................................................................. 167
9.2.2 When to use Inter Cluster Gateway ................................................................................................. 167
9.2.3 Reviewing Inter Cluster Gateway characteristics ............................................................................ 168
9.2.4 Inter Cluster Gateway connectivity ................................................................................................. 169
9.3 Remote EEOUT (REEOUT) Function Block ................................................................................................. 170
9.3.1 Functional description-REEOUT ................................................................................................... 170
10 Controller Redundancy Functionality ............................................................................................ 171
10.1 Basic Redundancy Design Concepts ............................................................................................................ 172
10.1.1 Switchover and Secondary readiness ............................................................................................. 172
10.1.2 Failure conditions and switchover ................................................................................................. 173
10.1.3 Role of the Redundancy Module ................................................................................................... 174
10.2 Implications for Control Builder Functions .................................................................................................. 176
10.2.1 Redundant C200/C200E CPM configuration ................................................................................ 176
10.2.2 RM configuration ........................................................................................................................... 176
10.2.3 RM monitoring .............................................................................................................................. 177
10.2.4 RM/RCP dialog box ...................................................................................................................... 177
10.2.5 Main tab ......................................................................................................................................... 178
10.2.6 Summary tab .................................................................................................................................. 178
10.2.7 RM Profiles tab .............................................................................................................................. 180
10.2.8 Configuration tab ........................................................................................................................... 182
10.2.9 Synchronization tab ....................................................................................................................... 183
10.2.10 Chassis Profiles tab ...................................................................................................................... 186
10.2.11 Display tab ................................................................................................................................... 187
10.2.12 Server History tab ........................................................................................................................ 188
10.2.13 Server Displays tab ...................................................................................................................... 190
10.2.14 Auto-Synchronization events ....................................................................................................... 191
11 Control Mode Shed on Loss of I/O Functionality .......................................................................... 193
11.1 Basic Control Mode Shed Design Concepts ................................................................................................. 194
11.1.1 How it works .................................................................................................................................. 194
6 www.honeywell.com
CONTENTS
11.2 Option to specify a time delay for the REGCTL blocks to shed the mode .................................................. 196
11.2.1 Enabling the option of specifying time delay for REGCTL blocks to shed the mode .................. 196
11.2.2 Description of values for Bad Output Connection Option ............................................................. 197
11.2.3 Considerations for setting the BADOCOPT value ........................................................................ 198
11.2.4 Applicability of BADOCOPT parameter for FANOUT blocks .................................................... 199
11.2.5 Simulation support for the BADOCOPT parameter ...................................................................... 199
11.2.6 Impact of BADOCOPT parameter on regulatory control functionalities ...................................... 199
11.2.7 Effects of BADOCOPT value on delay timer in various scenarios ............................................... 199
11.2.8 Auxiliary memory usage for the parameters .................................................................................. 200
11.2.9 Detail Displays ............................................................................................................................... 200
11.3 Implications for Operation ............................................................................................................................ 202
11.3.1 Resetting mode after I/O communications are restored. ................................................................ 202
11.3.2 Allowing Redundancy synchronization with lost I/O communications ........................................ 202
11.4 Remote Cascade function between Controllers ............................................................................................ 203
12 Enhancements to MODE behavior of the regulatory control blocks ........................................... 205
12.1 About the MODESTARTMAN parameter ................................................................................................... 206
12.2 MODESTARTMAN ..................................................................................................................................... 208
13 Control Builder Export and Import Functionality .......................................................................... 209
13.1 Basic Export/Import Design Concepts ......................................................................................................... 210
13.1.1 Export functionality ....................................................................................................................... 210
13.1.2 Import functionality ....................................................................................................................... 210
14 SCM and CM Chart Visualization Functionality ............................................................................. 211
14.1 Basic Chart Visualization Design Concepts ................................................................................................. 212
14.1.1 How SCM chart visualization works ............................................................................................. 212
14.2 Some SCM and CM Chart Operation Considerations .................................................................................. 216
14.2.1 Detail display interaction notes ..................................................................................................... 216
15 Enhancements to reporting of alarms in Station .......................................................................... 217
15.1 Various configurable alarm attributes ........................................................................................................... 218
15.2 Blocks and applicable alarms ....................................................................................................................... 219
15.2.1 Guidelines for configuring on-delay time for BADCTL alarm ..................................................... 220
15.2.2 Example to illustrate the alarm behavior based on alarm attributes .............................................. 220
15.2.3 Impact of alarm priority change on alarm behavior ...................................................................... 221
15.2.4 Impact of migration on alarm attributes ........................................................................................ 221
15.2.5 Impact of OUTIND parameter on alarm attributes ........................................................................ 221
16 I/O Link Interface .............................................................................................................................. 223
16.1 I/O Functions ................................................................................................................................................ 224
16.2 A word about Point form .............................................................................................................................. 225
16.3 IOP validation ............................................................................................................................................... 226
16.4 I/O Link Cable Status and Statistics ............................................................................................................. 227
16.4.1 Periodic swap functionality ........................................................................................................... 227
16.4.2 Periodic swap transition diagram ................................................................................................... 227
16.4.3 Enabling periodic channel swap .................................................................................................... 228
16.4.4 Viewing cable status and statistics ................................................................................................. 229
17 Process Manager Input/Output Functionality ................................................................................ 231
17.1 High and Low Level Analog Input Points .................................................................................................... 232
17.1.1 Function of high and low level analog input points ...................................................................... 232
17.1.2 PV Characterization ....................................................................................................................... 234
17.1.3 Linear Conversions ........................................................................................................................ 234
17.1.4 Square root conversion .................................................................................................................. 235
17.1.5 Thermal conversion ....................................................................................................................... 235
17.2 Smart Transmitter Interface Point ................................................................................................................. 237
7
CONTENTS
17.2.1 Smart Transmitter support ............................................................................................................. 237

17.2.2 Multivariable transmitter support .................................................................................................. 237
17.2.3 Transmitter parameters and database access .................................................................................. 238
17.2.4 STI parameter comparisons ........................................................................................................... 238
17.2.5 Transmitter communication mode ................................................................................................. 239
17.2.6 STI IOP commands ........................................................................................................................ 239
17.2.7 Point states ..................................................................................................................................... 240
17.2.8 STI IOP functions .......................................................................................................................... 241
17.2.9 STI PV characterization ................................................................................................................. 241
17.2.10 STI linear conversion ................................................................................................................... 242
17.2.11 STI square root conversion .......................................................................................................... 243
17.2.12 STI thermal conversion ................................................................................................................ 243
17.2.13 STI PV range checking and filtering ........................................................................................... 243
17.3 Analog Output Point ..................................................................................................................................... 245
17.3.1 AO functions .................................................................................................................................. 245
17.3.2 AO direct/reverse output ................................................................................................................ 245
17.3.3 AO output characterization ............................................................................................................ 246
17.3.4 AO calibration compensation ........................................................................................................ 246
17.4 Digital Input Point ........................................................................................................................................ 247
17.4.1 DI functions ................................................................................................................................... 247
17.4.2 DI status point ................................................................................................................................ 248
17.4.3 DI PV source selection .................................................................................................................. 248
17.4.4 DI off-normal alarming .................................................................................................................. 248
17.4.5 Alarm delay ................................................................................................................................... 249
17.4.6 Event reporting .............................................................................................................................. 250
17.4.7 DI latched input point .................................................................................................................... 250
17.4.8 DI sequence of events point ........................................................................................................... 250
17.4.9 SOE definitions .............................................................................................................................. 250
17.4.10 SOE resolution considerations ..................................................................................................... 251
17.4.11 DI SOE configuration considerations .......................................................................................... 251
17.5 Digital Output Point ...................................................................................................................................... 254
17.5.1 DO functions .................................................................................................................................. 254
17.5.2 Pulse Width Modulated (PWM) Output Type ............................................................................... 255
17.5.3 Status Output Type ......................................................................................................................... 255
17.5.4 Initialization request flag ............................................................................................................... 255
18 Component Categories and Types ................................................................................................. 257
18.1 About categories ........................................................................................................................................... 258
18.2 Function block types and data organization ................................................................................................. 259
19 Regulatory Control ........................................................................................................................... 261
19.1 Regulatory Control Blocks ........................................................................................................................... 262
19.1.1 Common regulatory control functions for C200/C200E and ACE controllers without insertion
points .................................................................................................................................................... 264
19.1.2 Common regulatory control functions for ACE controllers with insertion points ........................ 265
19.1.3 CAB insertion configuration considerations for regulatory control blocks ................................... 266
19.1.4 Insertion type functional characteristics for regulatory control blocks ......................................... 267
19.1.5 Functional requirements for Custom CAB algorithm for regulatory control block ...................... 268
19.1.6 CAB insertions for Regulatory Control block parameters ............................................................ 269
19.1.7 Pin connections to inserted CAB instances ................................................................................... 269
19.1.8 Insertion status and fail alarm for regulatory control blocks ......................................................... 270
19.1.9 Handling of insertion failure on regulatory control block ............................................................. 270
19.1.10 CAB insertion on regulatory control block configuration examples ........................................... 270
19.1.11 Tuning Conversions from Interactive to Non-Interactive PID .................................................... 276
19.2 About Safety Interlock Function .................................................................................................................. 278
8 www.honeywell.com
CONTENTS
19.2.1 Safety Interlock processing ............................................................................................................ 278

19.2.2 Safety Interlock processing considerations ................................................................................... 278
19.2.3 Safety Interlock Alarming ............................................................................................................. 279
19.3 About Red Tagging ....................................................................................................................................... 280
19.3.1 Function of Red Tagging ............................................................................................................... 280
19.3.2 Before red tagging a point ............................................................................................................. 280
19.4 AUTOMAN (Auto Manual) Block .............................................................................................................. 281
19.4.1 Function-AUTOMAN ................................................................................................................... 289
19.4.2 Configuration example-AUTOMAN ............................................................................................. 289
19.4.3 Inputs-AUTOMAN ........................................................................................................................ 291
19.4.4 Output-AUTOMAN ....................................................................................................................... 291
19.4.5 Initializable inputs and outputs for AUTOMAN ........................................................................... 291
19.4.6 Output ranges of AUTOMAN ....................................................................................................... 292
19.4.7 Output bias-AUTOMAN ............................................................................................................... 292
19.4.8 Output Indication function for AUTOMAN .................................................................................. 293
19.4.9 Mode Handling-AUTOMAN ........................................................................................................ 295
19.4.10 Timeout Monitoring-AUTOMAN ............................................................................................... 295
19.4.11 Control Initialization-AUTOMAN .............................................................................................. 296
19.4.12 Secondary initialization option-AUTOMAN .............................................................................. 296
19.4.13 Override feedback processing-AUTOMAN ................................................................................ 296
19.4.14 Windup processing-AUTOMAN ................................................................................................. 297
19.4.15 Anti-Reset Windup Status-AUTOMAN ...................................................................................... 298
19.4.16 AUTOMAN parameters .............................................................................................................. 299
19.5 ENHREGCALC (Enhanced Regulatory Control Calculator) Block ............................................................ 300
19.5.1 Function-ENHREGCALC ............................................................................................................. 310
19.5.2 Configuration example-ENHREGCALC ...................................................................................... 310
19.5.3 Operating modes and mode handling for ENHREGCALC ........................................................... 311
19.5.4 Inputs-ENHREGCALC ................................................................................................................. 311
19.5.5 Initializable input-ENHREGCALC ............................................................................................... 311
19.5.6 SP limit checking-ENHREGCALC ............................................................................................... 311
19.5.7 SP target value processing-ENHREGCALC ................................................................................. 312
19.5.8 Initializable outputs-ENHREGCALC ........................................................................................... 314
19.5.9 Output ranges and limits-ENHREGCALC .................................................................................... 314
19.5.10 Assignable outputs-ENHREGCALC ........................................................................................... 314
19.5.11 Output assignment rules-ENHREGCALC .................................................................................. 315
19.5.12 Control initialization-ENHREGCALC ........................................................................................ 316
19.5.13 Output bias-ENHREGCALC ....................................................................................................... 316
19.5.14 Output Indication Function-ENHREGCALC .............................................................................. 318
19.5.15 Timeout monitoring-ENHREGCALC ......................................................................................... 319
19.5.16 Timeout processing-ENHREGCALC .......................................................................................... 320
19.5.17 Mode shedding on timeout-ENHREGCALC .............................................................................. 320
19.5.18 Override feedback processing-ENHREGCALC ......................................................................... 320
19.5.19 Windup handling-ENHREGCALC ............................................................................................. 321
19.5.20 Windup processing-ENHREGCALC .......................................................................................... 322
19.5.21 Anti-Reset Windup Status-ENHREGCALC ............................................................................... 323
19.5.22 Expressions .................................................................................................................................. 324
19.5.23 Parameters in Expressions ........................................................................................................... 325
19.5.24 Guidelines for Writing Expressions ............................................................................................. 326
19.5.25 Enable/Disable switch example expression ................................................................................. 327
19.5.26 String data support in expressions ............................................................................................... 327
19.5.27 Time support in expressions ........................................................................................................ 328
19.5.28 Restart or point activation ............................................................................................................ 329
19.5.29 ENHREGCALC parameters ........................................................................................................ 329
19.6 FANOUT Block ............................................................................................................................................ 330
9
CONTENTS
19.6.1 Function-FANOUT block .............................................................................................................. 337

19.6.2 Configuration example-FANOUT block ....................................................................................... 337
19.6.3 Inputs-FANOUT block .................................................................................................................. 337
19.6.4 Outputs-FANOUT block ................................................................................................................ 338
19.6.5 Initializable inputs and outputs for FANOUT block ..................................................................... 338
19.6.6 Output ranges for FANOUT block ................................................................................................ 338
19.6.7 Output bias-FANOUT block .......................................................................................................... 339
19.6.8 Mode handling-FANOUT block .................................................................................................... 340
19.6.9 Timeout monitoring-FANOUT block ............................................................................................ 340
19.6.10 Control initialization-FANOUT block ......................................................................................... 341
19.6.11 Secondary initialization option-FANOUT block ......................................................................... 342
19.6.12 Override feedback processing-FANOUT block .......................................................................... 342
19.6.13 BACKCALC processing ............................................................................................................. 342
19.6.14 Output Indication Function .......................................................................................................... 343
19.6.15 Windup processing in FANOUT block ........................................................................................ 345
19.6.16 Windup processing in Regulatory blocks .................................................................................... 345
19.6.17 Anti-Reset Windup Status ............................................................................................................ 347
19.6.18 FANOUT parameters ................................................................................................................... 348
19.7 OVRDSEL (Override Selector) Block ......................................................................................................... 349
19.7.1 Function-OVRDSEL block ........................................................................................................... 355
19.7.2 Configuration example-OVRDSEL block ..................................................................................... 357
19.7.3 Configuration considerations-OVRDSEL block ........................................................................... 358
19.7.4 Inputs-OVRDSEL block ................................................................................................................ 359
19.7.5 Input ranges for OVRDSEL block ................................................................................................ 359
19.7.6 Input descriptors-OVRDSEL block ............................................................................................... 359
19.7.7 Initializable outputs-OVRDSEL block .......................................................................................... 359
19.7.8 Output ranges and limits for OVRDSEL block ............................................................................. 360
19.7.9 Output Indication Function-OVRDSEL block .............................................................................. 360
19.7.10 Mode handling-OVRDSEL block ............................................................................................... 362
19.7.11 Timeout monitoring-OVRDSEL block ........................................................................................ 362
19.7.12 Timeout processing-OVRDSEL block ........................................................................................ 362
19.7.13 Bypass processing-OVRDSEL block .......................................................................................... 363
19.7.14 Bad input option .......................................................................................................................... 363
19.7.15 OVRDSEL Equations .................................................................................................................. 363
19.7.16 Input switching ............................................................................................................................ 363
19.7.17 Output bias-OVRDSEL ............................................................................................................... 363
19.7.18 Bad CV processing ...................................................................................................................... 364
19.7.19 Control initialization-OVRDSEL ................................................................................................ 364
19.7.20 Restart or function block activation ............................................................................................. 364
19.7.21 Override feedback propagation .................................................................................................... 364
19.7.22 Recommendations on configuring override strategies ................................................................ 365
19.7.23 Windup processing ....................................................................................................................... 365
19.7.25 OVRDSEL parameters ................................................................................................................ 368
19.8 PID Block ..................................................................................................................................................... 369
19.8.1 Function-PID Block ....................................................................................................................... 382
19.8.2 Functional scenario-PID Block ...................................................................................................... 382
19.8.3 Configuration examples-PID Block .............................................................................................. 383
19.8.4 Operating modes and mode handling-PID Block .......................................................................... 386
19.8.5 Required inputs-PID Block ............................................................................................................ 386
19.8.6 Input ranges and limits-PID Block ................................................................................................ 386
19.8.7 Initializable outputs-PID Block ..................................................................................................... 387
19.8.8 Control initialization-PID Block .................................................................................................... 387
19.8.9 Output bias-PID Block .................................................................................................................. 387
10 www.honeywell.com
CONTENTS
19.8.10 Output ranges and limits-PID Block ............................................................................................ 389

19.8.11 Direct or reverse control-PID Block ............................................................................................ 389
19.8.12 Set Point Ramping-PID Block ..................................................................................................... 389
19.8.13 PV tracking-PID Block ................................................................................................................ 392
19.8.14 PID equations ............................................................................................................................... 393
19.8.15 Gain options-PID block ............................................................................................................... 394
19.8.16 Tuning Constant Change Considerations .................................................................................... 395
19.8.17 Timeout monitoring-PID block ................................................................................................... 395
19.8.18 Timeout processing-PID block .................................................................................................... 395
19.8.19 Output Indication Function-PID block ........................................................................................ 396
19.8.20 Windup handling-PID block ........................................................................................................ 398
19.8.23 Override feedback processing-PID block .................................................................................... 401
19.8.24 PID parameters ............................................................................................................................ 401
19.9 PID-PL (Profit Loop PKS) Block ................................................................................................................. 402
19.9.1 Function-PID-PL ........................................................................................................................... 412
19.9.2 Configuration examples-PID-PL ................................................................................................... 418
19.9.3 Operating modes and mode handling-PID-PL .............................................................................. 422
19.9.4 Required inputs-PID-PL ................................................................................................................ 423
19.9.5 Input ranges and limits-PID-PL ..................................................................................................... 423
19.9.6 Initializable outputs-PID-PL .......................................................................................................... 423
19.9.7 Control initialization-PID-PL ........................................................................................................ 423
19.9.8 Output bias-PID-PL ....................................................................................................................... 424
19.9.9 Output ranges and limits-PID-PL .................................................................................................. 424
19.9.10 Direct or reverse control-PID-PL ................................................................................................ 424
19.9.11 Set Point Ramping-PID-PL ......................................................................................................... 424
19.9.12 Range Control Ramping-PID-PL ................................................................................................ 424
19.9.13 PV tracking-PID-PL .................................................................................................................... 425
19.9.14 PV Bad Value Handling ............................................................................................................... 425
19.9.15 PV Calibration ............................................................................................................................. 425
19.9.16 Asynchronous PV Inputs ............................................................................................................. 426
19.9.17 Control Equations-PID-PL block ................................................................................................ 426
19.9.18 Output Indication Function .......................................................................................................... 427
19.9.19 Tuning Constant Change Considerations .................................................................................... 429
19.9.20 Timeout monitoring ..................................................................................................................... 429
19.9.21 Windup handling-PID-PL block .................................................................................................. 429
19.9.24 Override feedback processing-PID-PL block .............................................................................. 432
19.9.25 PID-PL parameters ...................................................................................................................... 432
19.10 PIDER (PID with External Reset Feedback) Block ................................................................................... 433
19.10.1 Configuration example-PIDER block .......................................................................................... 434
19.10.2 Function ....................................................................................................................................... 446
19.10.3 Operating modes and mode handling-PIDER block ................................................................... 447
19.10.4 Required inputs-PIDER block ..................................................................................................... 447
19.10.5 Input ranges and limits-PIDER block .......................................................................................... 447
19.10.6 Initializable outputs-PIDER block ............................................................................................... 448
19.10.7 Control initialization-PIDER block ............................................................................................. 448
19.10.8 Output bias-PIDER block ............................................................................................................ 448
19.10.9 Output ranges and limits-PIDER block ....................................................................................... 450
19.10.10 Direct or reverse control-PIDER block ..................................................................................... 450
19.10.11 Set Point Ramping-PIDER block .............................................................................................. 450
19.10.12 PV tracking ................................................................................................................................ 453
11
CONTENTS
19.10.13 PID equations for PIDER block ................................................................................................ 453

19.10.14 PIDER equation variations ........................................................................................................ 454
19.10.15 Gain options ............................................................................................................................... 455
19.10.16 Output Indication Function- PIDER block ................................................................................ 456
19.10.17 Tuning Constant Change Considerations .................................................................................. 458
19.10.18 Timeout monitoring ................................................................................................................... 458
19.10.19 Timeout processing .................................................................................................................... 458
19.10.20 Windup handling ........................................................................................................................ 459
19.10.21 Windup processing ..................................................................................................................... 459
19.10.22 Anti-Reset Windup Status .......................................................................................................... 460
19.10.23 Override feedback processing-PIDER block ............................................................................. 461
19.10.24 Error handling for RFB and TRFB inputs ................................................................................. 461
19.10.25 Restart or point activation .......................................................................................................... 461
19.10.26 PIDER parameters ..................................................................................................................... 461
19.11 PIDFF (PID with Feedforward) Block ....................................................................................................... 462
19.11.1 Function-PIDFF block ................................................................................................................. 475
19.11.2 Functional scenario-PIDFF block ................................................................................................ 475
19.11.3 Operating modes and mode handling-PIDFF block .................................................................... 476
19.11.4 Required inputs-PIDFF block ...................................................................................................... 477
19.11.5 Input ranges and limits-PIDFF block ........................................................................................... 477
19.11.6 Initializable outputs-PIDFF block ............................................................................................... 477
19.11.7 Control initialization-PIDFF block .............................................................................................. 478
19.11.8 Output bias-PIDFF block ............................................................................................................. 478
19.11.9 Output ranges and limits-PIDFF block ........................................................................................ 480
19.11.10 Direct or reverse control for PIDFF block ................................................................................. 480
19.11.11 Set Point Ramping-PIDFF block ............................................................................................... 480
19.11.12 PV tracking-PIDFF block .......................................................................................................... 483
19.11.13 Feedforward add or multiply action and equations-PIDFF block ............................................. 484
19.11.14 Feedforward value status-PIDFF block ..................................................................................... 485
19.11.15 PID equations-PIDFF block ....................................................................................................... 485
19.11.16 Gain options-PIDFF block ......................................................................................................... 487
19.11.17 Output Indication Function-PIDFF block .................................................................................. 488
19.11.18 Tuning Constant Change Considerations-PIDFF block ............................................................. 490
19.11.19 Timeout monitoring-PIDFF block ............................................................................................. 490
19.11.20 Timeout processing-PIDFF block .............................................................................................. 490
19.11.21 Windup handling-PIDFF block .................................................................................................. 491
19.11.22 Windup processing-PIDFF block ............................................................................................... 491
19.11.23 Anti-Reset Windup Status-PIDFF block .................................................................................... 493
19.11.24 Bypassing feedforward control action-PIDFF block ................................................................. 493
19.11.25 Override feedback processing-PIDFF block .............................................................................. 494
19.11.26 PIDFF parameters ...................................................................................................................... 494
19.12 LEGACYGAP Option in R300 .................................................................................................................. 495
19.12.1 Legacy gap gain option ................................................................................................................ 495
19.12.2 Equation-LEGACYGAP ............................................................................................................. 495
19.12.3 Configuration-LEGACYGAP ..................................................................................................... 496
19.12.4 Migration-LEGACYGAP ............................................................................................................ 497
19.13 POSPROP (Position Proportional) Block ................................................................................................... 498
19.13.1 Function-POSPROP block ........................................................................................................... 505
19.13.2 Operating modes and mode handling-POSPROP block .............................................................. 506
19.13.3 Required inputs-POSPROP block ............................................................................................... 506
19.13.4 Input ranges and limits-POSPROP block .................................................................................... 507
19.13.5 Output-POSPROP block .............................................................................................................. 507
19.13.6 Initializable inputs and outputs-POSPROP block ....................................................................... 507
19.13.7 Output ranges-POSPROP block .................................................................................................. 508
CONTENTS
19.13.8 Set Point Ramping-POSPROP block ........................................................................................... 508

19.13.9 Timeout monitoring-POSPROP block ......................................................................................... 510
19.13.10 Timeout processing-POSPROP block ....................................................................................... 511
19.13.11 Equations-POSPROP block ....................................................................................................... 511
19.13.12 Control Initialization-POSPROP block ..................................................................................... 512
19.13.13 Secondary initialization option-POSPROP block ..................................................................... 512
19.13.14 Override feedback processing for POSPROP block .................................................................. 512
19.13.15 Raise/Lower limit switches of POSPROP block ....................................................................... 512
19.13.16 Bad control processing-POSPROP block .................................................................................. 512
19.13.17 Windup processing-POSPROP block ........................................................................................ 513
19.13.18 Anti-Reset Windup Status-POSPROP block ............................................................................. 515
19.13.19 POSPROP parameters ............................................................................................................... 515
19.14 PULSECOUNT Block ................................................................................................................................ 516
19.14.1 Function-PULSECOUNT block .................................................................................................. 517
19.14.2 Required inputs-PULSECOUNT block ....................................................................................... 517
19.14.3 Output-PULSECOUNT block ..................................................................................................... 518
19.14.4 Initializable inputs and outputs-PULSECOUNT block ............................................................... 518
19.14.5 PULSECOUNT parameters ......................................................................................................... 518
19.15 PULSELENGTH Block .............................................................................................................................. 519
19.15.1 Function-PULSELENGTH block ................................................................................................ 519
19.15.2 Required inputs-PULSELENGTH block .................................................................................... 520
19.15.3 Output-PULSELENGTH block ................................................................................................... 520
19.15.4 Initializable inputs and outputs-PULSELENGTH block ............................................................ 521
19.15.5 PULSELENGTH parameters ....................................................................................................... 521
19.16 RAMPSOAK Block ................................................................................................................................... 522
19.16.1 Function-RAMPSOAK block ...................................................................................................... 530
19.16.2 Required inputs-RAMPSOAK block .......................................................................................... 532
19.16.3 Input ranges and limits-RAMPSOAK block ............................................................................... 532
19.16.4 Initializable outputs-RAMPSOAK block .................................................................................... 532
19.16.5 Output ranges and limits-RAMPSOAK block ............................................................................ 532
19.16.6 Mode handling-RAMPSOAK block ............................................................................................ 533
19.16.7 Hold command-RAMPSOAK block ........................................................................................... 533
19.16.8 CEE idle or Control Module inactivate command-RAMPSOAK block ..................................... 533
19.16.9 Profile statistics-RAMPSOAK block .......................................................................................... 533
19.16.10 Guaranteed ramp rate-RAMPSOAK block ............................................................................... 534
19.16.11 Guaranteed soak time-RAMPSOAK block ............................................................................... 534
19.16.12 Event timer functions-RAMPSOAK block ............................................................................... 534
19.16.13 Control initialization-RAMPSOAK block ................................................................................ 535
19.16.14 Override feedback processing-RAMPSOAK block .................................................................. 535
19.16.15 Output Indication Function-RAMPSOAK block ...................................................................... 535
19.16.16 Windup processing-RAMPSOAK block ................................................................................... 536
19.16.17 Anti-Reset Windup Status-RAMPSOAK block ........................................................................ 537
19.16.18 RAMPSOAK parameters ........................................................................................................... 538
19.17 RATIOBIAS Block ..................................................................................................................................... 539
19.17.1 Function-RATIOBIAS block ....................................................................................................... 546
19.17.2 Configuration example-RATIOBIAS block ................................................................................ 546
19.17.3 Operating modes and mode handling-RATIOBIAS block .......................................................... 547
19.17.4 Required inputs-RATIOBIAS block ............................................................................................ 547
19.17.5 Input ranges and limits-RATIOBIAS block ................................................................................ 547
19.17.6 Initializable outputs-RATIOBIAS block ..................................................................................... 548
19.17.7 Output ranges and limits-RATIOBIAS block .............................................................................. 548
19.17.8 Control initialization-RATIOBIAS block .................................................................................... 549
19.17.9 Ratio bias option-RATIOBIAS block .......................................................................................... 549
19.17.10 Output bias-RATIOBIAS block ................................................................................................. 550
13
CONTENTS
19.17.11 Timeout monitoring-RATIOBIAS block ................................................................................... 552

19.17.12 Timeout processing-RATIOBIAS block .................................................................................... 552
19.17.13 Override feedback processing .................................................................................................... 552
19.17.14 Output Indication Function-RATIOBIAS block ........................................................................ 553
19.17.15 Windup handling-RATIOBIAS block ........................................................................................ 554
19.17.16 Windup processing-RATIOBIAS block .................................................................................... 555
19.17.17 Anti-Reset Windup Status-RATIOBIAS block ......................................................................... 556
19.17.18 RATIOBIAS parameters ............................................................................................................ 557
19.18 RATIOCTL (Ratio Control) Block ............................................................................................................. 558
19.18.1 Function-RATIOCTL block ......................................................................................................... 567
19.18.2 Configuration example-RATIOCTL block .................................................................................. 567
19.18.3 Operating modes and mode handling-RATIOCTL block ............................................................ 568
19.18.4 Required inputs-RATIOCTL block ............................................................................................. 568
19.18.5 Input ranges and limits-RATIOCTL block .................................................................................. 568
19.18.6 Initializable outputs-RATIOCTL block ....................................................................................... 568
19.18.7 Output ranges and limits-RATIOCTL block ............................................................................... 569
19.18.8 Control initialization-RATIOCTL block ..................................................................................... 569
19.18.9 Equations-RATIOCTL block ....................................................................................................... 570
19.18.10 Output bias-RATIOCTL block .................................................................................................. 571
19.18.11 Timeout monitoring-RATIOCTL block ..................................................................................... 573
19.18.12 Timeout processing-RATIOCTL block ..................................................................................... 573
19.18.13 Override feedback processing-RATIOCTL block ..................................................................... 573
19.18.14 Output Indication Function-RATIOCTL block ......................................................................... 574
19.18.15 Windup handling-RATIOCTL block ......................................................................................... 576
19.18.16 Windup processing-RATIOCTL block ...................................................................................... 576
19.18.17 Anti-Reset Windup Status-RATIOCTL block ........................................................................... 578
19.18.18 Restart or point activation-RATIOCTL block ........................................................................... 578
19.18.19 Error handling-RATIOCTL block ............................................................................................. 579
19.18.20 RATIOCTL parameters ............................................................................................................. 579
19.19 REGCALC (Regulatory Control Calculator) Block ................................................................................... 580
19.19.1 Function-REGCALC block ......................................................................................................... 589
19.19.2 Operating modes and mode handling-REGCALC block ............................................................ 589
19.19.3 Inputs-REGCALC block ............................................................................................................. 589
19.19.4 Input ranges and limits-REGCALC block ................................................................................... 589
19.19.5 Initializable outputs-REGCALC block ........................................................................................ 590
19.19.6 Output ranges and limits-REGCALC block ................................................................................ 590
19.19.7 Assignable outputs-REGCALC block ......................................................................................... 590
19.19.8 Output assignment rules-REGCALC block ................................................................................. 591
19.19.9 Control initialization-REGCALC block ...................................................................................... 592
19.19.10 Output bias-REGCALC block ................................................................................................... 592
19.19.11 Timeout monitoring-REGCALC block ..................................................................................... 594
19.19.12 Timeout processing-REGCALC block ...................................................................................... 594
19.19.13 Override feedback processing-REGCALC block ...................................................................... 594
19.19.14 Output Indication Function-REGCALC block .......................................................................... 595
19.19.15 Windup handling-REGCALC block .......................................................................................... 597
19.19.16 Windup processing-REGCALC block ....................................................................................... 597
19.19.17 Anti-Reset Windup Status-REGCALC block ............................................................................ 599
19.19.18 Expressions-REGCALC block .................................................................................................. 599
19.19.19 Parameters in Expressions-REGCALC block ........................................................................... 601
19.19.20 Guidelines for Writing Expressions-REGCALC block ............................................................. 601
19.19.21 String data support in expressions-REGCALC block ............................................................... 602
19.19.22 Time support in expressions-REGCALC block ........................................................................ 603
19.19.23 REGCALC parameters .............................................................................................................. 604
19.20 REEOUT (Remote EEOUT) Block ............................................................................................................ 605
CONTENTS
19.20.1 Function-REEOUT block ............................................................................................................ 605

19.20.2 Configuration Example-REEOUT block ..................................................................................... 606
19.20.3 Inputs-REEOUT block ................................................................................................................ 606
19.20.4 Outputs-REEOUT block .............................................................................................................. 606
19.20.5 Push of SP to secondary cluster's regulatory FBs-REEOUT block ............................................. 606
19.20.6 REEOUT parameters ................................................................................................................... 607
19.21 REGSUMMER (Regulatory Summer) Block ............................................................................................ 608
19.21.1 Equation-REGSUMMER block .................................................................................................. 616
19.21.2 Function-REGSUMMER block ................................................................................................... 616
19.21.3 Configuration example-REGSUMMER block ............................................................................ 616
19.21.4 Inputs-REGSUMMER block ....................................................................................................... 617
19.21.5 Outputs-REGSUMMER block .................................................................................................... 617
19.21.6 Initializable inputs and outputs-REGSUMMER block ............................................................... 618
19.21.7 Output Ranges-REGSUMMER block ......................................................................................... 618
19.21.8 Output bias-REGSUMMER block .............................................................................................. 618
19.21.9 Mode handling-REGSUMMER block ........................................................................................ 619
19.21.10 Control initialization-REGSUMMER block ............................................................................. 619
19.21.11 Override feedback processing-REGSUMMER block ............................................................... 620
19.21.12 Output Indication Function-REGSUMMER block ................................................................... 621
19.21.13 Windup processing-REGSUMMER block ................................................................................ 622
19.21.14 REGSUMMER parameters ....................................................................................................... 624
19.22 REMCAS (Remote Cascade) Block ........................................................................................................... 625
19.22.1 Function-REMCAS block ........................................................................................................... 632
19.22.2 Configuration example-REMCAS block ..................................................................................... 633
19.22.3 Inputs-REMCAS block ................................................................................................................ 636
19.22.4 Input ranges and limits-REMCAS block ..................................................................................... 636
19.22.5 Input descriptors-REMCAS block ............................................................................................... 636
19.22.6 Outputs-REMCAS block ............................................................................................................. 636
19.22.7 Output ranges and limits-REMCAS block .................................................................................. 637
19.22.8 Output Indication Function-REMCAS block .............................................................................. 637
19.22.9 Mode handling-REMCAS block ................................................................................................. 639
19.22.10 Timeout monitoring-REMCAS block ....................................................................................... 640
19.22.11 Timeout processing-REMCAS block ........................................................................................ 640
19.22.12 Input switching-REMCAS block ............................................................................................... 640
19.22.13 Equations-REMCAS block ........................................................................................................ 641
19.22.14 Output bias-REMCAS block ..................................................................................................... 641
19.22.15 Control Initialization-REMCAS block ...................................................................................... 642
19.22.16 Override feedback processing-REMCAS block ........................................................................ 643
19.22.17 Windup processing-REMCAS block ......................................................................................... 643
19.22.18 Anti-Reset Windup Status-REMCAS block .............................................................................. 645
19.22.19 REMCAS parameters ................................................................................................................ 646
19.23 SWITCH Block .......................................................................................................................................... 647
19.23.1 Function-SWITCH block ............................................................................................................. 654
19.23.2 Inputs-SWITCH block ................................................................................................................. 655
19.23.3 Input ranges and limits-SWITCH block ...................................................................................... 655
19.23.4 Input descriptors-SWITCH block ................................................................................................ 656
19.23.5 Initializable Outputs-SWITCH block .......................................................................................... 656
19.23.6 Output ranges and limits-SWITCH block ................................................................................... 656
19.23.7 Mode handling-SWITCH block .................................................................................................. 656
19.23.8 Timeout monitoring-SWITCH block ........................................................................................... 657
19.23.9 Timeout processing-SWITCH block ........................................................................................... 657
19.23.10 Equations-SWITCH block ......................................................................................................... 657
19.23.11 Bad input handling-SWITCH block .......................................................................................... 658
19.23.12 Bypass processing-SWITCH block ........................................................................................... 659
15
CONTENTS
19.23.13 Input switching-SWITCH block ................................................................................................ 659

19.23.14 Output bias-SWITCH block ...................................................................................................... 659
19.23.15 Error handling-SWITCH block ................................................................................................. 660
19.23.16 Control initialization-SWITCH block ....................................................................................... 661
19.23.17 Override feedback processing-SWITCH block ......................................................................... 661
19.23.18 Output Indication Function-SWITCH block ............................................................................. 662
19.23.19 Windup processing-SWITCH block .......................................................................................... 663
19.23.20 Anti-Reset Windup Status-SWITCH block ............................................................................... 665
19.23.21 SWITCH parameters ................................................................................................................. 665
20 UCN Interface .................................................................................................................................... 667
20.1 Universal Control Network (UCN) Interface Block Library ........................................................................ 668
20.2 UCNOUT/EUCNOUT block ........................................................................................................................ 669
20.2.1 About remote cascade - UCNOUT/EUCNOUT block .................................................................. 670
20.2.2 Configuration form overview ........................................................................................................ 671
20.2.3 Input/Output - UCNOUT/EUCNOUT block ................................................................................. 672
20.2.4 Configuration example - UCNOUT/EUCNOUT block ................................................................ 673
20.2.5 UCNOUT/EUCNOUT parameters ................................................................................................ 675
21 Hiway Interface ................................................................................................................................. 677
21.1 Hiway Interface (HIWAYIF) Block Library ................................................................................................. 678
21.2 HIWAYOUT Block ....................................................................................................................................... 679
21.2.1 About remote cascade-HIWAYOUT Block ................................................................................... 680
21.2.2 Configuration form overview-HIWAYOUT Block ....................................................................... 680
21.2.3 Input/Output-HIWAYOUT Block .................................................................................................. 681
21.2.4 Configuration example-HIWAYOUT Block ................................................................................. 682
21.2.5 Load and Execution-HIWAYOUT Block ...................................................................................... 683
21.2.6 HIWAYOUT parameters ................................................................................................................ 683
22 Exchange Functions ........................................................................................................................ 685
22.1 Exchange Function Blocks ........................................................................................................................... 686
22.2 REQFLAGARRAY Block ............................................................................................................................ 687
22.2.1 Function-REQFLAGARRAY Block ............................................................................................. 690
22.2.2 Input/Output-REQFLAGARRAY Block ....................................................................................... 690
22.2.3 REQFLAGARRAY parameters ..................................................................................................... 690
22.3 REQNUMARRAY Block ............................................................................................................................. 691
22.3.1 Function-REQNUMARRAY Block .............................................................................................. 694
22.3.2 Input/Output-REQNUMARRAY Block ........................................................................................ 694
22.3.3 REQNUMARRAY parameters ...................................................................................................... 694
22.4 REQTEXTARRAY Block ............................................................................................................................ 695
22.4.1 Function-REQTEXTARRAY Block .............................................................................................. 698
22.4.2 Input/Output-REQTEXTARRAY Block ....................................................................................... 698
22.4.3 REQTEXTARRAY parameters ..................................................................................................... 698
22.5 RSPFLAGARRAY Block ............................................................................................................................. 699
22.5.1 Function-RSPFLAGARRAY Block .............................................................................................. 699
22.5.2 Input/Output-RSPFLAGARRAY Block ........................................................................................ 700
22.5.3 RSPFLAGARRAY parameters ...................................................................................................... 700
22.6 RSPNUMARRAY Block .............................................................................................................................. 701
22.6.1 Function-RSPNUMARRAY Block ............................................................................................... 701
22.6.2 Input/Output-RSPNUMARRAY Block ......................................................................................... 702
22.6.3 RSPNUMARRAY parameters ....................................................................................................... 702
22.7 RSPTEXTARRAY Block ............................................................................................................................. 703
22.7.1 Function-RSPTEXTARRAY Block ............................................................................................... 703
22.7.2 Input/Output-RSPTEXTARRAY Block ........................................................................................ 704
22.7.3 RSPTEXTARRAY parameters ...................................................................................................... 704
CONTENTS
23 Auxiliary Function Blocks ............................................................................................................... 705

23.1 Common auxiliary block functions .............................................................................................................. 707
23.2 AUXCALC (Auxiliary Calculation) Block .................................................................................................. 708
23.2.1 Function-AUXCALC block ........................................................................................................... 708
23.2.2 Configuration example-AUXCALC block .................................................................................... 709
23.2.3 Input-AUXCALC block ................................................................................................................ 710
23.2.4 Output-AUXCALC block .............................................................................................................. 710
23.2.5 Expressions-AUXCALC block ..................................................................................................... 710
23.2.6 Parameters in Expressions-AUXCALC block ............................................................................... 711
23.2.7 Guidelines for Writing Expressions-AUXCALC block ................................................................ 711
23.2.8 Assignable Outputs-AUXCALC block ......................................................................................... 712
23.2.9 AUXCALC parameters ................................................................................................................. 712
23.3 AUXSUMMER (Auxiliary Summer) Block ................................................................................................ 713
23.3.1 Function-AUXSUMMER block .................................................................................................... 713
23.3.2 Configuration parameters-AUXSUMMER block ......................................................................... 714
23.3.3 Configuration example-AUXSUMMER block ............................................................................. 714
23.3.4 Input-AUXSUMMER block .......................................................................................................... 715
23.3.5 Output-AUXSUMMER block ....................................................................................................... 715
23.3.6 Error handling-AUXSUMMER block ........................................................................................... 716
23.3.7 Restart or point activation-AUXSUMMER block ........................................................................ 716
23.3.8 AUXSUMMER parameters ........................................................................................................... 716
23.4 CTUD (COUNTER UP/DOWN) Block ....................................................................................................... 717
23.4.1 Function-CTUD block ................................................................................................................... 717
23.4.2 Inputs-CTUD block ....................................................................................................................... 718
23.4.3 Outputs-CTUD block ..................................................................................................................... 719
23.4.4 Edge or Level trigger mechanism-CTUD block ............................................................................ 719
23.4.5 Supported algorithms-CTUD block ............................................................................................... 722
23.4.6 Counter overflow and underflow conditions-CTUD block ........................................................... 722
23.4.7 Effects of restart or point activation on CTUD .............................................................................. 724
23.4.8 Effects of Import or Export on CTUD ........................................................................................... 724
23.4.9 Effects of Checkpoint operations CTUD ....................................................................................... 724
23.4.10 Parameter error handling-CTUD block ....................................................................................... 725
23.4.11 CTUD parameters ........................................................................................................................ 725
23.5 DEADTIME Block ....................................................................................................................................... 726
23.5.1 Function-DEADTIME block ......................................................................................................... 727
23.5.2 Input-DEADTIME block ............................................................................................................... 728
23.5.3 Output-DEADTIME block ............................................................................................................ 728
23.5.4 PV status-DEADTIME block ........................................................................................................ 728
23.5.5 Error handling-DEADTIME block ................................................................................................ 728
23.5.6 Delay type-DEADTIME block ...................................................................................................... 728
23.5.7 Delay table-DEADTIME block ..................................................................................................... 729
23.5.8 Restart condition-DEADTIME block ............................................................................................ 730
23.5.9 DEADTIME parameters ................................................................................................................ 730
23.6 ENHAUXCALC (Enhanced Auxiliary Calculation) Block ......................................................................... 731
23.6.1 Function-ENHAUXCALC block .................................................................................................. 731
23.6.2 Configuration parameters-ENHAUXCALC block ........................................................................ 732
23.6.3 Input-ENHAUXCALC block ........................................................................................................ 733
23.6.4 Output-ENHAUXCALC block ..................................................................................................... 733
23.6.5 Expressions-ENHAUXCALC block ............................................................................................. 733
23.6.6 Parameters in Expressions-ENHAUXCALC block ...................................................................... 733
23.6.7 Guidelines for Writing Expressions-ENHAUXCALC block ........................................................ 734
23.6.8 Enable/Disable switch example expression-ENHAUXCALC block ............................................ 735
23.6.9 Scaled Input example expression-ENHAUXCALC block ............................................................ 735
23.6.10 Assignable Outputs-ENHAUXCALC block ............................................................................... 736
17
CONTENTS
23.6.11 ENHAUXCALC parameters ....................................................................................................... 736

23.7 ENHGENLIN (Enhanced General Linearization) Block ............................................................................. 737
23.7.1 Function-ENHGENLIN block ....................................................................................................... 738
23.7.2 Configuration Parameters-ENHGENLIN block ............................................................................ 739
23.7.3 Configuration Example-ENHGENLIN block ............................................................................... 739
23.7.4 Input-ENHGENLIN block ............................................................................................................. 740
23.7.5 Output-ENHGENLIN block .......................................................................................................... 740
23.7.6 Error Handling-ENHGENLIN block ............................................................................................. 740
23.7.7 Strategy Optimization using ENHGENLIN block ........................................................................ 741
23.7.8 ENHGENLIN block - Usage Scenario .......................................................................................... 741
23.7.9 ENHGENLIN parameters .............................................................................................................. 746
23.8 FLOWCOMP (Flow Compensation) Block ................................................................................................. 747
23.8.1 Function-FLOWCOMP block ....................................................................................................... 747
23.8.2 Configuration parameters-FLOWCOMP block ............................................................................ 748
23.8.3 Input-FLOWCOMP block ............................................................................................................. 749
23.8.4 Output-FLOWCOMP block .......................................................................................................... 749
23.8.5 Equations-FLOWCOMP block ..................................................................................................... 749
23.8.6 Additional considerations for FLOWCOMP Equation A ............................................................. 750
23.8.7 Error handling-FLOWCOMP block .............................................................................................. 752
23.8.8 Alarm behavior-FLOWCOMP block ............................................................................................ 752
23.8.9 Alarm example-FLOWCOMP block ............................................................................................. 753
23.8.10 Fail-Safe values-FLOWCOMP block .......................................................................................... 753
23.8.11 FLOWCOMP parameters ............................................................................................................ 753
23.9 GENLIN (General Linearization) Block ...................................................................................................... 754
23.9.1 Function-GENLIN block ............................................................................................................... 755
23.9.2 Inputs ............................................................................................................................................. 755
23.9.3 Outputs-GENLIN block ................................................................................................................. 755
23.9.4 Error handling-GENLIN block ...................................................................................................... 755
23.9.5 GENLIN parameters ...................................................................................................................... 755
23.10 LEADLAG Block ....................................................................................................................................... 756
23.10.1 Function-LEADLAG block ......................................................................................................... 757
23.10.2 Input-LEADLAG block ............................................................................................................... 757
23.10.3 Output-LEADLAG block ............................................................................................................ 757
23.10.4 PV status-LEADLAG block ........................................................................................................ 758
23.10.5 Error handling-LEADLAG block ................................................................................................ 758
23.10.6 Equation-LEADLAG block ......................................................................................................... 758
23.10.7 Time constant recommendations-LEADLAG block ................................................................... 758
23.10.8 Restart condition-LEADLAG block ............................................................................................ 759
23.10.9 LEADLAG parameters ................................................................................................................ 759
23.11 ROC (Rate of Change) Block ..................................................................................................................... 760
23.11.1 Function-ROC block .................................................................................................................... 762
23.11.2 Configuration examples-ROC block ............................................................................................ 763
23.11.3 Inputs-ROC block ........................................................................................................................ 764
23.11.4 Outputs-ROC block ..................................................................................................................... 764
23.11.5 Error handling-ROC block ........................................................................................................... 764
23.11.6 ROC parameters ........................................................................................................................... 764
23.12 SIGNALSEL (Signal Selector) Block ........................................................................................................ 765
23.12.1 Function-SIGNALSEL block ...................................................................................................... 765
23.12.2 Configuration parameters-SIGNALSEL block ........................................................................... 766
23.12.3 Configuration examples-SIGNALSEL block .............................................................................. 768
23.12.4 Input-SIGNALSEL block ............................................................................................................ 772
23.12.5 Ignore Inputs-SIGNALSEL block ............................................................................................... 772
23.12.6 Ignore Limit Checking-SIGNALSEL block ................................................................................ 773
23.12.7 Output-SIGNALSEL block ......................................................................................................... 773
CONTENTS
23.12.8 Selection Methods-SIGNALSEL block ...................................................................................... 773

23.12.9 Force-Select-SIGNALSEL block ................................................................................................ 775
23.12.10 Bumpless Input Switching-SIGNALSEL block ........................................................................ 775
23.12.11 Deviation Alarming-SIGNALSEL block .................................................................................. 775
23.12.12 Deviation Alarm Deadband-SIGNALSEL block ...................................................................... 775
23.12.13 Deviation Alarm Deadband Units-SIGNALSEL block ............................................................ 776
23.12.14 Error handling-SIGNALSEL block ........................................................................................... 776
23.12.15 Restart or point activation-SIGNALSEL block ......................................................................... 776
23.12.16 Parameters for Checkpoint-SIGNALSEL block ....................................................................... 776
23.12.17 SIGNALSEL parameters ........................................................................................................... 777
23.13 TOTALIZER Block .................................................................................................................................... 778
23.13.1 Description ................................................................................................................................... 778
23.13.2 Function-TOTALIZER block ...................................................................................................... 778
23.13.3 Configuration example-TOTALIZER block ................................................................................ 778
23.13.4 Input-TOTALIZER block ............................................................................................................ 780
23.13.5 Outputs-TOTALIZER block ........................................................................................................ 780
23.13.6 TOTALIZER states ...................................................................................................................... 780
23.13.7 Accumulator target value-TOTALIZER block ............................................................................ 781
23.13.8 Deviation trip points-TOTALIZER block ................................................................................... 781
23.13.9 Equations-TOTALIZER block ..................................................................................................... 781
23.13.10 Accumulated value calculation-TOTALIZER block ................................................................. 782
23.13.11 Error handling-TOTALIZER block ........................................................................................... 783
23.13.12 Restart and activation-TOTALIZER block ................................................................................ 783
23.13.13 TOTALIZER parameters ........................................................................................................... 783
24 Data Acquisition Functions ............................................................................................................. 785
24.1 DATAACQ (Data Acquisition) Block .......................................................................................................... 786
24.1.1 Function-DATAACQ block ........................................................................................................... 790
24.1.2 CAB Insertions for DATAACQ block parameters ........................................................................ 792
24.1.3 CAB insertion configuration considerations ................................................................................. 793
24.1.4 Insertion type functional characteristics-DATAACQ block .......................................................... 793
24.1.5 Pin connections to inserted CAB instances-DATAACQ block ..................................................... 794
24.1.6 CAB Insertion status and fail alarm-DATAACQ block ................................................................. 794
24.1.7 Handling of insertion failure-DATAACQ block ............................................................................ 794
24.1.8 CAB insertion configuration examples-DATAACQ block ........................................................... 795
24.1.9 Input-DATAACQ block ................................................................................................................. 799
24.1.10 Input ranges and limits-DATAACQ block ................................................................................... 799
24.1.11 P1 status ....................................................................................................................................... 799
24.1.12 PV Characterization-DATAACQ block ....................................................................................... 800
24.1.13 Input filtering-DATAACQ block ................................................................................................. 800
24.1.14 Input clamping-DATAACQ block ............................................................................................... 801
24.1.15 Low signal cut off-DATAACQ block .......................................................................................... 801
24.1.16 Output-DATAACQ block ............................................................................................................ 801
24.1.17 PV source selection-DATAACQ block ........................................................................................ 802
24.1.18 PV status-DATAACQ block ........................................................................................................ 802
24.1.19 Alarm processing-DATAACQ block ........................................................................................... 802
24.1.20 Additional Rate of Change Alarm considerations-DATAACQ block ......................................... 804
24.1.21 PV significant-change alarming-DATAACQ block .................................................................... 804
24.1.22 Bad PV alarm-DATAACQ block ................................................................................................. 804
24.1.23 DATAACQ parameters ................................................................................................................ 804
25 Pulse Input ........................................................................................................................................ 805
25.1 Pulse Input Block .......................................................................................................................................... 806
25.2 PITOTALIZER Block ................................................................................................................................... 807
25.2.1 Function-PITOTALIZER block ..................................................................................................... 807
19
CONTENTS
25.2.2 Configuration example-PITOTALIZER block .............................................................................. 807

25.2.3 Input-PITOTALIZER block ........................................................................................................... 809
25.2.4 Outputs-PITOTALIZER block ...................................................................................................... 809
25.2.5 PITOTALIZER states .................................................................................................................... 809
25.2.6 Accumulator target value-PITOTALIZER block .......................................................................... 810
25.2.7 Deviation trip points-PITOTALIZER block .................................................................................. 810
25.2.8 Near-Zero Cutoff-PITOTALIZER block ....................................................................................... 810
25.2.9 Bad Input Handling and Warm-Restart Options-PITOTALIZER block ....................................... 810
25.2.10 Bad Input Options (PVEQN) Selection Summary ....................................................................... 811
25.2.11 Control Module Activation-PITOTALIZER block ...................................................................... 811
25.2.12 Operating Algorithms-PITOTALIZER block .............................................................................. 811
25.2.13 Pulse versus Analog Operation .................................................................................................... 812
25.2.14 Error handling-PITOTALIZER block .......................................................................................... 812
25.2.15 Restart and activation-PITOTALIZER block .............................................................................. 813
25.2.16 PITOTALIZER parameters .......................................................................................................... 813
26 Device Control .................................................................................................................................. 815
26.1 DEVCTL (Device Control) Block ................................................................................................................ 816
26.1.1 Function-DEVCTL block ............................................................................................................. 822
26.1.2 Configuration examples-DEVCTL block ...................................................................................... 825
26.1.3 Inputs-DEVCTL block .................................................................................................................. 827
26.1.4 Outputs-DEVCTL block ................................................................................................................ 827
26.1.5 States-DEVCTL block ................................................................................................................... 828
26.1.6 State parameters and descriptors-DEVCTL block ........................................................................ 828
26.1.7 Two-State motor input example-DEVCTL block .......................................................................... 829
26.1.8 Valve input example-DEVCTL block ........................................................................................... 830
26.1.9 Two-Input motor example-DEVCTL block .................................................................................. 830
26.1.10 Reversible motor input example-DEVCTL block ....................................................................... 830
26.1.11 Four-Input two-valve example-DEVCTL block .......................................................................... 831
26.1.12 DI to PV state map ....................................................................................................................... 832
26.1.13 Two-State motor with latched output example ............................................................................ 832
26.1.14 Valve Output Example-DEVCTL block ...................................................................................... 832
26.1.15 Three-State Motor output examples-DEVCTL block ................................................................. 832
26.1.16 Mode and mode attribute-DEVCTL block .................................................................................. 833
26.1.17 Safe output state-DEVCTL block ................................................................................................ 833
26.1.18 Momentary state-DEVCTL block ............................................................................................... 833
26.1.19 Local manual-DEVCTL block .................................................................................................... 834
26.1.20 Permissive interlocks-DEVCTL block ........................................................................................ 834
26.1.21 Safety Override Interlock-DEVCTL block ................................................................................. 835
26.1.22 Override Interlocks-DEVCTL block ........................................................................................... 835
26.1.23 Configurable Override/Permissive Interlock Bypass-DEVCTL block ....................................... 835
26.1.24 Alarms-DEVCTL block ............................................................................................................... 836
26.1.25 Seal-In option-DEVCTL block .................................................................................................... 837
26.1.26 Initialization Manual condition-DEVCTL block ......................................................................... 837
26.1.27 OP Initialization Option-DEVCTL block .................................................................................... 837
26.1.28 Initialization Manual Condition with Safety Override Interlock, Override Interlocks,
LocalMan, and OP Initialization .......................................................................................................... 838
26.1.29 Initialization with Pulse Output-DEVCTL block ........................................................................ 839
26.1.30 Initialization Request Flags-DEVCTL block .............................................................................. 840
26.1.31 OP and DO Initialization After Load-DEVCTL block ................................................................ 840
26.1.32 Maintenance Statistics-DEVCTL block ...................................................................................... 840
26.1.33 Output requests-DEVCTL block ................................................................................................. 841
26.1.34 Output command-DEVCTL block .............................................................................................. 841
26.1.35 Logic override OPREQ ................................................................................................................ 842
26.1.36 DEVCTL parameters ................................................................................................................... 842
CONTENTS
27 Logic Functions ................................................................................................................................ 843

27.1 Logic Function Blocks .................................................................................................................................. 844
27.1.1 Parameters-Logic Functions Blocks .............................................................................................. 860
27.2 Change Execute (CHGEXEC) Block ........................................................................................................... 861
27.3 CHGEXEC Usage Considerations for Change Driven Execution ............................................................... 862
27.4 Change Driven Application Risk Factors ..................................................................................................... 863
27.5 Blocks Qualified for Use with CHGEXEC Block ........................................................................................ 864
27.6 Experion Controller Platform Support for CHGEXEC ................................................................................ 867
27.7 CHGEXEC Main Parameter Details ............................................................................................................ 868
27.8 CHGEXEC Cascading Between Control Modules Example ....................................................................... 870
27.8.1 Graphical Examples of Cascaded CHGEXEC control charts ....................................................... 870
27.8.2 Cascaded CHGEXEC functional considerations ........................................................................... 871
27.9 CHGEXEC Cascading Within Control Module Example ............................................................................ 873
27.9.1 EXITOPT considerations for cascaded CHGEXEC in single CM ................................................ 873
27.10 Importance of Using Consistent Input Data ............................................................................................... 874
27.10.1 Wrong input data example ........................................................................................................... 874
27.10.2 Correct input data example .......................................................................................................... 875
27.11 Periodic Auto Trigger Function of CHGEXEC .......................................................................................... 876
27.11.1 Auto Trigger application support ................................................................................................. 876
27.11.2 ATUOPERIOD sets period for Auto Trigger ............................................................................... 876
27.11.3 TRIGGER output and Auto Trigger execution ............................................................................ 877
27.11.4 Relationship between Auto Trigger and AUTOPHASE for synchronization prevention ........... 877
27.11.5 AUTOPERIOD configuration restrictions ................................................................................... 877
27.12 Execution Order Considerations for CHGEXEC within CM ..................................................................... 879
27.13 CHGEXEC Behaviors for State Transitions ............................................................................................... 880
27.14 CHGEXEC Supports Checkpoint Function ................................................................................................ 885
27.15 Load Monitoring Parameters ...................................................................................................................... 886
27.16 Sample CHGEXEC TESTOPT Procedure ................................................................................................. 887
27.17 Examples and scenarios .............................................................................................................................. 888
27.17.1 CheckBool functionality .............................................................................................................. 888
27.17.2 CheckBool scenario 1 .................................................................................................................. 890
27.18 Contact Monitoring (CONTACTMON) Block .......................................................................................... 894
27.18.1 Function-CONTACTMON block ................................................................................................ 894
27.18.2 Predecessor Block-CONTACTMON block ................................................................................. 894
27.18.3 Execution-CONTACTMON block .............................................................................................. 894
28 Math Functions ................................................................................................................................. 897
28.1 Math Function Blocks ................................................................................................................................... 898
28.1.1 Available Math blocks and size ..................................................................................................... 898
28.1.2 Math blocks functional description ............................................................................................... 899
28.1.3 Rolling Average block-CONTACTMON block ............................................................................ 901
29 Power Generation Functions .......................................................................................................... 905
29.1 POWERGEN Function Blocks ..................................................................................................................... 906
29.2 GRPCAPRBK (Group Capability and Runback) Block .............................................................................. 907
29.2.1 Function-GRPCAPRBK block ...................................................................................................... 908
29.2.2 Configuration examples-GRPCAPRBK block .............................................................................. 910
29.2.3 Inputs-GRPCAPRBK block .......................................................................................................... 911
29.2.4 Outputs-GRPCAPRBK block ........................................................................................................ 911
29.2.5 Error handling-GRPCAPRBK block ............................................................................................. 911
29.2.6 GRPCAPRBK parameters ............................................................................................................. 912
29.3 HTMOTOR (HT Motor Drive Control) Block ............................................................................................. 913
21
CONTENTS
29.3.1 Function-HTMOTOR block .......................................................................................................... 921

29.3.2 Configuration examples-HTMOTOR block .................................................................................. 922
29.3.3 Inputs-HTMOTOR block .............................................................................................................. 930
29.3.4 Outputs-HTMOTOR block ............................................................................................................ 931
29.3.5 Error handling-HTMOTOR block ................................................................................................. 931
29.3.6 States-HTMOTOR block ............................................................................................................... 932
29.3.7 State parameters and descriptors-HTMOTOR block ..................................................................... 932
29.3.8 Mode and mode attribute-HTMOTOR block ................................................................................ 933
29.3.9 Safe output state-HTMOTOR block .............................................................................................. 933
29.3.10 Command dependency on switches and Mode attribute-HTMOTOR block .............................. 933
29.3.11 Local manual-HTMOTOR block ................................................................................................. 934
29.3.12 Permissive interlocks-HTMOTOR block .................................................................................... 934
29.3.13 Safety Override Interlock-HTMOTOR block .............................................................................. 934
29.3.14 Override Interlocks-HTMOTOR block ....................................................................................... 935
29.3.15 Configurable Override/Permissive Interlock Bypass-HTMOTOR block ................................... 935
29.3.16 Alarms-HTMOTOR block ........................................................................................................... 935
29.3.17 Seal-in option-HTMOTOR block ................................................................................................ 936
29.3.18 FIRSTUP functionality-HTMOTOR block ................................................................................. 936
29.3.19 Initialization Manual condition-HTMOTOR block ..................................................................... 936
29.3.20 OP initialization option-HTMOTOR block ................................................................................. 937
29.3.21 Initialization Manual condition with Safety Override Interlock, Override Interlocks,
LocalMan, and OP initialization-HTMOTOR block ........................................................................... 937
29.3.22 Initialization with pulse output-HTMOTOR block ..................................................................... 937
29.3.23 Initialization request flags-HTMOTOR block ............................................................................. 937
29.3.24 OP and DO initialization after load-HTMOTOR block .............................................................. 938
29.3.25 Maintenance statistics-HTMOTOR block ................................................................................... 938
29.3.26 Output requests-HTMOTOR block ............................................................................................. 938
29.3.27 Output command-HTMOTOR block ........................................................................................... 938
29.3.28 Logic override OPREQ-HTMOTOR block ................................................................................. 939
29.3.29 Monitoring HT Motor Current ..................................................................................................... 939
29.3.30 HTMOTOR parameters ............................................................................................................... 940
29.4 LEVELCOMP (Drum Level Computation) Block ....................................................................................... 941
29.4.1 Function-LEVELCOMP block ...................................................................................................... 943
29.4.2 Inputs-LEVELCOMP block .......................................................................................................... 944
29.4.3 Outputs-LEVELCOMP block ....................................................................................................... 944
29.4.4 Error handling-LEVELCOMP block ............................................................................................. 944
29.4.5 LEVELCOMP parameters ............................................................................................................. 945
29.5 LTMOTOR (LT Motor Drive Control) Block .............................................................................................. 946
29.5.1 Function-LTMOTOR block ........................................................................................................... 951
29.5.2 Configuration examples-LTMOTOR block ................................................................................... 952
29.5.3 Inputs-LTMOTOR block ............................................................................................................... 959
29.5.4 Outputs-LTMOTOR block ............................................................................................................. 959
29.5.5 Error handling-LTMOTOR block .................................................................................................. 960
29.5.6 States-LTMOTOR block ................................................................................................................ 960
29.5.7 State parameters and descriptors-LTMOTOR block ..................................................................... 960
29.5.8 Mode and mode attribute-LTMOTOR block ................................................................................. 961
29.5.9 Safe output state-LTMOTOR block ............................................................................................... 961
29.5.10 Command dependency on switches and mode attribute-LTMOTOR block ................................ 961
29.5.11 Local manual-LTMOTOR block .................................................................................................. 962
29.5.12 Permissive interlocks-LTMOTOR block ..................................................................................... 962
29.5.13 Safety Override Interlock-LTMOTOR block .............................................................................. 963
29.5.14 Override Interlocks-LTMOTOR block ........................................................................................ 963
29.5.15 Configurable Override/Permissive Interlock Bypass-LTMOTOR block .................................... 963
29.5.16 Alarms-LTMOTOR block ........................................................................................................... 963
29.5.17 Seal-in option-LTMOTOR block ................................................................................................. 964
CONTENTS
29.5.18 Initialization Manual condition-LTMOTOR block ..................................................................... 964

29.5.19 OP initialization option-LTMOTOR block .................................................................................. 965
29.5.20 Initialization Manual condition with Safety Override Interlock, Override Interlocks,
LocalMan, and OP initialization-LTMOTOR block ............................................................................ 965
29.5.21 Initialization with pulse output-LTMOTOR block ...................................................................... 965
29.5.22 Initialization request flags-LTMOTOR block ............................................................................. 965
29.5.23 OP and DO initialization after load-LTMOTOR block ............................................................... 966
29.5.24 Maintenance statistics-LTMOTOR block .................................................................................... 966
29.5.25 Output requests-LTMOTOR block .............................................................................................. 966
29.5.26 Output command-LTMOTOR block ........................................................................................... 966
29.5.28 LTMOTOR parameters ................................................................................................................ 967
29.6 MAINIBV (IBV Logic) Block ..................................................................................................................... 968
29.6.1 Function-MAINIBV block ............................................................................................................ 970
29.6.2 Inputs-MAINIBV block ................................................................................................................. 970
29.6.3 Outputs-MAINIBV block .............................................................................................................. 970
29.6.4 Control logic-MAINIBV block ..................................................................................................... 970
29.6.5 Open sequence logic-MAINIBV block ......................................................................................... 971
29.6.6 Close sequence logic-MAINIBV block ......................................................................................... 972
29.6.7 Error handling-MAINIBV block ................................................................................................... 973
29.6.8 MAINIBV parameters ................................................................................................................... 973
29.7 SOLENOID (Solenoid Valve Drive Control) Block .................................................................................... 974
29.7.1 Function-SOLENOID block .......................................................................................................... 979
29.7.2 Configuration examples-SOLENOID block .................................................................................. 979
29.7.3 Inputs-SOLENOID block .............................................................................................................. 986
29.7.4 Outputs-SOLENOID block ........................................................................................................... 986
29.7.5 Error handling-SOLENOID block ................................................................................................. 987
29.7.6 States-SOLENOID block ............................................................................................................... 987
29.7.7 State parameters and descriptors-SOLENOID block .................................................................... 987
29.7.8 Mode and mode attribute-SOLENOID block ................................................................................ 988
29.7.9 Safe output state-SOLENOID block ............................................................................................. 988
29.7.10 Command dependency on switches and mode attribute-SOLENOID block ............................... 988
29.7.11 Local manual-SOLENOID block ................................................................................................ 989
29.7.12 Permissive interlocks-SOLENOID block .................................................................................... 989
29.7.13 Safety Override Interlock-SOLENOID block ............................................................................. 990
29.7.14 Override Interlocks-SOLENOID block ....................................................................................... 990
29.7.15 Configurable Override/Permissive Interlock Bypass-SOLENOID block ................................... 990
29.7.16 Alarms-SOLENOID block .......................................................................................................... 990
29.7.17 Seal-in option-SOLENOID block ................................................................................................ 991
29.7.18 Initialization Manual condition-SOLENOID block .................................................................... 992
29.7.19 OP initialization option-SOLENOID block ................................................................................. 992
LocalMan, and OP Initialization-SOLENOID block .......................................................................... 992
29.7.21 Initialization request flags-SOLENOID block ............................................................................ 992
29.7.22 OP and DO initialization after load-SOLENOID block .............................................................. 993
29.7.23 Maintenance statistics-SOLENOID block ................................................................................... 993
29.7.24 Output requests-SOLENOID block ............................................................................................. 993
29.7.25 Output command-SOLENOID block .......................................................................................... 993
29.7.27 SOLENOID parameters ............................................................................................................... 994
29.8 VALVEDAMPER (Valve/Damper Drive Control) Block ............................................................................ 995
29.8.1 Function-VALVEDAMPER block ............................................................................................... 1001
29.8.2 Configuration examples-VALVEDAMPER block ...................................................................... 1001
29.8.3 Inputs-VALVEDAMPER block ................................................................................................... 1008
29.8.4 Outputs-VALVEDAMPER block ................................................................................................ 1009
23
CONTENTS
29.8.5 Limit Switches-VALVEDAMPER block .................................................................................... 1009

29.8.6 Error handling-VALVEDAMPER block ..................................................................................... 1009
29.8.7 States-VALVEDAMPER block ................................................................................................... 1010
29.8.8 State parameters and descriptors-VALVEDAMPER block ......................................................... 1010
29.8.9 Mode and mode attribute-VALVEDAMPER block ..................................................................... 1011
29.8.10 Safe output state-VALVEDAMPER block ................................................................................ 1011
29.8.11 Command dependency on switches and Mode attribute-VALVEDAMPER block ................... 1011
29.8.12 Local manual-VALVEDAMPER block ..................................................................................... 1012
29.8.13 Permissive interlocks-VALVEDAMPER block ........................................................................ 1012
29.8.14 Safety Override Interlock-VALVEDAMPER block .................................................................. 1012
29.8.15 Override Interlocks-VALVEDAMPER block ............................................................................ 1012
29.8.16 Configurable Override/Permissive Interlock Bypass-VALVEDAMPER block ........................ 1013
29.8.17 Alarms-VALVEDAMPER block ............................................................................................... 1013
29.8.18 Seal-in option-VALVEDAMPER block .................................................................................... 1014
29.8.19 Initialization Manual condition-VALVEDAMPER block ......................................................... 1014
29.8.20 OP initialization option-VALVEDAMPER block ..................................................................... 1014
LocalMan, and OP Initialization-VALVEDAMPER block ............................................................... 1014
29.8.22 Initialization request flags-VALVEDAMPER block ................................................................. 1015
29.8.23 OP and DO initialization after load-VALVEDAMPER block ................................................... 1015
29.8.24 Maintenance statistics-VALVEDAMPER block ....................................................................... 1015
29.8.25 Output requests-VALVEDAMPER block .................................................................................. 1016
29.8.26 Output command-VALVEDAMPER block ............................................................................... 1016
29.8.27 Logic override OPREQ-VALVEDAMPER block ..................................................................... 1017
29.8.28 VALVEDAMPER parameters ................................................................................................... 1017
30 Thermodynamic Utility Functions ................................................................................................ 1019
30.1 Steam Property Block (STEAMPROP) ...................................................................................................... 1020
30.1.1 Function ....................................................................................................................................... 1021
30.1.2 Inputs/Outputs - STEAMPROP block ......................................................................................... 1022
30.1.3 Configuration parameters - STEAMPROP block ........................................................................ 1023
30.1.4 Configuration example - STEAMPROP block ............................................................................ 1024
30.1.5 Typical configuration of STEAMPROP block ............................................................................ 1026
30.1.6 Error handling - STEAMPROP block ......................................................................................... 1027
30.1.7 STEAMPROP block parameters ................................................................................................. 1027
31 I/O Reference blocks ...................................................................................................................... 1029
31.1 Configuration of Reference block .............................................................................................................. 1031
31.2 Behavior of Reference blocks when REFTYPE is configured as PARAMETER ..................................... 1034
31.3 AIREF (AI Reference block) ...................................................................................................................... 1036
31.3.1 Function-AIREF block ................................................................................................................ 1036
31.3.2 Configuration example-AIREF block .......................................................................................... 1036
31.4 AOREF (AO Reference block) ................................................................................................................... 1038
31.4.1 Function-AOREF ......................................................................................................................... 1038
31.4.2 Configuration example-AOREF block ........................................................................................ 1038
31.5 DIREF (DI Reference block) ...................................................................................................................... 1040
31.5.1 Function-DIREF .......................................................................................................................... 1040
31.5.2 Configuration example-DIREF block .......................................................................................... 1040
31.6 DOREF (DO Reference block) ................................................................................................................... 1042
31.6.1 Function-DOREF ......................................................................................................................... 1042
31.6.2 Configuration example-DOREF block ........................................................................................ 1042
31.7 Copying Reference blocks .......................................................................................................................... 1044
31.8 Bulk Build of CM containing Reference blocks ......................................................................................... 1045
31.9 Navigating from Reference block faceplate to parameters or I/O channels ............................................... 1046
31.10 UDT behavior of Reference blocks .......................................................................................................... 1047
CONTENTS
31.11 Limitations of Reference blocks ............................................................................................................... 1048

32 Utility Functions ............................................................................................................................. 1049
32.1 Utility Function Blocks ............................................................................................................................... 1050
32.2 ALMWINDOW (Alarm Window -Alarm Annunciator) Block ................................................................. 1052
32.2.1 Function-ALMWINDOW block ................................................................................................. 1053
32.2.2 Inputs-ALMWINDOW block ...................................................................................................... 1054
32.2.3 Outputs-ALMWINDOW block ................................................................................................... 1054
32.2.4 Alarms-ALMWINDOW block .................................................................................................... 1054
32.2.5 Error handling-ALMWINDOW block ........................................................................................ 1056
32.2.6 ALMWINDOW parameters ........................................................................................................ 1057
32.3 ANNPANEL (Annunciator Panel) Block ................................................................................................... 1058
32.3.1 Function-ANNPANEL block ....................................................................................................... 1059
32.3.2 Configuration Example-ANNPANEL block ............................................................................... 1059
32.3.3 Inputs-ANNPANEL block ........................................................................................................... 1060
32.3.4 Outputs-ANNPANEL block ........................................................................................................ 1060
32.3.5 Error Handling-ANNPANEL block ............................................................................................. 1060
32.3.6 ANNPANEL parameters .............................................................................................................. 1061
32.4 DIGACQ (Digital Acquisition) Block ........................................................................................................ 1062
32.4.1 Function-DIGACQ block ............................................................................................................ 1063
32.4.2 Configuration Scenario-DIGACQ block ..................................................................................... 1064
32.4.3 Inputs-DIGACQ block ................................................................................................................. 1065
32.4.4 Outputs-DIGACQ block .............................................................................................................. 1065
32.4.5 Error handling-DIGACQ block ................................................................................................... 1066
32.4.6 DIGACQ parameters ................................................................................................................... 1066
32.5 EXECTIMER Block ................................................................................................................................... 1067
32.5.1 Function-EXECTIMER block ..................................................................................................... 1069
32.5.2 Input-EXECTIMER block ........................................................................................................... 1069
32.5.3 Output-EXECTIMER block ........................................................................................................ 1070
32.5.4 EXECTIMER Parameters ............................................................................................................ 1070
32.5.5 EXECTIMER Example ............................................................................................................... 1070
32.5.6 Limitations-EXECTIMER block ................................................................................................. 1071
32.6 FIRSTOUT (First Out Detection) Block .................................................................................................... 1072
32.6.1 Function-FIRSTOUT block ......................................................................................................... 1073
32.6.2 Inputs-FIRSTOUT block ............................................................................................................. 1076
32.6.3 Outputs-FIRSTOUT block .......................................................................................................... 1076
32.6.4 Error handling-FIRSTOUT block ................................................................................................ 1076
32.6.5 First out detection FB parameters ................................................................................................ 1076
32.7 FLAG Block ............................................................................................................................................... 1077
32.7.1 Function-FLAG block ................................................................................................................. 1077
32.7.2 Input/Output-FLAG block ........................................................................................................... 1078
32.7.3 FLAG parameters ........................................................................................................................ 1078
32.8 FLAGARRAY Block .................................................................................................................................. 1079
32.8.1 Function-FLAGARRAY block .................................................................................................... 1079
32.8.2 Input/Output-FLAGARRAY block ............................................................................................. 1079
32.8.3 FLAGARRAY parameters ........................................................................................................... 1079
32.9 MESSAGE Block ....................................................................................................................................... 1080
32.9.1 Function-MESSAGE block ......................................................................................................... 1080
32.9.2 Configuration and Operation Considerations-MESSAGE block ................................................ 1081
32.9.3 Input/Output-MESSAGE block ................................................................................................... 1081
32.9.4 MESSAGE parameters ................................................................................................................ 1082
32.10 NUMERIC Block ..................................................................................................................................... 1083
32.10.1 Function-NUMERIC block ....................................................................................................... 1083
32.10.2 Input/Output-NUMERIC block ................................................................................................. 1083
32.10.3 NUMERIC parameters .............................................................................................................. 1083
25
CONTENTS
32.11 NUMERICARRAY Block ........................................................................................................................ 1084

32.11.1 Function-NUMERICARRAY block .......................................................................................... 1084
32.11.2 Input/Output-NUMERICARRAY block .................................................................................... 1084
32.11.3 NUMERICARRAY parameters ................................................................................................. 1084
32.12 PUSH Block ............................................................................................................................................. 1085
32.12.1 Function-PUSH block ................................................................................................................ 1085
32.12.2 Execution Status-PUSH block ................................................................................................... 1085
32.12.3 Store Status-PUSH block ........................................................................................................... 1085
32.12.4 PUSH parameters ....................................................................................................................... 1086
32.13 TEXTARRAY Block ................................................................................................................................ 1087
32.13.1 Function-TEXTARRAY block .................................................................................................. 1087
32.13.2 Input/Output-TEXTARRAY block ............................................................................................ 1087
32.13.3 TEXTARRAY parameters ......................................................................................................... 1087
32.14 TEXTCOMMENT (Text Comment) Block .............................................................................................. 1088
32.14.1 Benefits of using Text Comment block ..................................................................................... 1088
32.14.2 TEXTCOMMENT parameters .................................................................................................. 1088
32.15 TIMER Block ........................................................................................................................................... 1089
32.15.1 Function-TIMER block ............................................................................................................. 1089
32.15.2 Input/Output-TIMER block ....................................................................................................... 1089
32.15.3 Commands-TIMER block ......................................................................................................... 1089
32.15.4 TIMER parameters .................................................................................................................... 1090
32.16 TYPECONVERT Block ........................................................................................................................... 1091
32.16.1 Function-TYPECONVERT block ............................................................................................. 1091
32.16.2 Execution status-TYPECONVERT block ................................................................................. 1092
32.16.3 Input/Output-TYPECONVERT block ....................................................................................... 1092
32.16.4 TYPECONVERT parameters .................................................................................................... 1092
33 Sequential Control ......................................................................................................................... 1093
33.1 SCM (Sequential Control Module) Block .................................................................................................. 1094
34 Notices ............................................................................................................................................ 1095
1 About This Document
Provides general and detailed theoretical or how it works information for selected Control Builder related
functions and the control library function blocks. It does not cover the hardware associated blocks like the
Control Processor Module (CPM) and Input/Output Module blocks.
Revision history
Revision Date Description
A February 2015 Initial release of document.
B April 2016 Updated the document with the C300CEE windup behavior when PVSTS =
Manual.
C December 2017 Updated the RTRIG and TRIG blocks
D January 2018 Updated PAR # 1-8MGI93 information in the document.
E April 2018 Note is added regarding K (gain) in the document.
27
1 ABOUT THIS DOCUMENT
2 Control Builder Components
Related topics
“Control Builder Underlying Concepts” on page 30
“Control Capacity and Performance” on page 39
“I/O Capacity and Performance” on page 51
“Function Block Execution Schedules” on page 55
“Block Configuration Load Considerations” on page 62
“Memory Usage for CEE on C200/C200E, C300 or ACE” on page 65
“CPU Utilization for CEE on CPM” on page 73
“CEE Standard Control Blocks” on page 74
“Control Component Library (CCL) Blocks” on page 78
29
2 CONTROL BUILDER COMPONENTS
2.1 Control Builder Underlying Concepts

As with any emerging technology, the Experion system has spawned its share of new or recast terms to define
its unique features. In most cases, these terms clearly relate form and content with function, so you can
intuitively determine their meaning. This section reviews some basic concepts behind the following Control
Builder terms.
• Function Block (FB)
• Control Execution Environment (CEE)
• Independent Name
• Dependent Name
• Container Block
• Self-Standing Block
Attention
The C200E Controller is an enhanced C200 Controller with additional user memory and an enhanced function block
set. The C200E Controller provides increased user memory from 4 MB to 16 MB.
2.1.1 In the beginning or the Single-Loop Controller Reference

Before reviewing Experion concepts, it may be helpful to quickly review single-loop controller operation as a
point of reference. A single-loop controller typically includes the following process control related functions in
one form or another as shown in the following figure.
• Human Interface
• Communications Driver
• Control Data Processor
• Input/Output (I/O) Interface
Figure 1: Generic single-loop controller functions.
A brief description of each of these functions is given in the following table.
Function Description
Human Interface The user's “window-on-the-process” as well as the configuration for the controller's
functionality. It usually provides varying levels of access for viewing and changing
process related parameters, such as the:
• Process Variable (PV)
• Set Point (SP)
• Output (OP)
• Tuning Constants, and
• Alarm Conditions.
In addition, operators can view entries made in the controller's configuration
database, but changes are usually under keylock or password control.
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.
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.
2.1.2 Experion architecture - partitioned functionality

While we will not get into internal design details, it may be helpful to take a high-level look at how Experion
works. In a very simple way, the following figure shows how Experion partitions control operations among its
hardware components.
Experion features an object oriented system environment. This means it is based on the technology of Object
Linking and Embedding (OLE) which promotes the partitioning of functions among multiple subsystems. The
Control Builder is the heart of Experion functionality. It includes libraries of objects that are easily configured
graphically to emulate the generic control operations of communications driver, control data processor, and I/O
Interface as well as providing a run-time monitoring capability.
Experion includes several repositories for supporting build-time and real-time data exchange and storage. Data
flow is based on client/server relationships where the client pulls data or the server pushes data.
31
Figure 2: Simplified overview of Experion architecture.
2.1.3 Blocks for building process control operations

If we had to use one term to sum up the Experion Control Builder application, it would be Function Block.
Essentially, a Function Block is an executable software object that performs a specific task. Control Builder has
libraries of Function Blocks that let you graphically build the exact control operations you need for your
process. There are three major types of blocks as listed below.
Block Type Description Name of example block in Control

Builder
Container A container block can “contain” other component Control Module (CM)
blocks. It appears as a chart in Control Builder into
Sequential Control Module (SCM)
which component blocks are placed.
Component A block which exists only as a component of a container PID (All blocks listed in CM and
block. It appears as a generic named block with SCM Libraries in Control Builder,
configurable pins and parameters within a container with the exception of CM and
block in Control Builder. Note that a component block SCM, of course.)
may also be referred to as a Basic Function Block, or
just a Basic Block.
Self-Standing (or Stand- A block that stands on its own. It is neither a container TC-IAH061 (All blocks listed in
Alone) for other blocks or a component of a container block. It Input/Output Module (IOM) library
appears as an icon in the menu area of Control Builder. as well as related blocks in Rail I/O
and Pulse Input libraries in Control
Builder.)
CPM
CEE
RM
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.
Figure 3: Typical linking of Function Blocks through Control Builder.
2.1.4 Naming convention- independent versus dependent

Every computer based application uses a more-or-less common naming convention for identifying data created
within the application. If you were to use a word-processing program on your personal computer to draft a letter
to Honeywell, you might assign a file name like HONLET1.DOC to save the letter as a file on your hard disk.
In this case, the first part of the name represents a personal choice and the suffix or second part identifies the
application used to create the file.
Like other computer applications, Control Builder employs a naming scheme to uniquely identify Experion
system information. In most cases, Control Builder assigns default names for blocks, which you can change
through configuration. We commonly refer to the name of a block as its Tag Name. This is a carryover from the
Tag Number convention used to identify components on a process Piping and Instrumentation Diagram.
While the Experion system obviously recognizes all “Tag Names”, the tag names for component type blocks are
considered “dependent” names and those for container and self-standing type blocks are “independent” names.
The independent names are unique Tag Names within Experion by default. This means a block with an
independent name receives system wide recognition without any other qualifications.
The dependent names are Tag Names that uniquely identify component blocks only within their container
module. This means component blocks in different container modules can have the same Tag Name. For
33
example, If you have two Control Modules named CM724 and CM725, you can have a PID block named PIDA
in CM724 and in CM725 as shown in the following figure. In this case, the Tag Name PIDA is dependent on the
Control Module's independent name of CM724 or CM725 for system wide recognition.
Figure 4: Component block names are dependent on container block tag name for system wide recognition.
2.1.5 Full or expanded tag name

You must prefix the component block Tag Name (or dependent name) with its associated container block Tag
Name (or independent name) when you need to provide a reference to a specific component for system wide
recognition. We call this independent and dependent name combination the Full or Expanded Tag Name. A Full
Tag Name has this general format for a component type function block.
• <Independent Tag Name>.<Dependent Tag Name>
For example, the Full Tag Name for a PID block named PIDA in a Control Module named CM1 would be:
• CM1.PIDA
2.1.6 Parameter names

The parameters associated with a given Function Block have pre-assigned names. These parameter names are
dependent type names. This means 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 thing to remember about naming is that you must specify a unique name for the Function Block or
parameter that you want recognized on a system wide basis.
The following figure illustrates some typical Tag Name assignments used in a sample Control Builder
configuration.
Figure 5: Sample Control Builder configuration with sample tag name assignments.
See the following table for a description of the callouts in the figure above.
Callout Description
1 Tag names for CPM and CEE with MAC address of 01 and CPM installed in slot number 1.
(CPM0101, CEE0101)
Note that the format for these tag names is used for example purposes only.
2 Configured tag name for analog input type IOM FB. (AI_IOM_01)
3 Predefined names for FB parameters. (PVSRCOPT, PIFILTIME, PVEULO, PVEUHI, P1)
4 Configured tag name for Control Module. (FIC101)
35
Callout Description
5 Configured dependent block names for component FBs. (DACA, PIDA, AI00, AO00)
6 Configured full tag name for connection to a parameter in another Control Module.
(TIC101.PIDA.OP)
2.1.7 Naming restrictions and conventions

The naming restrictions apply to point, area, and parameter naming.
• The following characters are restricted and may not be used:
`~!@#$%^&*+-=(){}[]|\\:;'<>,.?/\“
– Dots are allowed in parameter naming only.
• An embedded space or leading space is not allowed.
– Spaces are allowed in area naming only.
• Tabs may not be used.
• The name may not be null (no characters).
• One of these characters must be present in a valid name:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
• The name must be less than the maximum size allowed for a tagname:
– 16 for composites.
– 15 for basic blocks.
– 100 for parameter names.
• The name must be unique.
2.1.8 Parameter data types

Parameter values are expressed in one of the following major data types.
• BOOLEAN
• ENUM (Enumeration)
• INT16 (Signed 16-bit Integer)
• INT32 (Signed 32-bit Integer)
• UINT16 (Unsigned 16-bit Integer)
• UINT32 Unsigned 32-bit Integer)
• FLOAT32 (32-bit IEEE Floating Point)
• FLOAT64 (64-bit IEEE Floating Point)
• TIME
• STRING
In most cases, only output and input parameters with matching data types can be connected. One exception is
with input and output connections for SCM blocks.
2.1.9 Data flow -- active versus passive

Before control data can flow in an Experion system, you must load the Control Execution Environment (CEE)
FB and assign it to the Control Processor module that will contain the control strategy loaded from the Control
Builder. You must also assign the Control Module to the CEE through Control Builder configuration. The
procedures associated with these activities are covered in the Control Building Guide. They are only mentioned
here to remind you that you must configure hardware as well as functional control operations through the
Control Builder.
The CEE provides the control execution services for the Control Processor. It coordinates all data flow between
parameters at execution time. Without getting into a lot of detail, the CEE parameters exist only within the
Function Blocks for the loaded control strategy. These parameters are classified as “active” or “passive” based
on whether or not the block itself handles the data flow connection processing. The active parameters require
special connection processing for actions such as status handling or initialization propagation from inside the
block. The passive parameters depend on activity outside the block to initiate data flow in or out. The Control
Module Function Block is the agent for data flow between connected passive parameters.
2.1.10 Active and passive connectors

The CEE has active and passive connectors that support the functionality of active and passive parameters,
respectively. These connections cause data flow to occur between connected parameters at block execution time.
For active parameters, the data flow caused by connection processing is phased so that the block algorithm itself
executes the transfer at the start of its execution. For passive parameters, the data flow is phased so 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 will appear 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.
2.1.11 Cascade loop connections

The following figure shows typical connections configured to provide a PID cascade loop with full initialization
handling. The connections between the primary OP and secondary SP parameters must be made by the user
during Control Module configuration. Control Builder automatically makes implicit/hidden connections
between the primary BACKCALCIN and secondary BACKCALCOUT parameters. The cascade operation is
also complemented by a general-purpose connection within the controller that is automatically configured when
a user associates an IOCHANNEL FB with a particular channel on an IOM FB. This connection handles all of
the data flow between the IOCHANNEL FB and the IOM FB. It allows one-shot initialization processing up the
cascade chain in a single execution cycle.
37
Figure 6: Sample PID cascade loop configuration
2.1.12 Data pull or push

We use Pull or Push to describe how data flows across connections. In general, a block's active input parameter
pulls data while a block's active output parameter pushes data. This information is for reference only, since the
CEE uses a connection scheme that readily recognizes whether a Pull or a Push is causing data flow.
For Control Module configurations, active parameters always pull data and passive parameters connected
between Control Module FBs also pull data. Passive parameter connections between blocks in the same Control
Module FB are neither pull nor push. In this case, the parent Control Module FB effects the data transfer.
For Sequential Control Module configurations, the input expressions always pull data while the output
expressions always push data.
2.2 Control Capacity and Performance

This section provides performance related information for the various Experion controllers for convenient
reference. The following information is subject to change without notice and is superseded by information in
applicable Experion product Specification and Technical data documents.
Related topics
“Control network capacity” on page 39
“C200/C200E configuration options” on page 40
“C200/C200E Redundancy” on page 41
“C200/C200E communication performance” on page 41
“C200E Whole Array Transfer Performance” on page 43
“C200/C200E processing resources” on page 43
“C200/C200E Memory Resources and Block Configuration” on page 44
“C300 configuration options” on page 44
“C300 Redundancy” on page 45
“C300 communication performance” on page 45
“C300 processing resources” on page 47
“C300 Memory Resources” on page 48
“ACE configuration options” on page 48
“ACE communication performance” on page 48
“ACE processing resources” on page 50
“ACE Memory Resources” on page 50
2.2.1 Control network capacity

The network capacity limits for each supervisory control network media available are listed in the following
table.
Topic Network Media and Limits

FTE CIP Ethernet ControlNet
(See Notes 4 to 8) (See Notes 9 to 11)
Supervisory Networks per 1 redundant network 1 non-redundant network 1 redundant or non-
Experion Server serviced by 1 or more serviced by 1 redundant or redundant network serviced
redundant or non-redundant non-redundant Experion by 1 redundant or non-
Experion servers up to the server redundant Experion Server
maximum FTE Nodes
allowed per FTE
Community.
(See Note 1)
ControlNet Connection N/A N/A 127
Limit per PCIC
Maximum Number of 330 FTE nodes per FTE 12 32
Nodes allowed community
(See Note 2)
Controllers per Serve Up to 20 Redundant or Non- Up to 10 Non-Redundant Up to 10 Redundant or Non-
Redundant in any only Redundant in any
combination combination
(See Note 3)
39
Topic Network Media and Limits

FTE CIP Ethernet ControlNet
(See Notes 4 to 8) (See Notes 9 to 11)
ACEs per Server Up to 7 Not Supported Up to 2
Transmission Rate 100 Mbits/sec 10 Mbits/sec 5 Mbits/sec
10 Mbits/sec for FTEBs
Media Redundancy Redundant only Non-redundant only Single cable or redundant
media operation supported.
Notes:
1. SCADA connected PLCs can still be connected through ControlNet/PCIC when C200/C200Es or C300s reside on the
FTE supervisory control network.
2. When any FTEB is present in the FTE community the limit is 200 FTE nodes.
3. SCADA PLCs do not count as “Controllers” against this limit on FTE.
4. Non-redundant 10Mbps Ethernet using the TC-CEN011 (obsolete) or TC-CEN021.
5. L3 FTE based servers will NOT support CIP Ethernet supervisory control network.
6. Only qualified for Redundant Servers + 10 non-Redundant Controllers.
7. FIMs are NOT supported on a supervisory CIP Ethernet system in any configuration.
8. ACEs are NOT supported on a supervisory CIP Ethernet system in any configuration.
9. Only 1 PCIC Card per computer supported.
10. Each of these nodes uses 1 PCIC connection from the server regardless of where they reside in the system. For
example, Supervisory or I/O ControlNet: CPM, IOLIM, FIM. Each ControlNet resident PLC should be limited to 2
connections, if configured as SCADA controllers (this is configured in RSLinx).
11. Default system is configured for 24 nodes (UMAX) but can be updated to 32 only if the actual number of physical
nodes required exceeds 24. (Any unconnected but configured MAC addresses consume bandwidth time on the
ControlNet.)
2.2.2 C200/C200E configuration options

The following table lists the options related to configuring a C200/C200E Controller.
Attention
The CEE of the C200E Controller supports only 50 ms base execution period.
Module Slot Width 2 slots

Number of CPM Modules allowed per Chassis 1
Base Execution Periods Supported • C200: 50 ms, 5 ms*
(*Requires different firmware personality.)
• C200E: 50 ms
Loaded Controller Personality-> 5 ms CEE 50 ms CEE
Redundancy Supported No Yes
Remote I/O Supported No Yes
I/O Module Execution Period 5 ms 50 ms
Configurable Values for CM/SCM Execution Periods 5, 10, 20, 50, 100, 200 ms. 50, 100, 200, 500, 1000,
2000 ms.
Configurable Values of Peer Update Rates (period). 10, 20, 50, 100, 200, 500, 100, 200, 500, 1000 ms.
1000 ms.
(Defines the period at which data is updated for all 'pull/get' (See Note)
requests for peer data required by all blocks within a CEE.)
Note:
Supervisory CIP Ethernet LAN clusters only guarantee a Pull/Get Request Rate of 500 milliseconds or greater. Faster
Pull/Get rates can be configured, however, data arrival at the configured rate cannot be guaranteed for rates faster than 500
milliseconds.
2.2.3 C200/C200E Redundancy

The following table lists data pertinent to the configuration of C200/C200E Controllers with Series A chassis-
based redundant hardware. The C200/C200E Controller must have a 50 ms CEE personality to support
redundant operation.
Attention
The PROFIBUS interface Module SST-PB3-CLX-HWL (SAP item 1120160021), manufactured by Molex Inc.
(formerly Woodhead / SST), supersedes models SST-PBF-CLX and SST-PBF-CLX-RLL.
Redundancy compliant devices CNI, C200/C200E CPM, FTEB, FIM, IOLIM, RM, BEM,
LIOM
Non-redundancy compliant devices (cannot be Chassis IOM, SIM, PIM, SST-PB3-CLX-HWL, C100 CPM,
introduced in a redundant chassis pair) TC-CEN021 Ethernet Module, DHRIO, DeviceNet Module
Control Processing Switchover Interruption Time 500 ms
Redundancy Module Cable Medium Fiber Optic Cable
Redundancy Module Cable Lengths 1, 3, 10 meters
Redundancy Module Slot Width 2 slots
Initial Synchronization Time (from Sync Start to • C200: 90 sec
Completion) • C200E: 300 sec
Maximum Elapsed Time Between Commanded • C200: 150 sec
Switchover and Completion of Initial Synchronization • C200E: 400 sec
Maximum Elapsed Time Between Switchover Due to • C200: 200 sec
Power Cycle of the Primary and Completion of Initial • C200E: 400 sec
Synchronization
Maximum OPM Control Freeze time • C200: 10 seconds
• C200E: 20 seconds
2.2.4 C200/C200E communication performance

Attention
The following table lists performance related values for C200/C200E Controller communications. The
abbreviation PPS stands for Average Parameters Per Second and PPM stands for Average Parameters Per
Minute.
Overall Data Access Performance 5 ms CEE 50 ms CEE

Maximum Total Parameter Access Response Rate9 2000 PPS 2000 PPS
(Includes all Server Data Requests, Console Station Data
Requests, and peer communications including other ACEs,
C200/C200Es, C300s, SIM-C200Es, SIM-C300s, SIM-ACEs,
and FIMs, but not including IOLIM data transfers)
See Note 9 regarding IOLIM data transfer rate.
41

Display Data Access Capacity 5 ms CEE 50 ms CEE
Maximum Total Subscribed Parameters per C200/C200E 2000 2000
(Includes all Server Data Requests + Console Station Data
Requests)
Request/Response Data Access Performance 5 ms CEE 50 ms CEE
Max Request/Response Parameter Access Rate 3000 PPM Read 3000 PPM Read
(Includes all Slow Server Data Requests, e.g. Greater than 10 1500 PPM Write 1500 PPM Write
sec OPC data, Slow History, Data Writes, etc.)
Peer-to-Peer Performance 5 ms CEE 50 ms CEE
Maximum Initiator Pull/Get Request Rate to all target 500 PPS 500 PPS
nodes (incoming data)10
Maximum Target Response Rate to Pull/Get Requests 500 PPS 500 PPS
from all initiator nodes (outgoing data)9,11
Peer-to-Peer Subscription Capacity / ControlNet or FTE3 ControlNet or FTE3
Update Rate
Maximum C200/C200E peer capacity per update rate 5 @ 10 ms 50 @ 100 ms
choices:
10 @ 20 ms 100 @ 200 ms
25 @ 50 ms 250 @ 500 ms
50 @ 100 ms 500 @ 1 sec
100 @ 200 ms
250 @ 500 ms
500 @ 1 sec
CIP Ethernet1 CIP Ethernet1
250 @ 500 ms 250 @ 500 ms 500 @ 1 sec
500 @ 1 sec
Push/Store Request Performance 5 ms CEE 50 ms CEE
Maximum Push/Store Request Rate to all target nodes2 50 PPS 50 PPS
Maximum Response Rate to Push/Store Requests from all 50 PPS 50 PPS
initiator nodes4
Peer-to-Peer Node Capacity 5 ms CEE 50 ms CEE
Peer Connection Units5,6 (PCUs) 5 30
*Remote CEEs that this C200/C200E can initiate a peer (Includes total of other (Includes total of other
connection with ACEs, C200/C200Es, ACEs, SIM-ACEs, C200/
C300s, SIM-C200Es and/or C200Es, C300s, LIOMs,
SIM-C300s) SIM-C200Es, SIM-C300s,
IOLIMs and/or Primary
FIMs)
Peer-to-Peer Capacity using Exchange FB 5 ms CEE 50 ms CEE
Maximum Number of Qualified/Recommended 32 32
REQUEST blocks per CEE/CPM
Maximum RESPONSE blocks per CEE/CPM 32 32
Maximum Number of Target Devices for REQUEST 8 8
blocks per CEE/CPM6,7,8
Maximum Number of Remote Initiating Devices for 8 8
RESPONSE block data per CEE/CPM

Notes:
1. CIP Ethernet is a non-redundant network that should not be used for a mission critical control strategy
2. For CIP Ethernet Supervisory clusters; the maximum store rate is 500 msec.
3. Series A FIM and IOLIM have fixed publish rates, therefore, these rates and capacities are not applicable to FIM or
IOLIM Peer-Peer connections.
4. Currently the SCM Step and the PUSH Block are the only block types that can initiate peer push/store requests for
CEE-to-CEE peer communications.
5. Does not include Exchange Peer-Peer
6. May be limited by other Connection capacities.
7. DHRIO Module only counts as 1 Target Device even when communicating with multiple PLCs on either of the two
DH+ networks per DHRIO.
8. See “C300 IO capacity” on page 52for DHRIO capacities supported.
9. An additional 4000 PPS is supported exclusively to IOLIMs. Response Rate to all other peer and display clients
remains 2000 PPS. Overall Response Rate with IOLIMs is effectively 6000 PPS.
10. incoming peer data benefits from the RBE (Report by Exception) comparisons done at the data source, so only
changed parameters contribute to the incoming PPS load.
11. Outgoing peer data capacity is defined/measured before the RBE (Report by Exception) comparisons are done, so all
parameters requested as peer data contribute to the outgoing PPS load, whether they are changing or not and sent over
the network or not.
2.2.5 C200E Whole Array Transfer Performance

The following table lists whole array transfer performance related values for C200E Controller communications.
The abbreviation EPS stands for Average Array Elements Per Second.
Overall Controller Whole Array Transfer Performance 50 ms CEE

Whole Array Response Rate (EPS) 1000 EPS
(Includes all peers and Displays - when supported) This is in addition to the Parameters Per
Second specification.
Peer-to-Peer Whole Array Performance
Maximum Initiator Whole Array Pull/Get Request Rate (to all peers) 500 EPS
Maximum Target Node Response Rate to Whole Array Pull/Get Requests (from all initiator 500 EPS
nodes)
Whole Array Capacity
Maximum Array Size for Whole Array Transfer 400bytes
(50-floats)
Initiator's Maximum Whole Array Connection References (to all peers, including OPC 20
connections) using pub-sub
Responder's Maximum Whole Array Connections (from all peers) using pub-sub 20
2.2.6 C200/C200E processing resources

Attention
The following table lists the processing resources for a C200/C200E Controller in Processing Units (PU). The
PU represents a platform independent amount of processing resources (time) required to complete a predefined
amount of computational (control) work.
43
Minimum Reserved CPU to be Maintained During 20%

Runtime (CPUFREEAVG)
CEE/CPM Configuration PU Maximum1 Maximum Cycle Loading2
50 ms CEE - Non-Redundant Configuration 3600 PU/sec 60%
50 ms CEE - Redundant Configuration 1600 PU/sec 60%
5 ms CEE - (Non-Redundant only) 2400 PU/sec 40%
Notes:
1. Available Processing Units at indicated maximum loading cycle percentage. For example, for a 50 ms non-redundant
CEE, it may be configured to use all of the 3600 PU. The CPU load must be balanced across all cycles. No single cycle
should exceed 60% in its CPUCYCLEAVG value.
2. Maximum Cycle Loading: Over a cycle (0-39), the “Average CPU Used” (CPUCYCLEAVG) statistic is not to exceed
the stated maximums.
2.2.7 C200/C200E Memory Resources and Block Configuration

The following table lists the memory units and block capacities for a C200/C200E Controller. The memory unit
(MU) represents 1 kilobyte or 1024 bytes.
Maximum Available C200/C200E CEE Memory Resources • C200: 4000 MU

• C200E: 16000 MU
Maximum Total Number of CMs, SCMs and IOMs Configurable per C200/C200E CEE • C200: 1000
• C200E: 4095
Maximum Number of Component Blocks per CM 100
Maximum Number of Component Blocks per SCM 400
Maximum number of parallel paths executing in SCM simultaneously 10
2.2.8 C300 configuration options

The following table lists the options related to configuring a C300 Controller.
Configuration Options 50mSec CEE 20mSec CEE

Control Networks Supported FTE only1 FTE only1
Device Index Configuration Between 1 and 255 Between 1 and 255
IOTA Size 6 inches 6 inches
Number of I/O Links Supported 2 2
I/O Link Speeds Available 375 Kbaud (PM I/O Link) 750 Kbaud (Series C I/O Link)
750 Kbaud (Series C I/O Link)
Base Execution Periods Supported 50 ms 20ms
Redundancy Supported Yes Yes
Remote I/O Supported Yes - PM I/O or Series A I/O No
I/O Module Execution Period 50 ms 20ms
Configurable Values for CM/SCM Execution 50, 100, 200, 500ms, 1s, 2s. 20, 40, 80, 200, 400, 800ms.
Periods
Configuration Options 50mSec CEE 20mSec CEE

Configurable Values of Peer Update Rates (period). 100, 200, 500, 1000 ms 100, 200, 500, 1000 ms.
(Defines the period at which data is updated for all
‘pull/get’ requests for peer data required by all
blocks within a CEE.)
C300 Time Source SNTP SNTP
SNTP Update Period 1 minute 1 minute
GPS Time Support2 No No
Notes:
1. Currently, every C300 must be connected to a Control Firewall.
2. A GPS connector is available on the IOTA, but it is not supported until a future release.
3. C300 - 20mS CEE Controller hardware is same as the C300 - 50ms Controller, and only the C300 - 20mS CEE
firmware is different.
2.2.9 C300 Redundancy

The following table lists data pertinent to the configuration of C300 Controllers for redundant operation.
Configuration Options for Redundancy 50mSec CEE 20mSec CEE

C300 Function Block Redundancy “Module is Redundant” “Module is Redundant”
Configuration Selection:
Number of IOTAs used for Redundant 2 2
C300
Redundant Device Index Configuration Redundant Controller pairs Redundant Controller pairs must have
must have Device Index values Device Index values of n and n + 1,
of n and n + 1, where n is an where n is an odd value
odd value
Redundancy Cable Medium Ethernet STP Ethernet STP
Redundancy Cable Lengths 36, 48, 60, 84 inches 36, 48, 60, 84 inches
Control Processing Switchover 500 ms 200ms
Interruption Time1
Initial Synchronization Time (from Sync 240 seconds 200 seconds
Start to Completion)
Maximum Elapsed Time Between 500 seconds 300 seconds
Commanded Switchover and Completion
of Initial Synchronization
Maximum Elapsed Time Between 500 seconds 300 seconds
Switchover Due to Power Cycle of the
Primary and Completion of Initial
Synchronization
Maximum OPM Control Freeze time 20 seconds Not applicable.
Notes:
1. Dual I/O Link failures may cause longer interruption times in the order of several seconds.
2.2.10 C300 communication performance

The following table lists performance related values for C300 Controller communications. The abbreviation
PPS stands for Average Parameters Per Second, PPM stands for Average Parameters Per Minute, and EPS
stands for Average Array Elements Per Second.
45
Overall Data Access Performance 50mSec CEE 20mSec CEE

Maximum Total Parameter Access Response Rate 2500 PPS 700 PPS
(Includes all Server Data Requests, Console Station Data
Requests, and peer communications including other ACEs,
C200s, C300s, and FIMs)
Overall Array Transfer Response Performance 50mSec CEE 20mSec CEE
Whole Array Response Rate (EPS) 4000 EPS 1000 EPS
(Includes all Peers and Displays - when supported) This is
in addition to the Parameters Per Second specification.
Display Data Access Capacity 50mSec CEE 20mSec CEE
Maximum Total Subscribed Parameters per C300 4000 1000
(Includes all Server Data Requests + Console Station Data
Requests)
Request/Response Data Access Performance 50mSec CEE 20mSec CEE
Max Request/Response Parameter Access Rate 3000 PPM Read
(Includes all Slow Server Data Requests, e.g. Greater than 1500 PPM Write
10 sec OPC data, Slow History, Data Writes, etc.)
Peer-to-Peer Performance 50mSec CEE 20mSec CEE
Maximum Initiator Pull/Get Request Rate to all target 1000 PPS 250 PPS
nodes (incoming data)7
Maximum Target Response Rate to Pull/Get Requests 1000 PPS 250 PPS
from all initiator nodes (outgoing data)8
Peer-to-Peer Subscription Rates/ 50mSec CEE 20mSec CEE
Update Rate
Maximum C300 peer capacity per update rate choices1 50 @ 100 ms 5@20 msec
100 @ 200 ms
250 @ 500 ms
500 @ 1 sec
Push/Store Request Performance 50mSec CEE 20mSec CEE
Maximum Push/Store Request Rate to all target nodes 50 PPS 12 PPS
Maximum Response Rate to Push/Store Requests from 50 PPS 12 PPS
all initiator nodes
Peer-Peer Whole Array Transfer Performance 50mSec CEE 20mSec CEE
Max Initiator Whole Array Request Rate (to all peers) 2500 EPS 625 EPS
Max Target Node Response Rate to Whole Array 1500 EPS 375 EPS
Pull/Get Requests
(from all initiator nodes)
Initiator Whole Array Push/Store Rate 1000 EPS 250 EPS
Target Node Whole Array Response Rate to Push/Store 1000 EPS 250 EPS
Requests
(from all initiator nodes)
Peer-to-Peer Capacity 50mSec CEE 20mSec CEE
Overall Data Access Performance 50mSec CEE 20mSec CEE

Peer Connection Units (PCUs) 303 (Includes total of other ACEs,
C200s, C300s, and/or Primary
(*Number of remote CEEs that this C300 can initiate a peer (Includes total of other
FIMs)
connection with) ACEs, SIM-ACEs,
C200s, C300s, SIM-
C300s, and/or Primary
FIMs)
Peer-to-Peer Capacity using Exchange FB 50mSec CEE 20mSec CEE
Maximum Number of REQUEST blocks per C300 32 Not Applicable
Maximum Number of RESPONSE blocks per C300 32 Not Applicable
Maximum Number of Target Devices for REQUEST 8 Not Applicable
blocks per C3004
Maximum Number of Remote Initiating Devices for 8 Not Applicable
RESPONSE block data per C300
PCDI Capacity and Performance 50mSec CEE 20mSec CEE
Maximum Number of Modbus TCP devices 8 3
(represented by PCDI Master blocks)
Maximum Number of Serial Modbus Devices per 16 3
Gateway
Maximum Number of Serial Modbus Devices per C300 128 3
Maximum Number of PCDI Request blocks assigned to 64 8
a PCDI Master block
Maximum Number of PCDI Request block messages per 512 6
second - includes both Read and Write6
(maximum size 256 byte messages assumed)
Notes:
1. Series C FIM has fixed publish rate, therefore, these rates and capacities are not applicable to Series C FIM Peer-Peer
connections.
2. Exchange Peer-Peer does not count against this limit.
3. 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.
4. One DHRIO Module only counts as 1 Target Device even when communicating with multiple PLCs on either of the
two DH+ networks per DHRIO.
5. Redundant devices that use two PCDI Master blocks count as only one device.
6. PCDI impact on C300 performance can be estimated with the C300 Performance Model worksheet; important factors
are number of PCDI Master blocks, number of PCDI Request block messages per second, and message data size.
7. Incoming peer data benefits from the RBE (Report by Exception) comparisons done at the data source, so only
the network or not.
2.2.11 C300 processing resources

The following table lists the processing resources for a C300 Controller in Processing Units (PU). The PU
represents a platform independent amount of processing resources (time) required to complete a predefined
47
For Maximum Cycle Loading, over a cycle (0-39), the “Average CPU Used” (CPUCYCLEAVG) statistic is not
to exceed the stated maximums.
50mSec CEE 20mSec CEE

Minimum Reserved CPU to be Maintained During 20% Greater than or equal to 20%
Maximum Cycle Loading - CEE Configuration 60% Less than or equal to 50%
2.2.12 C300 Memory Resources

The following table lists the memory units and block capacities for a C300 Controller. The memory unit (MU)
represents 1 kilobyte or 1024 bytes.
50mSec CEE 20mSec CEE

Maximum Available C300 CEE Memory Resources 16000 MU 16000 MU
Maximum Total Number of CMs, SCMs, and IOMs 4095 4095
Configurable per C300 CEE
See Note.
Maximum Number of Component Blocks per CM 100 100
Maximum Number of Component Blocks per SCM 400 Not applicable.
Maximum number of parallel paths executing in Not applicable.
SCM simultaneously
Note:C300 - 20mS CEE Controller does not support
SCMs.
2.2.13 ACE configuration options

The following table lists the options related to configuring an ACE Controller.
Base Execution Periods Supported 500 ms

Redundancy Supported No
Remote I/O Supported N/A
I/O Module Execution Period N/A
Configurable Values for CM/SCM Execution Periods 500 ms and 1, 2, 5, 10, 20 sec
Additional options for CMs only:
30, 40 sec
1, 2, 5,10, 20, 30 min
1,2,4,8,12, 24 hr
NOPERIOD
Configurable Values of Peer Update Rates (period) 500 ms and 1, 2, 5, 10 sec
(Defines the period at which data is updated for all ‘pull/get’
requests for peer data required by all blocks within a CEE.)
2.2.14 ACE communication performance

The following table lists performance related values for ACE Controller communications. The abbreviation PPS
stands for Average Parameters Per Second, PPM stands for Average Parameters Per Minute, and EPS stands
for Average Array Elements Per Second.
Overall Data Access Performance 500 ms CEE

Maximum Total Parameter Access Response Rate 3000 PPS
(Includes all Server Data Requests, Console Station Data Requests, and peer communications
including other ACEs, C200/C200Es, C300s, SIM-C200Es, SIM-C300s, SIM-ACEs, and
FIMs)
Display Data Access Capacity 500 ms CEE
Maximum Total Subscribed Parameters per ACE 6000
(Includes all Server Data Requests + Console Station Data Requests)
Request/Response Data Access Performance 500 ms CEE
Max Request/Response Parameter Access Rate 3000 PPM Read
(Includes all Slow Server Data Requests, e.g. Greater than 10 sec OPC data, Slow History, 1500 PPM Write
Data Writes, etc.)
Peer-to-Peer Performance 500 ms CEE
Maximum Initiator Pull/Get Request Rate to all target nodes (incoming data)4 1000 PPS
Maximum Target Response Rate to Pull/Get Requests from all initiator nodes (outgoing 1000 PPS
data)5
Peer-to-Peer Subscription Rates/Update Rate ControlNet or FTE1
Maximum ACE peer capacity per update rate choices 500@ 500 ms
1000 @ 1 sec
2000 @ 2 sec
5000 @ 5 sec
10000 @ 10 sec
Push/Store Request Performance 500 ms CEE
Maximum Push/Store Request Rate to all target nodes3 50 PPS
Maximum Response Rate to Push/Store Requests from all initiator nodes 50 PPS
Peer-to-Peer Capacity 500 ms CEE
Peer Connection Units (PCUs) 30
(Remote CEEs that this ACE can initiate a peer connection with, includes total of remote
ACEs, SIM-ACEs, C200/C200Es, C300s, SIM-C200Es, SIM-C300s, and/or Primary FIMs)
ACE to OPC Gateway Peer Performance 500 ms CEE
Maximum Initiator OPC Pull/Get Request Rate 2000 PPS
(to all target OPC Gateways)
Maximum Initiator OPC Push/Store Request Rate 500 PPS
(to all target OPC Gateways)
Whole Array Capacity 500 ms CEE
Maximum Array Size for Whole Array Transfer 8K bytes
(1000 float64s)
Initiator's Maximum Whole Array Connection References 25
Responder's Maximum Whole Array Connections 25
(from all peers using pub-sub)
Initiator's Maximum Whole Array Connection References 5
(to all peers using request/response)
49
Overall Data Access Performance 500 ms CEE

Responder's Max Whole Array Connections 5
(to all peers using request/response)
Overall Array Transfer Response Performance 500 ms CEE
Whole Array Response Rate (EPS) 4000 EPS
(Includes all Peers and Displays - when supported) This is in addition to the Parameters Per
Second specification.
Notes:
1. ACE is not supported on CIP Ethernet based cluster.
2. See Section OPC Servers that can be accessed by the ACE.
3. Currently the SCM Step and the PUSH Block are the only block types that can initiate peer push/store requests for
CEE-to-CEE peer communications.
4. Incoming peer data benefits from the RBE (Report by Exception) comparisons done at the data source, so only
the network or not.
2.2.15 ACE processing resources

The following table lists the processing resources for an ACE Controller in Processing Units (PU). The PU
represents a platform independent amount of processing resources (time) required to complete a predefined
For Maximum Cycle Loading, over a cycle (0-39), the “Average CPU Used” (CPUCYCLEAVG) statistic is not
to exceed the stated maximums.
Minimum Reserved CPU to be Maintained During 40%

(Note: CPUFREEAVG not supported on ACE; CPU Usage
from Windows Task Manager provides the %CPU used.)
CEE Configuration PU Maximum Maximum Cycle Loading
500 ms CEE - Non-Redundant Configuration 100,000 PU/sec 60%
2.2.16 ACE Memory Resources

The following table lists the memory units and block capacities for an ACE Controller. The memory unit (MU)
represents 1 kilobyte or 1024 bytes.
Maximum Available ACE CEE Memory Resources 128,000 MU

Maximum Total Number of CMs, SCMs and IOMs Configurable per ACE CEE 4095
Maximum Number of Component Blocks per CM 100
Maximum Number of Component Blocks per SCM 400
Maximum number of parallel paths executing in SCM simultaneously
2.3 I/O Capacity and Performance

Every I/O Device presents a “Load” on the C200/C200E or C300 Controller performance by using I/O Network
bandwidth, Controller memory, ControlNet or FTE Connections, and CPU resources. In order to not overload
the ability for the C200/C200E or C300 to operate correctly, configuration constraints are defined in the
following Tables for C200/C200E and C300 I/O. Many of these constraints are measured in “IO UNITS”, which
is a generic loading definition used to “normalize” the load among the many different I/O devices and families
supported. See the IO Unit load factors section below for the IO UNIT loads assigned to various devices and
modules.
Related topics
“C200/C200E IO capacity” on page 51
“C300 IO capacity” on page 52
“IO Unit load factors” on page 53
2.3.1 C200/C200E IO capacity

Attention
The following table lists I/O configuration constraints you should observe to avoid overloading the C200/
C200E Controller and impacting its ability to operate correctly.
Function 5 ms CEE 50 ms CEE

Maximum Number of IO UNITS per CEE/CPM1,2 12 64
(Rail I/O is not
supported)
Maximum Number of Remote Series A I/O Chassis + Remote Mixed 0 8
Chassis + Rail Adapters (combined) perC200/C200E3,4,5
(Local I/O Only)
Maximum Number of IO UNITS that can be assigned per Downlink 0 24
CNI1
(Local I/O Only)
Maximum Number of Downlink CNIs per C200/C200EController 0 4
Chassis
(Local I/O Only)
Maximum number of Allen Bradley variable speed drives supported per 0 64
Controller.
(Local I/O Only) (Limited to 20 per
This function requires the optional control library TCABDL01 isolated downlink
CNI)
Each drive counts as one IO UNIT in the maximum number of IO per CEE
Each drive has to be equipped with the 1203-CN1 communication module
(available directly from Allen Bradley)6
Maximum Number of IOLIMs + LIOMs per CEE/CPM Not supported 2
Maximum Number of DHRIO Modules per CEE/CPM 2 2
(Local I/O Only)
Serial Interface Related Only
Maximum Number of Serial Interface Modules per CEE/CPM 1 3
Maximum Number of FTA assemblies per Serial Interface Module7 2 2
Fieldbus Interface Related Only
51
Function 5 ms CEE 50 ms CEE

Maximum number FF non-redundant Series A FIMs per CEE/C200/ Not Supported 21
C200E8
Maximum number of Redundant Series A FIMs per C200/C200E9 Not Supported 12
Maximum number of Series C FIMs per C200/C200E Not Supported Not Supported
PROFIBUS Related Only
Maximum number of PROFIBUS function block modules per CPM 2 10
Maximum number of PROFIBUS function block modules per downlink Not Supported 4 @ 25 ms
CNI
2 @ 12.5 ms
(based on update rate, 25ms default)
DeviceNet Bridge Related Only
Maximum number of DeviceNet Bridge modules per CPM 2 32
Maximum number of DeviceNet Bridge modules per downlink CNI Not Supported 12
Notes:
1. See the IO Unit Load Factors below for details.
2. Specific IO Devices may be further limited as described elsewhere.
3. FIM-only chassis or redundant chassis pairs do not count against this limit
4. PM I/O chassis do not count against this limit
5. This limit can be exceeded under special conditions
6. The drives have to reside on an isolated I/O network separate from standard Series A chassis or Rail I/O
7. Each SIM FTA is the equivalent of 4 IO UNITS in the 64 IO per CPM calculation and the 24 IO per CNI calculation.
8. Each FIM counts as 2 IO UNITS in the 64 IO/CPM calculations above
9. Primary FIM counts as 2 IO UNITS in the 64 IO/CPM calculations above. Each FIM pair counts as 4 IO Units in the
24 IO Units per downlink CNI calculation.
10. The C200/C200E Controller supports up to a total of 64 I/O Units which can be calculated as:
PMIO I/O Units + Fieldbus IO Units = 64
Where …
• One non-redundant or redundant PM IOP = 1 I/O Unit.
• The number of I/O Units assigned to any given Series A I/O device is specified for that device.
• One non-redundant or redundant Series A Fieldbus Interface Module = 2 I/O Units.
• One Serial Interface Module connection of one-four arrays = 1 I/O Unit.
2.3.2 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.
Function 50mSec CEE 20mSec CEE

Maximum Number of IO UNITS per C3001,2 64 12
1. See the IO Unit load factors below for details. 80 (if using PM
2. Specific IO Devices may be further limited as described below. IOPs only)
Maximum Number of IOMs having Scan Rate as “Priority IOM” Per Not applicable. 4 modules
IOLINK Of C300”
SERIES A I/O-RELATED ONLY
Maximum Number of Series A I/O Chassis connected through FTEB per 83 Not Supported
C300
Function 50mSec CEE 20mSec CEE

Maximum Number of IO UNITS per Series A I/O Chassis/FTEB 16 Not Supported
Supported Series A I/O modules: Not Supported
• Serial Interface Module
• DeviceNet interface Module
• Profibus Module
• Pulse Input Module1
Maximum Number of Serial Interface Modules per C300 3 Not Supported
Maximum Number of Serial Interface Modules per FTEB 1 Not Supported
Maximum Number of DeviceNet Modules per C300 8 Not Supported
Maximum Number of DeviceNet Modules per FTEB 4 Not Supported
Maximum Number of Profibus Modules per C300 8 Not Supported
Maximum Number of Profibus Modules per FTEB 4 Not Supported
Series C FIM Relate Only
Maximum number of Redundant or Non-Redundant Series C FIMs per 15 Not Supported
C3004
Notes:
1. See the IO Unit load factors below for details.
2. Specific IO Devices may be further limited as described below.
3. Because the FTEB has to connect to the same Control Firewall as the C300, this may be further limited by the number
of available ports on the Control Firewall
4. Each Primary FIM counts as 4 IO UNITS in the 64 IO/C300 calculations above. This is only applicable for C300 50ms
Controller.
The C300 50ms controller strategies cannot be imported to a C300 - 20, as CM and IOM assignments will fail.
To modify the exported file, change the CM Periods and IOM Scan rates to a value, which is supported by the
C300 - 20 and then import the exported file to a C300 - 20 controller. These CMs can only contain function
blocks that are supported by C300 - 20 controller.
2.3.3 IO Unit load factors

The following Table defines the IO UNIT load factor for the various I/O Devices the C200/C200E and C300
Controllerssupport.
I/O Device or Module IO Units

1 PM IOP Module 1
Note:For redundant IOPs, each pair of IOPs counts as 1 IO Unit.
1 Series C I/O Module 1
Note:For redundant IOMs, each pair of IOMs counts as 1 IO Unit.
1 Series A chassis-mounted I/O Module C200/C200E:
Note:except where noted elsewhere. 1
C300:
1.5
1 Series A or H Rail-mounted I/O Module 1
1 Serial Interface Module (SIM) FTA 4 for C200/C200E
Note:For SIM using both FTAs, this count is doubled to 8 and 16 IO Units, respectively. 8 for C300
53
I/O Device or Module IO Units

1 Pulse Input Module (PIM) C200/C200E:
1 (for 64 Unit/CPM limit)
1.5 (for 24 Unit/CNI limit)
C300:
2 (for 64 Unit/C300 Limit
and 16 Unit/FTEB Limit)
1 Series C Fieldbus Interface Module (FIM4) 4
Note:Same IO Unit count whether redundant or non-redundant.
1 non-redundant Series A Fieldbus Interface Module (FIM) 2 (for 64 Unit/CPM limit)
3 (for 24 Unit/CNI limit)
1 Redundant Series A Fieldbus Interface Module Pair (Red-FIM) 2 (for 64 Unit/CPM limit)
4 (for 24 Unit/CNI limit)
1 DHRIO Module 1 (for 24 Unit/CNI limit)
0 (for 64 IOU limit)
1 1203-CN1 AB Drive Controller 1
1 SST-PB3-CLX-HWL Profibus Module C200/C200E:
2 (for 64 Unit/CPM Limit)
6 (for 24 Unit/CNI Limit)
C300:
8 (for 64 Unit/C300 Limit)
4 (for 16 Unit/FTEB Limit)
1 DeviceNet Bridge module (DNB) C200/C200E:
2 (for 64 Unit/CPM Limit)
2 (for 24 Unit/CNI Limit)
C300:
8 (for 64 Unit/C300 Limit)
4 (for 16 Unit/FTEB Limit)
1 Source or Destination Device on Auxiliary Exchange peer-to-peer network 1 (for 24 Unit/CNI Limit)
2.4 Function Block Execution Schedules
Related topics
“Schedule consideration differences” on page 55
“Control Module and Sequential Control Module FBs schedule” on page 55
“CM Component Function Block scheduling” on page 58
“IOM FB schedule” on page 60
“CPM, ACE, and CEE FBs schedule” on page 61
“Cycle overruns” on page 61
2.4.1 Schedule consideration differences

The CEE execution schedule considerations differ for each of the following Function Block types.
• Control Module and Sequential Control Module FBs(Container FB)
• Component FB
• IOM FB (Self-Standing FB)
• CPM and CEE FBs (Self-Standing FB)
The scheduling considerations for a given FB type are discussed in the following sections.
2.4.2 Control Module and Sequential Control Module FBs schedule

You configure the Execution Period and the Execution Phase values for the Control Module FB and the
Sequential Control Module FB through the respective Parameters Configuration form in the Control Builder.
These values determine the scan period and the cycles allocated for the block's execution.
You can picture the execution cycle as a set of 40 timing cycles of 50 milliseconds each as shown in the
following figure. The configured Execution Period value sets the block's scan period at DEFAULT, 5, 10, 20,
50, 100, 200, 500, 1000, or 2000 milliseconds. (Note that the configuration load will be rejected if the
configured scan period is not supported by the 5 ms CEE or 50 ms CEE image loaded in the Controller.) This
Period value defines the number of cycles needed for block execution. The configured Execution Phase value
identifies the timing cycle in which the execution of the block starts. This lets you stagger the block execution
starting times to balance the load processing across the cycles. The DEFAULT value is converted to 1000
milliseconds for a 50 ms CEE or to 200 milliseconds for a 5 ms CEE, when the CEE is loaded to a Controller.
The following figure provides a graphical interpretation of how the processing of some sample Control Module
configurations would be scheduled across the timing cycles for a 50 ms CEE.
55
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 will run in
cycles 1, 5, 9, …,37. Another Control Module block with an Execution Period of 200 milliseconds and a Phase
of 2 will run in cycles 2, 6, 10, …,38. The entry value range for the Execution Phase is -1 and 0 to 39. However,
the system will accept and clamp values outside the appropriate range for a given Period as long as the value is
within the overall entry range. Obviously, a block with an Execution Period of 50 milliseconds will always be
evenly distributed, since it will run 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. In the future, a Phase value of -1 will instruct the CEE to assign Phase values that will
distribute the overall-processing load.
Attention
This same scheduling concept applies for the ACE supervisory controller but for periods from 500 milliseconds to 20
seconds.
If Period in milliseconds is. . . And Phase is . . . Then, cycles of execution are. . .

5 ms CEE 50 ms CEE
5 50 0 0, 1, 2, 3, . . ., 39
10 100 0 0, 2, 4, . . ., 38
10 100 1 1, 3, 5, . . ., 39
20 200 0 0, 4, 8, . . ., 36
20 200 1 1, 5, 9, . . ., 37
20 200 2 2, 6, 10, . . ., 38
If Period in milliseconds is. . . And Phase is . . . Then, cycles of execution are. . .

5 ms CEE 50 ms CEE
20 200 3 3, 7, 11, . . ., 39
50 500 0 0, 10, 20, 30,
50 500 1 1, 11, 21, 31
50 500 2 2, 12, 22, 32
50 500 3 3, 13, 23, 33
50 500 4 4, 14, 24, 34
50 500 5 5, 15, 25, 35
50 500 6 6, 16, 26, 36
50 500 7 7, 17, 27, 37
50 500 8 8, 18, 28, 38
50 500 9 9, 19, 29, 39
100 1000 0 0, 20
100 1000 1 1, 21
100 1000 2 2, 22
100 1000 3 3, 23
100 1000 4 4, 24
100 1000 5 5, 25
100 1000 6 6,26
100 1000 7 7, 27
100 1000 8 8, 28
100 1000 9 9,29
100 1000 10 10, 30
100 1000 11 11, 31
100 1000 12 12, 32
100 1000 13 13, 33
100 1000 14 14, 34
100 1000 15 15, 35
100 1000 16 16, 36
100 1000 17 17, 37
100 1000 18 18, 38
100 1000 19 19, 39
200 2000 1 1
200 2000 2 2
200 2000 : :
200 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. This means 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.
57
C300 Execution Periods of 5 sec, 10 sec, 20 sec, 30 sec, and 1 min should only be used for Control Modules
with Profit Controller blocks. For more information on Profit Controller blocks in CEE, see the Experion Profit
Controller User's Guide.
2.4.3 CM Component Function Block scheduling

Execution of a Control Module's component function blocks is always subordinate to the containing or parent
CM. The component function blocks are executed during the same Period as their containing CM given that the
conditions for execution are satisfied. You can configure the execution order of function blocks through the
block parameter Execution Order in CM (ORDERINCM).
Function Block Execution Order in CM

The value of ORDERINCM determines the execution order of function blocks within a Control Module (CM).
In a given CM, a block with a lower value for ORDERINCM executes before any block with a higher value.
The value of ORDERINCM can range from 1 to 32,767 where default values are assigned in multiples of 10,
although keeping values as multiples of 10 is not a requirement.
Example: If there are two function blocks in a CM with 10 and 20 as their ORDERINCM values, the FB with
ORDERINCM as 10 is executed first.
If you do not individually assign ORDERINCM, the default value 10 is set into all blocks within the CM. When
this occurs or when the same value is assigned to multiple blocks, Control Builder assigns a random execution
order based on the order in which the function blocks were added to the CM. The value of ORDERINCM
parameter is not changed by the Control Builder. If the order of execution is critical, then assign ORDERINCM
values to the CM.
With R400, 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.
Attention
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 type IOCHANNEL FBs do a sample and hold operation when they execute. IOCHANNEL FBs read data
from the associated IOM FB 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.
59
Connection Execution Order in CM

Connections are processed in relation to a function block's execution order. Inputs are fetched before the block
executes and newly calculated values are available only after the block executes.
Example of connection execution order - shift register

The order in which connections are made is critical in rare cases when blocks without any execution method/
behavior are used in a strategy. A Numeric Array used as a Shift Register demonstrates this rare case. In this
example, the numeric contained in Function Block nn1 feeds PV[1] of nna. This connection could have been
wired, but for clarity the example shows a named connection. The purpose of the CM is to act as a register and
move the value of Function Block nn1 through the ten inputs of function block nna by making each output of
Function Block nna a different input to the same block.
If the connections were made in order from top to bottom, the execution order would be from top to bottom and
in one execution cycle of the CM, the value of nn1 would be passed from PV[1] through all the PVs to PV[10].
At the end of the cycle, all the values would be equal and the intended register would be ineffective.
To create the register correctly and pass the value from one PV to the next on each cycle, the connections must
be built from the bottom of Function Block nna to the top. The first connection created must be to PV[10] in
order to ensure it is executed first. The next connection must be made to PV[9], then PV[8], and so on until the
final connection is made to PV[1]. Making the connections in this order will ensure that the Control Module
acts as a register moving the newest input value through the registers from PV[1] to PV[10].
2.4.4 IOM FB schedule

IOM FBs have a fixed Execution Period of 5 or 50 milliseconds, for 5 ms CEE or 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.
2.4.5 CPM, ACE, and CEE FBs schedule

CPM and CEE FBs have a fixed Execution Period of 2000 milliseconds. The Execution Phase is fixed at 19 for
the CEE FB and at 39 for the CPM FB. The CEE FB executes after all other blocks in the cycle. The same is
true for the ACE and CEEACE Function Blocks.
The CPM and CEE 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.
2.4.6 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.
• ACE running instances of CAB types with string or time Value Custom Data Parameters that can cause the
memory to increase. Refer to the Custom Algorithm Block and Custom Data Block User's Guide for more
information about Organizing CAB programs for best performance.
The CEE 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 CPM 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.
If Controller is . . . CEE reports alarm if . . . CEE clears alarm if . . .

CPM (50 ms BASEPERIOD) two consecutive intervals of 2000 four consecutive intervals of 2000
milliseconds have at least one cycle milliseconds have no cycle overruns.
overrun.
ACE (500 ms BASEPERIOD) two consecutive intervals of 20 seconds four consecutive intervals of 20 seconds
have at least one cycle overrun. have no cycle overruns.
Obviously, 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.
61
2.5 Block Configuration Load Considerations

The following considerations influence CEE operations relative to the loading of block configurations.
• Data Categories
• Container and Self-Standing Blocks Load versus States
• Load Error Messages
• RAM Retention Start Up
These considerations are briefly reviewed in the following sections to provide general background information
only.
Related topics
“Data categories” on page 62
“Container and self-standing blocks load versus states” on page 62
“Load error messages” on page 63
“RAM Retention Start Up (RRSU)” on page 63
2.5.1 Data categories

The major data categories found in the CEE FB are summarized below.
Data Category Description

Live Data that is derived from the process, such as PV; or is updated frequently as part of
the control computation, such as OP and SP.
This data can also be considered as the non-structural type.
Tunable Constant Data that does not change frequently enough to be considered “Live” data. It
includes parameters that support states of operation derived from the process or
stored by the operator. You can modify values for these parameters on process, but
they usually hold fixed values for the life cycle of a control strategy. You can also
configure this data at load time. The Execution Phase and Execution Period
parameters are examples of this data type, which can be changed independent of
block load.
This data can also be considered as the non-structural type.
Structural Data that is considered to make up the structure of the block configuration. It
includes parameters, which express the containment of a component FB, connection
references, or the order of block execution. You can only modify these parameters as
part of the block load. The Order in CEE and Order in CM parameters are examples
of this data type.
2.5.2 Container and self-standing blocks load versus states

The CEE supports the independent loading of container and self-standing FBs. Component FBs can only be
loaded as part of their parent container FB. This means you must load control strategies to the CEE as Control
Module or Sequential Control Module configurations.
You can load IOM, CEE, and CPM FBs individually. However, you must load the CPM FB before you load the
CEE FB and you must load the CEE FB before you can load other FBs. The status of the following state
parameters determines whether or not you can make a FB load at a given time.
• CEEFB. CEESTATE
• CMFB.EXECSTATE
• SCMFB.STATE
• IOMFB.EXECSTATE
The following table summarizes the state parameter status versus FB load permissions.
If status is . . . Then, you can load . . .

CEESTATE = Idle. • container blocks regardless of their execution state.
Changing the CEESTATE to Idle causes container FBs and – CMFB.EXECSTATE = Inactive or Active
their component FBs to cease operation and set their live data – SCMFB.STATE = Inactive or Active
to failsafe values. The self-standing FBs (IOM, CEE and
• self-standing blocks if their execution state is
CPM) continue to execute unless EXECSTATE is set to
Inactive.
Inactive. .
– IOMFB.EXECSTATE = Inactive
2.5.3 Load error messages

Block configurations are loaded to the CEE as a series of parameter value stores. Checks are made on every
store to determine if it is “valid” or not. The store of any parameter found to be “invalid” is stopped and a
corresponding error message is displayed in Control Builder. The error message is a brief descriptive text string,
which includes the name of the “invalid” parameter, so you can quickly determine the cause of the error.
The following three categories of severity apply to CEE error messages.
Severity Category Description

Warning The store of an invalid parameter is being accepted with applied qualification. For
example, error message “OPHILM - Value Clamped Warning” tells you that the
parameter OPHILM is being accepted with clamping applied.
Error The store of an invalid parameter is being rejected. (Note that the load of other
associated parameters continues.) For example, error message “TMOUTMODE -
Parameter Invalid” which tells you parameter TMOUTMODE is not operative for this
block configuration.
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” tells you that the user memory allocation was exhausted
during block load.
When a severe error occurs, the block is left in an unusable state within the CEE. If
desired, you can reload the “old“ version of the block through the Monitor tab in
Control Builder.
This error message generation applies for on-line parameter stores as will 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.
2.5.4 RAM Retention Start Up (RRSU)

The CPM includes a battery that provides backup power for Random Access Memory (RAM) retention during a
power interruption. If power is restored while the RAM is still retained through the battery backup, the CEE
will start up with the database retained prior to the power interruption. We refer to this as the RAM Retention
Start Up (RRSU).
Upon the restoration of power, the CPM runs its startup diagnostics to verify that its RAM was retained during
the power interruption. If the CPM detects RAM errors, it starts up with a “null” database. If the CPM detects
no RAM errors, it starts up with the database it had prior to the power interruption. In this case, the CEE 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 CEE FB Run state. (Note that the Idle to Run transition triggers output
path initialization.)
63
If RAM errors were detected or you did not load the CEE FB before the power interruption, the CEE FB state
will be NotLoaded at startup.
Upon any CPM startup, the CEE reissues all active notifications as part of the Experion notification recovery
routine. The CEE also issues “stat” transition notifications from the CEE FB and CPM FB that are logged in the
event journal to show whether or not an RRSU occurred.
Refer to Notifications Theory for more information
2.6 Memory Usage for CEE on C200/C200E, C300 or ACE

The following topics identify typical processing and memory resource requirements for IOMs, CMs per module
and Memory Resource usage. The Processings are computed as “Processing Resource Consumption (PU/
module execution) divided by Execution Period (sec/module execution)”. Refer to the previous C200/C200E,
C300, and ACE processing and memory resource sections for more information about the terms PU and MU.
The following typical requirements also apply for the ACE supervisory controller.
Attention
The following Control Builder Block Libraries will consume the extra Memory Units listed, when the first block of a
given type is loaded to the C200/C200E Controller:
• RAIL_IO_HAZ = 125 MU
• RAIL IO = 125 MU
• EXCHANGE = 70 MU
• PLUSEINPUT = 100 MU
• FBUSIF = 90 MU
2.6.1 C200/C200ECEE Processing and Memory Models
Typical Module Types Processing Resource Memory Resource Usage

Consumption1
(FB Content in Parenthesis) (See the ATTENTION note
(Per Module) above.)
50/5 ms CEE 50 ms 50/5 ms CEE
CEE
Non-Redundant (MU/Mod)
Redun
(PU/Module
dant
Execution)
(PU/
Modul
e
Execut
ion)
Typical I/O Module 0.3 0.19 0.6
(Average consumption of available IOMs)
Analog Digital Acquisition Module 2.9 4.5 8.0
(10 AI, 10 DataAcq FBs)
Small Analog Data Acquisition Module 0.47 0.45 1.1
(1 AI, 1 DataAcq FB)
Regulatory Control Module 2.8 2.8 3.9
(1 AI, 1 DataAcq, 1 PID, 1 AO, 6 Logic FBs)
Auxiliary Function Module 4.2 6.7 5.9
(10 Aux. FBs, such as AuxCalc, Totalizer)
Digital Data Acquisition Module 1.2 0.93 2.3
(10 DI, 10 Flag FBs)
Small Digital Data Acquisition Module 0.22 0.12 0.2
(1 DI, 1 Flag FBs)
Device Control Module 1.3 1.4 2.6
(2 DI, 2 DO, 1 DevCtl, 5 Logic FBs)
65

Consumption1
CEE
Redun
(PU/Module
dant
Execution)
(PU/
Modul
e
Execut
ion)
Logic Control Module 1.0 1.0 3.0
(20 Logic FBs)
Sequence Control Module A 2.0 3.0 28.9
(1 each of Main, Hold, Stop and Abort Handlers, 10 Steps with 8
Outputs each, 10 Transitions with 5 Conditions each, 10 Recipe
items, 5 History items)
SCM has total of 10 Steps and 10 Transitions among the 4
Handlers
Sequence Control Module B 2.0 3.0 35.7
(1 Main Handler, no other Handlers, 20 Steps with 4 Outputs
each, 20 Transitions with 3 Conditions each, 10 Recipe items, 5
History items)
SCM has total of 20 Steps and 20 Transitions
Sequence Control Module with an alias table size of 45 rows 2.0 3.0 128.5
by 100 columns
Outputs each, 10 Transitions with 5 Conditions each interspersed
in all the handlers, 10 Recipe items, 5 History items)
Handlers
Sequence Control Module with an alias table size of 500 rows 2.0 3.0 124.5
by 9 columns
Outputs each, 10 Transitions with 5 Conditions each interspersed
in all the handlers, 10 Recipe items, 5 History items)
Handlers
Medium sized CDB Module (CM with 1 medium sized CDB 0 0 1.5 (Note 2)
instance)
1.0 (Note 3)
(CDB instance has a total of 15 Custom Data Parameters of which
2 are arrays:
5 32 character STRING;
4 scalar FLOAT64;
4 scalar BOOLEAN;
1 20 element FLOAT64 array;
1 20 element BOOLEAN array.)

Consumption1
CEE
Redun
(PU/Module
dant
Execution)
(PU/
Modul
e
Execut
ion)
Note:
1. Total Processing Resources (PU/sec) per module are computed as = Processing
Resource Consumption (PU/module execution) / Execution Period (sec/module
execution).
2. Memory usage for first module instance.
3. Memory usage for every subsequent module instance.
4. PID-PL use 1.4 X the PU values listed here.
CCL Memory Resources:
These Block Libraries will consume the following extra memory when the first block is loaded to the C200/C200E
Controller:
AB_DRIVE_IF 90 MU
AGA 172 MU
DNETIF 106 MU
EXCHANGE 89 MU
FBUSIF (NI Fieldbus Linking Device) 82 MU
HARTIO 105 MU
PBUSIF 244 MU
PULSEINPUT 90 MU
RAIL_IO 120 MU
RAIL_IO_HAZ 107 MU
2.6.2 C300 CEE Processing and Memory Models

Consumption1
(FB Content in Parenthesis)
(Per Module)
50 ms C300 50 ms C300
(PU/Module Execution) (MU/Module)
Typical I/O Module 0.2 0.5
Analog Digital Acquisition Module 4.4 7.2
Small Analog Data Acquisition Module 0.5 1.0
67

Consumption1
(Per Module)
50 ms C300 50 ms C300
Regulatory Control Module 3.1 3.8
Auxiliary Function Module 5.0 6.2
Digital Data Acquisition Module 1.2 1.5
Small Digital Data Acquisition Module 0.2 0.5
(1 DI, 1 Flag FBs)
Device Control Module 1.3 2.3
Logic Control Module 1.3 3.6
(20 Logic FBs)
Sequence Control Module A 6.0 21.0
(1 each of Main, Hold, Stop and Abort Handlers, 10 Steps with
8 Outputs each, 10 Transitions with 5 Conditions each, 10
Recipe items, 5 History items)
Handlers
Sequence Control Module B 2.6 18.8
History items)
Sequence Control Module with an alias table size of 45 rows 5.0 151.5
by 100 columns
8 Outputs each, 10 Transitions with 5 Conditions each
interspersed in all the handlers, 10 Recipe items, 5 History
items)
Handlers
Sequence Control Module with an alias table size of 500 5.0 156.3
rows by 9 columns
items)
Handlers

Consumption1
(Per Module)
50 ms C300 50 ms C300
Recipe Control Module A 4.8 30.4
(1 each of Main, Hold, Stop and Abort Handlers; each handler
has 1 Invoke transition with 5 Conditions. Main Handler
contains 1 Step with 8 outputs, 4 Synch blocks, and 2 Transition
blocks with 1 Condition each, and 10 Phase blocks with 25
Formula parameters and 25 Report parameters each.)
The RCM executes 5 Phases in parallel.
Recipe Control Module B 2.8 19.3
Medium sized CDB Module 0 1.5 (Note 2)
(CM with 1 medium sized CDB instance) 1.0 (Note 3)
(CDB instance has a total of 15 Custom Data Parameters of
which 2 are arrays:
4 scalar FLOAT64;
4 scalar BOOLEAN;
NOTES:)
1. Total Processing Resources (PU/sec) per module are computed as = Processing Resource Consumption (PU/module
execution) / Execution Period (sec/module execution).
The C300 - 20msCEE controller supports all the modules except Sequence Control Module (SCM) and Recipe
Control Module (RCM) with same Memory Resource Usage.

Consumption1
(Per Module)
20 ms C300 20 ms C300
Typical I/O Module Not Applicable 0.5
Analog Digital Acquisition Module Not Applicable 7.2
69

Consumption1
(Per Module)
20 ms C300 20 ms C300
Small Analog Data Acquisition Module Not Applicable 1.0
Regulatory Control Module Not Applicable 3.8
Auxiliary Function Module Not Applicable 6.2
Digital Data Acquisition Module Not Applicable 1.5
Small Digital Data Acquisition Module Not Applicable 0.5
(1 DI, 1 Flag FBs)
Device Control Module Not Applicable 2.3
Logic Control Module Not Applicable 3.6
(20 Logic FBs)
Medium sized CDB Module Not Applicable Not Applicable
(CM with 1 medium sized CDB instance)
(CDB instance has a total of 15 Custom Data Parameters of
which 2 are arrays:
4 scalar FLOAT64;
4 scalar BOOLEAN;
Speed Protection Module Not Applicable
Servo Valve Positioner Module Not Applicable
NOTES:
2.6.3 ACE CEE Processing and Memory Models

Consumption1
(Per Module)
500ms ACE CEE 500ms ACE CEE
Analog Digital Acquisition Module 3.4 7.3
(10 Numerics, 10 DataAcq FBs)
Small Analog Data Acquisition Module 0.6 1.0
(1 Numeric, 1 DataAcq FB)
Regulatory Control Module 3.2 3.9
(1 Numeric, 1 DataAcq, 1 PID4, 6 Logic FBs)
Auxiliary Function Module 0.7 6.4
Digital Data Acquisition Module N/A for ACE 2.0
Small Digital Data Acquisition Module N/A for ACE 0.5
(1 DI, 1 Flag FBs)
Device Control Module 0.8 2.5
(4 Flags, 1 DevCtl, 5 Logic FBs)
Logic Control Module 1.3 3.9
(20 Logic FBs)
Sequence Control Module A 2.5 27.9
8 Outputs each, 10 Transitions with 5 Conditions each, 10
Recipe items, 5 History items)
Handlers
Sequence Control Module B 3.0 35.7
History items)
Sequence Control Module with an alias table of size 45 rows 3.0 128.5
by 100 columns
items)
Handlers
71

Consumption1
(Per Module)
500ms ACE CEE 500ms ACE CEE
Sequence Control Module with an alias table of size 500 3.0 124.5
rows by 9 columns
items)
Handlers
Recipe Control Module A 0.7 10.5
Recipe Control Module B 2.7 19.3
Medium sized CDB Module 0 1.5 (Note 2)
(CM with 1 medium sized CDB instance). 1.0 (Note 3)
CDB instance has a total of 15 Custom Data Parameters of
which 2 are arrays:
5 32 char. STRING;
4 scalar FLOAT64;
4 scalar BOOLEAN;
1 20 element BOOLEAN array.
NOTES:
2.7 CPU Utilization for CEE on CPM
CPU load categories

We divide the total CPU load to a CPM into the following three categories.
Category Description
Core CPU Load CPU load from core services independent of any load imposed by user
configuration.
Dynamic CPU Load CPU load imposed circumstances, which are unaccounted for by block
configuration. This includes such factors as CPU loading From:
notification report and distribution, and
parameter response Server Cache.
Configured CPU Load CPU load imposed by the user's control strategy configuration. You can
estimate this load by determining the number of “typical module types” as
described in the previous Typical Requirements section.
CPU utilization limits and estimates

This is based on the previous maximum loading cycle ratings listed in the table in the “C200/C200E processing
resources” on page 43 section. In summary, 60 percent of the CPU can be used for the configuration load with a
50 ms CEE or 40 percent with a 5 ms CEE.
Attention
This is not intended for the C300 - 20mS CEE Controller.
73
2.8 CEE Standard Control Blocks

The following table lists the size of the standard function blocks for the CEE controller (C200/C200E, C300,
ACE). This size information, along with a count of the number of blocks being used by a controller, can be
found on the CEE detail display for that controller.
Block Name C300 Size (bytes) C200/C200E Size (bytes) ACE Size (bytes)
2OO3 64 60 64
ABS 48 40 48
ACEFB 232
ADD 108 100 108
AICHANNEL 100 88
AIMODULECLS 552 516
AINIMODULECLS 684 648
ALMPANEL 212 212
ALMWINDOW 128 132
AND 44 36 44
AOCHANNEL 184 172
AOMODULECLS 588 552
AONIMODULECLS 668 632
AUTOMAN 1268 1272 1708
AUXCALC 536 516 560
AUXSUMMER 684 656 724
CABLOCK 404
CDBLOCK 164 152 164
CEEACEFB 37752
CEEC300FB 30164
CEEFB 29784
CHECKBAD 44 36 44
CHECKBOOL 976 952 1008
CHGEXEC 112 112
CONTACTMON 68 68
CONTROLMODULE 288 272 336
CPMFB 516
DATAACQ 680 672 1116
DEADTIME 784 772 792
DELAY 48 40 48
DEVCTL 1104 1084 1132
DICHANNEL 100 88
DIGACQ 120 124
DIMODULECLS 280 244
DIV 56 48 56
DOCHANNEL 132 120
DOMODULECLS 968 932
EHGOUT 470
ENHAUXCALC 932 904 972
ENHGENLIN 1784 1788
ENHREGCALC 2628 2608 3112
EQ 80 72 80
EXECTIMER 120 120
EXP 48 40 40
FANOUT 2700 2704 9168
FIRSTOUT 204 204
FLAG 52 44 52
FLAGARRAY 44 36 44
FLOWCOMP 480 472 508
FTRIG 36 28 36
GE 80 72 80
GENLIN 304 296 308
GRPCAPRBK 648 692
GT 80 72 80
HANDLER 44 36 44
HIWAYOUT 472
HTMOTOR 1096 1116
LE 80 72 80
LEADLAG 240 232 244
LEVELCOMP 240 248
LIMIT 140 132 140
LN 48 40 48
LOG 48 40 48
LT 80 72 80
LTMOTOR 992 1012
MAINIBV 268 276
MAX 108 100 108
MAXPULSE 48 40 48
MESSAGE 212 204 212
MIN 108 100 108
MINPULSE 48 40 48
MOD 56 48 56
MUL 108 100 108
MUX 56 48 68
MUXREAL 108 100 108
MVOTE 68 64 68
75
NAND 44 36 44
NE 80 72 80
NEG 48 40 48
NOON 100 92 100
NOR 44 36 44
NOT 36 28 36
NUMERIC 64 56 64
NUMERICARRAY 48 40 48
OFFDELAY 48 40 48
ONDELAY 48 40 48
OR 44 36 44
OVRDSEL 1864 1848 2316
PCDI_MASTER 25512
PCDI_FLAGARRCH 13512
PCDINUMARCH 9140
PCDINTEXTARRCH 3232
PHASE 420 404 428
PID 1892 1892 2336
PIDER 2016 2012 2468
PIDFF 2012 2008 2460
PID-PL 2904 2788 3348
POSPROP 2016 2012 2472
POW 56 48 56
PULSE 48 40 48
PULSECOUNT 336 320 356
PULSELENGTH 316 300 356
PUSH 192 180 200
PWMCHANNEL 184 172
QOR 60 52 60
RAMPSOAK 1588 1592 2028
RATIOBIAS 1428 1424 1872
RATIOCTL 1768 1764 2220
RCM 3128 3160
REGCALC 1988 1980 2448
REGSUMMER 1492 1488 1944
REMCAS 1492 1488 1936
ROC 156 160
ROL 40 32 40
ROR 40 32 40
ROUND 48 40 48
RS 36 28 36
RTRIG 36 28 36
SCM 3128 3112 3160
SecCPMFB 400
SEL 40 32 40
SELREAL 60 52 60
SHL 40 32 40
SHR 40 32 40
SIFLAGARRCH 360 348
SIGNALSEL 520 504 544
SIM 1712 1436 1712
SIMODULECLS 4876 4856
SINUMARRCH 688 676
SITEXTARRCH 436 424
SOLENOID 960 980
SQRT 48 40 48
SR 36 28 36
STARTSIGNAL 44 36 44
STEP 200 192 200
SUB 56 48 56
SWITCH 2544 2504 3012
SYNC 176 168 176
TEXTARRAY 48 40 48
TIMER 72 64 72
TOTALIZER 248 240 252
TRANSITION 184 176 184
TRIG 36 28 36
TRUNC 48 40 48
TYPECONVERT 156 148 160
UCM 296 264 344
UCNOUT 472
VALVEDAMPER 1120 1148
WATCHDOG 48 40 48
XOR 44 36 44
77
2.9 Control Component Library (CCL) Blocks

The following table lists the size of the CCL function blocks. This size information, along with a count of the
number of blocks being used by a controller, can be found on the CEE detail display for that controller.
Block Name Size (Bytes) Block Name Size (Bytes)

HARTAIM 2264 REQFLAGARRAY 300
HARTAOM 2284 REQNUMARRAY 496
HARTDEVICE 420 REQTEXTARRAY 372
RAILDIM 176 RSPFLAGARRAY 192
RAILDOM 296 RSPNUMARRAY 388
RAILAIM 216 RSPTEXTARRAY 264
RAILAOM 232 PBIM 3752
RAILTIM 208 PBI_DEVICE 180
DNET_IM 4320 PBI_INCHAN 1432
DNET_DEVICE 676 PBI_OUTCHAN 824
DNET_INCHAN 1872 ENCODERDEV 184
DNET_OUTCHAN 1264 ENCODERIN 92
AGA8GS_94 348 ENCODEROUT 104
AGA8DL_94 720 PBAIM 428
AGA3OM_92 460 PBAOM 308
AGA9UM_98 164 PBDIM 192
AGA7TM_96 164 PBDOM 196
IN 92 PROFIDRIVEDV 184
OUT 192 PROFIDRIVEI 696
IN_D 88 PROFIDRIVEO 572
OUT_D 132 SIMOCODE3UF5DEV 184
LD 808 SIMOCODE3UF5I 216
FLEXDOM 532 SIMOCODE3UF5O 128
FLEXTIM 204 BIZERBASTDEV 180
FLEXDIM 232 BIZERBASTIN 216
FLEXDIM641 284 BIZERBASTOUT 92
FLEXAIM 192 PBDIAGNOSTIC 1440
FLEXAOM 204 DRIVEDEV 220
CNTRFB 100 DRIVEINCHAN 264
PIMFB 472 DRIVEOUTCHAN 212
PICFB 132
PICFCFB 136
TOTALIZER 204
3 Control Module Independence
Related topics
“Module Independence for Flexible Modification” on page 80
“CM Independence and Hypothetical Controller Comparison” on page 81
“CEE Architecture” on page 83
“Validation of Control Module Independence” on page 87
“Resource Coupling Across Different Platforms” on page 88
79
3 CONTROL MODULE INDEPENDENCE
3.1 Module Independence for Flexible Modification

The Experion system supports both batch and continuous control applications that vary widely in terms of
control duration requirements. Batch applications typically remain online to provide active control for only a
few hours, days, or weeks at most. In contrast, continuous control applications can remain in active control for
years. A running continuous control strategy is usually only shut down when product goals change or capital
equipment needs to be replaced or repaired. The Experion Control Execution Environment (CEE) provides a
hybrid control that incorporates product capabilities geared toward supporting both batch and continuous
control disciplines.
The CEE is a layer of software services that allow Experion control applications to run in multiple hardware
platforms. The CEE runs in the Experion C200/C200E and C300 process-connected controllers as well as the
Application Control Environment (ACE) supervisory, soft controller.
The CEE allows users to build and modify complete control strategy configurations for continuous control over
periods of months or years. Users can modify existing segments or add new ones without affecting other
segments that remain online. The CEE design gives users the ability to modify control strategies independently.
3.2 CM Independence and Hypothetical Controller Comparison

The notion of independence of control strategies within a controller may be new to some control engineers. Not
all controllers have supported this feature in the past, and different engineers may form conflicting opinions
about the feasibility of this idea based on different mental models of how controllers work internally.
3.2.1 Hypothetical controller structure

For comparison purposes, consider a controller design with a software architecture that is broadly divided into
two layers as illustrated below.
Infrastructure services
The infrastructure services would consist of a variety of system enablers, two of the most important being a
Real Time Operating System, vendor purchased or custom developed, and a set of Communication Services.
Another important set of infrastructure services would 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 would
develop this program and implement custom control strategies. Supposing that multiple control strategies could
be supported within this program, all applications implemented within it would share certain properties since it
is a single program. For example, they would all be loaded together and would have the same timing properties.
Assuming that the timing properties have the potential to be fast, they are unregulated.
3.2.2 Coupling effects in hypothetical controller

In the hypothetical controller described above, there would be significant coupling between the various control
strategies within the controller. The following table summarizes the types of coupling that would exist.
Type of Coupling Comparison Consideration

Execution Timing The hypothetical controller does not regulate the execution period of the application program.
This could be an advantage in fast, discrete control applications. End users could deliberately
choose to use a small application program to get the fastest possible response time. However,
it could be a disadvantage in continuous applications where the scaling of time constants
required for time discretization works best under a well regulated execution period.
In addition, the lack of a regulated execution period introduces a form of coupling between
control strategies. If the user wished to augment or reduce a particular control strategy it
might substantially impact the execution time of the program as a whole. If this happened,
execution timing for all strategies would be affected, not just the one modified.
Load / Unload In the hypothetical controller design, the application program is monolithic. Thus, it is not
possible to load or unload a particular control strategy without loading or unloading all others
at the same time. To change an individual control strategy, all control strategies must be shut
down following the required safety procedures and incurring whatever loss in production
results.
81

Data Reference This coupling is designed into the application by the end user and is consistent with the
control mission. Typically, various control applications within the application program need
to share data and do so by holding references to data located within a common pool.
However, depending on the controller design, the impact of this coupling can be greater or
smaller. Let us assume that in the hypothetical controller, access to data owned by the
application program is not possible unless that data is explicitly declared public within the
program. Under this assumption, custom displays cannot be developed without potential
impact to the application program. If it were necessary to build a new display or change a
display after the controller had been commissioned, the controller would have to be shut
down and the application program reloaded.
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.
In the case of the hypothetical controller architecture, all control strategies within the
application program use memory from a common pool. Once the memory pool is exhausted,
the size of the program cannot be further increased. If the pool has been exhausted and it is
essential to augment a particular control strategy, it may be necessary to reduce or eliminate
another control strategy.
CPU Utilization Another common resource shared across control strategies is CPU execution time.
Assuming that control strategies must be executed at a certain rate and assuming that a
certain level of CPU is used for support services, there will be a finite amount of CPU
execution time available for control strategies. If the CPU resource is at its limit and it
becomes necessary to add a control strategy, it may be necessary to remove another one.
Communication Data transfer between control strategies and IO requires the use communication bandwidth.
Bandwidth Utilization Similarly data transfer between control strategies and supervisory controllers, peer controllers
or HI requires the use of communication bandwidth.
Communication bandwidth can be a somewhat abstract resource to quantify. It depends on
the characteristics of parallel and serial communication paths and on the characteristics of
Asics or CPUs which serve those paths. But it is an identifiable and finite resource. If the
Communication bandwidth is at its limit and it becomes necessary to add a control strategy, it
may be necessary to remove another one.
3.3 CEE Architecture

The hypothetical controller described above may or may not resemble controller products on the market today.
But similar controllers have been sold in the past and may impact the expectations of some control engineers.
The design of CEE and its hosting on the C200/C200E, C300 and ACE controllers is different. These
differences eliminate some of the potential couplings between control strategies and reduce others. Some forms
of coupling, in particular coupling that arises from a finite computing or communication resource cannot be
entirely eliminated in any controller design. But its impact can be moderated
3.3.1 CEE controller structure

The following illustration gives a high level view of the software layers in a controller hosting a CEE.
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 in that 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
3.3.2 Program and Data Partitioning

The Control Modules layer in the illustration above sits above the Application Programs and provides
partitioning between program and data set.
Control Modules or just “Modules” are grouped data sets which contain the data associated with component
blocks and the relationships which connect those blocks. Several types of modules are supported. Control
Modules (CMs) support repetitive, regulatory control algorithms. Sequence Control Modules (SCMs) and
Recipe Control Modules (RCMs) support batch oriented sequential control algorithms.
83
Application programs and control modules work together to create the complete functionality of the application.
In software terminology, the application programs hold the classes for the control algorithms while the Control
Modules hold the object instances (the data).
In CEE, the terminology used is more specific to the domain of control. Classes are referred to as block types
while object instances are referred to as block instances or just blocks. Most CEE block types are encoded
within application programs which are built into the controller and do not change when control applications are
created. These are called native block types. Others types created by end users. These are called custom block
types.
When users insert a block into a Control Module, they are actually creating a block instance. Each module can
hold one or many block instances. Within a module, configuration can be changed and tunable constants can be
modified, both off-line and on-line. All this can be done without impact to any but the module being touched.
In addition, control modules can be loaded and unloaded individually. Load and unload of one module has no
impact on any other.
3.3.3 Native program and custom program partitioning

The two types of programs within the application program layer shown in the illustration above provide
partitioning between native programs and custom programs. One type of program holds the native block types
which are built into the controller. The other holds custom block types created by the end user.
Blocks which instantiate native types are used more widely than blocks which instantiated custom types. But
regardless of whether they instantiate native or custom types all block instances and their parent modules
provide the characteristics of data independence described in the preceding section.
Custom block types

The following three categories of custom block types are within CEE.
• PHASE blocks
• Custom Algorithm Blocks (CAB)
• Custom Data Blocks (CDB)
The advantage of Custom types is that a single piece of source code (the type) can be created and used,
unmodified, by multiple instances. At the same time, custom types present an additional form of coupling
within the application. Changing a block instance has no impact upon the type it instantiates. But, when a
custom type is changed, that change must eventually be propagated to every instance of the type.
Coupling between custom types and Control Modules must be managed by the application engineer. However,
custom block types are independent of each other, which makes the task a little easier. They are loaded
independent of each other, with the load happening implicitly upon load of the first instance. Any coupling
between types is limited to that which the application engineer creates between the instances. There is no direct
coupling between the types themselves.
3.3.4 Regulated Base Cycle

Another CEE design feature, which enhances independence, is its execution scheduling. In the hypothetical
controller described above, the control period could vary depending on flow through the application program for
any particular execution. Different code paths could get executed under different executions causing the control
period to vary.
In the CEE design, all control periods are based on a fundamental base cycle whose start time is regulated.
While execution timing varies within any real-time software design, the cycle scheme used in CEE controls the
amount of variation possible.
3.3.5 Coupling effects in CEE-based controller

In the hypothetical controller described above, there would be significant coupling between the various control
strategies within the controller. The following table summarizes the limited types of coupling that can exist
between control strategies within a CEE-based controller.

Execution Timing No coupling
Load / Unload When a control module containing only native block types is loaded, it has no impact on any
other control module.
When a control module containing instances of one or more custom block types is loaded, it
has no impact on any other control module.
When custom block instances are loaded, they always have a dependence upon a type. If the
needed type, or the needed version of the type, is not already present within the CEE, it is
loaded implicitly along with the control module. If there are pre-existing instances which use
an older version of the type, they are unaffected and continue to execute. The old block type
is not eliminated as a result of loading the new type. However, application engineers must
take responsibility to see that, eventually, all previously loaded instances are reloaded, so that
they start to use the new version of the type.
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 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 is or is not data transfer
between modules is completely controlled by the application engineer.
However, the design of the CEE controller and the Experion 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 accessed data.
Similarly, when supervisory or peer control strategies are created which access data for the
first time, no change or load of the reference module is required.
Because of inherently external parameter linkage, CEE modules do not need to be re-
qualified if the set of data to be read is changed after the initial qualification.
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 a module to be loaded might not fit into the
remaining memory. This can happen if an application engineer has increased the module's
configuration so that it requires more memory. Or it can happen if application engineers have
changed other modules so that upon reload of this module, not enough memory remains.
By design, memory allocations generally do not occur dynamically within a CEE-based
controller. They only happen as a direct result of a user-initiated module load. In all cases, the
failure of a module to load is known immediately by the return of an error message. When
this happens, there are no adverse consequences other than the fact that the module itself
cannot be loaded. Modules which have already been loaded and which are resident do not
require any kind of re-qualification because a different module has failed to load.
In general, application engineers should plan the configuration of a CEE-based controller so
that there is always some amount of reserve memory. Parameters TOTALMEM, USEDMEM
and FREEMEM of the CPM block should be checked from time to time to determine how
much memory remains unused.
85

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 case of overrun.
The processing scheme is based on 40 cycles, each one 0.05 seconds long (the count and
length of base cycles are different in the ACE soft controller). The start of each cycle is time
regulated. Modules which run in each cycle are selected by the application engineer in a
balancing procedure which distributes total load across the set of cycles. In a CEE
configuration which is balanced properly, and which is not overloaded, a module can be
added or removed without impact to any other module, despite the use of a shared CPU
resource.
On the other hand, if the controller as a whole is overloaded, or if one or more cycles is
overloaded, it is possible to incur processing overruns. An overrun occurs when cycle N does
not finish its processing in time for the start of cycle N+1. If this happens, the start of cycle N
+1 is postponed until the time originally designated for the start of cycle N+2. The net effect
is to pause control processing by one cycle. No module's processing is skipped. Some timing
operations are extended. No timing operations are shortened.
In general, a configuration which incurs one or a few overruns in the space of an hour suffers
no degradation of control. However, application engineers should be conscious of the CPU
resource when configuring a controller and should design control configurations that do not
incur overruns. They should insure that the controller as a whole is not overloaded and that
no individual processing cycle is overloaded. This activity does not require re-validation of
individual modules. Rather it is a standard procedure which should be followed for the
controller as a whole whenever its configuration is changed.
As a general guideline, the total, time-average, free CPU available within the controller
should be kept above 20%. This can be determined from the value of the device block
parameter CPUFREEAVG. The time-average CPU utilization of any individual cycle should
be loaded in accordance with the specifications of the controller in use (C200/C200E, C300
or ACE). Cycle loading can be determined from the value of the CEE block parameter
CPUCYCLEAVG(I). In addition, during configuration, application engineers should
occasionally check the overrun statistics parameters CRCYCLEOVRN(I) and
LSCYCLEOVRN(I) of the CEE block to see whether there have been any overruns within
the controller or within any particular cycle of the controller.
If a configuration error is made which causes repetitive overruns that could degrade control,
the host controller will report an overrun alarm. This alarm will clear once repetitive overruns
cease.
Communication Like any controller, the CEE-based controllers use communication bandwidth for data
Bandwidth Utilization transfer. Types of data transfer include: communication with IO devices; communication with
peer controllers; communication with supervisory human interface and control devices; alarm
and event reporting.
Communication bandwidth can be viewed as a common resource shared by all modules
analogous to memory or CPU processing time. Reliance on this common pool introduces a
potential coupling between modules.
Adverse effects from sharing communication bandwidth do not occur, if the CEE-based
controller is configured within its specified operating limits. Under these conditions, modules
can be added and deleted at will and all modules operate using their needed communication
bandwidth with no impact to other modules.
To construct CEE configurations which conform to the specified operating limits, application
engineers should refer to the Control Capacity and Performance section in this document as
well as Experion product specifications for more information.
3.4 Validation of Control Module Independence

Honeywell's TDC2000, which was the original distributed control system (DCS) introduced circa 1970,
employed several of the fundamental principles of control module independence even though its control objects
were not called modules. These principles were first implemented to meet the rigorous requirements of long-
term continuous control. They have been employed in each of the generations of Honeywell DCS to follow,
most recently in the Experion system.
Since the principles of control module independence have become so fundamental, some of them are not
explicitly tested in new generations of DCS. In the case of the Experion system, some of the independence
principles have been tested explicitly while others have been tested implicitly within the hundreds and
thousands of test cases that cover the entire set of functionality contained within the DCS.
The following list indicates the extent to which control module independence has been tested explicitly or
implicitly within the Experion system.
Type of Coupling Test Consideration

Execution Timing Tested that 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 CMs and SCMs can be loaded independently of one another gets
continuously revalidated with every control configuration that is created. That other modules
are unaffected is implicitly revalidated when the control strategies behave as testers expect.
That the programs associated with instances of custom block types are loaded independently
was tested extensively with the introduction of the first Experion category of custom types,
CAB. It has been retested with the introduction of the new categories of CDB and PHASE.
That loading a new version of a custom block type does not impact blocks already running on
a previously loaded version was tested with the initial introduction of custom block types. It
gets retested implicitly every time an instance of a modified type is reloaded when pre-
existing instances are already present in the CEE.
Data Reference The fact that CEE and the Experion 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.
CEE algorithm blocks support a policy of built-in fail-safe handling is very well known by
system testers and is covered by numerous tests that they have designed and run. That fail-
safe handling applies to de-activation is also well known and well tested.
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 has been done on the behavior of control execution in response to overload
and in response to configurations with poor balancing. That the response is controlled
overruns, that the overruns are counted and that when they occur repetitively an alarm is
generated has been very well validated.
Communication Explicit testing has been done on the communication load that can be handled by each of the
Bandwidth Utilization communication channels used at run time by a CEE-based controller. The capacities are
consistent with published Experion specifications.
87
3.5 Resource Coupling Across Different Platforms

The various types of “couplin” that can exist among control strategies within a controller can be divided into the
following two broad categories.
Category Description
Programmatic Coupling These are dependencies which arise from the fact that algorithms are implemented
in a monolithic program or which arise from the fact that there are explicit data
dependencies among the algorithms. Of the types of coupling described in the
preceding sections, Load / Unload, Execution Timing and Data Reference can be
considered examples of Programmatic Coupling.
Resource Coupling Other dependencies are less direct but can arise 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 can be
considered examples of Resource Coupling.
All CEE-based controllers have equivalent behavior with respect to Programmatic Coupling as these
characteristics are directly determined by the design of CEE. Each hosting controller, C200/C200E, C300 and
ACE, has distinct characteristics of resource coupling, which derive directly from the capacities of the host
platforms. In each case, the effects of adverse Resource Coupling can be controlled by using configurations that
are within specification for the hosting platform.
4 Relative References
This section describes what relative references are, how they are displayed, and what Control Builder functions
support them as well as some examples of how they may be used.
Related topics
“About Relative References” on page 90
“Relative References structure rules” on page 91
“Display options for relative references” on page 93
“Control Builder functions supporting relative references” on page 95
“Control Builder blocks supporting expressions” on page 96
“Example of TRANSITION block using relative references” on page 97
“Example of parameter connector using relative references” on page 99
“Example of other parameters using relative references” on page 100
“Bulk Builder and Bulk Editor support” on page 102
89
4 RELATIVE REFERENCES
4.1 About Relative References

Beginning in Experion R300.1, you can use a relative reference as a shorthand method for specifying a
parameter reference in the following scenarios, since all relative parameter references are within the scope of a
tagname.
• A parameter reference on any block could refer to another parameter on the same block.
• A parameter reference on a container block could refer to a parameter of a contained basic block.
• A parameter reference on a basic block could refer to a parameter on its container.
• A parameter reference on a basic block could refer to a parameter on another basic block within the same
container as the basic block.
4.2 Relative References structure rules

The following table lists the syntax for relative references. As noted in the table, a special character ($) is used
when the parameter name desired for the reference resides on the container block, but the reference owner also
defines the same parameter name. Without special handling, the entry would resolve the reference to
cm.myblock.param, where the user desired a reference to cm.param. In this case, a special character specifies
that the container block is desired for the reference.
Reference Is Owned Parameter to be Referenced Is Owned By

By
Same Block Tagged Basic Container with Same Container Other basic block
Block same param within container
name as a basic
block
Basic Block param $.tag.param or $. param param or $.param block. param or
tag.param $.block.param
Tagged Basic Block param FULLNAME $.param Param or $.param block. param or
(Hart enabled $.block.param
channel blocks)1
Tagged Block param or $.param FULLNAME FULLNAME FULLNAME FULLNAME
Container Block param or $.param $.tag.param or FULLNAME param or $.param block. param or
tag.param $.block.param
Note
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.
4.2.1 How relative reference matching function works

The following flowchart diagram provides an overview of how the relative reference matching function
searches for a match on the user entry.
91
4.3 Display options for relative references

You can select whether relative references are to be displayed in Full Name or Short Name format through the
Relative Reference Display Option on the General tab of the System Preferences dialog in Control Builder.
Refer to Setting system preferences in the Control Building Guide for more information. This option only
applies to how relative references are displayed and the default is Full Name. Relative references may be
entered in shorthand format, regardless of the option selected
If you select the Full Name option and enter a reference as block.param, the reference will be displayed as
tagname.block.param.
If you select the Short Name option and enter a reference as tagname.block.param that is within the scope of
the tagname, the reference will be displayed in a short name format. When a basic block references a parameter
on its container block, a special character ($) precedes the parameter name. The following table outlines how
references are displayed when the Short Name option is selected.
Reference Is Owned Parameter to be

By Referenced Is
Owned By
Same Block Tagged Basic Container with Same Container Other basic block
Block same param within container
name that a basic
block has
Basic Block param FULLNAME $. param $. param block. param
Tagged Basic Block param FULLNAME $. param $. param block. param
(Hart enabled
channel blocks)1
Tagged Block param FULLNAME FULLNAME FULLNAME FULLNAME
Container Block param FULLNAME FULLNAME param block. param
Note
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.
4.3.1 How short name display option works

The following flowchart diagram provides an overview of how parameter references are displayed when you
select the Short Name as the Relative Reference Display Option.
93
4.4 Control Builder functions supporting relative references

The following Control Builder functions support the entry of parameters as relative references.
• Expressions
• Parameter Connectors
• Parameters of type TC_PARAMID. Examples of these parameters are the history, trend and group
configuration parameters associated with tags and key parameters used in the SCM/RCM table view.
95
4.5 Control Builder blocks supporting expressions

The following blocks support the use of expressions and the entry of parameters as relative references.
• AUXCALC
• ENHAUXCALC
• ENHREGCALC
• REGCALC
• STEP
• TRANSITION
4.6 Example of TRANSITION block using relative references

You can enter an expression using relative references for parameter references within the scope of the
containing Control Module (CM), Sequential Control Module (SCM), or Recipe Control Module (RCM). The
length of the expression will be validated against the string as it will be displayed based on the Relative
Reference Display Option selection and not the length of the entry.
The following are valid entries for the same equation in a TRANSITION block within the Example_SCM.
• example_scm.COMMAND=3
• COMMAND=3
The following example illustrations show how expressions would appear with Short Name as the selected
Relative Reference Display Option.
4.6.1 A container reference from a chart
4.6.2 A reference to a parameter on the same block from a form
97
4.6.3 A reference to a parameter on a different block in the same CM
4.6.4 Expression display interaction

The format of an expression parameter that is read from Server (Station displays), displayed in a Control
Builder Report, or included in an Import/Export (IXP) file depends on whether the Relative Reference Display
Option selection on the Control Builder System Preferences dialog is Full Name or Short Name.
4.7 Example of parameter connector using relative references

You can enter a parameter connector as a relative reference. The container owns the parameter connection. The
display format for a parameter connector in the Control Builder chart depends on whether the Relative
Reference Display Option selection on the Control Builder System Preferences dialog is Full Name or Short
Name. All cross references will be displayed as full name regardless of the Relative Reference Display Option
selection.
The following example illustration shows how parameter connectors would appear with Short Name as the
Relative Reference Display Option selection.
4.7.1 A reference to a parameter on a different block in the same CM
4.7.2 Parameter connector display interaction

The format of a parameter connector displayed in a Control Builder Report or included in an Import/Export
(IXP) file will always be full name.
99
4.8 Example of other parameters using relative references

You can enter the following parameters as a relative reference. The display format for a parameter in the Control
Builder chart depends on whether the Relative Reference Display Option selection on the Control Builder
System Preferences dialog is Full Name or Short Name.
• 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 shows how other parameters would appear if Short Name is the Relative
Reference Display Option selection.
4.8.1 A reference to a parameter on a basic block of the CM
4.8.2 Other parameters display interaction

The format of other parameters read from Server (Station displays) will always be full name.
The format of other parameters displayed in a Control Builder Report, or included in an Import/Export (IXP)
file depends on whether the Relative Reference Display Option selection on the Control Builder System
Preferences dialog is Full Name or Short Name.
101
4.9 Bulk Builder and Bulk Editor support

The Bulk Builder and Bulk Editor do not support entry or display of shorthand relative references.
5 Peer-to-Peer Functionality
Related topics
“Basic Peer-to-Peer Design Concepts” on page 104
“Initiator Rate - Calculation” on page 115
“Implications for Control Builder Configuration” on page 118
103
5 PEER-TO-PEER FUNCTIONALITY
5.1 Basic Peer-to-Peer Design Concepts

You can implement peer-to-peer communications among CEEs in multiple C200/C200E Control Processor
Modules (CPMs) networked to the same Server.
You can visualize the peer-to-peer function as a set of connections between two CPMs. This allows function
blocks in different Control Execution Environments (CEEs) to share data through user configured parameter
connections. The Control Data Access (CDA) services assume the responsibility for maintaining all
connections.
You can implement peer-to-peer communications among CEEs in multiple Application Control Environment
(ACE) supervisory controllers that belong to the same system Server over the Fault Tolerant Ethernet (FTE) or
Ethernet network. The ACE supervisory controller can peer-to-peer with CEEs in multiple C200/C200E CPMs
through an optional direct connection to the ControlNet supervisory network. The following figure illustrates
the possible peer-to-peer communication topologies. It shows peer-to-peer between ACE supervisory controllers
over Ethernet, between ACE supervisory controller and C200/C200E Process Controllers over ControlNet
supervisory network, and between C200/C200E Process Controllers over the supervisory network.
5.1.1 Data flow models

The peer-to-peer design uses both Publish/Subscribe and Request/Response data flow models.
The Publish/Subscribe model establishes a publication contract between two CEEs. The one CEE (Subscriber)
asks the other CEE (Publisher) to periodically publish the data value. You can configure the Subscriber's
subscription rate as 10, 20, 50, 100, 200, 500 or 1000 milliseconds through the associated CPM block
configuration form. (Note that the applicable subscription rates vary for the 5 ms CEE or 50 ms CEE image
loaded in the Controller.) The Publisher periodically publishes data on a report by exception basis. If a Publisher
supports two Subscribers with different publication rates, it maintains independent publication rates for all of its
clients. The Publisher continues to publish data until the Subscriber cancels the contract.
The Request/Response model involves a one-time request forget/store data. A get request reads the value of a
data item and a store request writes the value of a data item. Once the responder fulfills the request and the
requester receives the response, the operation is complete.
5.1.2 Peer environments and subscription periods

You can identify different peer environments and configure individual subscription periods and store response
time values through the applicable CEE configuration form in Control Builder. This includes other ACE
supervisory controllers, C200/C200E Process Controllers, and external servers, such as OPC servers. The
configuration form also specifies default subscription period and store response time values to be used for all
peer environments without individually specified settings.
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.
5.1.3 Software Architecture for CPM/CEE

The graphic in the following figure gives a high level view of the Experion communication architecture. It
shows how CDA Publish/Subscribe and Request/Response data access methods provide network
communications to/from blocks associated with CEEs loaded in CPMs.
This graphic is only intended to give you a general idea of how CDA manages the flow of data values for CEEs,
CB Monitoring , and Station displays within the Experion system. The dynamic cache acts like a
communications filter to reduce multiple requests for the same data value down to one, which in turn, results in
the sending of only one publication request for the item.
The important thing to remember is that peer-to-peer communications are layered upon CDA, which uses
connection-oriented communications.
105
Figure 8: Peer-to-peer is layered upon CDA connection-oriented communications.
5.1.4 A word about ACE/CEE architecture

The overall architecture for the ACE supervisory controller is similar to the C200/C200E Process Controller. It
features separate CEE and Control Data Access-supervisory platform (CDA-sp) processes that communicate
through shared memory and Windows 2000 events.
The ACE/CEE executes on a personal computer running a Windows Server operating system. The CEE consists
of two subsystems: Control Kernel (CK) and Control Functions (CF). The CK provides services for function
block execution and data transfer for controlling a process. The CF is a collection of function (algorithm) blocks
for controlling a process.
Attention
Refer to the latest Experion Specification document for the operating system specifications.
Since the ACE/CEE runs on a time-sharing operating system, the timed event for function block execution may
be delayed or interrupted by other tasks. The ACE/CEE function block includes statistical parameters for
calculating timed event for function block execution.
Cyclic “get” requests are forwarded to the CDA during function block connection configuration load. This
results in the allocation and addition of a request in the shared memory between CDA-sp and ACE/CEE where
peer data is imaged. CDA-sp collects peer data and copies it from communication buffers into shared memory.
At run time, a function block converts memory data into a reference to intimately access peer data.
5.1.5 Peer-to-peer communication between CEE and non-CEE points

Prior to R410, OPC Integrator and OPC Gateway were used to transfer data from the Experion Server points
such as SCADA Points and OPC Advance Points to the CEE controllers such as C300/C200E. In addition, peer-
to-peer communication between the C300 Controller and the Safety Manager was achieved using PCDI. Peer-
to-peer communication between the ACE and TPS points was supported through OPC Gateway and direct peer
references from CEE to Experion Server Points was not supported. Moreover, the peer-to-peer communication
was not redundant, and peer-to-peer communication between C300/C200E and TPS points was not supported.
CEE controller points

With R410, native peer-to-peer communication is supported between CEE-controllers such as C300, C200E,
ACE, SIM-C300, SIM-C200E, and SIM-ACE, and non-CEE controllers such as PMD and Safety Manager. In
addition, peer-to-peer communication is also supported between the CEE-controllers and Experion Server
points such as OPC point, OPC-Advanced point, DSA, Point Servers, SCADA, and TPS, through Experion
Server. This feature is licensed as Experion Server Peer Responder.
The peer-to-peer communication with non-CEE points is possible in the control strategies assigned to the CEE
points using the following functions.
• Parameter connector
• SCM expression
• SCM Alias Table
• CAB parameter references
• PHASE block parameter reference using Formula Parameter and Report Parameters
• Expressions in the AUXCALC, ENHAUXCALC, REGCALC, and ENHREGCALC blocks
Attention
• Peer-to-peer communication is not supported between the non-CEE points and the following:
– C300-20msCEE
– Fieldbus blocks
– PMIO and Series C I/O blocks
– Control cascade.
5.1.6 Peer-to-peer communication between ACE/C300 and EHPM points

Starting with Experion R430, peer-to-peer communication is supported between the ACE/C300 Controller and
the EHPM Controller.
For information on establishing peer-to-peer communication between the ACE/C300 Controller and the EHPM
Controller, refer to the Control Building User’s Guide.
Peer-to-peer communication between EHPM and PMD

Peer-to-peer communication between the EHPM Controller and the PMD Controller is not supported.
107
CAUTION
If there are any PMD-Experion server Peer Responder connections to points in an EHPM Controller, then, before
you import these EHPM points into ERDB, configure these PMD-Experion server Peer Responder connections to
use a different data access path to the EHPM. If left unchanged, PMD-Experion server Peer Responder
connections are lost permanently after the EHPM points are imported and the EHPM block is loaded to the
Control Builder Monitoring side.
For example, consider a scenario where an EHPM Controller has a point n11b11pmp31, and PMD is
communicating with the EHPM point n11b11pmp31 through the Experion server Peer Responder connection. In
this case, import of EHPM point n11b11pmp31 succeeds but when the EHPM is loaded to the monitoring side in
Control Builder, then the PMD-n11b11pmp31 connection is lost permanently.
If the ACE/C300 CEE-Experion server Peer Responder connections to the EHPM points exist, these connections
are not affected by the import of EHPM points into ERDB and continues to work unchanged.
5.1.7 Guidelines for configuring peer-to-peer communication between CEE and non-CEE points
Common configuration guidelines

Before configuring the peer-to-peer communication between CEE and non-CEE points, you must adhere to the
following common guidelines.
• Data type of non-CEE point's parameters and CEE parameters must be identical.
Note:If you try to configure different data type parameters for peer-to-peer communication, DataType
mismatch error appears.
• The format in which you need to reference non-CEE peer-to-peer parameters except for TPS points must be
as follows:
<point name>.<parameter name>[<array index1>,<array index2>]
Note:Use Square bracket [] instead of braces ().
• The format for configuring the TPS points must be as follows:
<point name>.<parameter name>(<array index1>,<array index2>)
• Non-CEE points can be entered while resolving substitute parameters.
Example: Consider that if the actual Safety Manager parameters are not published and the configuration has
to proceed. In this case, use substitute names feature of the Control Builder to configure the points. Later,
publish the Safety Manager points and use resolve substitute parameter name to replace with the actual
parameter name.
• For TPS points, only alphanumeric characters and the following special characters can be used while
configuring the expressions.
– Underscore (_)
– At sign (@)
– Dollar sign ($)
Attention
• Whole array peer-to-peer communication is not supported between CEE and non-CEE points.
• CAB on ACE dynamic re-referencing is not supported for non-CEE peer-to-peer references.
• You cannot configure non-CEE points in the Server History and Trend configuration of CM in Control Builder
• Non-CEE points are not listed in the Point Picker. Therefore, you must remember the correct non-CEE point
names to configure in the control strategies.
• The following parameters of the SCM-STEP block cannot be configured for peer-to-peer communication with the
non-CEE points.
– OP[].INSTRUCTTYPE
– OP[].CURRVALREF
– OP[].ENTRYVALREF
– OP[].MONTASKREF
– OP[].TARGETVALREF
– OP[].TARGETDESCREF
– OP[].TARGETMAXREF
– OP[].TARGETMINREF
– OP[].TARGETEUDESCREF
– OP[].CURRDESCREF
– OP[].CURREUDESCREF
– OP[].ENTRYDESCREF
– OP[].ENTRYMAXREF
– OP[].ENTRYMINREF
– OP[].ENTRYEUDESCREF
Before configuring a peer-to-peer reference in the Control Builder to an Experion Server point, you must ensure
the following:
• The point to which the peer-to-peer communication is being configured must exist in the Experion Server
database.
• Performing the Experion Server peer-to-peer configuration when both servers are running and are in
synchronization is recommended. If you perform peer-to-peer configuration when only one server running
as primary, ensure that the System Repository is in synchronized state after the other server is started as
backup server.
• Ensure that you do not perform Experion server peer-to-peer configuration and load when the servers are in
dual primary state. If you attempt to do so, the peer-to-peer communication between the Experion server
points would be lost once the servers recover from the dual primary state.
• TPS points must be primed before referencing it for peer-to-peer communication.
• Array parameter of the TPS point must be configured before configuring the peer-to-peer configuration to
the array parameter of the TPS point in the Experion Controllers (Example: C300, C200E or ACE). If you
want to reconfigure the array parameter of the TPS point, you must reload the control strategy. To reload the
control strategy, refer “Regulatory Control” on page 261.
• Data type of the OPC advanced point is always configured as FLOAT64 parameter. Hence, peer-to-peer
configuration has to be done for FLOAT64 parameter only in the Control Builder. For data type conversion
(example, converting a data type from FLOAT64 to INT16), use TYPECONVERT block for peer-to-peer
communication.
• Variant data types published by point servers cannot be added to peer-to-peer configuration.
Data type matching between the Experion Server points and CEE points.
The following table lists the data type between the CEE, SCADA, OPC advanced, and DSA points.
109
Experion SCADA OPC Advanced point DSA point

BOOL Enumeration Float 64 Enumeration
Enumeration Enumeration Float 64 Enumeration
Float 64 Float 64 Float 64 Float 64
Float 32 Float 64 Float 64 Float 32
INT 32 Float 64 Float 64 INT 32
SD Enumeration Float 64 Not applicable Enumeration
UINT 16 Float 64 Float 64 INT 32
STRING Not applicable Not applicable STRING
TIME Not applicable Not applicable TIME
TOD Not applicable Not applicable TOD
Delta Time Not applicable Not applicable Delta Time
Attention
DSA point name has to be unique across clusters. The DSA point with the same name in another cluster cannot be
configured for peer-to-peer communication.
Before configuring a peer-to-peer reference in Control Builder to a Safety Manager or a PMD point, you must
ensure the following:
• Safety Manager and PMD are published to Experion from their respective configuration tools.
For more information about the supported release and subsystem configuration tools for enabling the peer-to-
peer communication between the Experion CEE points and non-CEE points, refer to the respective subsystem
documents. For example, if you want to know about the compatible release of Experion with PMD Controller
that supports native peer-to-peer communication with CEE controllers, refer to Experion PKS with PMD
Controller Software Change Notice and Experion PKS with PMD Controller Overview Guide. For peer-to-peer
configuration details, refer to Experion PKS with PMD Controller Configuration and Operations Guides.
Other considerations for peer-to-peer configuration

Though the Experion Server parameter is invalid, the parameter referenced in configuration is not deleted
automatically. However, the runtime of already loaded strategies with invalid non-CEE parameter stops
working. Loading or re-loading of strategies with the invalid non-CEE parameter displays the validation error.
5.1.8 Renaming non-CEE point/data type change consideration in configuration

Any renaming of a non-CEE point and data type changes of a parameter to an already configured non-CEE
point parameter in Control Builder needs to re-configure the peer-to-peer connection. For example, consider a
Safety Builder point parameter of FLOAT64 data type is connected to a CEE FLOAT64 point parameter. At
later point of time, the data type of the same Safety Builder point is changed to INT32. During such changes of
data type for the point needs to re-configure the peer-to-peer connection as the connection becomes invalid.
Similarly, a renaming of a Safety Manager (SM) point that is already configured for peer-to-peer
communication in Control Builder needs to re-configure the peer-to-peer connection as the connection becomes
invalid.
Perform the following steps to re-configure the peer-to-peer connection.
1. Find all the reference of the non-CEE point for which the data type has been changed.
Note: Configuration Studio Search function can be used to find all the references of the non-CEE point used
in the Control Builder.
2. Open the Control Builder and delete all peer-to-peer non-CEE point references from both Project and
Monitoring view for which the data type has been changed.
3. Close the Control Builder and the Recipe Builder on all nodes.
4. Use the following steps to clear the dangling non-CEE point parameter references when there are dangling
non-CEE point parameter references.
a. From the Configuration Studio, click Administer the control strategy database.
The dbadmin window opens.
b. Navigate to the Server node and select Non-ERDB Dangling Connections tree.
The dangling connections are displayed in the right pane.
c. Right-click Non-ERDB Dangling Connections and select Clear List.
The references to the dangling parameter are cleared.
5. Re-configure the parameter with the new data type.
Attention
• If the dangling point is a DSA point and the data type of the parameter changes on the publishing server, the
parameter type does not change in the subscribing server. This is applicable until the subscriber reads the changed
value next time.
For example, viewing the point parameter value on a display or a trend.
• Before configuring the peer-to-peer configuration with the DSA points, ensure that the DSA point is activated in
the publishing server. Otherwise, the subscribing Server handles the data type as INT16. If the DSA peer-to-peer
reference displays the wrong data type, perform the following steps to fetch the actual data type after activating the
DSA point.
1. Reload the DSA points from publisher and activate the DSA points.
2. Call the DSA parameters in the Trend display from the subscribing Server to fetch the new data type.
3. Open the Control Builder and delete all peer-to-peer non-CEE point references from both Project and
Monitoring view for which the data type has been changed.
4. Close the Control Builder and the Recipe Builder on all nodes.
5. Use the following steps to clear the dangling non-CEE point parameter references when there are dangling
non-CEE point parameter references.
6. From the Configuration Studio, click Administer the control strategy database.
The dbadmin window opens.
7. Navigate to the Server node and select Non-ERDB Dangling Connections tree.
The dangling connections are displayed in the right pane.
8. Right-click Non-ERDB Dangling Connections and select Clear List.
The references to the dangling parameter are cleared.
9. Restart the Control Builder.
10. Reconfigure or re-import the DSA parameter references.
5.1.9 Designing control strategy for failsafe control

To read non-CEE values in their C300 control strategies, you must consider handling of communication
disconnection scenarios. There are two main reasons which could cause a transfer of bad value to C300
Controller.
• Server failover
The failover from the primary Experion server to the backup Experion server may take between 30-70
seconds (depending on the size of the system). When Experion fails over to the backup server, values from
non-CEE points that are being read by the CEE through Experion Server Peer Responder are not available.
111
• Point becoming bad at its native interface

The non-CEE point being transferred through Experion Server Peer Responder may become bad because of
sensor failure or communication loss with controller where this point resides.
Normally, the control failsafe value must not be transferred directly to the process since this could cause
incorrect setpoints setting or inadequate logic results, generating process bumps or trips.
The control failsafe value can be handled using one of the following ways.
• Hold the previous good value until the non-CEE point parameter returns from control failsafe to good values
again.
• Hold the previous good value for a defined period (for example, 70 seconds) and then write a specific value
to the process to indicate that the input is bad.
The control strategy logic listed in the following table can be used to detect the control failsafe value for each
data type. Additional logic could be built to implement the appropriate behavior for the process. In addition, the
following table lists the values that the CEE can view for non-CEE points during disconnection event.
Data Type Example Point Control Failsafe Detecting Failsafe value

Parameter value
SCADA ANA01.PV NaN Two different Function blocks could be used , depending on
Floating control strategy needs as illustrated.
point
• Using CHECKBAD Function block
(FLOAT64)
• Using DATA ACQUISITION Function block
TPS Floating TPS_REG001.PV NaN

Point
(FLOAT32)
SCADA/TPS ANA01.MODE Enum 0

Enumeration
STA01.PV
(ENUM)
TPS_ALM.MODE
Data Type Example Point Control Failsafe Detecting Failsafe value

Parameter value
TPS Boolean TPS_FLG001.OFFNRMA Enum 0
(BOOLEAN) L
SCADA/TPS ANA01.INALM 0
Integer STA01.NumberOfInpu
(INT16) tStates
TPS_ALM.NOPINPTS
5.1.10 Runtime peer-to-peer behavior between CEE and non-CEE point

Deleting, renaming, publishing non-CEE point
The following scenario is applicable when a non-CEE point participating in peer-to-peer communication is
deleted, renamed, and published
When the non-CEE point is deleted, the function block that is running in one of the CEE controllers reading the
non-CEE point parameter receives “FAILSAFE” value. However, if the same non-CEE point is renamed and
published to Experion, the function block can successfully read the non-CEE point parameter value.
In the Monitoring view, the control strategy resolves new non-CEE point name only in expressions. However,
the parameter connections still displays the old non-CEE point name and the control strategy does not display
the delta flag indicating the non-CEE point name has changed in the Monitoring view.
In the Project view, the non-CEE point cannot be automatically renamed in the control strategy. In addition, a
reload of this control strategy fails with unresolved non-CEE point. Follow the considerations provided in
“Renaming non-CEE point/data type change consideration in configuration” on page 110 while deleting,
renaming, and publishing the non-CEE point.
Attention
If there is any exception in this behavior, refer to the specific sub-system documentation for the related information.
For example, if there is any behavior change when PMD point is deleted, renamed and published, refer to Experion
PKS with PMD Controller Configuration and Operations Guides.
Experion function block can successfully read the non-CEE point parameter value.
5.1.11 Runtime peer-to-peer behavior between CEE and Experion Server points
Deleting, recreating, reloading the Experion Server points during runtime
The following scenario is applicable when the Experion Server point participating in peer-to-peer
communication is deleted, recreated, and reloaded while reading the Experion Server point.
When an Experion Server point is deleted, the function block running in one of the CEE controllers and reading
the Experion point.parameter receives “FAILSAFE” value. However, if the deleted Experion Server point is
recreated with the same name and reloaded, the function blocks continues to receive the “FAILSAFE” value. To
avoid this issue, perform the following steps.
113
1. Delete the control modules referring to the Experion Server point.parameter completely from the
Monitoring view.
Note:You can use Configuration Studio Search Tool to find the Experion Server point.parameter references
in control modules (Search is performed on project configuration and assumption is that project and monitor
configuration is almost the same)
2. Wait for 20 seconds and reload the control modules from the Project to the Monitoring view.
Note:Even, if one of the control modules referring to the Experion Server point.parameter is not deleted from
the Monitoring view, the function blocks reading the Experion Server point.parameter continues to receive the
“FAILSAFE” value. This is applicable though the corresponding control module is deleted/reloaded in the
Monitoring view.
The following scenario is applicable when the Experion Server point is deleted, recreated, and reloaded while
writing the Experion Server point.
When an Experion Server point is deleted, the function block running in one of the CEE controllers and storing
the Experion point.parameter receives “FAILSAFE” value. This is because the destination Experion Server
point is deleted. The Experion Server point writing continues to FAIL until the Experion Server point with the
same name and data type is recreated.
Communication loss between the Experion Server and non-CEE points during runtime
Consider that the CEE controllers are reading the parameter from multiple SCADA points and other Experion
Server points such as SCADA, DSA, OPC, TPS points, and so on. In this case, say parameter reading from one
of the SCADA points fails because the particular SCADA point is not functioning, the parameter reading from
the other points may also result in failure. Similarly, consider that the CEE controllers are trying to write the
parameter to multiple SCADA points and other Experion Server points. In this case, the parameter writing to
one of the SCADA points or any other points may fail because the particular SCADA point or other point is not
functioning.
Experion Server switchover during runtime

Consider that an Experion Server switchover is initiated when the CEE controllers are reading the parameters
from multiple Experion Server points. In this case, the parameter value store initiated from the controllers may
fail during the switchover. However, the parameter value store succeeds only when the Experion Server
switchover completes.
Subscription period to an Experion Server point

The minimum subscription period for any Experion Server point is 1 second. Any subscription requests less
than 1 second is not guaranteed to be less than a second for initiating controllers.
Other runtime considerations

• If there is an IP address change for any of the Experion Servers, the strategies configured with Experion
Server parameter references must be reloaded from the Control Builder.
• If there is a change in CDA handle for the configured non-CEE parameter in SR, question mark is displayed
as “point.parameter?” only in Expressions.
• If the point exists and the non-CEE parameter is invalid, question mark is displayed as “point?parameter”
only in Expressions.
• If you are remapping the TPS unit's asset with Experion assets, the peer-to-peer communication between the
TPS points and the Experion does not automatically recover.
5.2 Initiator Rate - Calculation

Initiator Rate is the initiator Parameter count Per Second (pps). The initiator parameter count on a connection is
measured by adding the small and large cyclic parameter requests on the connection. The guideline is that the
sum total of initiator rates on all the 30 connections should not exceed 1000 pps.
The following parameter values are used to calculate the initiator rate.
• ICYCSMREQUSEDCONN[0-29] - Number of cyclic small requests per connection
• ICYCLGREQUSEDCONN[0-29] - Number of cyclic large requests per connection
• NUMCCLRQU parameter - Total number of cyclic parameter requests (initiator requests) for all
connections.
• SUBSCPERIOD - Peer update rate for peer-to-peer communications between two or more CEEs in
milliseconds
All the above parameters are present in the CEE block of the C300, C200/C200E and ACE controllers, and
SIM-C200E.
The following procedures describe how to calculate the initiator rate of a controller. This rate includes
Publisher, Subscriber and Dynamic Fetch parameter requests per second by the Initiator of the node. Two
methods are used depending on whether peer connections are configured using the Peer Environment Table.
5.2.1 Configuration without peer environment table

To calculate the initiator rate, divide the total initiator count by the global peer subscription period using the
formula:
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.
5.2.2 Configuration with peer environment table

If the Peer Environment Table is configured to have special subscription periods for different target nodes, then
the initiator count must be calculated separately for each connection. The initiator rate then can be calculated for
each connection. Initiator rate is calculated by dividing the count by the peer subscription period configured in
the Peer Environment Table. The initiator rate for all the connections is then summed to get the total initiator
rate of the node. Follow the steps below:
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).
2. Record the index number for that Target Name.
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.
3. Initiator Rate for the connection x1 =
4. The Peer Subscription Period is used in the Peer Environment table for SUBSCPERIOD of the target node.
5. 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.
115
6. 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.
7. Calculate the initiator rate for these target nodes using the formula below.
8. Initiator Rate for the connection y1 =
9. Note: The global Subscription Period value is used for SUBSCPERIOD (on the Peer Configuration tab).
10. Add the initiator rates obtained in the steps above for all the connections to obtain the total initiator rate.
Total Initiator Rate N = N[x1] + N[x2] + ? + N[y1] + N[y2] + ?
This CEE block shows the Peer Environment Table with one target node configured, ACE_TGT1, with a Peer
Subscription Period of 500mS.
ACE_TGT2 is configured to use the Global Subscription Period which is 1sec. (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 ACE_TGT1 (CEEACEFB_TGT1), 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 ACE_TGT1 =
To calculate the Initiator rate for ACE_TGT2, 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 ACE_TGT2 =
Therefore the Total Initiator Rate = N[1] + N[2] or 20 + 1 = 21 pps.
117
5.3 Implications for Control Builder Configuration
Attention
Note that the format used for the CPM and CEE tag names in this section is for example purposes only and does not
reflect the current default naming conventions used in Control Builder.
5.3.1 Multiple CPMs and ACEs

You can now configure multiple CPMs for C200/C200E Process Controllers networked to the same system
Server as well as up to two ACE supervisory controllers. This also means that there are multiple CEEs - one
associated with each CPM and one associated with each ACE supervisory controller.
As before, each CPM and CEE will have unique tag names based on the Media Access Control (MAC) address
for the controller and the numbered slot position of the CPM in the controller. This means you can now have
multiple CEEs for I/O Modules, Control Modules, and Sequential Control Modules assignment.
Like the CPM/CEE, the ACE and CEE function blocks will have unique tag names assigned as default by the
system or configured by the user. The ACE supervisory controller node is identified on the Ethernet network by
its host name and Internet Protocol (IP) address that must be configured by the user. If the ACE supervisory
controller includes a network interface card for direct connection to a ControlNet supervisory network, users
must also specify the MAC address assigned to the interface card.
5.3.2 CEE execution and subscription rates

The configurable Base Execution Period (BASEPERIOD) defines the macro cycle based on the 40 phases used
for CEE scheduling. See the previous “Schedule consideration differences” on page 55 section for more
information. The BASEPERIOD is user configurable as 5ms or 50ms for a CPM/CEE and fixed at 500ms for
ACE/CEE.
You can configure default Peer Subscription Period (SUBSCPERIOD) and Peer Store Response Expiration
Time (STRRESP) values to be used for all peer environments without a specific configured value.
You can configure specific Peer Subscription Period (PEERSUBSCPER[ ]) and Peer Store Response Expiration
Time (PEERSTRRESP[ ]) values for specific environments (PEERENV[ ]) identified through configuration.
5.3.3 Function block support

Since ACE supervisory controller operation is based upon the Control Processor Module (CPM) design, ACE
supports many of the same function blocks as the CPM. The ACE supervisory controller does not support any
of the existing function blocks associated with I/O communication interface. The CPM does not support the new
UCNIF block. The following table lists the Function Block Libraries in Control Builder and identifies which
control environment supports them.
If Function Block Is From This Library in Control Builder . . . Then, It Can Be Used With This Control Environment . . .
CPM/CEE
(Typical Fieldbus Device vendor library.)
ACE/CEE
CPM/CEE
(Restrictions apply - loaded strategies must contain
supported blocks only.)
ACE/CEE
CPM/CEE
If Function Block Is From This Library in Control Builder . . . Then, It Can Be Used With This Control Environment . . .
ACE/CEE
CPM/CEE
ACE/CEE
CPM/CEE
CPM/CEE
CPM/CEE
CPM/CEE
ACE/CEE
CPM/CEE
ACE/CEE
CPM/CEE
ACE/CEE
CPM/CEE
ACE/CEE
CPM/CEE
CPM/CEE
CPM/CEE
CPM/CEE
CPM/CEE
CPM/CEE
CPM/CEE
ACE/CEE
5.3.4 Peer-to-peer connections and DEF and REF blocks

You make peer-to-peer connections by specifying the full tag names for parameters in parameter connectors,
calculation expressions, and input and output condition expressions for TRANSITIONs and STEPs in SCMs.
This identifies the source of the parameter value from a compatible block parameter in another CM or SCM,
which is assigned to a different CEE.
In peer-to-peer applications, the function block that defines a parameter value that can be referenced by another
function block is referred to as the DEF (definition) block. The function block that reads a parameter value from
a DEF block is referred to as the REF (reference) block. The DEF versus REF block concept is useful in quickly
determining whether CEEs contain publishers (DEF blocks) or subscribers (REF block) of data. However, it is
possible for a function block to be both a DEF and a REF block. Refer to the Configuration example section
next for details.
Also, the storing of an output from a STEP block in an SCM to another function block is handled as a one-time
request/response operation. The STEP block is the REF block and the function block receiving the output store
is the DEF block. A one-time request is issued each time the STEP is executed.
5.3.5 Peer-to-peer configuration example

Views A and B in the following figure and the companion callout description table show a sample configuration
that uses a REMCAS block to form a cascade control loop with remote and local primary loops.
119
For this example, assume that this application includes two C200/C200E Process Controllers with CPM blocks
configured as CPM0101 and CPM0301, and their associated CEE blocks CEE0101 and CEE0301, respectively.
The remote primary loop is configured as a CM named REMCAS_PRIMARY and is assigned to CEE0101. The
local primary loop is configured as a CM named REMCAS_CM and is assigned to CEE0301.
In this example, the PID_PRIMARY and REMCAS_1 blocks have both DEF and REF relationships for peer-to-
peer communications.
Figure 9: View A - Remote Primary Control Loop
Figure 10: Example of DEF and REF block functions in CB configuration using REMCAS block.
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.
2 CB builds implicit/hidden connections for BACKCAL data. In this case, CB makes a peer-to-peer
connection to the X1BACKCALOUT parameter from the REMCAS_1 block contained in another CM
named REMCAS_CM, which is assigned to CEE0301.
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.
3 The output parameter OP is to be used as the input value for the X1 parameter for the REMCAS_1 block
contained in another CM named REMCAS_CM.
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.
4 The PID_BACKUP block represents the local or backup primary control loop for a cascade loop using the
REMCAS block. It is contained in the REMCAS_CM CM with the REMCAS_1 block. If there is a
problem with the remote primary loop, the REMCAS_1 block switches its input to the backup primary
loop.
5 The REMCAS block operates like any cascaded secondary loop except that it can switch between two
different primaries.
121
Callout Description
6 A parameter connector is used to form a peer-to-peer connection to the OP parameter from the
PID_PRIMARY block contained in another CM named REMCAS_PRIMARY, which is assigned to
CEE0101. In this case, the full tag name for the parameter is REMCAS_PRIMARY.PID_PRIMARY.OP.
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.
7 CB builds implicit/hidden connections for BACKCAL data. In this case, the BACKCAL parameter
X1BACKCALOUT is to be used as the input value for the BACKCALCIN parameter for the
PID_PRIMARY block contained in another CM named REMCAS_PRIMARY.
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.
5.3.6 Peer-to-peer configuration guidelines

Observe the following guidelines when configuring peer-to-peer functions in CB.
• Assign CMs with I/O Channel blocks and their associated IOM blocks to the same CEE.
• Assign CM containing ultimate secondary control block and CM containing its output channel and IOM
blocks to the same CEE.
• Assign CM containing data acquisition or regulatory control block and CM containing its input channel and
IOM blocks to the same CEE.
• Do not assign IOM blocks to multiple CEEs. Use peer-to-peer communications to share input channel values
among CMs in multiple CEEs.
• If you delete and unassign a loaded CM containing a DEF block from one CEE and reassign and load it to
another, you must reload all CMs containing REF blocks with peer-to-peer relationships to the DEF block in
the reassigned CM. Otherwise, the REF blocks will continue to receive published failsafe data from the
former CEE. You can use the loaded version of the REF block CM for the reloading operation.
• We recommend that you assign CMs containing DEF and REF blocks to their respective CEEs before you
make the named parameter connections to the REF blocks.
• You must load CMs containing REF and DEF blocks to CEEs associated with CPMs in C200/C200E
Process Controllers or ACE supervisory controllers networked to the same Experion server. This means
controllers must be in the same management domain.
• You must assign CMs with DEF blocks to their CEEs before you load CMs with REF block relationships.
Otherwise, the peer-to-peer connections are invalid.
• You can add CMs with REF block relationships to CEEs online at any time.
• Control Modules can contain any number of parameter references as well as any mix of intra-CEE and inter-
CEE (peer-to-peer) references.
• 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.
5.3.7 Example to illustrate peer-to-peer configuration for non-CEE points

The following example illustrates a sample configuration for peer-to-peer communication between the CEE and
non-CEE points. The communication between the CEE SM points is explained using the parameter connector.
Consider that you have already configured the Safety Manger points in the Safety Manager builder and
published the points to the Experion server. In addition, consider that you have configured the CEE points in the
Control Builder.
The following figure illustrates how you can configure the Safety Manager in the Control Builder.
In this example, FLD_P2P_C300.C3_BO_02.OP parameter is configured as an input pin for IN.FLOAT32

parameter of SM_AI_READ block. This configuration is performed in the Safety Manager Builder. Similarly,
FLD_P2P_C300.C3_BO_01.PV parameter is configured as an output pin for OUT.FLOAT32 parameter of the
PUSH block. This configuration is performed in the Control Builder. Note that when you configure the Safety
Manager point name, you must configure the parameter in the reference table as follows:
FLD Name.Basic Block Name. Parameter Name
Note: You must use the Basic Block Name as applicable.
Similarly, you can configure the Experion Server points such as SCADA points, in the CEE strategy.
123
6 Time Support in Experion System
Experion uses Coordinated Universal Time (UTC) which is raw time with no time zone and no daylight savings
time adjustments. UTC is stored internally in Experion and is converted to local time when shown to the user
using time zone and daylight savings time adjustments.
Whenever time is stored by Server for history and events, Server also stores bias (minutes offset from UTC
including daylight adjustment) so that local time can be reconstructed at any time in the future regardless of any
adjustments in daylight savings rules in future years, which can be expressed as
• Local Time = UTC + bias
125
6 TIME SUPPORT IN EXPERION SYSTEM
6.1 Date and Time Synchronization

Experion Time Source varies depending on Windows Domain. Servers that are part of Windows Domain use the
Primary Domain Controller (PDC) as the time source. Without Windows Domain, a primary Server is
designated as the time source and the backup/DSA Servers identify the time source machine and are
synchronized by the Windows Time service.
Time source time is set via Windows Date/Time applet and all Windows machines in a cluster (Servers,
Stations) are synchronized via Windows mechanisms.
Execution Environment (EE) devices (C200/C200E, ACE, FIM, IOLIM) are synchronized by Experion Control
Data Access (CDA) Server with the one exception of Custom Algorithm Block (CAB) on Application Control
Environment (ACE).
Every minute, CDA obtains current time from Server and point to point delivers it to primary Execution
Environment (EE) devices on the network (ControlNet or Fault Tolerant Ethernet). Devices update their system
time and use local free-running counters to compute the current system time between updates.
CAB on ACE functionality is not synchronized by CDA; it relies on the underlying .NET and Windows OS
services of the ACE platform.
Time sensed within CAB programs is based on Windows OS synchronization derived from the same Experion
Server that supplies time synchronization to CDA.
6.2 C300 and Series C Fieldbus Interface Module Time Synchronization

The C300 Controller and Series C Fieldbus Interface Module require high-quality time from a Network Time
Protocol (NTP) Server. The quality of time determines how tightly events from different devices can be
correlated, especially with regard to digital Sequence-of-Events (SOE). You must specify the address for the
NTP source through the System Preference dialog that is accessible through the Tools menu in Control Builder.
The procedure is described in the Supplementary Installation Tasks Guide.
Note that the C300 and Series C Fieldbus Interface Module will start with time sources noted below, but they
require an NTP time source for optimal operation.
Time Source Comments

CDA Time Time is provided by the first Windows Server/Station that makes a data connection. C300 control
resumes as configured by user for warm or cold initialization, based on time controller was
powered down. A notification and soft failure indication will flag degraded time source.
No time If C300 control is configured to resume, it will do so with cold initialization but it will not run until
it receives time from the specified source.
Details of NTP and its subset SNTP (Simple Network Time Protocol) are available by referencing RFC 1361 on
the Web.
6.2.1 BOOTP Mechanism and Multiple Clusters

The C300 and FIM4 receive their IP Addresses and the IP Addresses of the configured NTP Servers through the
Experion R300 BOOTP Service. BOOTP is a broadcast protocol; all BOOTP servers on a given subnet respond
to all requests. In a mixed release system on one subnet, even when using different FTE Multicast Addresses,
only the newest (R300) BOOTP can provide all of the necessary information for R300 and prior-release
devices.
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.
127
6.3 Time Configuration Considerations

Experion supports three time data types in CEE Blocks which encode values of time:
• TIME encodes absolute time
• TIMEOFDAY encodes time of day
• DELTATIME encodes time differences
6.3.1 Time Data Types in Control Execution Environment (CEE) Blocks

CURTIME is of type TIME and always shows the current “wall time” for the system where the platform blocks
reside. The CURTIME parameter is defined on platform entity blocks such as ACE, CPM, and FIM.
Parameters of time data types most frequently appear in custom block types. The two categories of custom
block types supported in Experion are Custom Algorithm Blocks (CAB) and Custom Data Blocks (CDB).
6.3.2 Time Data Types in User Algorithms and Displays

Time data types are often used in conjunction with some form of user written algorithm. In the case of the
Custom Algorithm Block (CAB), the user defines a block type which encapsulates both a data definition and an
algorithm definition. If the data definition incorporates a Custom Defined Parameter (CDP) of time data type
then the CDP is read or written by the CAB program as needed.
In the case of a CDB type incorporating time CDPs, the CDB itself never reads or writes the CDPs since the
CDB is a data repository and contains no algorithm. However, a CDB's time CDP may be read or written by
user defined expressions contained in the algorithm of other blocks. User defined expressions associated with
instances of SCM, AUXCALC, or REGCALC blocks may access time CDPs as appropriate.
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 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 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, be that algorithm 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“.
6.3.3 C200/C200E, Application Control Environment (ACE) Time Parameters
Parameter Description
Current Time Format is MM/DD/YY HH:MM:SS
(CURTIME)
Server local time communicated to the controller by Control Data Access (CDA) from Server.
Not affected by TIMEZONE and DAYLIGHTTIME
CURTIME is stored as UTC within the CEE and converted to local time when displayed at
HMI.
TIMEZONE Conversion value for controller's “local time”; must be configured once for each individual
platform
default = 0.0
Range of Values:
-12.0 to 13.0
Consult a World Map of Time zones for the appropriate value for your time zone.
Allows support for unusual case of controller physically residing in different time zone than the
Server, and interpretation of YEAR, MONTH, etc. parameters based on controller's time zone
DAYLIGHTTIME Conversion value for controller's “local time”; must be configured once for each individual
platform
default = OFF
Possible Values:
ON = Daylight savings time is active
OFF = Daylight savings time is inactive
Allows support for unusual case of controller physically residing in different time zone than the
Server, and interpretation of YEAR, MONTH, etc. parameters based on controller's time zone
YEAR “local time” for use in control strategies, including expressions IF TIMEZONE and
DAYLIGHTTIME are set to their default values, YEAR, MONTH, DAY, HOUR, MINUTE,
SECOND, WEEKDAY integer values will always be in raw UTC.
MONTH Same as above
DAY Same as above
HOUR Same as above
MINUTE Same as above
SECOND Same as above
WEEKDAY Same as above
Examples of TIMEZONE and DAYLIGHTTIME configuration:
In Windows Date/time applet, Server Time Zone Settings ‘local HOUR’ for use
is set to GMT -05:00 Eastern Time
(US & Canada)
Current time (CURTIME) = 11/02/2003 TIMEZONE = 0 HOUR will be 13
08:54:00
DAYLIGHTTIME = OFF
129
In Windows Date/time applet, Server Time Zone Settings ‘local HOUR’ for use
is set to GMT -05:00 Eastern Time
(US & Canada)
Current time (CURTIME) = 06/12/2003 TIMEZONE = -5 HOUR will be 17
13:54:00
DAYLIGHTTIME = ON
6.3.4 Custom Algorithm Block (CAB) on ACE Time Functions

Custom Algorithm Blocks (CAB) access .NET functions on the local Application Control Environment (ACE)
machine and use .NET Time functions supported on the Date Time structure as follows:
UtcNow current UTC time
For CAB VB.NET programs, DateTime.Now is derived from Experion synchronized time.
Time zone and daylight selection are configured through the Windows date / time applet on the
primary server which has been designated as the system time source. This configuration need
only be done on one server within the system
Now current local time
Date Time Now is based on Windows OS time services and is independent of parameters
TIMEZONE and DAYLIGHTTIME.
ToUniversalTime converts local to UTC time
ToLocalTime converts UTC to local time
It is appropriate for some applications to make use of the UTC time references, DateTime.UtcNow in the case
of CAB VB.NET and UTCNOW in the case of CEE expressions. For other applications, it is appropriate to use
the local time references, DateTime.Now in VB.NET and NOW in CEE expressions.
Application Control Environment (ACE) machine time synchronization

The ACE node time is synchronized two ways:
1. By Control Data Access (CDA) for non-CAB CEE functions, like controllers.
2. By Windows mechanism for Windows time used by the Custom Algorithm Block (CAB).
Application Control Environment (ACE) Implications

1. Within CAB or within non-CAB Control Execution Environments, time precision is consistent down to the
execution period of the blocks.
2. Between CAB and non-CAB CEE, the potential skew is the same or slightly worse than the Windows
mechanism. For example, Windows Simple Network Time Protocol (SNTP) should not be expected to
provide better than +/- 2 seconds synchronization between machines.
6.4 Examples of Time Usage in CAB and SCM
Related topics
“Example - Custom Algorithm Block (CAB) writes Time CDP” on page 131
“Example - Custom Algorithm Block (CAB) reads Time CDP” on page 131
“6.4.3 Example - Sequence Control Module (SCM) waits for a specified Time” on page 132
“Example - Sequence Control Module (SCM) records Time of process command” on page 132
6.4.1 Example - Custom Algorithm Block (CAB) writes Time CDP

The CAB VB.NET program uses variable Current Time to capture the current time in the local time zone, uses
variable NextCalcHour to hold the next hour when shift calculations are due, and publishes the last time of
calculation in a Custom Defined Parameter (CDP) called LASTRUNTIME. CurrentTime is used as a local time
variable internally. LASTRUNTIME must be published as UTC.
To create a CAB to do shift calculations at the end of every 8 hour shift

• Create a CDP called LASTRUNTIME.Code the CAB's VB.NET program as
Dim NextCalcHour As Integer
Dim CurrentTime As DateTime
Dim CurrentHour As Integer
CurrentTime = Now
CurrentHour = CurrentTime.TimeOfDay.Hours
If CurrentHour = NextCalcHour Then
NextCalcHour = (CurrentHour + 8) Mod 24
LASTRUNTIME.Value = CurrentTime.ToUniversalTime
DoShiftCalculations()
End If
6.4.2 Example - Custom Algorithm Block (CAB) reads Time CDP

The CAB VB.NET program uses a Custom Defined Parameter (CDP) called CAPTURETIME specified by the
operator in local time.
To create a CAB to capture data at an operator specified time

• Code the CAB's VB.NET program with:
If DateTime.UtcNow = CAPTURETIME.Value
DoCapture();
End If
(The statement If DateTime.Now = CAPTURETIME.Value would not work because by the time CAB
receives the value of CAPTURETIME it is in UTC, not local time.)
131
6.4.3 6.4.3 Example - Sequence Control Module (SCM) waits for a specified Time
To create an SCM transition that designed to wait until a time specified by an operator or supervisor
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 will use CDB2 within CM2 as a data repository.
3 CM2.CDB2 has a parameter called STARTTIME of type TIME. The operator will specify STARTTIME.
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.
(The transition condition expression NOW = CM2.CDB2.STARTTIME would not work even though the
operator enters values for STARTTIME according to the local time zone.)
6.4.4 Example - Sequence Control Module (SCM) records Time of process command
To record the time at which an important process command was issued

1 Create a Custom Data Block (CDB) called CDB1 in a Control Module called CM1.
2 Create a parameter of type TIME in CM1.CDB1 called CMDISSUETIME.
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.
(The output expression CM1.CDB1.CMDISSUETIME := NOW is incorrect because the display would not
use the value of CMDISSUETIME according to the local time zone.)
7 Cold and Warm Restart Functionality
Related topics
“Overview” on page 134
“Planning” on page 136
“Configuration of Restart Behaviors” on page 140
“Warm and Cold Restart Behaviors of Cascades” on page 147
“Operations” on page 153
133
7 COLD AND WARM RESTART FUNCTIONALITY
7.1 Overview
Related topics
“CEE Initial Startup” on page 134
“CEE Restarts” on page 134
“CEE Restart Behaviors” on page 134
7.1.1 CEE Initial Startup

The initial startup occurs when a CEE is started by initial load of its parent controller / device block. In this
situation, the CEE starts out empty of algorithm blocks and is basically inert. Cold and Warm Restart
functionality is irrelevant to the start of a CEE empty of algorithm blocks.
7.1.2 CEE Restarts

The two types of restarts are:
• Cold Restart initiated on transition of CEESTATE from idle to run occurs
– After the CEE FB has just been 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 as to which data is preserved and which is 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 a 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 would normally go
to run with a cold start command but nothing prevents him from commanding warm start. In regulatory
cascades MODE values loaded as configuration data will be retained across warm restart even if the cascade
terminates on a direct analog output.
7.1.3 CEE Restart Behaviors

All CEE blocks perform some kind of initialization in response to a restart condition. Most blocks do the same
kind of initialization regardless of whether the restart is warm or cold. For blocks that vary behavior based on
restart the categories of functionality involved are:
• Mode shed of regulatory cascades
Depending on the restart type and on the nature of the cascade configuration, cascades will either shed to
manual or hold last mode. The behavior that occurs depends on whether the type of cascade is CEE-to-
Legacy or CEE-to-CEE, upon the type of block that is in the role of secondary, upon the type of node
undergoing restart, and other factors.
• Resumption of sequences
Depending on the particular sequence application it may be appropriate for an SCM to remain inert awaiting
operator command before it resumes execution. On the other, in some special applications, it may be
appropriate that an SCM restart automatically. SCM supports a range of restart behaviors subject to
configuration options.
• Resumption of totalizers
Within CEE totalizers always remain stopped after cold restart but can automatically resume totalizing after
warm restart. The warm restart behavior is configurable and is coupled with the selection of bad input
behavior.
• Restart signals
In some cases it may be necessary for an application engineer to cause his control strategy to go through a
special initialization in response to restart. To enable this, parameters are supported which allow SCM
expressions or CM component blocks to detect that a restart has just occurred and what kind of restart it was.
135
7.2 Planning
Related topics
“Invariant or Variant Restart Behaviors” on page 136
“Blocks with Invariant Restart Behavior” on page 136
“Blocks with Variant Restart Behavior” on page 138
7.2.1 Invariant or Variant Restart Behaviors

CEE blocks can be broadly divided into two categories with respect to how the 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
(PITOTALIZER and TOTALIZER are the only exceptions). 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, etc.) 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 or IOLIM 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.
7.2.2 Blocks with Invariant Restart Behavior

While behavior varies according to block type most CEE blocks execute the same kind of restart and
initialization regardless of whether the start up is warm or cold. These behaviors conform to a few general
principles.
• Data storage parameters and data storage blocks: hold on all restarts
There is a category of parameters whose sole purpose is to serve as data storage. For these parameters there
is no built-in algorithm implemented by the block underneath, neither in the sense that the parameter value is
read and processed by the algorithm, nor in the sense that the value is written by the algorithm. Rather, the
parameter serves to hold data which can be read or written by applications created by the end user. In some
cases, there are blocks (simple blocks) whose sole purpose is to establish this kind of parameter. In other
cases, parameters like this are one kind of parameter 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. This means that 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 will be 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 will 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 under all restart scenarios.
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 will be restored as TRUE. If connected to an
RTRIG's IN, the RTRIG would generate 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
A non-logic block which accumulates state or history in response to inputs initializes at first execution in
such a manner that current output is consistent with current inputs as if those inputs had been applied
infinitely in the 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.
Table 1: Special Case Blocks with Invariant Restarts
# Library Block Type Summary Description

1 DEVCTL DEVCTL Initialization behavior is the same regardless of restart type.
Supports different initialization behaviors based on input mapping,
output mapping and other configuration.
2 REGCTL RAMPSOAK Different from other RegCtl blocks in that behavior is the same for all
restarts.
Behavior is: set MODE to manual; set CV to NaN; reset internal timers;
set current profile identifier to first; set current segment identifier to
first; set RESETTIMER to On; apply STARTOP[ ] value at next Man to
Auto transition.
Behavior is always safe because it forces the ramping action to stop and
await intervention by the operator.
137

3 UTILITY TIMER Continues timing in response to any restart. Output parameters which
indicate state are held.
The PV parameter, which gives time accumulated since start, continues
to increment from its previously retained value.
4 <Custom Custom Algorithm CEE and CAB infrastructure leave values of all custom parameters
Libraries Block Types (CAB unchanged across all restarts.
Created By End Types)
User-implemented CAB algorithms may detect restarts and either
Users>
modify or leave unchanged the values of custom parameters.
7.2.3 Blocks with Variant Restart Behavior

Within CEE there are several block types whose behavior is impacted by restart handling. The following is a list
of these block types with a summary description of their behavior, categorized by Control Builder library.

1 SYSTEM CEE FB Reports notifications which record fact of warm or cold
restart in event journal when idle to run transition occurs.
1 SYSTEM CONTROLMODULE Forwards selected restart commands (warm restart or cold
restart) to component basic blocks.
Supports option parameter which allows selection of whether
the CONTROLMODULE should follow CEE, always restart
cold or always restart warm upon idle to run transition.
1 SYSTEM SCM Supports option parameter which allows selection of whether
the SCM should follow CEE, always restart cold or always
restart warm upon idle to run transition.
Supports a set of additional parameters which allow
application engineers to control how an SCM resumes
execution upon restart.
Supports signal parameter which tells type of restart
executed.
2 SCM STEP Holds instruction state information which is held or reset
based on selection of cold or warm restart and on SCM
configuration.
3 PULSEINPUT PITOTALIZER On cold restart, stops totalizing.
On warm restart, either stops totalizing or continues
totalizing based on configured equation.
4 AUXILIARY TOTALIZER Same as above.
4 AUXILIARY SIGNALSEL On a Warm restart, Cold restart or when this FB is
inactivated the following parameters are initialized
P(1) through P(6) values are set to NaN.
PSTS(1) through PSTS(6) are set to BadValSts.
5 REGCTL AUTOMAN Either holds last mode or sheds to manual based upon
whether warm or cold restart is selected and upon the nature
of the cascade relationship.
5 REGCTL ENHREGCALC Same as above.
5 REGCTL FANOUT Same as above.
5 REGCTL OVRDSEL Same as above.
5 REGCTL PID Same as above.

5 REGCTL PIDEXTRFB Same as above.
5 REGCTL PIDFF Same as above.
5 REGCTL PID-PL Either holds last mode or sheds to manual based upon
5 REGCTL POSPROP Either holds last mode or sheds to manual based upon
5 REGCTL PULSECOUNT Same as above.
5 REGCTL PULSELENGTH Same as above.
5 REGCTL RATIOBIAS Either holds last mode or sheds to manual based upon
5 REGCTL RATIOCTL Same as above.
5 REGCTL REMCAS Same as above.
5 REGCTL REGCALC Same as above.
5 REGCTL REGSUMMER Same as above
5 REGCTL SWITCH Same as above.
6 HIWAYIF HIWAYOUT Supports cascade relationship to enable prescribed restart
behavior for RegCtl primary in ACE.
7 UCNIF UCNOUT Same as above.
8 LOGIC STARTSIGNAL Provides parameters which can optionally be used within
CONTROLMODULE configurations to trigger
initializations in response to restart events.
9 UCNIF EUCNOUT Either holds last mode or sheds to manual based upon
139
7.3 Configuration of Restart Behaviors

Restart behaviors vary depending on the type of block and the cascade control design. To view the specific
configurations relating to restart behavior,
Topic For more information

CEE Block “CEE Block” on page 140
Control Module (CM) “Control Module (CM)” on page 140
Control Module Function Blocks “Control Module Function Blocks” on page 141
Sequential Control Module (SCM) “Sequential Control Module (SCM)” on page 142
Regulatory Cascades “Regulatory Cascades” on page 147
UCNIF:UCNOUT “Cascades through UCNIF: UCNOUT/
EUCNOUT” on page 152
Logic Block “Logic Blocks” on page 141
Related topics
“CEE Block” on page 140
“Control Module (CM)” on page 140
“Control Module Function Blocks” on page 141
“Logic Blocks” on page 141
“Sequential Control Module (SCM)” on page 142
“Summary Of SCM Restart Behavior” on page 144
“Supporting SCM Functionalities” on page 145
“SCM Blocks” on page 146
7.3.1 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 CEE FB reports the idle to run state change event occurred with a warm restart.
• On Cold restart, the CEE FB reports the idle to run state change event occurred with a cold restart.
7.3.2 Control Module (CM)

Control modules do not have functionality modified by selection of warm or cold restart but the behavior of
blocks contained within the control module can be impacted. Control Modules therefore have a configuration
parameter CEESTARTOPT which optionally allows the application designer to override the warm or cold
selection made by an operator at runtime.
CM Parameter Configuration Options

CEESTARTOPT • ALWAYSCOLD (default)
(Access Lock = ENGR) For this configuration parent control modules instruct their component blocks to do a
cold restart regardless of which restart option has been selected for the CEE as a whole.
• ALWAYSWARM
For this configuration parent control modules instruct their component blocks to do a
warm restart regardless of which restart option has been selected for the CEE as a
whole.
• FOLLOWCEE
For this configuration parent control modules instruct their component blocks to
initialize according to whichever type of restart the operator has selected for the CEE as
a whole: cold or warm.
7.3.3 Control Module Function Blocks
Pulse Input Totalizer

On CEE startup the behavior of the PITOTALIZER block varies depending upon whether warm or cold restart
has been commanded and upon how parameter PVEQN is configured. The value selected for PVEQN actually
controls PITOTALIZER behavior on restart handling and on bad input handling. This is shown in the following
table.
PVEQN Bad Input Handling Warm Restart Handling Cold Restart Handling
EQA Stop accumulation while input is Continue after input turns valid. Set PV to bad and stop accumulation.
bad.
(default)
EQB Use last good value if input is bad. Continue after input turns valid. Set PV to bad and stop accumulation.
EQC Stop if the input is bad and set PV Continue after input turns valid. Set PV to bad and stop accumulation.
to NaN.
EQD Stop accumulation while input is Set PV to bad and stop Set PV to bad and stop accumulation.
bad. accumulation.
EQE Use last good value if input is bad. Set PV to bad and stop Set PV to bad and stop accumulation.
accumulation.
EQF Stop if the input is bad and set PV Set PV to bad and stop Set PV to bad and stop accumulation.
to NaN. accumulation.
Auxiliary Totalizer
All restart behavior of the AUXILIARY TOTALIZER block is equivalent to that of the PULSEINPUT
PITOTALIZER block.
7.3.4 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 “puls” 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.
141
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.
RESTART An enumeration valued summary parameter. Following a transition, it shows a value different
from NONE until the end of first block execution. For each of the values of RESTART, a
corresponding flag is set. The flag holds true until the restart state changes. The possible
values for RESTART and the corresponding flags are:
• NONE - normally shown.
• CMLOAD - Holds CMLOADFL true for the first execution cycle following a load of the
parent control module.
• CMACTIVE - Holds CMACTIVEFL true for the first execution cycle following
inactivation and then activation of the parent control module.
• CEECOLD -Holds CEECOLDFL true for the first execution cycle following cold start of
the CEE.
• CEEWARM -Holds CEEWARMFL true for the first execution cycle following warm start
of the CEE.
• CEESWITCH - Holds CEESWITCHFL true for the first execution cycle following
redundant switchover of the CEE on a C200/C200E.
• ANYRESTART - Holds ANYRESTARTFL true for the first execution cycle if any of the
preceding flag parameters are true.
It is possible for more than one transition to occur between the time that a control module
stops executing and the time that it restarts. For this reason, there is a priority built into the
values of parameter RESTART. This priority insures that the strongest initialization signal is
the one which will be seen. The priority for RESTART values is CMLOAD > CMACTIVE >
CEECOLD > CEEWARM > CEESWITCH > NONE.
There is no implied priority or mutual exclusivity among the flag parameters. Consider a
scenario in which the CEE starts out in idle, the control module is loaded, the control module
is activated, then the CEE is warm started. On first execution of the control module
parameters CMLOADFL, CMACTIVEFL, CEEWARMFL and ANYRESTARTFL will be
True. Parameters CEECOLDFL and CEESWITCHFL will be False. Parameter RESTART
will have the value CMLOAD.
Parameter RESTART may be displayed on the symbol faceplate of block RESTART for monitoring purposes
but it will only show 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 will be
more convenient to use one of the associated Boolean-valued flag parameters.
7.3.5 Sequential Control Module (SCM)

The SCM behavior upon CEE restart can vary according to several types of user selections. The main user
options are as follows:.
• Configuration-time selection to either start at top or use a retained location indicator when CEE restarts.
– SCM supports parameters which allow the engineer to encode a variety of behaviors with respect to the
SCM's internal location counter. The SCM can be set up to always restart within the Main handler with
location counter set to top. It can be set up to resume execution from the last step or transition within the
Main handler. It can be set up to explicitly assign a restart location somewhere within the Main handler.
• Run-time selection of warm or cold restart and resultant impact on SCM MODE
– Under cold restart SCM comes up with MODE equal to Manual regardless of previous value. This
causes the SCM to remain inert until an operator takes action. In contrast, when warm restart occurs
MODE retains its last value. This allows the SCM to resume execution automatically if triggered by an
Invoke handler.
• Configuration time selection of whether or not to follow the restart selection made for CEE as a whole
CEESTARTOPT for SCM

The SCM supports a CEESTARTOPT parameter which is fully analogous to that of CM as described in the
following table.
SCM Parameter Configuration Options

CEESTARTOPT (Access • ALWAYSCOLD
Lock = ENGR)
For this configuration, SCMs execute cold start behavior regardless of the restart
commanded for CEE as a whole. 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 regardless of the restart
commanded for CEE as a whole. This means that the previous MODE is retained. Other
parameters such as MODEATTR and STATE are also left unchanged.
• FOLLOWCEE
For this configuration, SCMs follow the restart commanded for CEE as a whole.
CEETOPSTART for SCM

The parameters CEETOPSTART, CEERESADDR[ ] and UPDCEERESROPT determine the location at which
an SCM begins execution following a CEE restart. The first two are SCM parameters while the latter is a
parameter supported by each SCM STEP.
The CEETOPSTART is a Boolean parameter with an access lock of Engineer and the values as noted in the
following table.
SCM Parameter Configuration Options

CEETOPTSTART(Access • ON
Lock = ENGR)
When CEE restarts, the SCM starts executing at the top of the Check handler unless the
operator commands execution 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[ ].
CEERESADDR[ ] for SCM

The CEERESADDR[ ] parameter is an array of BlockIds with an access lock of Engineer. It acts as a location
indicator so that, if CEETOPSTART is OFF, the value it has at the time of the restart determines where the Main
handler of the SCM will start executing. Each element of the array corresponds to one of the ten possible SCM
threads. Elements of CEERESADDR[ ] start out with the value Null. In some configurations, this value never
changes. If an SCM restarts with CEERESADDR[ ] = Null, then it restarts at 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
143
by SCM expressions. Whatever the value of CEERESADDR[ ] is at restart, the SCM will resume execution at
that step within the Main handler unless the operator commands execution to start at a different handler.
STEP.UPDCEERESOPT for SCM

The STEP.UPDCEERESOPT is a Boolean parameter with an access lock of Engineer. The functionality of
STEP.UPDCEERESOPT approximately parallels that of STEP.UPDRESOPT, which is used in connection with
Exception handlers. The values of STEP.UPDCEERESOPT have the following meanings.
Step Parameter Configuration Options

STEP.UPDCEERESOPT • ON
(Access Lock = ENGR) If the step is within the Main handler, then upon execution the step assigns its
own name to that element of CEERESADDR[ ] which corresponds to its
thread of execution. This will cause 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.
Note that unlike STEP.UPDRESOPT, there is no requirement that
STEP.UPDCEERESOPT be ON for the first step of the Main handler. If a
CEE restart occurs with CEETOPSTART OFF and CEERESADD[ ] = Null,
then execution resumes at the top of the Check handler.
• OFF
The value of CEERESADDR[ ] is not automatically changed by the SCM. It
holds at previous value unless it is explicitly changed by an SCM expression.
CEERESADDRN[ ]
The CEERESADDR[ ] parameter may be explicitly changed by SCM expressions, but not through direct
assignment to parameter CEERESADDR[ ]. This is because CEERESADDR[ ] has type BlockId which is not
supported in SCM expressions. A parallel parameter named CEERESADDRN[ ] of integer type is supported.
The CEERESADDRN[ ] parameter is a mirror image of parameter CEERESADDR[ ]. Thus, CEERESADDR[]
and CEERESADDRN[] work in tandem. Anytime one of these parameters changes, the change is reflected in
the other parameter automatically.
To change the values of CEERESADDR[ ] and CEERESADDRN[ ] by writing from a step output, the syntax
would be as shown in the following example.
• SCM1.CEERESADDRN[1] := SCM1.Step2.NUM
7.3.6 Summary Of SCM Restart Behavior

The table below summarizes SCM restart behavior for different cases of CEETOPSTART configuration and
run-time selection of restart type. The table assumes that CEESTARTOPT = FOLLOWCEE.
If SCM CEETOPSTART And, CEE Restart Type Is …

Is … Cold Warm
Then, Conditions after restart are as follows:
ON • MODE is set to Manual. • MODE is at previous value.
• SCM location counter is set to top of • SCM location counter is set to top of
Check handler. Check handler.
SCM resumes execution after the SCM resumes execution after the
following actions: following actions:
• Operator sets MODE to Auto. • If last MODE was Auto SCM
• Operator sets SCM COMMAND to resumes without MODE change.
Reset in order to start Check handler • Operator sets SCM COMMAND to
Reset in order to start Check handler
or
or
the check handler starts automatically
if it has been configured with a non- the Check handler starts
null invoke transition. automatically if it has been
configured with a non-null invoke
transition.
OFF • MODE is set Manual. • MODE is left at previous value.
• SCM location counter is set to the • SCM location counter is set to the
step in Main handler indicated by step in Main handler indicated by
CEERESADDR[]. CEERESADDR[].
SCM resumes execution after the SCM resumes execution after the
following actions: following actions:
• Operator sets MODE to Auto. SCM • If last MODE was Auto, SCM
then continues execution, re-sending continues execution automatically,
all outputs of the active step re-sending all outputs of the active
step.
or
operator sets COMMAND to a
different handler. If EXCMODEOPT
is Auto this forces MODE to Auto
and starts execution of the SCM.
7.3.7 Supporting SCM Functionalities
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.
If EXCMODEOPT Value Is … Then, Corresponding Cold Restart Behavior Is …

None When the SCM is in Manual MODE, invoke Transitions for higher priority exception
handlers are not evaluated. MODE will not be automatically changed to Auto when the
SCM is commanded to execute another handler.
Auto When the SCM is in Manual MODE, invoke Transitions for higher priority Exception
handlers are evaluated. MODE will be automatically changed to Auto when the SCM is
commanded to execute another handler or when an invoke Transition causes execution of
another handler. For SCMs with EXCMODEOPT of Auto, SCMs that are cold started and
set to Manual MODE can subsequently be caused to execute without explicitly changing
MODE to Auto.
145
Restart And Level 1 Devices

The configuration chosen for parameters CEESTARTOPT and CEETOPSTART, together with the selection
made for cold or warm restart at run time, can have an impact on any level 1 devices under control of the SCM.
Depending upon the abnormal state options and upon parameter MODETRACK, level 1 devices may change
outputs or MODEATTR in response to SCM STATE or MODE changes.
Restart Signal Parameter

SCM supports a parameter named RESTART, which is directly analogous to the RESTART parameter
supported on the previously described Logic block STARTSIGNAL. While
“CM.STARTSIGNAL.RESTART“ allows CM configurations to be customized so that they respond to start-up
transitions in different ways, “SCM.RESTART“ allows SCM expressions to be written so that they can handle
start-up transitions in different ways.
The SCM RESTART has pulse semantics. The manner in which RESTART is reset to NONE after initial
execution is as follows.
• If a Check handler is the first handler executed after SCM restart, then parameter RESTART is set to NONE
after the Check handler finishes. Under this scenario, the value of parameter RESTART would be read
within the Check handler.
• If a handler other than the Check handler is the first to execute after SCM restart, then parameter RESTART
is set to NONE after the first execution cycle of the SCM. Under this scenario, the value of parameter
RESTART would have be read in Interrupt, Hold, Stop or Abort handlers as appropriate to the planned
configuration and usage.
The following table lists the possible values of the parameter RESTART.
If RESTART Value Is … Then, …

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 gone through a cold restart since the last execution
of the SCM/RCM.
CEEWARM The CEE containing the SCM/RCM has gone through a warm restart since the last
execution of the SCM/RCM.
CEESWITCH The controller hosting the CEE which contains the SCM/RCM has gone 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
7.3.8 SCM Blocks

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)” on page 142 section.
7.4 Warm and Cold Restart Behaviors of Cascades
Related topics
“Definitions” on page 147
“Regulatory Cascades” on page 147
“CEE to CEE Cascades” on page 148
“CEE to Legacy Cascade when Node hosting Primary is restarted” on page 150
“CEE to EHPM FTE Cascade” on page 151
“CEE to Legacy Cascade when Node hosting Secondary is restarted” on page 151
“RegCtl Cascades when Node hosting the Primary is restarted” on page 151
“Cascades through UCNIF: UCNOUT/EUCNOUT” on page 152
7.4.1 Definitions
CEE-to-CEE Cascade - a cascade relationship in which the primary is located within the CEE-ACE or CEE-
C200/C200E and the secondary is located within a CEE-ACE or, CEE-C200/C200E or within an IOP presented
by an IOLIM. The primary is always a CEE regulatory control block. The secondary may be a regulatory
control block or a direct analog output block (or slot). CEE-to-CEE Cascades can be local (primary and
secondary located within the same EE) or peer-peer (primary and secondary located in different EEs).
CEE-to-Legacy Cascade - a cascade relationship in which the primary is located within the CEE-ACE and the
secondary is located within a legacy controller presented by an interface gateway or bridge. The primary is
always a CEE regulatory control block assisted by a special purpose interface block. The secondary may be a
regulatory control block or direct analog output located in an XPM accessed through a TPN Server and one or
more additional gateways. It may be a regulatory control block or direct analog output located in a TDC2000
Hiway box accessed through a TPN Server and one or more additional gateways.
CEE-to-EHPM FTE Cascade - a cascade relationship in which the primary is located within the CEE-ACE or
CEE-C300 and the secondary is located within a legacy controller presented by an EHPM FTE. The primary is
always a CEE regulatory control block assisted by a special purpose EUCNOUT interface block. The secondary
may be a regulatory control block or direct analog output located in an EHPM accessed through FTE.
Restart Behaviors of For more information

Regulatory Cascades “Regulatory Cascades” on page 147
CEE to CEE Cascades “CEE to CEE Cascades” on page 148
CEE to Legacy Cascade when Node hosting Primary is “CEE to CEE Cascades” on page 148
restarted
CEE to Legacy Cascade when Node hosting Secondary is “CEE to Legacy Cascade when Node hosting Secondary
restarted is restarted” on page 151
RegCtl Cascades when Node hosting the Primary is restarted “RegCtl Cascades when Node hosting the Primary is
restarted” on page 151
Cascades through UCNIF:UCNOUT/EUCNOUT “Cascades through UCNIF: UCNOUT/EUCNOUT” on
page 152
7.4.2 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.
1. Resume automatic control without human intervention if automatic control was operative before shut down.
147
2. 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
When the node undergoing the restart is an ACE or C200/C200E and it is hosting the cascade primary then the
CEE generally responds as follows according to restart type.
• Warm Restart
All cascades resume processing under the mode that applied before shut down.
• Cold Restart
Cascades in which the secondary is another regulatory block resume processing under the mode that applied
before shut down. Cascades in which the secondary is a direct analog output shed to manual and do not
resume automatic control until the operator changes mode.
While the above description conveys a guiding principle, actual behavior can be different depending on the type
of node which hosts the cascade secondary. Behavior is as described above when the secondary is hosted by an
ACE, C200/C200E or IOLIM. If the secondary is presented by a different type of node (for example a TPN
Server) the behavior can be different.
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.
7.4.3 CEE to CEE Cascades

When the cascade primary block is hosted by an ACE or C200/C200E and the cascade secondary block is
presented by an ACE, C200/C200E or IOLIM, cascades are of the CEE-to-CEE type.
When the node hosting the primary goes through a restart, the behaviors are the same regardless of whether
primary and secondary are in the same node or in peer nodes. In the following two behaviors, assume that the
database at the primary is reloaded through checkpoint restore and that the mode of the primary RegCtl is
restored along with checkpoint.
• When configured with Recall Primary Mode
The primary mode is retained across restart transition and the primary RegCtl goes through complete
initialization and resumes control as consistent with its mode.
• When configured with Shed Primary Mode
The primary mode is overwritten to manual upon restart transition and the primary RegCtl awaits mode
change from operator before initializing and resuming automatic control.
When the node presenting the secondary rather than the node hosting the primary goes through a restart and the
primary and secondary are in separate nodes, the CEE-to-CEE cascades have two additional behaviors. These
behaviors are the same regardless of whether the fault detected at the primary results from shutdown of the node
hosting the secondary or from interruption of communication. When a CEE Controller is SHUTDOWN,
Control Data Access (CDA) communication is lost between nodes or peers. Putting a CEE Controller in IDLE,
does not cause communication loss. If primary CEE is IDLE, you can initiate a ColdStart without
SHUTDOWN.
• When configured with Hold Primary Mode across Secondary Fault
The mode of the secondary RegCtl block is either recalled or shed to manual based on the type of start up
and on role of the secondary as primary to a subsequent secondary. The primary RegCtl block holds its mode
across fault and recovery of secondary. The primary initializes and resumes control action as appropriate to
mode of secondary after its host node restarts which refers to the behavior induced in the upstream controller
by the remote secondary as the primary restarts.
Following are the example scenarios:
• When the secondary is in Manual or Auto mode, at the conclusion of primary recovery, the primary will be
held in initialization.
• When the secondary is in Cascade, the primary receives the initialization value from the secondary, but the
initialization handshake is allowed to conclude and both the controllers operate in unison forward control.
• Upon recovery, the primary receives a Fail-Safe value on PV from peer I/O which has not concluded
initialization and primary will shed to Manual.
• When the primary recovers and the communication is not restored to downstream secondary, eventually the
primary will detect communication failure and will shed based on the loss of communication.
• When configured with Shed Primary Mode on Secondary Fault
The secondary AO block has no mode. Primary RegCtl sheds mode to manual on first detection of
communication failure with secondary. Primary RegCtl awaits mode change by operator before initializing
and resuming automatic control.
The following table enumerates the types of events which cause each of the 4 behaviors listed above.
Cascade Primary RegCtl Cascade Secondary type and Event Functional Behavior of
location location Cascade
RegCtl block in ACE1 RegCtl block in ACE Shutdown and cold restart at Recall Primary Mode
primary.
RegCtl block in C200/ Shutdown and cold restart at Recall Primary Mode
C200E primary.
AO block in C200/C200E Shutdown and cold restart at Shed Primary Mode.
primary.
AO point under C200/ Shutdown and cold restart at Shed Primary Mode.
C200E IOLIM primary.
RegCtl block in C200/C200E RegCtl block in ACE Shutdown and cold restart at Recall Primary Mode
primary.
RegCtl block in C200/ Shutdown and cold restart at Recall Primary Mode
C200E primary.
AO block in C200/C200E Shutdown and cold restart at Shed Primary Mode.
primary.
AO point under C200/ Shutdown and cold restart at Shed Primary Mode.
C200E IOLIM primary.
RegCtl block in ACE1 RegCtl block in ACE Shutdown and warm restart Recall Primary Mode
at primary
RegCtl block in C200/ Shutdown and warm restart Recall Primary Mode
C200E at primary
AO block in C200/C200E Shutdown and warm restart Recall Primary Mode
at primary
AO point under C200/ Shutdown and warm restart Recall Primary Mode
C200E IOLIM at primary
RegCtl block in C200/C200E RegCtl block in ACE Shutdown and warm restart Recall Primary Mode
at primary
RegCtl block in C200/ Shutdown and warm restart Recall Primary Mode
C200E at primary
AO block in C200/C200E Shutdown and warm restart Recall Primary Mode
at primary
149
Cascade Primary RegCtl Cascade Secondary type and Event Functional Behavior of
location location Cascade
AO point under C200/ Shutdown and warm restart Recall Primary Mode
C200E IOLIM at primary
RegCtl block in ACE1 RegCtl block in ACE Shutdown and any recovery Hold Primary Mode Across
at secondary Secondary Fault
RegCtl block in C200/ Shutdown and any recovery Hold Primary Mode Across
C200E at secondary Secondary Fault
AO block in C200/C200E Shutdown and any recovery Shed Primary Mode On
AO point under C200/ Shutdown and any recovery Shed Primary Mode On
C200E IOLIM at secondary Secondary Fault
RegCtl block in C200/C200E RegCtl block in ACE Shutdown and any recovery Hold Primary Mode Across
RegCtl block in C200/ Shutdown and any recovery Hold Primary Mode Across
C200E at secondary Secondary Fault
AO block in C200/C200E Shutdown and any recovery Shed Primary Mode On
AO point under C200/ Shutdown and any recovery Shed Primary Mode On
C200E IOLIM at secondary Secondary Fault
Notes:
1. When you shutdown the ACE, you do not have an ACE block that you can issue COLDSTART, IDLE or
WARMSTART command to unless you load the ACE. ACE does not support RAM retention startup or redundancy.
Only in this case, ACE comes up as IDLE.
7.4.4 CEE to Legacy Cascade when Node hosting Primary is restarted

When the cascade primary is hosted by an ACE and the cascade secondary is presented by a TPN Server,
cascades work according to a CEE-to-Legacy relationship.
The database at primary is reloaded through checkpoint restore and the Mode of the primary RegCtl block is
restored along with checkpoint. CEE-to-Legacy cascades have 2 behaviors when the node hosting the primary
goes through a restart.
• When configured for Honor Secondary Cascade Request
The primary mode is retained across restart transition. At start of execution the primary RegCtl honors any
outstanding cascade requests at downstream secondaries. The primary RegCtl block goes through complete
initialization and resumes control as consistent with its mode.
• When configured for Clear Secondary Cascade Request
At start of execution the primary RegCtl turns off any outstanding cascade requests at downstream
secondaries and leaves the primary Mode unchanged. The primary RegCtl awaits command from operator
before initializing and resuming automatic control.
The following table enumerates the types of events which cause each behavior listed above.
Cascade Primary Cascade Secondary Event Functional Behavior of

Cascade
Regulatory control block in SPC cascade to regulatory Shutdown and warm restart Honor Secondary Cascade
ACE control slot under TPN at primary. Request
Server
DDC cascade to regulatory Shutdown and warm restart Honor Secondary Cascade
control slot under TPN at primary. Request
Server

Cascade
DDC cascade to AO slot Shutdown and warm restart Honor Secondary Cascade
under TPN Server at primary. Request
7.4.5 CEE to EHPM FTE Cascade

The cold restart of the ACE/C300 interfacing through EUCNOUT preserves the mode for all cascades, and
downstream secondary cascade requests in the EHPM are reset. The warm restart of the ACE/C300 interfacing
through EUCNOUT preserves the mode for all cascades, and downstream secondary cascade requests in the
EHPM are honored.
7.4.6 CEE to Legacy Cascade when Node hosting Secondary is restarted

For the case where the primary of a regulatory cascade is hosted by an ACE, the secondary is presented by a
node other than ACE, C200/C200E or IOLIM and the secondary's node is the one that goes through restart,
there are a variety of possible behaviors for cascades. Events described focus on restart of gateway nodes which
present the secondary to the primary.
In this instance, control automatically resumes with the TPN Server restarting, the Cascade requests fulfilled
and automatic control resuming as consistent with primary mode.
The following table enumerates the types of events which cause behavior listed above.

Cascade
Regulatory control block in SPC cascade to regulatory Shutdown and restart at TPN Automatically Resume
ACE control slot under TPN Server Control
Server
DDC cascade to regulatory Shutdown and restart at TPN Automatically Resume
control slot under TPN Server Control
Server
SPC cascade to AO slot Shutdown and restart at TPN Automatically Resume
under TPN Server Server Control
7.4.7 RegCtl Cascades when Node hosting the Primary is restarted

Regulatory Control blocks AUTOMAN, FANOUT, OVRDSEL, PID, PIDEXTRFB, PIDFF, PID-PL,
POSPROP, PULSECOUNT, PULSELENGTH, RATIOCTL, REGCALC, REGSUMMER, REMCAS,
SUMMER, and SWITCH behave as follows:
Type of Cascade Type of Restart Behavior

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.
Warm Mode is preserved regardless of the type of downstream secondary.
CEE-to-Legacy Cold Mode is preserved for all cascades. Outstanding cascade requests at
downstream secondaries are reset.
Warm Mode is preserved for all cascades. Outstanding cascade requests at
downstream secondaries are honored.
151
7.4.8 Cascades through UCNIF: UCNOUT/EUCNOUT

UCNOUT serves as an interface agent between ACE RegCtl blocks acting as primary and RegCtl blocks hosted
by an XPM acting as secondary. Access to the XPM on UCN is via the TPN Server.
Starting with Experion R430, the EUCNOUT block can be used for interfacing the ACE/C300 primary RegCtl
blocks and the EHPM secondary RegCtl blocks through the FTE network. The EUCNOUT is used directly
connecting the ACE/C300 Controller to the EHPM Controller through the CEE on the FTE network.
Though not a RegCtl block in itself, UCNOUT/EUCNOUT is designed to support appropriate restart behavior
for the cascades.
Behavior implemented within UCNOUT/EUCNOUT supports the restart functionality described by the
following table.
Table 2: UCNOUT block: Restart functionality

Cascade
Regulatory control block in Cascade to regulatory control Shutdown and cold restart at Clear Secondary Cascade
ACE or AO slot under TPN Server primary Request
Regulatory control block in Cascade to regulatory control Shutdown and warm restart Honor Secondary Cascade
ACE or AO slot under TPN Server at primary Request
Regulatory control block in Cascade to regulatory control Shutdown and restart at TPN Automatically Resume
ACE or AO slot under TPN Server Server Control
Table 3: EUCNOUT block: Restart functionality

Cascade
Regulatory control block in Cascade to regulatory control Shutdown and cold restart at Clear Secondary Cascade
ACE/C300 or AO slot in the EHPM primary Request1
Regulatory control block in Cascade to regulatory control Shutdown and warm restart Honor Secondary Cascade
ACE/C300 or AO slot in the EHPM at primary Request2,3
Regulatory control block in Cascade to regulatory control Shutdown and cold/warm Automatically Resume
ACE/C300 or AO slot in the EHPM restart at the EHPM. Control4,5
Notes:
1. Performing a cold primary restart clears the EHPM secondary point cascade request flags in the EHPM (for example,
MAN-C goes to MAN mode), and resumes control with the secondary EHPM points in cascade (CAS) mode.
2. When the control module containing EUCNOUT block contains a CEERESTARTOPT parameter value of
ALWAYSCOLD, the WARMSTART primary controller selection is overridden, and the controller goes through a
COLDSTART.
3. Performing a warm primary restart resumes control with the EHPM secondary points having cascade request flags set
in the EHPM (for example, MAN-C goes to CAS mode), and resumes control with the secondary EHPM points in
CAS mode.
4. Changing the EHPM Controller state to idle followed by cold or warm restart results in the controller automatically
resuming control, however, if the AO module slot is set to idle, the AO full points revert to MAN mode and must be
restored by the operator to CAS when needed.
If the EHPM Controller state is changed to idle from UCN Status display instead of HPM detail status display, the AO
module will also turn to idle state and hence the AO full points revert to MAN mode and must be restored by the
operator to CAS when needed.
5. EHPM Controller RAM retention restarts/shutdown/program load/cold or warm restart automatically resumes control.
7.5 Operations
Across Experion 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.
Subsystem Supports Supports Warm Start Idle Supports Cold Start Idle to Supports Generic Idle to Run
Activation to Run Transition Run Transition Transition
CM Yes No No No
IOM Yes No No No
CEE No Yes Yes No
IOLIM EE No No No Yes
FIM EE No No No Yes
Because of the different types of startup transitions supported across different Experion 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
7.5.1 CEE Function Block

CEE Function Block represents an Execution Environment (EE). To change the CEECOMMAND:
1. Open the CEE function block form either directly from Control Builder project or monitor.
2. Choose the command from the CEE Command pull down menu. Pull down menu choices are: None, Idle,
WarmStart, and ColdStart.
3. To accomplish an Idle to Run transition, choose WarmStart or ColdStart. Commanding None has no effect.
7.5.2 ACE Function Block

ACE Function Block represents a controller platform and is unique in that it presents CEECOMMAND and
CEESTATE for view and manipulation. Commands for CEECOMMAND in the ACE Function Block is parallel
to the CEE Function Block.
7.5.3 CPM Function Block

Commands for CEECOMMAND in the CPM200 Function Block is parallel to the CEE Function Block.
153
8 External OPC Server Support
Related topics
“OPC Data Access” on page 156
“OPC Data References” on page 157
“OPC Data Type Conversions” on page 160
“ACE interface to TPS system as OPC server” on page 164
155
8 EXTERNAL OPC SERVER SUPPORT
8.1 OPC Data Access
Related topics
“OPC Server function block” on page 156
“OPC client/server data flow” on page 156
8.1.1 OPC Server function block

The Control Builder application includes a function block that represents an external OPC server.
This is an independent, tagged block that is used to identify an external subsystem to exchange data with the
system through the Application Control Environment (ACE) supervisory controller.
Users specify the communications path to the OPC server through the blocks configuration form. This data is
stored in the System Repository when the block is loaded.
8.1.2 OPC client/server data flow

The following figure illustrates how the ACE supervisory controller initiates communications directly with
external OPC servers and indirectly with external OPC clients through the OPC server of the system Server. The
CPM in the C200/C200E Process Controller does not support an OPC client, but OPC clients can access its data
through the OPC server of the system Server.
8.2 OPC Data References
Related topics
“OPC Data Name Syntax” on page 157
“Parameter connectors only” on page 157
“OPC references in expressions” on page 158
“OPC references in SCM Alias table” on page 158
“Validation of OPC references” on page 159
8.2.1 OPC Data Name Syntax

Use the following naming syntax to identify the data of interest in the OPC server.
<OPC server function block name>.<OPC server data specific name>
For example, you configure an OPC server block in Control Builder with the name OPC1 and you want to
access data named InterlockA.Active in the configured OPC server. The correct reference to this data would be
formatted as follows:
OPC1.InterlockA.Active
Note: If the OPC server data specific name contains illegal characters of Experion namespace, you must use the
following syntax.
<OPC server function block name>.‘<OPC server data specific item name>’
8.2.2 Parameter connectors only

Since an OPC server block cannot be contained in a Control Module (CM), you must use parameter connectors
to route OPC server data elements to applicable block connections in the control strategy. The following figure
shows two parameter connectors being used to connect data elements named InterlockA.Active and
InterlockB.Active from the configured OPC server named OPC1 to inputs 1 and 2 of an AND function block in
a Control Module named CM865 for reference. This strategy is only valid if loaded to an ACE/ CEE
environment.
157
8.2.3 OPC references in expressions

You configure OPC data references in SCM Step Output, SCM Transition, AUXCALC block, or REGCALC
block the same as other system parameters using the valid naming syntax for the OPC data elements. The
following figure displays a SCM Step Output expression used to read the “Count.PV“ data from an OPC server
named OPC2, add 1.0 to the read value, and store the new value to the Count.PV data in OPC2.
With R400, the OPC parameter, which is referenced through the OPC gateway, appears as a hyperlinked
parameter. This enables you to navigate to the configuration form of the corresponding tagged block.
Attention
Expressions support the single quote character, ‘, as a special delimiter that can be used to surround the OPC Server
namespace portion of an external/OPC reference.
For example, OPCTag.‘tag.Param(1)’ can be used so that the parenthesis characters do not confuse the expression
parser.
8.2.4 OPC references in SCM Alias table

Use the following guidelines to configure OPC data references in the Aliases table for a SCM block.
• Choose the OPC server block as the Model Block for the given Alias.
• Choose either the External Reference (EXTREF) or the External Reference Structure (EXTREFSTRUCT)
parameters of the OPC server block for the given Alias.
– For an Alias with the EXTRETSTRUCT parameter, the instance references can be references to either
the OPC server data or EXTREF_STRUCT type system Server data.
The following figure shows a sample reference to OPC server data in a SCM Aliases table. The first alias is for
an OPC server block with an EXTREF parameter for an Instance 1 data reference from an OPC server named
OPC46. The second alias is for a Numeric block with a PV parameter for an Instance 1 data reference from a
Numeric block named n1 in a Control Module named cm42.
8.2.5 Validation of OPC references

With R410, a new feature is introduced in the Control Builder/Recipe Builder to validate blocks with OPC
references after loading the OPC gateway. This feature can also be used for validating OPC references, if the
OPC gateway is configured through the Redirection Manager (RDM). For the validation to be successful, the
OPC gateway must be loaded. For more information about validation of block references, refer to the Control
Building User's Guide.
159
8.3 OPC Data Type Conversions

Since the data type of the OPC server data reference is not known at configuration time, it is possible that the
actual data type accessed at run time will not match the data type expected by the control strategy in the ACE
supervisory controller. Review the following sections for a summary of the guidelines covering data type
conversions for OPC data Gets and Stores.
Related topics
“Gets conversions” on page 160
“General data conversion considerations” on page 161
“Stores conversions” on page 162
8.3.1 Gets conversions

The ACE supervisory controller receives the actual OPC data type for “gets” at run time and translates the value
into a system data type based on the following translation table.
If OPC VARTYPE Is . . . Then, System Data Type Is . . .

VT_BOOL BOOL
VT_UI1 UINT8
VT_UI2 UINT16
VT_UI4 UINT32
VT_UI8 UINT64
VT_I1 INT8
VT_I2 INT16
VT_I4 INT32
VT_I8 INT64
VT_R4 FLOAT32
VT_R8 FLOAT64
VT_BSTR STRING
VT_FILETIME TIME
VT_ARRAY EXTREF_STRUCT
VT_BLOB
Other VT_ data types Bad Value Status
The general translation scenario is as follows.

• The CDA-sp performs the interface specific translation of external reference type to system type.
• The system value status is set according to the quality bit field of the OPC item state quality.
• The sub status and limits bit fields of the OPC item are ignored.
• The OPC array and blob variant types are forced into a system External reference structure type to
distinguish them from internal system structures. A specific purpose function block, such as the UCNOUT
block, is required to use an External reference structure type.
• The OPC variant types that are not supported result in a data type mismatch error.
• The CDA-sp delivers a system value to the appropriate function block.
• When the data types do not match, the function block receiving the data makes an attempt to convert
between the actual and expected data types.
8.3.2 General data conversion considerations

The following table shows the data type conversions that the system does or does not support. A Yes means that
the conversion is supported or not required, when the data types match, and a No means that the data type
conversion is not supported.
Table 4: Keep the following considerations in mind when dealing with data conversions.
From BOOL UINT8 UINT INT8 INT ENUM SD_ENUM FLOAT STRING TIME
UINT16 INT16
To 64 64 32 FLOAT
UINT32 INT32
64
BOOL Yes Yes Yes Yes Yes Yes Yes No No
UINT8 Yes Yes Yes Yes Yes Yes Yes No No
INT8 Yes Yes Yes Yes Yes Yes Yes No No
FLOAT Yes Yes Yes Yes Yes Yes Yes No No
32
FLOAT Yes Yes Yes Yes Yes Yes Yes No No
64
STRING No No No No No No No Yes No
TIME No No No No Yes No No No Yes
EXTREF_ No No No No No No No No No
STRUCT
• Be aware that downcasting occurs when conversions involve a type that supports a wider range of values to
a type with a more narrow range of values.
– For example, an INIT16 value of 333 is converted to UNIT8 value of 255.
– For example, an INT32 value of 100,000 is converted to the maximum Enumeration value of 65,535.
The function block that receives the Enumeration ordinal of 65,535 will likely reject this value, since it is
out of range for the applicable Enumeration parameter. This is consistent with the current behavior where
an out of range store to an Enumeration parameter does not cause the destination parameter to assume
the failsafe value.
– For example, an OPC server data type of Integer is connected to a PID block's MODE parameter. If the
Integer value is 7 at run time, the MODE parameter rejects the value because it is outside the MODE
enumeration range of 0 to 5.
• Float to integer conversions use truncation instead of rounding. For example, a Float of 3.75 is converted to
the Integer 3.
• The underlying type for system Boolean values is unsigned character. Since the underlying type for Boolean
external references cannot be assumed, all external Boolean references are converted in the context of the
system, which uses 0 for False and 1 for True. For example:
– Boolean True converts to Integer 1 or Float 1.0
– Boolean False converts to Integer 0 or Float 0.0
161
– Integer 7 converts to Boolean True

– Integer 0 converts to Boolean False
– Integer -336 converts to Boolean True
– Float 33.33 converts to Boolean True
– Float -0.567 converts to Boolean True
– Float 0.0 converts to Boolean False
– Float 0.0001 converts to Boolean True (Similar to expressions, no threshold value is used in the test for
zero. The TypeConvert block does provide a threshold for Float compares to zero, so use this block when
this conversion is a concern.)
– Enumeration ordinal 0 converts to Boolean False
– Enumeration ordinal 8 converts to Boolean True
– Float 5.82 converts to Enumeration ordinal 5
– Float -11.0 converts to Enumeration ordinal 0
• Conversions between Strings and Integers and between Strings and Floats are not supported
The following table summarizes the failsafe data value that is substituted when a given data type conversion is
not supported.
If Data Type Is . . . Then, Failsafe Value Is . . .

BOOL Off
UINT8 0
UINT16
UINT32
UINT64
INT8 0
INT16
INT32
INT64
ENUM Ordinal value of 0
SD_ENUM
FLOAT32 NaN
FLOAT64
STRING Blank
TIME 0
EXTREF_STRUCT Bad Status
For example, if the OPC1.InterlockA.Active parameter used as the input to an AND block in the previous figure
in section “Parameter connectors only” on page 157 returns a Boolean, Integer, or Float data type at run time,
the appropriate conversion is made and the data get is completed successfully. If the OPC1.InterlockA.Active
parameter returns a String data type, the Boolean failsafe value of Off is applied to the AND block input.
8.3.3 Stores conversions

The CDA-sp receives the store value from the initiating function block and converts it as needed before storing
the value to the OPC server. The CDA-sp executes a onetime read of the value from the OPC server to learn its
actual data type before initiating the Store.
The ACE supervisory controller supports the UCNOUT block, PUSH block, and SCM Step Output expressions
for initiating stores to the OPC server.
163
8.4 ACE interface to TPS system as OPC server

The ACE supervisory controller interfaces to the TPS system through an Application (APP) node running Total
Plant Network (TPN) server as another OPC server - See the figure below. The TPN server supports both OPC
data access and Honeywell Communications Infrastructure (HCI) extensions to OPC. The ACE supervisory
controller recognizes when it is communicating with an OPC server that includes HCI, such as the APP node,
and provides the following additional functions.
Added ACE Function With HCI Server What the Added Functions Provides
Experion server to TPS system access Access levels for stores from Control Strategies loaded in ACE supervisory
level propagation controller to a TPN server in APP node are sent along with the data. The
Sequential Control Modules (SCMs) in Control Strategies use Program access
level, while other function blocks like the UCNOUT block use a Continuous
Control access level. Since the access level definitions for an Experion system and
a TPS system are consistent, no translation is necessary.
Redirection Server When the Redirection Server is installed on the ACE node, the CDA-sp interfaces
to it just like a remote HCI server. As long as the OPC server block configured in
Control Builder identifies the HCI Redirection Server, the HCI Redirection
capabilities are used.
Tip
The additional HCI related functions are transparent to the Control Modules and Sequential Control Modules in
control strategies that are executing in the ACE supervisory controller. No changes are required in control strategy
configurations through Control Builder whether the OPC server being accessed supports HCI or not.
9 System Namespace Workaround
Related topics
“Inter-Cluster Communication” on page 166
“Using the Inter Cluster Gateway for Communication between Experion Clusters” on page 167
“Remote EEOUT (REEOUT) Function Block” on page 170
165
9 SYSTEM NAMESPACE WORKAROUND
9.1 Inter-Cluster Communication

The issue of communication between Experion clusters is handled in R300 by the introduction of the following
components and configuration changes:
• The Inter Cluster Gateway (ICG) block
• The Remote EEOUT (REEOUT) function block
• The addition of SP “push” to the configuration of a subset of the existing function blocks
The relationship of these components is shown below:
9.2 Using the Inter Cluster Gateway for Communication between

Experion Clusters
The Inter Cluster Gateway (ICG) serves as a communication bridge between the Application Control
Environment (ACE) (or Simulation-Application Control Environment (SIM-ACE)) supervisory controllers in
two separate Experion clusters.
The ICG supports dual roles, server and client. Every ICG block acts as an OPC server (I-C Server) that can be
connected to by an OPC Gateway block. An ICG can also be used as a client to connect to other I-C Servers.
9.2.1 Inter Cluster Gateway configuration guidelines

• An ICG is required for each Experion cluster which contains blocks that are secondary to another Experion
cluster.
• The primary Experion cluster requires an OPC Gateway configured to talk to the I-C Server
(“Hci.OPCGateway”). The primary Experion cluster can contain an ICG if there is a need for bi-directional
control cascade or data transfer.
• There can only be one ICG per ACE.
• The ACE node hosting the ICG may also host OPC Gateways. Up to four gateways of either type can be
hosted by the ACE
9.2.2 When to use Inter Cluster Gateway

The Inter Cluster Gateway shares common infrastructure with the OPC Gateway. The following section
describes when each block should be used.
The client-server characteristics of the ICG and the OPCG are summarized in the following table:
Characteristic OPC Gateway Inter Cluster Gateway

Connect to any OPC server Yes No, only to another ICG
Simple Data Yes Yes
Whole arrays Yes Yes
Control cascade Yes Yes
The ACE interconnections possible using the OPCG, ICG, and the REEOUT, UCNOUT, EHGOUT, and
HIWAYOUT function blocks are summarized in the following table:
ACE-UCN ACE-ACE ACE-EHG

(different Experion cluster) (different Experion cluster)
Connect to TPN Server Inter Cluster Gateway Inter Cluster Gateway
Yes Whole arrays Yes Yes
Control cascade UCNOUT REEOUT EHGOUT
When communicating between Experion clusters, it is required that the Inter Cluster Gateway block is
configured and loaded in the secondary Experion cluster. The primary Experion cluster only requires that an
OPC Gateway block is used. The primary Experion cluster could also use an ICG block if there is a need for bi-
directional control cascade or data transfer.
In the primary Experion cluster, the OPC Gateway block needs to be activated in order to enable
communication. The secondary Experion cluster's ICG block makes data available as soon as it is loaded. It
only needs to be activated if it is also being used as a client.
167
Without the use of Inter Cluster Gateway, the OPC Gateway block can be connected to the Experion OPC server
in another Experion cluster to access data. The following table shows when an ICG might be needed.
Experion OPC Server Inter Cluster Gateway

Connect to HwHsc.OPCServer Hci.OPCGateway
Simple data Yes Yes
Whole arrays No Yes
Control cascade No Yes
Access Level (Continuous Control) No Yes
9.2.3 Reviewing Inter Cluster Gateway characteristics

The IC Gateway operates as a bridge/translator between the Control Data Access (CDA) communications
protocol between two Experion PKS systems.
The IC Gateway depends on the CDA-supervisory platform (CDA-sp) for its communications link to the rest of
the Experion PKS system, but it uses OPC to communicate between Experion clusters, as shown in the
following figure.
Both Experion clusters can contain an ICG if there is a need for bi-directional control cascade or data transfer,
as shown in the following figure.
9.2.4 Inter Cluster Gateway connectivity

The IC Gateway provides a single point of connectivity to an Experion cluster, as shown in following figure.
169
9.3 Remote EEOUT (REEOUT) Function Block
9.3.1 Functional description-REEOUT

The REEOUT function block is used in conjunction with the Inter Cluster Gateway to support regulatory
cascades between ACE nodes residing in two separate Experion clusters. It is described elsewhere in this
document ( “REEOUT (Remote EEOUT) Block”).
10 Controller Redundancy Functionality
Related topics
“Basic Redundancy Design Concepts” on page 172
“Implications for Control Builder Functions” on page 176
171
10 CONTROLLER REDUNDANCY FUNCTIONALITY
10.1 Basic Redundancy Design Concepts

If you have redundancy compliant Controller hardware, you can implement redundant Controller operation
through a Redundant Chassis Pair (RCP). A RCP consists of two Controller chassis which include identical
redundancy compliant modules in matching slot positions within their given chassis. The following figure
shows a typical hardware configuration for a RCP.
Table 5: Typical RCP setup in 10-slot chassis.
The goal of Controller redundancy is to improve the availability of the Controller to perform its assigned control
functions. The RCP does this by providing a pair of Controller chassis so a component failure in one chassis
switches the handling of the assigned control functions to the other chassis. This is considered a dual redundant
system, which is characterized by the following two main redundancy states.
• Primary - Refers to the chassis executing the assigned control functions.
• Secondary - Refers to the chassis in some state of readiness to assume the responsibilities of the Primary.
10.1.1 Switchover and Secondary readiness

A switchover describes the process where a Secondary chassis assumes the Primary state, and the Primary
chassis assumes the appropriate Secondary state of readiness, depending upon what triggered the switchover. A
switchover can be triggered immediately upon the detection of a fault in the Primary or upon the receipt of an
operator command.
The ability of a Secondary chassis to take over the assigned control functions of the Primary depends upon
which one of the following readiness states reflects its current state.
If Secondary Chassis State is . . . Then, the Secondary Chassis . . .

Disqualified Cannot assume the Primary state. This is a state of non-readiness.
Synchronized Can assume the Primary state upon switchover. In this state, the
database in the Secondary is aligned with the database in the Primary.
The Secondary closely tracks database changes to maintain its
synchronization with the database of the Primary. Otherwise, the
Secondary will revert to a Disqualified state.
Standby The Standby state is not available at this time.
10.1.2 Failure conditions and switchover
Conditions that result in switchover

The following table identifies failure conditions that result in a switchover. As noted in the table above, the
Secondary control chassis must be in its synchronized state for a switchover to occur.
Attention
When any failure that results in a switchover occurs in a Secondary, the Secondary chassis/FIM loses synchronization.
In addition to the failure conditions, these events are reported as diagnostic notifications:
• Loss of view of redundant partner on H1 network (applies to FIM link).
• Loss of private path connection from Primary to Secondary (lonely event).
Failure Conditions That Result in a Switchover

Loss of input power to Primary chassis power supply
Primary chassis power supply fails or is turned Off.
Integrated Control Protocol (ICP) backplane in Primary chassis fails
Any module in Primary chassis fails.
Both ControlNet drop cables to Primary ControlNet module are lost.
Both FTE links to Primary FTE Bridge module are lost.
Either Channel A or Channel B RJ-45 cable to Primary IOLIM is lost.
Inserting any module into a powered Primary chassis.
Removing any module from a powered Primary chassis.
Primary FIM's connection to Redundant Remote Terminal Panel is lost.
Conditions that do not result in a switchover

The following tables identify failure conditions that do not result in a switchover. The first table identifies
conditions that are categorized as non-switchover triggers or that trigger no action in the Secondary. The
second table identifies conditions that are categorized as disqualification triggers or that trigger disqualified
state in the Secondary.
Failure Conditions That Do Not Result in a Switchover - Non-Switchover Triggers

Either ControlNet drop cable A or B to Primary ControlNet module is lost.
Both FTE links to Secondary FTE Bridge module are lost.
One FTE link to Primary FTE Bridge module is lost.
173
Failure Conditions That Do Not Result in a Switchover - Non-Switchover Triggers

Either or both Channel A and/or Channel B RJ-45 cable(s) to Secondary IOLIM is(are) lost.
One or both H1 cables fail.
One or both H1 network conditioners fail.
The 24-Volt power supply for Fieldbus devices fails.
Failure Conditions That Do Not Result in a Switchover - Disqualification Triggers

Loss of input power to Secondary chassis power supply
Secondary chassis power supply fails or is turned Off.
Integrated Control Protocol (ICP) backplane in Secondary chassis fails
Any module in Secondary chassis fails.
Remove any module from a powered Secondary chassis.
Insert any module into a powered Secondary chassis.
Both ControlNet drop cables to Secondary ControlNet module are lost.
Secondary FIM's connection to Redundant Remote Terminal Panel is lost.
Redundancy cable between Primary and Secondary Redundancy Modules is lost.
Data communication failures with Secondary chassis during qualification.
Data communication failures with Secondary chassis during steady-state operation.
10.1.3 Role of the Redundancy Module

The Redundancy Module (RM) serves as a high-performance, chassis-to-chassis, communications bridge for
redundancy compliant modules in a RCP. It only provides the path for modules to synchronize themselves and
coordinates the synchronization process. The RM does not determine what portions of a module's database get
synchronized.
The communication path begins at a given module in a chassis, continues over the chassis backplane to the RM,
from the RM in this chassis over the RM-to-RM private path to the partner RM in the partner chassis, and then
over the partner chassis backplane to the partner module. The following figure is a simple graphic
representation of the RM communication path.
Table 6: Typical redundancy communications path.
The RM functionality features the following major tasks.

• Gathers module status from all resident chassis modules.
• Gathers module status from its partner RM.
• Receives and logs event reports from resident chassis modules as well as from its partner RM.
• Resolves states based on gathered and reported data.
• Resolves contention situations with its partner RM.
• Coordinates state transition activity for the chassis.
• Provides redundancy-related read (status) and write (control) access to local controllers and remote network
devices.
175
10.2 Implications for Control Builder Functions
Related topics
“Redundant C200/C200E CPM configuration” on page 176
“RM configuration” on page 176
“RM monitoring” on page 177
“RM/RCP dialog box” on page 177
“Main tab” on page 178
“Summary tab” on page 178
“RM Profiles tab” on page 180
“Configuration tab” on page 182
“Synchronization tab” on page 183
“Chassis Profiles tab” on page 186
“Display tab” on page 187
“Server History tab” on page 188
“Server Displays tab” on page 190
“Auto-Synchronization events” on page 191
10.2.1 Redundant C200/C200E CPM configuration

You can now configure C200/C200E CPMs for redundant Controllers. This creates a partner CPM based on the
uplink Media Access Control (MAC) address for the Controller and the numbered slot positions of the CPMs in
the RCP. The corresponding redundant CPM icons appear in the Control Builder Project tree view.
10.2.2 RM configuration
You can configure the RM block and its partner RM through the Main tab in the RM/RCP dialog box in the
Control Builder Project tree view only. The corresponding redundant RM icons appear in the Project view.
Refer to Creating Redundancy Modules in the Control Building Guide for block configuration details.
While the Configuration tab in the RM/RCP dialog box in Control Builder Project view shows the default
values as Never for Auto-Synchronization and DISABLED for Program Command Recognition, these values
are not written to the RM when the RM block is loaded from the Project view.
For a fully functional pair of RMs, some configuration changes applicable to both RMs can be made through the
dialog box for either RM in the Monitoring view. In either case, the Primary RM eventually receives and
executes the request, and directs the Secondary to make the same change. If the partner RM is not present, the
local RM makes the changes regardless of the redundancy state.
You can also configure Description and Keyword text strings for use with Station displays through the RM
profiles tab in the RM/RCP dialog box in the Project view only. You must call up the RM/RCP dialog box for
the Primary RM to enter the text strings in the applicable Primary fields on the RM profiles tab. You must call
up the RM/RCP dialog box for the Secondary RM to enter the text strings in the applicable Secondary fields on
the RM profiles tab. These entries are written to the appropriate RM when the given RM block is loaded from
the Project view.
The RM overwrites the unassigned Chassis ID parameter at power up to be Chassis_A, if its redundancy state is
Primary; or Chassis_B, if its redundancy state is Secondary. You can toggle the chassis ID assignment through a
button on the Configuration tab or the Display tab in the RM/RCP dialog box.
10.2.3 RM monitoring
You can view relevant information about the operation of the RMs and the RCP and issue online commands
through the RM/RCP dialog box in the Control Builder Monitoring tree view. You only need to double-click the
Primary or Secondary icon for a loaded RM in the Monitoring tree view to call up the RM/RCP dialog box. As
shown in following figure, the dialog box includes nine different categories of information under separately
labeled tabs.
Tip
The Identification, Dependencies, and Template Defining tabs only appear when the optional Template license is
activated.
Figure 11: RM/RCP dialog box.
The following paragraphs give a brief description of the functions associated with the RM/RCP dialog box and
each of its tabs.
10.2.4 RM/RCP dialog box

The RM/RCP dialog box includes the following status boxes in addition to its tabbed categories.
• Primary- Relates physical hardware data for chassis identification (Chassis_A) and RM serial number to the
Primary redundancy state.
• Secondary Readiness - Shows readiness of Secondary chassis to assume the role of the Primary if a
switchover occurs. The possible readiness states are:
– UNDEFINED: Insufficient data to assess readiness. This is generally a startup state.
– NOPARTNER: Partner (Secondary) is not visible through RM-to-RM private path and cannot assume the
role of the Primary.
177
– DISQUALIFIED: Secondary is present and disqualified for operation as the Primary. It cannot assume
the role of the Primary.
– SYNCHRONIZED: Secondary is synchronized with the Primary. It can now assume the role of the
Primary.
– STANDBY: Secondary is not synchronized but it can assume the role of the Primary. This state is not
available in R120.
• Secondary - Relates physical hardware data for chassis identification (Chassis_B) and RM serial number to
the Secondary redundancy state.
If a switchover occurs, the data in the Primary and Secondary boxes change places.
10.2.5 Main tab

The Main tab includes the following fields that must be initially configured through the Project view to create
the Redundancy Module block in Control Builder. The data on this tab cannot be changed in the Monitoring
view.
10.2.6 Summary tab

The Summary tab includes the following fields and buttons to provide an overview of synchronization
configuration and status, and a means to initiate operator commands.
• Auto-Synchronization - This refers to the ability of the RCP to synchronize without user intervention. This
is only applicable when the Auto-Synchronization state is Enabled and an Auto-Synchronization event is
triggered.
– Option: Shows the current configuration status and provides these on-line configuration selections.
ALWAYS - Auto-Synchronization State is always Enabled.
NEVER - Auto-Synchronization is always Disabled
CONDITIONAL - Auto-Synchronization is Enabled upon receipt of any valid Initiate Synchronization
command; or Disabled upon receipt of any valid Disqualify Secondary command.
– State: Shows the current Auto-Synchronization state.
ENABLED: An RM with a Disqualified Secondary will attempt to synchronize the Secondary when it
receives any Auto-Synchronization event trigger.
DISABLED: An RM ignores any Auto-Synchronization event trigger.
• Synchronize Secondary Button - Lets you send a synchronize command to the RM. If a Primary RM with a
Disqualified Secondary accepts the command, it attempts to synchronize with its partner.
• Disqualify Secondary Button - Lets you send an abort synchronization command to the RM. If a Primary
RM with a Qualified Secondary accepts the command, it aborts synchronization with its partner.
• Swap Control Button - Not active for R120.
• Swap to Standby Button - Not active for R120.
• Become Primary Button - Lets you send a change to Primary command to the RM. If a Disqualified
Secondary RM with no partner (Primary not visible) accepts the command, it switches to the Primary state.
179
• Chassis Synchronization States - Provides a status overview of the synchronization activity on a module by
module basis.
– Slot: Numbered reference to the ICP chassis slot location.
– % Complete: Shows status of synchronization effort for a module pair as a percentage (0 to 100).
Modules synchronize at different rates. For example, a CPM can take as long as a minute to synchronize.
The RM always shows 0%, since it does not perform a configuration data exchange during
synchronization. The RMs synchronize their configurations at startup (or reconnect) and whenever a
configuration change occurs.
– Module: Identifies the module installed in a given slot with an abbreviation.
UNK - Unknown
- - - No module present
CPM - Control Processor module
CNI - ControlNet Interface
RM - Redundancy Module
– Compatibility: Shows module compatibility with respect to its partner.
UNDEFINED: No module, no partner, or not yet assessed. (Note that the second slot for a doublewide
module is shown as UNDEFINED.)
INCOMPATIBLE: Modules have detected an incompatibility in one or more of these attributes.
Honeywell ID
Product Type
Product Code
Revision
FULLY: Modules are compatible. It is possible that minor module differences do not warrant
incompatibility. If versions differ, the newer version is programmed to make this determination. .
– Initiate Switchover Button - Lets you send a switchover command to the RM. If a Primary RM with a
Qualified (Synchronized) Secondary accepts the command, it immediately initiates the switchover.
10.2.7 RM Profiles tab

The RM Profiles tab includes the following fields to provide an overview of RM attributes, synchronization
configuration and general RM status for both the Primary and Secondary RMs.
• IDENTIFICATION - List of attributes that identify the given RM.

– Platform Ver. Rev: Shows version and revision numbers for the RM hardware.
– Boot Ver. Rev: Shows version and revision numbers for the RM Boot firmware
– Application Ver. Rev: Shows version and revision numbers for the RM application firmware.
– Product Type-Code: Shows enumeration's of the RM product type (class) and product code (class
member).
– Honeywell Code: Shows enumeration of the RM manufacturer identification.
– Serial Number: Show unique identification number assigned to given RM.
– Description: Lets you enter a descriptive text string that is used by the Experion server and visible on all
RM alarms.
– Keyword: Lets you enter a definitive text string that is used on Station displays.
• SUMMARY STATUS - List of items that reflect the general status of the RM.
– General State: Shows the general operational state of the RM.
UNDEFINED - General state of the RM has not yet been assessed.
STARTUP - RM in process of startup.
RELOAD - RM firmware in reload cycle.
FAULT - RM in fault state.
OK - RM is fully operational.
– Auto-Sync Option: Shows current Auto-Synchronization option selection - See Summary tab for more
details.
ALWAYS
181
NEVER
CONDITIONAL
– Auto-Sync State: Shows current state for Auto-Synchronization relative to an event trigger - See
Summary tab for more details.
ENABLED
DISABLED
– Program Cmnd: Shows current configuration selection for allowing the RM to accept program
commands from a controller module.
ENABLED - RM accepts all valid commands from a Control Processor module.
DISABLED - RM rejects any command from a Control Processor module and generates an error
message.
– Error Code: Shows any detected error code in the format EXXX. Where XXX represents an
alphanumeric code.
– Fault Bits: Shows status of four severity fault flags in the RM. A checkmark in a box indicates an active
fault.
10.2.8 Configuration tab

The Configuration tab includes the following fields and buttons for making configuration selections and
toggling display positions.
• Chassis Pair - Includes configuration selections for Auto-Synchronization and Program Commands.
– Auto-Synchronization Option: Shows current option selection and lets you make another selection. See
the Summary tab for Auto-Synchronization details.
ALWAYS
NEVER
CONDITIONAL
– Program Command: Shows current command selection and lets you make another selection. See the RM
Profiles tab for Program Command details.
ENABLED
DISABLED
• Chassis ID - Shows current chassis ID position relative to Primary (Chassis_A) and Secondary (Chassis_B)
for given RM serial number.
– RM Serial Number: Lists unique identification number assigned to given RM.
– Chassis ID: Shows display position relative to Primary and Secondary states as Chassis_A and
Chassis_B, respectively.
• Toggle Chassis ID Button - Lets you send a Toggle Display command to the RM. It switches the chassis ID
labels between two RM serial numbers.
10.2.9 Synchronization tab

The Synchronization tab includes the following fields and buttons to provide a window to synchronization
operations and a means to initiate operator commands. Since most of the buttons and display fields are the same
as those on the Summary tab, only the Recent Sync Attempts field is described below. Refer to the Summary tab
for the other button and field descriptions.
183
• Recent Synchronization Attempts - Lists the result and cause for the four most recent synchronization
attempts.
– Order: Shows the chronological order of the data as follows.
N… Most recent data
N-1 Second most recent data
N-2 Third most recent data
N-3 Fourth most recent data
– Result: Shows the result of the synchronization attempt.
NOATTEMPT - Indication of an empty location in the Result log. Usually only seen soon after an RM
startup, when the RM doesn't have enough Synchronization attempts to fill its log.
SUCCESS - Indication that attempt resulted in RCP reaching full synchronization. ABORT - Indication
that attempt was aborted.
– Cause: Shows a message that identifies the possible cause for the result of the given recent
synchronization attempt. The following table lists the cause messages and gives a brief description of
each for reference.
Cause Message Description

BADSEC_EXIST Module in Secondary chassis failed prior to the synchronization attempt. Repair or
replace the failed module and retry.

COMM_DISCONN Communications failed (disconnect) during the synchronization attempt. Try the
following recovery procedures in the order presented and retry the synchronization
attempt after each procedure.
• Check redundancy cable installation.
• Reseat each module in turn.
• Replace each RM in turn.
• Replace each module in turn.
• Replace each chassis in turn.
COMM_NOEXIST Communications failed before the synchronization attempt. Try the recovery procedures
listed for the COMM_DISCONN message.
CROSSLD_FAIL The cross load of data from Primary partner modules failed. Try the recovery
procedures listed for the COMM_DISCONN message.
EDIT_IN_PROG An editing session is in progress. Stop configuration operations on all modules and retry
the synchronization attempt.
LOC_MAJFLT Major unrecoverable fault detected for module in the local chassis. Repair or replace the
failed module and retry the synchronization attempt.
MODCONF_ERR Module configuration error. Check module configuration for compliance with
redundancy requirements and retry the synchronization attempt.
MOD_INSERT Module was inserted into the chassis during the synchronization attempt. Check and
correct module installation and pairing in the RCP and retry the synchronization
attempt.
MODPAIRINCMP A pair of modules is incompatible. Use other RM/RCP dialog box tab views to identify
the incompatible pair. Use the Network Tools application to check module data and
update firmware as required. Retry the synchronization attempt.
MOD_REMOVAL Module was removed from the chassis during the synchronization attempt. Check and
correct module installation and pairing in the RCP and retry the synchronization
attempt.
NOABORT Result was either NOATTEMPT or SUCCESS.
NRCMOD_EXIST A non-redundancy compliant module is installed in the RCP. Use Network Tools
application to check model numbers and version data for installed modules to identify
non-redundancy module. Replace module with redundancy compliant one and retry the
synchronization attempt.
PRTNR_MAJFLT Major unrecoverable fault detected for the partner module. Repair or replace the failed
module and retry the synchronization attempt.
SECMOD_FAIL Module in Secondary chassis failed. Repair or replace the failed module and retry the
synchronization attempt.
SECRM_COMERR Communications error with the RM in the Secondary chassis. Try the following
recovery procedures in the order presented and retry the synchronization attempt after
each procedure.
• Check redundancy cable installation.
• Reseat each RM in turn.
• Replace each RM in turn.
• Reseat each module in turn.
• Replace each module in turn.
• Replace each chassis in turn. .
SECRMMAJRFLT Major recoverable fault detected for the RM in the Secondary chassis. Repair or replace
the RM and retry the synchronization attempt.
SECRMMAJUFLT Major unrecoverable fault detected for the RM in the Secondary chassis. Replace the
RM and retry the synchronization attempt.
185

SECSUBSYSFLT Secondary subsystem fault.
WRONG_CHS_ST Chassis is in the wrong redundancy state for synchronization. The Primary chassis must
have a Disqualified Secondary to accept the synchronization attempt. Disqualify the
Secondary and retry the synchronization attempt.
WRON_DEV_ST Module is in the wrong device state. Individual module state does not support
redundancy function. For example, the CPM is in its ALIVE state. Change device state
as required and retry the synchronization attempt.
10.2.10 Chassis Profiles tab

The Chassis Profiles tab includes the following fields to provide an overview of the RCP status. Since the fields
in the Primary and Secondary categories are identical, they are only described once here.
• Primary/Secondary - Provides a status overview of the RCP activity on a module by module basis for the
given chassis.
– Module: Identifies the module installed in a given slot with an abbreviation.
UNK - Unknown
- - - No module present
CPM - Control Processor module
CNI - ControlNet Interface
RM - Redundancy Module
– Gen State: Shows the general operational state of the given module.
UNDEFINED - General state of the module has not yet been assessed.
STARTUP - Module in process of startup.
RELOAD - Module firmware in reload cycle.
FAULT - Module in fault state.
OK - Module is fully operational.
– See Readiness - Shows readiness of Secondary chassis to assume the role of the Primary if a switchover
occurs. The possible readiness states are:
UNDEFINED: Insufficient data to assess readiness. This is generally a startup state.
NOPARTNER: Partner (Secondary) is not visible through RM-to-RM private path and cannot assume the
role of the Primary.
DISQUALIFIED: Secondary is present and disqualified for operation as the Primary. It cannot assume
the role of the Primary.
SYNCHRONIZED: Secondary is synchronized with the Primary. It can now assume the role of the
Primary.
STANDBY: Secondary is not synchronized but it can assume the role of the Primary. This state is not
available in R120.
– Compatible: Shows module compatibility with respect to its partner.
UNDEFINED: No module, no partner, or not yet assessed. (Note that the second slot for a doublewide
module is shown as UNDEFINED.)
INCOMPATIBLE: Modules have detected an incompatibility in one or more of these attributes.
Honeywell ID
Product Type
Product Code
Revision
FULLY: Modules are compatible. It is possible that minor module differences do not warrant
incompatibility. If versions differ, the newer version is programmed to make this determination. .
10.2.11 Display tab

The Display tab includes the following fields and buttons for toggling display positions for the RM/RCP dialog
box and checking the refresh intervals for the Primary and Secondary RMs in milliseconds.
Refer to the Configuration tab section for descriptions of the Chassis ID fields and Toggle Chassis ID button.
187
10.2.12 Server History tab

The Server History tab includes the following fields for configuring the parameters related to history collection
in the Experion server applications. The entries are the same for both Primary and Secondary chassis.
Control Level - A system wide configuration parameter for Experion Server to limit control over selected
display data in Station. A control level can be any number from 0 to 255. An operator can only control a point if
their assigned control level is equal or greater than the assigned Control Level. The default value is 200.
Control Area - A system wide configuration parameter for Experion Server to restrict access to data in Station.
Number of History Parameters - Defines the number of history parameters to be included in the History
Configuration table. Key in the desired number from 1 to 25 and press <Enter> to initiate changes in the Table.
Parameter - Enter a valid parameter name for a parameter associated with the given point that is to be collected
and stored as historical data at predetermined intervals. You can enter up to 25 different parameters for this
given point.
Description - This read-only field provides a brief description of the entered parameter.
FAST - Check box lets you select the Fast type of history collection.
STD - Check box lets you select the Standard type of history collection.
EXTD - Check box lets you select the Extended type of history collection.
EXC - Check box lets you select the Exception type of history collection.
Gating Parameter - Enter an optional gating parameter to define the conditions under which data for this
parameter should be collected. This field is only active when associated valid parameter and history type are
configured.
Gate State - Defines the gate state for the configured gating parameter. This field is only active when a gating
parameter is configured.
189
10.2.13 Server Displays tab

The Server Displays tab includes the following fields for configuring the parameters related to standard display
functions in the Experion Server applications. The entries are the same for both Primary and Secondary chassis.
Point Detail Page - Links the RM data to a Detail display template for Station. The default display file name is
sysDtlRMA.dsp
Associated Display - Links a custom schematic created in Display Builder to the RM Detail display. Enter page
number or file name assigned to the custom graphic in Display Builder.
Group Detail Page - Links RM faceplates to a Group display template for Station. The default display file name
is sysGrpRMA.dsp.
Number of Trends - Defines the number of trend parameters to be included in the Trends Configuration table.
Key in the desired number from 1 to 25 and press <Enter> to initiate changes in the Table.
Trend # - Key in the desired Trend # (Number) to be associated with this trend parameter. Trend set displays are
standard Station displays that provide a way of viewing historical data for points. Trend set displays
complement other types of displays that can be used to view historical data such as point detail trends, group
trends, and custom display trends.
Pen - Defines the color of the pen that will be used to trace the assigned parameter on the Station Trend display.
Trend Parameter - Enter a valid parameter name for a parameter associated with the given point that is
configured for history collection. When a point parameter has been configured for history collection, it is
sampled and stored in the server database history files. The Trend displays show the history data contained in
these files. You can include this point as a member of up to 10 trends.
Number of Groups - Defines the number of group parameters to be included in the Groups Configuration table.
Key in the desired number from 1 to 25 and press <Enter> to initiate changes in the Table.
Group # - Key in the desired Group # (Number) to be associated with this group parameter. Group displays are
single Station displays that provide a way of viewing up to eight related points. Each group display can contain
a mixture of point types.
Pos - Defines the number of the position the configured parameter will occupy in the Station Group display.
Group Parameter - Enter a valid parameter name for a parameter associated with the given point that is
configured in the system. You can include this point as a member of up to 10 groups.
10.2.14 Auto-Synchronization events

The following events can trigger an Auto-Synchronization in a Primary RM with a Disqualified Secondary.
• The Secondary chassis becomes disqualified for one of the following reasons:
– At power up, the Secondary chassis RM finds the Primary chassis RM and becomes a Disqualified
Secondary. (Note that this also defines a simultaneous power up of the RCP.)
– The RMs establish/re-establish an inoperative RM-to-RM connection and disqualify the Secondary as a
result. For example, the redundancy cable installed between RMs in a powered RCP.
– The Primary RM completes a switchover initiated by an Initiate Switchover command, or the insertion of
a module into a Primary chassis with a Synchronized Secondary. These types of switchovers result in a
Disqualified Secondary.
• Module detected in either chassis. Detection means that the module has completed a portion of its startup
process and begins interacting with the RM. Other actions, such as a switchover caused by inserting a
module, may precede Auto-Synchronization.
• Module goes invisible in the Secondary chassis.
• All major faults cleared in the Primary chassis.
• The redundancy's backplane hardware failure signal (SYS_FAIL_L) is deactivated. This applies to either
chassis, and is probably caused by the removal of a failed module.
• Auto-Synchronization option changes to ALWAYS, with Auto-Synchronization state of DISABLED. This
causes the Auto-Synchronization state to change to ENABLED.
Note that all of these events result in only one attempt at synchronization. If the synchronization function aborts,
it takes another event trigger (or Secondary command) to initiate another synchronization attempt.
191
11 Control Mode Shed on Loss of I/O Functionality
Related topics
“Basic Control Mode Shed Design Concepts” on page 194
“Option to specify a time delay for the REGCTL blocks to shed the mode” on page 196
“Implications for Operation” on page 202
“Remote Cascade function between Controllers” on page 203
193
11 CONTROL MODE SHED ON LOSS OF I/O FUNCTIONALITY
11.1 Basic Control Mode Shed Design Concepts

If your control strategy includes cascaded loops, the ultimate secondary Regulatory Control type blocks will
shed their Control Mode to Manual (MAN) upon the loss of I/O communications. This is in addition to going
into initialization. The ultimate secondary block must be connected directly to an Analog Output Channel or a
Pulse Width Modulator Channel block, so it can detect when communications fail with the Analog Output
Module or Digital Output Module with a PWM Channel block.
This functionality applies to the family of Experion system I/O modules including Series A Chassis I/O, Series
A Rail I/O, and Series H Rail I/O.
11.1.1 How it works

Any condition that breaks the communication path between the physical I/O module and the I/O function block
will initiate 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.
• Removing the I/O module from the chassis.
• Removing the local or remote CNI module from the chassis
• Disconnecting the ControlNet Cable.
• Cycling power to the remote chassis that contains an associated I/O module.
• 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 would 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:
• Activating/inactivating the IOM block.
• Activating/inactivating the CEE that contains the IOM block.
• Activating/inactivating the Control Module that contains an associated AOCHANNEL or PWMCHANNEL block.
For example, if the Analog Output module associated with the AO_SECONDARY block in the typical cascade
control strategy shown below is removed from the chassis, the control MODE of the connected
PID_SECONDARY block would shed to MAN (Manual). You could observe this action take place through the
Monitoring tab in Control Builder or the associated Detail display in Station.
195
11.2 Option to specify a time delay for the REGCTL blocks to shed the
mode
With R400, you can specify a time delay for the regulatory control blocks to shed the control mode in the event
of an IO communication loss.
Note that this functionality is applicable to all the regulatory control blocks which supported the mode shed
functionality prior to R400.
You can select one of the following options in the event of an IO communication loss.
• Shed the mode to MANual immediately after an IO communication loss (existing functionality).
• Shed the mode to MANual after a specified time delay (0 to 60 seconds).
• Do not shed the mode at all after an IO communication loss.
The functionality of specifying a time delay to shed the mode is applicable only to the regulatory blocks that are
connected to the local analog and digital outputs.
This configuration is accomplished through a new parameter, BADOCOPT (Bad Output Connection Option).
This configuration is applicable to all the regulatory control blocks except for the PIDER block. This is because
the PIDER block does not support any BACKCALC communication from the secondary.
Note: Only the users with an Engineer access level can change the BADOCOPT value. For more information
on BADOCOPT values, refer to the section “Description of values for Bad Output Connection Option” on
page 197.
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” on
page 196.
11.2.1 Enabling the option of specifying time delay for REGCTL blocks to shed the mode
The complete functionality of specifying time delay for the regulatory control blocks to shed the mode in the
event of an IO communication loss can be optionally enabled. This is accomplished through a new parameter
BADOCOPTENB. The available values for the BADOCOPTENB parameter are as follows:
• Enable - When this parameter is enabled, you can specify the time delay for the regulatory control blocks to
shed their 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.
Refer to the Control Builder Parameter Reference document for more information on the BADOCOPT and
BADOCOPTENB parameters.
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).
11.2.2 Description of values for Bad Output Connection Option

The available values for BADOCOPT are NaN, 0, and 1 to 60 seconds.
Value What happens when an IO communication loss Restore Conditions

occurs?
Nan No mode shed happens. After the IO communication is restored, the initialization
request is reset.
Only the initialization request for the block is
set and the upstream blocks are initialized.
0 Mode sheds to MANual immediately. The mode After the IO communication is restored, the initialization
attribute changes to Operator and an request is reset. You must revert the mode setting manually.
initialization request is set. When an
initialization request is set, the upstream blocks
are initialized and the control freezes.
197
Value What happens when an IO communication loss Restore Conditions

occurs?
1 - 60 Mode sheds to MANual and the mode attribute After the IO communication is restored, the initialization
changes to Operator based on the following request is reset and you must revert the mode setting
conditions: manually. However, if the IO communication is restored
within the specified time delay, there is no need to revert
When the BADOCOPT value is less than its
the mode setting.
associated Control Module's 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)
When the BADOCOPT value is greater than its
associated Control Module's execution period,
the mode shedding occurs as follows:
• If the BADOCOPT value is directly
divisible by the CM Period, the mode
shedding occurs after a time delay of
(BADCOPT/ Control Module Execution
Period) seconds. For example, if the
BADOCOPT value is 10 secs and if its
associated Control Module's period is 1 sec
then the mode shed to MANual happens
after 10 seconds. (10/1=10 block execution
cycles)
• If the BADOCOPT value is not exactly
divisible by the CM Period, the mode
shedding occurs after a time delay of a
rounded-off value available by dividing
BADOCOPT by the CM Period. For
example, if the BADOCOPT value is 15
secs and the Control Module's period is 10
secs then the mode shed happens after 20
seconds. (15/10= 1.5 rounded off to 2 block
execution cycle, that is, 20 seconds)
After an initialization request is set, the
upstream blocks are initialized and the control
freezes.
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.
11.2.3 Considerations for setting the BADOCOPT value

Before changing the value of BADOCOPT to a value in the range of 0 to 60 secs, you can set proper alarm
attributes in the UNCMDCHGALM parameter, if required. When this parameter is enabled, it notifies an alarm
in the alarm summary, whenever a mode shed happens in the event of an IO communication loss. This alarm
returns to normal, after you revert to the mode setting manually.
Also, before changing the value of BADOCOPT to NaN, you must set proper alarms and messages to indicate
that the block has transitioned into initialization state without changing its mode to MANual after an IO
communication loss.
11.2.4 Applicability of BADOCOPT parameter for FANOUT blocks

The BADOCOPT parameter is applicable to the FANOUT block under the following circumstances.
• 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.
11.2.5 Simulation support for the BADOCOPT parameter

The BADOCOPT parameter is supported in the simulation version of the SIM-ACE and SIM-C300 controllers.
In a simulation controller, the IO communication loss is simulated in the following scenarios.
• The output channel is in a Control Module different than the primary regulatory block.
• The Control Module containing the output channel is deleted.
Note that inactivation or deletion of the associated IO module does not cause a mode shed but sets the
INITMAN of the primary to ON.
For more information on the scenarios that result in IO communication loss, refer to the “Basic Control Mode
Shed Design Concepts” on page 194 section.
11.2.6 Impact of BADOCOPT parameter on regulatory control functionalities

The regulatory control functionalities such as Windup processing, Alarming, Override initialization, Override
Control, and Timeout processing are not impacted by this parameter. it is connected and the CM containing the
AO channel is inactivated and deleted. The ModeShed behavior in this scenarios, is based on the BADOCOPT
value chosen.
11.2.7 Effects of BADOCOPT value on delay timer in various scenarios
BADOCOPT Value Scenario Result

Between 0 - 60 You change the BADOCOPT value to a value Change comes into effect only when the timer is
secs between 0 - 60 while the delay timer is terminated after the period is over or the
running. communication is restored.
NaN You change the BADOCOPT value to NaN Change comes into effect immediately. Mode does
while the delay timer is running. not shed to MANual. Timer is reset.
Between 1 - 60 You change the mode to a non-MANual mode Mode sheds to MANual, even if the specified time
secs after the block has shed to MANual after the delay is not expired. However, if the communication
specified time delay or error is restored and restarted, the mode sheds to
MANual after the specified time delay is expired.
You set the mode to MANual before the delay
time expires and then change the mode to a
non-MANual mode.
199
BADOCOPT Value Scenario Result

Between 1 - 60 You set the CEE to Idle or make the Control Timer value is reset. The timer is restarted after the
secs Module containing the regulatory block CEE is started, Control Module is active and the IO
inactive. communication loss continues to exist.
Between 1 - 60 You perform a Checkpoint Save operation. Checkpoint Save does not store the active delay
secs 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 - 60 You perform an On-Process Migration. On-Process Migration does not restore the active
secs delay timer value after migrating to the new release.
The BADOCOPT value option is restored after
migration but the delay timer value is reset. If the IO
communication is not restored even at this point, this
is considered a new instance and the delay timer is
restarted.
Between 1 - 60 You perform a RAM Retention Restart. RAM Retention Restart does not restore the active
secs timer value but it is reset.
11.2.8 Auxiliary memory usage for the parameters

The parameters BADOCOPT, UNCMDCHGLM.OPT, UNCMDCHGLM.PR, UNCMDCHGLM.SV, and
UNCMDCHGLM.FL are placed in the auxiliary memory. Auxiliary memory for these parameters is allocated
only when the BADOCOPTENB parameter is enabled.
11.2.9 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.
For more information on the detail displays, refer to the following:

• HMIWeb Display Building Guide
• Operator's Guide
201
11.3 Implications for Operation
Related topics
“Resetting mode after I/O communications are restored.” on page 202
“Allowing Redundancy synchronization with lost I/O communications” on page 202
11.3.1 Resetting mode after I/O communications are restored.

When I/O communications are restored, the operator must manually reset the secondary regulatory block's
control mode back to AUTO (Automatic) or CAS (Cascade) from MAN.
For example, if the AOM removed in the previous example is returned to the chassis, an operator would have to
manually change the MODE of the PID_SECONDARY block from MAN to CAS through the Monitoring tab
in Control Builder or the Detail display in Station.
11.3.2 Allowing Redundancy synchronization with lost I/O communications

The Control Mode shed on loss of I/O function allows redundant Controllers to synchronize in the presence of
lost I/O communications.
For example, if you initiate a switchover in a synchronized Redundant Chassis Pair (RCP), the Secondary
Controller becomes the Primary. If you now remove the up-link CNI from the chassis of the Primary Controller,
any PID blocks in its control strategy change their control mode to MAN and go into initialization. The
Secondary controller is allowed to synchronize with good I/O communications and an automatic switchover
occurs making the Secondary the Primary again. The PID blocks in this Primary Controller's matching Control
Strategy will now be in MANual mode. Hence, an operator would have to manually reset any secondary
regulatory blocks that have shed to MAN mode back to AUTO or CAS mode.
11.4 Remote Cascade function between Controllers

The REMCAS (Remote Cascade) block provides automatic switching between a remote and backup cascade.
This block is typically used with a PID block that normally gets its set point from a remote source, but sheds to
a local source if there is a communications failure.
Note that when using a cascade control strategy between two controllers, or a controller and an ACE node, you
do not need to use the REMCAS block but switching to a backup primary is not supported. The Regulatory
Control (REGCTL) blocks in Experion do not contain the remote cascade function so the REMCAS block must
be included in the control strategy to provide the function.
Use a REMCAS block between the controller/ACE nodes to handle the initialization and handshaking required
to provide switching between remote and local sources.
See the following links for more detailed information about the REMCAS block and its usage.
• “REMCAS (Remote Cascade) Block”
• “Peer-to-peer configuration example” on page 119
203
12 Enhancements to MODE behavior of the regulatory
control blocks
Starting from Experion R430, project engineers can set the MODE behavior of the regulatory control blocks to
go to Manual mode or the configured mode upon controller download, last saved mode upon Checkpoint
Restore, and last mode upon RAM Retention Restart (RRR). To accomplish this, a new parameter
MODESTARTMAN is introduced on the Main page of the regulatory control blocks.
The behavior of the MODE parameter of the regulatory control blocks is decided by the following parameters.
These parameters take the priority in the order in which they are listed .
• MODESTARTMAN (Load and Start MODE in Manual)
• CEESTARTOPT (CEE Restart Option)
• RRRCEESTATERAM (Retention Restart CEESTATE)
If the MODESTART parameter is enabled, this always takes the priority.
Prior to R430, the MODE parameter of the regulatory control blocks was set to the configured mode after
download. In case of RRR, the MODE parameter was set to the last saved mode which was then followed by a
Cold Start or a Warm Start, depending on the RRRCEESTATE and the CEESTARTOPT parameter. This
behavior is not desirable as it possesses safety risks such as valves being unintentionally open.
205
12 ENHANCEMENTS TO MODE BEHAVIOR OF THE REGULATORY CONTROL BLOCKS
12.1 About the MODESTARTMAN parameter

The MODESTARTMAN (Load and Start MODE in Manual) parameter is added on the Main page of most
of the regulatory control blocks in C200E, C300, ACE and the simulation environments of these controllers.
The Load While Active feature is supported for this parameter and hence can be modified online without
inactivating the Control Module. However, you cannot modify the parameter from the Monitoring view.
Attention
• The MODESTARTMAN parameter is not applicable for the following blocks:
– REEOUT block
– RAMPSOAK block
– PULSECOUNT block
– PULSELENGHT block
• If you are on an R430 server and the controller is in R410 or earlier version, the MODESTARTMAN is available
in the database and on the configuration form of the regulatory control blocks. However, this does not have any
functional impact and the parameter value is displayed as blank in the Monitoring view. In addition, if you try to
modify the MODESTARTMAN parameter from the Monitoring view, an error message appears indicating that the
parameter is not recognized by the CEE.
When MODESTARTMAN is enabled

When MODESTARTMAN parameter is enabled, the mode of the regulatory control blocks will either go to
Manual or last mode. In addition, whenever the mode is set to Manual, the mode attribute is automatically set to
Operator.
The following table summaries the behavior of the MODE parameter of the regulatory control blocks after a
controller download, Checkpoint Restore, and RRR.
Block Name Download followed by Checkpoint Restore followed RRR followed by

by
Warm Start Cold Start Warm Start Cold Start Warm Start Cold Start
Regulatory control blocks Manual Manual Manual Manual Manual Manual
(with outputs connected to
IO channels)
Regulatory Control blocks Manual Manual Manual Manual Last Mode Last Mode
(with output connected to
another regulatory control
point)
RAMPSOAK Manual Manual Manual Manual Manual (Mode Manual (Mode
Attribute is Attribute is
retained) retained)
POSPROP Manual Manual Manual Manual Manual Manual
PIDER Manual Manual Manual Manual Last Mode Last Mode
Attention
• After a controller download or a Checkpoint Restore, you must perform a Cold Start or a Warm Start, as
applicable. The MODESTARTMAN parameter behavior then depends on the start type.
• After an RRR;
– If CEESTATE is Idle, this must be followed by either a Cold Start or a Warm Start. The MODESTARTMAN
parameter behavior then depends on the start type.
– If the CEESTATE is RUN, the MODESTARTMAN parameter behavior then depends on the RRRCEESTATE
and the CEESTARTOPT parameters.
• In a CEE-to-CEE cascade where the primary regulatory control block and the secondary AO channel are hosted on
different nodes, the primary regulatory control block’s mode is changed to Manual, if the node hosting the
secondary (AO channel) is shutdown and restarted.
When MODESTARTMAN is disabled

When MODESTARTMAN parameter is disabled, the mode is set to the configured mode or the last mode. The
following table summaries the behavior of the MODE parameter of the regulatory control blocks after a
controller download, Checkpoint Restore, and RRR.
Block Name Download followed by Checkpoint Restore followed by RRR followed by

Warm Start Cold Start Warm Start Cold Start Warm Start Cold Start
Regulatory Configured Manual Restores Mode to Manual Last Mode Manual
control blocks mode that in the
with Outputs Checkpoint file.
connected to IO
channels
Regulatory Configured Configured Restores Mode to Restores Mode to Last Mode Last Mode
Control blocks mode mode that in the that in the
with output Checkpoint file. Checkpoint file.
connected to
another
Regulatory
Control point)
RampSoak Manual (Mode Manual (Mode Manual (Mode Manual (Mode Manual Manual
Attribute is Attribute is Attribute is Attribute is (Mode (Mode
retained) retained) retained) retained) Attribute is Attribute is
retained) retained)
PosProp Configured Configured Restores Mode to Restores Mode to Manual Manual
mode mode that in the that in the (Mode (Mode
Checkpoint file. Checkpoint file. Attribute is Attribute is
retained) retained)
PIDER Configured Configured Restores Mode to Restores Mode to Last Mode Last Mode
mode mode that in the that in the
Checkpoint file. Checkpoint file.
207
12.2 MODESTARTMAN
Specific to Block(s) AUTOMAN, FANOUT, PID, SWITCH, REMCAS, OVRDSEL, REGCALC,

RATIOBIAS, PIDFF, POSPROP, PIDER, RATIOCTL, ENHREGCALC,
REGSUMMER, PID-PL
Description Load and start MODE in Manual.
Data Type Boolean
Range Off (0) - Retains configured/last mode and mode attribute
On (1)
• Sets MODE to Man and MODEATTR to Operator during controller download and
Checkpoint Restore.
• Sets MODE to Man and MODEATTR TO Operator during RAM Retention Restart
(RRR) if the regulatory control block is connected to a downstream IO channel.
Default Off (0)
Config Load Yes
Active Loadable Yes
Access Lock AppDeveloper
Residence CEE
Related Parameters MODE
MODEATTR
Remarks The parameter determines the values of the MODE and the MODEATTR parameters of
the block after controller download, Checkpoint Restore, and Ram Retention Restart.
• When this parameter is disabled;
– MODE and MODEATTR are downloaded as per the configuration.
– Checkpoint Restore restores MODE and MODEATTR with the value in the
Checkpoint file. Checkpoint Restore must then be followed by a Cold or a
Warm Start.
– Ram Retention Restart restores MODE as per the configuration of the
RRRCEESTATE and the CEESTARTOPT parameters and any subsequent
Warm or Cold Start operations, if required. MODEATTR is restored to the value
it had before Ram Retention Restart.
When this parameter is enabled;
– MODE is downloaded as Man and MODEATTR as Operator.
– Checkpoint Restore restores MODE as Man and MODEATTR as Operator.
– After an RRR if the regulatory control block is connected to a downstream IO
channel, MODE value is set to Man and MODEATTR value is automatically set
to Operator. However, if the regulatory control block is connected to another
regulatory control point, the MODE value is set to the last configured mode.
For detailed information, refer to the Control Builder Components Theory document.
13 Control Builder Export and Import Functionality
Related topics
“Basic Export/Import Design Concepts” on page 210
209
13 CONTROL BUILDER EXPORT AND IMPORT FUNCTIONALITY
13.1 Basic Export/Import Design Concepts

Control Builder includes Export and Import functions that are accessible through the File menu. These functions
provide dynamic copy-paste type functionality for the ERDB, which contain the control strategies that are
configured through the Control Builder. In addition, you can export and import the System Preferences and the
Checkpoint Preferences from the Control Builder.
With R410, the performance of the Export and Import functions are significantly improved. You can export or
import large number of objects in a single Export or Import.
The following figure illustrates the Export and Import function.
13.1.1 Export functionality

Export function operates as a dynamic copy operation for the ERDB being accessed through the Control
Builder. This function allows you to export a portion of the ERDB or the whole ERDB as viewed through the
Project view in the Control Builder. The exported or copied portion of the ERDB is automatically stored as
XML files in the following directory by default.
C:\Program Data\Honeywell\Experion PKS\Ixport
By default, the ERDB used by the Control Builder is stored in SQL Server under the filename ps_erdb (default
name).
Attention
If you have installed Experion in a different drive other than “c,” the exported portion of the ERDB is automatically
stored in the following directory by default.
C:\Users\Public\Public Documents\Honeywell\Experion PKS\Ixport
13.1.2 Import functionality

Import function operates as a dynamic paste operation for the ERDB being accessed through the Control
Builder. This function allows you to 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 view, which is associated with the ps_erdb file in the SQL Server.
For more information on the how to use Export and Import, refer to the Control Building User's Guide.
14 SCM and CM Chart Visualization Functionality
Related topics
“Basic Chart Visualization Design Concepts” on page 212
“Some SCM and CM Chart Operation Considerations” on page 216
211
14 SCM AND CM CHART VISUALIZATION FUNCTIONALITY
14.1 Basic Chart Visualization Design Concepts

A SCM chart configured and loaded to the Controller through Control Builder is now viewable through the
corresponding SCM Detail display in Station. You can also view a CM chart configured and loaded to the
Controller through Control Builder in its corresponding CM Detail display in Station.
This chart visualization function uses ActiveX? technology to embed an active document in the SCM or CM
Detail display. This means an operator can actively monitor an active SCM or CM chart through the
corresponding Detail display in Station.
You must have both Engineering Tools and Server/Client software components installed on the computer for the
chart visualization function to work.
14.1.1 How SCM chart visualization works

The ActiveX Controls needed to support the display and interaction of a Control Builder SCM or CM chart in
the associated Detail Display in Station are loaded as part of the software. The software also includes updated
SCM and CM Detail displays The SCM display includes a Tab labeled “Chart”. The redesigned CM display
includes a Tab labeled “Control Module”
Since the SCM and CM Detail displays mirror the SCM and CM chart configurations in Control Builder, you
first configure the SCM and CM charts in Control Builder as usual. Once the SCM and CM charts are
configured and loaded to a Controller, you can view them in the Monitoring Tab of Control Builder or in the
associated Detail display in Station.
With R400, 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 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.
Figure 12: View of example_scm chart in Control Builder Monitoring Tab.
For example: The example_pid.pida.SP is indicated as a hyperlink since the mouse pointer is moved on the
parameter.
213
Figure 13: View of example_scm chart in SCM Detail display Chart Tab in Station.
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.
Figure 14: View of CM102 chart in Control Builder Monitoring Tab.
Figure 15: View of CM102 chart in CM Detail display in Station.
215
14.2 Some SCM and CM Chart Operation Considerations
Related topics
“Detail display interaction notes” on page 216
14.2.1 Detail display interaction notes

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 will be different than the security level for Control Builder.
• A communications failure will result in question marks (?) being shown in place of live values until the fault
is cleared.
15 Enhancements to reporting of alarms in Station
Prior to R410, you could only configure on-delay time (deadband time) for process alarms at block level. For
example, if you configured an on-delay time for a PID block, all alarms associated with that PID block would
be set to the same on-delay time.
Although on-delay time was configured at block level, you could modify it individually for all alarms from the
Monitoring view only. However, the values modified from the Monitoring view could not be restored after a
Checkpoint Restore. As a result, you had to re-configure the on-delay time for individual alarms every time you
reloaded the strategies.
With R410, you can configure alarm attributes separately for individual alarms associated with a block. In
addition, these values are restored after a Checkpoint Restore. As a result, there is no need for reconfiguration
after a Checkpoint Restore.
For example, you can individually configure the alarm attributes for PID block's OPHIALM as follows:
• on-delay time - 5 seconds
• off-delay time - 10 seconds
• deadband value - 2
• deadband unit - Engineering Unit (EU)
This enhancement is applicable only for a set of analog and digital process alarms and is supported for the
following controllers.
• ACE
• SIM-ACE
• C200E
• SIM-C200E
• C300
• C300 - 20msCEE
• SIM-C300
217
15 ENHANCEMENTS TO REPORTING OF ALARMS IN STATION
15.1 Various configurable alarm attributes

You can configure the following attributes for a set of analog and digital alarms.
• On-delay time (xxxxALM.TM parameter) - You can configure time duration in seconds during which a
process alarm reporting is suppressed. The alarm is reported on the Station only when this time expires and
the alarm condition continues to exist even after this time expires.
For example, consider that you have configured an on-delay time of 10 seconds for OPHIALM. In this
scenario, an active OPHIALM alarm is reported in the Station only when it exists for more than 10 seconds.
• Off-delay time (xxxxALM.TMO parameter) - You can configure time duration in seconds during which an
RTN reporting is suppressed even though the alarm condition does not exist. The RTN is reported on the
Station only after this time expires and the alarm condition has returned to normal. However, if a deadband
value is also configured, the RTN is reported only when OP value is less than the trip point value - deadband
value for the configured off-delay time.
For example, consider that you have configured an off-delay time of 10 seconds for OPHIALM. In this
scenario, an existing OPHIALM is reported in the Station as RTN only when it is in the RTN state for more
than 10 seconds.
• Deadband value (xxxxALM.DB parameter) - With R410, deadband value can be individually configured for
each alarm. The deadband value is calculated as follows depending on the alarms.
– For high and high high alarms: Trip point - deadband value (configured)
– For low and low low alarms: Trip point + deadband value (configured)
For example, you can configure OPHIALM.DB as 5 and OPLOALM.DB as 3.
• Deadband units (xxxxALM.DBU parameter) - With R410, deadband unit can be individually configured for
each alarm.
For example, you can configure PVHIALM.DBU as percent and PVLOALM.DBU as Engineering Unit for
the DATAACQ block.
However, you can configure only identical deadband units for the alarms in the following blocks.
– AUTOMAN
– ENHREGCALC
– OVRDSEL
– PID
– PIDER
– PIDFF
– PID-PL
– POSPROP
– RAMPSOAK
– RATIOBIAS
– RATIOCTL
– REGCALC
– REGSUMMER
– REMCAS
– SIGNALSEL
– SWITCH
15.2 Blocks and applicable alarms

The following table lists the function block names and the respective alarms for which you can configure on-
delay time, off-delay time, deadband value, and deadband units.
Block Names Alarms for which on-delay time and off- Alarms for which deadband value and
delay time can be configured deadband units can be configured
ALMWINDOW, • Off-Normal alarm
CONTACTMON, FLAG
AUTOMAN, ENHREGCALC, • Bad Control alarm • Output (OP) High alarm
OVRDSEL, RATIOBIAS, • Output (OP) High alarm • Output (OP) Low alarm
REGCALC, REGSUMMER,
• Output (OP) Low alarm
REMCAS, SWITCH
DATAACQ • Bad PV alarm • PV High alarm
• Negative Rate Of Change alarm • PV High High alarm
• Positive Rate of Change alarm • PV Low alarm
• PV High alarm • PV Low Low alarm
• PV High High alarm
• PV Low alarm
• PV Low Low alarm
DIGACQ • Bad PV alarm
• Off-Normal alarm
FANOUT • Bad Control alarm
PID, PIDER, PIDFF, RATIOCTL • Advisory Deviation alarm • Advisory Deviation alarm
• Bad Control alarm • Deviation High alarm
• Deviation High alarm • Deviation Low alarm
• Deviation Low alarm • Output (OP) High alarm
• Output (OP) High alarm • Output (OP) Low alarm
PID-PL • Advisory Deviation alarm • Advisory Deviation alarm
• Deviation Low alarm • Output (OP) High alarm
• Output (OP) High alarm • Output (OP) Low alarm
• Predictive PV High alarm
• Predictive PV Low alarm
POSPROP • Advisory Deviation alarm • Advisory Deviation alarm
• Deviation Low alarm
RAMPSOAK • Deviation High alarm • Deviation High alarm
• Deviation Low alarm • Deviation Low alarm
• Output (OP) High alarm • Output (OP) High alarm
• Output (OP) Low alarm • Output (OP) Low alarm
ROC • Bad PV alarm
SIGNALSEL • Deviation alarm • Deviation alarm
219
Attention
The INALM parameter also changes based on the expiration of the alarm timer values.
15.2.1 Guidelines for configuring on-delay time for BADCTL alarm

You can configure an on-delay time for BADCTL alarm only when the BADCTLOPT is configured as
NOSHED. However, the BADCTLALM.TM and BADCTLOPT parameters are validated only when the block
is loaded and the subsequent changes made from the Monitoring view.
The following table illustrates the behavior of the on-delay time when the BADCTLOPT is configured to a
value other than NOSHED.
If you set the ? Then, the BADCTLALM.TM value is ?

BADCTLALM.TM to a non-zero value when the Rejected and the following message appears.
BADCTLOPT is configured as SHEDHI, SHEDLO,
“Config Not Permitted With Current BadControlOption
SHEDSAFE, or SHEDHOLD
[EXPKS_E_NONFATAL (2L.101.2189)]”
For more information about the error message, refer to
Control Builder Error Codes Reference.
BADCTLOPT as SHEDHI, SHEDLO, SHEDSAFE, or Reset to zero (default value) and the following message
SHEDHOLD when BADCTLALM.TM is already set to a appears.
non-zero value
“Bad Control Alarm OnDelay Time is Reset
[EPKS_E_WARNING (1L.101.2190)]”
For more information about the error message, refer to
Control Builder Error Codes Reference Guide.
However, BADCTLALM.TMO is supported for all configuration of BADCTLOPT parameter.
15.2.2 Example to illustrate the alarm behavior based on alarm attributes

You can choose to configure all four alarm attributes or some of the alarm attributes based on your alarm
reporting requirement. For the all configuration, an active alarm is reported in the Station only when the value
(OP/PV) exceeds the configured trip point value. However, the RTN behavior of the alarm is based on the
configured alarm attributes.
Note: The OP High alarm of the PID block is used for illustration.
The following table illustrates with example the behavior of the active/RTN of the alarm based on the
configured alarm attributes.
When the OP High alarm attributes Active OP High alarm occurs when ? RTN of active OP High alarm occurs when ?
are configured as?
• Trip point = 80 OP value exceeds 80. OP value persists below 80 for 30 seconds or
• Off-delay time = 30 sec more.
• Deadband value = 0
• Trip point = 80 OP value exceeds 80. OP value reaches a value = trip point -
• Off-delay time = 0 deadband value, 78 in this example.
• Trip point = 80 OP value exceeds 80. OP value goes below a value = trip point -
• Off-delay time = 30 sec deadband value, 78 in this example, and
persists in the same range for 30 sec or more.
When the OP High alarm attributes Active OP High alarm occurs when ? RTN of active OP High alarm occurs when ?
are configured as?
RTN is not issued if after crossing the trip
point, the OP value returns to normal range
but again crosses the trip point. In addition,
the off-delay timer is reset when the OP value
crosses the trip point.
15.2.3 Impact of alarm priority change on alarm behavior

The following list illustrates the impact of alarm priority change on behavior of the alarms based on the
configured on-delay time and off-delay time.
• On-delay time is configured and the on-delay timer is active - The alarm shall be reported with the changed
priority after the expiry of the alarm delay time.
• Off-delay is configured and the corresponding alarm is active - The alarm is reported with the changed
priority, immediately. However, there is no impact to the off-delay timer. The RTN is reported after the
alarm delay time expires, as applicable.
15.2.4 Impact of migration on alarm attributes

Alarm delay timers are active during the controller on-process migration/controller switch-over.
When you perform server/controller migration from a pre-R410 release to R410, all alarm attributes configured
at function block level from prior releases are transferred to individual alarm.
For example, consider that the ALMTM value of the PID block is configured as 20 seconds before server/
controller migration to R410. In this scenario, after completion of server and controller migration to R410, the
deadband time for all alarms associated with the PID block is set to 20 seconds. Otherwise, if only server
migration is complete, the new alarm attributes are available in the configuration of each block. You can
configure those alarm attributes for your requirements only when the controller migration is complete. If you try
to configure the new alarm attributes without completing the controller migration, the following error message
appears.
“InvalidParameterBlank”
The alarm/RTN is reported only after the controller migration/switch-over based on the alarm condition. You
can reconfigure the attributes based on your alarm reporting requirements.
15.2.5 Impact of OUTIND parameter on alarm attributes

The alarm delay timer is reset whenever OUTIND parameter configuration is modified from any value to
“Reverse” or from “Reverse” to any other value. In addition, the existing reported alarm RTNs immediately
regardless of the off-delay configuration. However, the new alarm/RTN is reported only after the delay time
expires.
For example, consider that you have configured the OPHIALM.TM and OPLOALM.TM as 5 and 10 seconds
and OPHIALM.TMO as 3 seconds and you modify the OUTIND parameter configuration from “Reverse” to
“Direct.” In this scenario, the OPHIALM RTNs immediately though you have configured the off-delay as 3
seconds. However, the OPLOALM will be reported on the Station only after OPLOALM.TM expires.
221
16 I/O Link Interface
The I/O Link supports both the:

• C200/C200E controller: where the I/O Interface Module (IOLIM) seamlessly integrates the Process
Manager I/O subsystem consisting of Input/Output Processor card file, Input/Output Processors (IOPs) and
power supply with an Experion system. It lets user easily configure IOPs as part of a control strategy
through the system's Control Builder application.
The IOLINK connection for process Manager I/O can be established through C200/C200E controller and
IOLIM or C300 controller.
• C300 controller: where the IOLINK contains a function that enables programming and reprogramming the
executable image (rather than substitution of a removable hardware component).
PM I/O and Series C I/O cannot exist on the same link.
223
16 I/O LINK INTERFACE
16.1 I/O Functions

The function of the IOPs remains the same.
Process Manager I/O: in conjunction with Field Termination Assemblies (FTAs), the IOPs perform input and
output scanning and processing for field I/O.
Series C 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.
16.2 A word about Point form

A configurable parameter called Point Form (PNTFORM) let users decide whether an IOP point was to be a
Full or Component type point in a Process Manager environment. A Full point form meant that the point
would have alarm-related parameters. A Component point meant that the point should be used as an input to
the Full point, and also for those points that handle the outputs from the Full points. While the PNTFORM
parameter does appear on the IOP configuration forms in Control Builder, the default selection for most IOPs is
Component and it is not user configurable.
225
16.3 IOP validation

Database security is provided to prevent an operator form starting an IOP that has an invalid database. After
initial configuration each IOP must be set valid. Users with an engineer access level or higher can initiate the
validation check through the Validate IOP Database button on the Control Builder configuration form for an
IOP in the Monitoring mode. The IOP must have a valid database before it can be set to RUN.
16.4 I/O Link Cable Status and Statistics
Related topics
“Periodic swap functionality” on page 227
“Periodic swap transition diagram” on page 227
“Enabling periodic channel swap” on page 228
“Viewing cable status and statistics” on page 229
16.4.1 Periodic swap functionality

When the periodic channel swap function is enabled, it swaps the active receive channel at one minute intervals
to monitor its health and update its status as follows.
If Status is . . . Then, Cable is . . .

Ok Good. No errors detected during last pass of periodic channel swap.
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.
16.4.2 Periodic swap transition diagram

The following diagram illustrates the states and conditions associated with the periodic swap behavior and its
associated I/O Link Interface Module annunciations.
227
16.4.3 Enabling periodic channel swap

Use one of the following procedures to issue the enable command to the entire associated I/O Link or just the
selected IOP. These procedures assume that Control Builder is running and the control strategy is loaded.
The SWAP PRIMARY command is only allowed when the IOP partners are synchronized, the primary is
connected to a Field Termination Assembly (FTA) and the secondary is connected to a FTA.
To enable periodic channel swap for entire I/O Link

1 In the Monitoring tab, expand the hierarchy for the applicable IOLIM block and double click the IOLINK
icon to open its configuration form.
2 On the Main tab, click the arrow button in the COMMAND box and select ENB PRESWAP.
3 Click the Yes button to confirm the action.
4 Click the OK button to close the form.
5 This completes the procedure.
To enable periodic channel swap for selected IOP

2 Click the I/O Status Summary tab to open it.
3 Scroll the IOP/IOM Number grid to locate the applicable IOP/IOM number. Click the appropriate row in the
IOM Commands column. Click the arrow button in the row and select SWAP PRIMARY.
4 Click the Yes button to confirm the action.

16.4.4 Viewing cable status and statistics

You can view a variety of cable status data and statistics through the tabs on the I/O Link block configuration
form in the Control Builder Monitoring tab. This procedure assumes that Control Builder is running and the
control strategy is loaded.
To view channel/cable status and statistics parameters

2 Click the Statistics tab to check various link interface and performance related parameters. Click the Show
Parameter Names check box in the lower left-hand corner of the form to display the actual parameter name
associated with a field. Refer to the Control Builder Parameter Reference document to find a definition for a
given parameter.
3 Repeat Step 2 for the I/O Link Status and I/O Status Summary tabs.
229
17 Process Manager Input/Output Functionality
Related topics
“High and Low Level Analog Input Points” on page 232
“Smart Transmitter Interface Point” on page 237
“Analog Output Point” on page 245
“Digital Input Point” on page 247
“Digital Output Point” on page 254
231
17 PROCESS MANAGER INPUT/OUTPUT FUNCTIONALITY
17.1 High and Low Level Analog Input Points
Related topics
“Function of high and low level analog input points” on page 232
“PV Characterization” on page 234
“Linear Conversions” on page 234
“Square root conversion” on page 235
“Thermal conversion” on page 235
17.1.1 Function of high and low level analog input points

The analog input point converts an analog PV signal received from a field sensor to engineering units for use by
other data points in the control strategy, as shown in the following figure. To accomplish this function, the
analog input point performs the following functions.
• Analog-to Digital Conversion
• PV Characterization
• Range Checking and PV Filtering
• PV Source Selection
• Alarm Detection
High-level points are located in the High Level Analog Input (HLAI and HLAIHART) IOP. One type of low
level point is located in the Low Level Analog Input (LLAI) IOP. This type is generally used for control points.
The other type is located in either the Low Level Multiplexer (LLMUX) or the Remote Hardened Multiplexer
(RHMUX) IOP. This type is generally used for data acquisition points. The type of analog input point needed is
based on the type of field sensor that is providing the input to the point and the characterization options selected
by the user as listed in following table.
Sensor Type AI Processor PVCHAR PVRAW(1) PVCALC Bad PV Direction(2)

(SENSRTYP)
Type Options
0 to 5 Volts HL and LL Linear Percent EU Range check on
PVCALC
HL and LL Square Root
HL Thermocouple
HL RTD
0.4 to 2 Volts HL and LL Linear Percent EU Range check on
PVCALC
HL Thermocouple HLAI checks for open
input
HL RTD
1 to 5 Volts HL and LL Linear Percent EU Range check on
PVCALC
HL Thermocouple HLAI checks for open
input
HL RTD
Slidewire HL Linear RATIO EU(3) Bad slidewire source,
range check on
PVCALC
0 to 100 mV LL, LLMUX, Linear Millivolts EU(3) Range check on
RHMUX PVCALC
Thermo-couple LL, LLMUX, Thermocouple Microvolts EU Open thermocouple, and
RHMUX range check on
PVCALC
RTD LL, LLMUX RTD Milliohms EU Range check on
PVCALC
233
Sensor Type AI Processor PVCHAR PVRAW(1) PVCALC Bad PV Direction(2)

(SENSRTYP)
Type Options
Legend: EU = Engineering Units
• HL = High Level Analog Input, (Includes HLAIHART)
• LL = Low Level Analog Input
• LLMUX = Low Level Analog Multiplexer Input
• PVCALC = Calculated Process Variable
• PVCHAR = Process Variable Characterization
• PVRAW = Process Variable received from field and converted to digital form by the
• A/D converter.
• RHMUX = Remote Hardened Analog Input Multiplexer.
Notes:
1. PVRAW is the voltage signal at the IOP Field Termination Assembly as a percentage of the voltage range for the
sensor type. The exceptions are as follows:
a. For a thermocouple sensor type, PVRAW is in microvolts after reference junction compensation. If an open
thermocouple is detected, PVRAW is set to NaN.
b. For an RTD sensor type, PVRAW is in milliohms after lead-wire compensation. If an open RTD * is detected,
PVRAW is set to NaN.
c. An external power source is used to excite the slidewire. The power source and the slidewire are connected to
separate analog input points. One power source input can be used with several slidewire inputs.
For slidewire input, PVRAW is the slidewire ratio (Vin/Vsrc).
Where: Vin is the FTA voltage input for this data point (slot)
Vsrc is the FTA voltage source at the slidewire source slot specified by
parameter SLWSRCID. If Vsrc is zero (fails the under-range check), PVRAW
is set to NaN.
d. For a 0 to 100 millivolt sensor type, PVRAW is the FTA voltage input for the slot.
2. If the diagnostics determine that the A/D converter has failed, PVRAW of the slot is set to NaN.
3. The normal operating range for PVRAW is configured by the user (for a thermocouple, 0 percent equals PVRAWLO
and 100 percent equals PVRAWHI; for a slidewire, 0 equals PVRAWLO and 1 equals PVRAWHI).
* Note that LLMUX FTAs provide three wire terminations for each sensor. Open wire detection for RTDs is
limited in that the FTA will detect an open wire between the “A” and “C” leads, but not the “B” lead.
17.1.2 PV Characterization
The PV signal received from the field is characterized based on the entries that the user makes for the
SENSRTYP, PVCHAR, PVTEMP, INPTDIR, and TCRNGOPT parameters as shown in the previous figure.
The input PV signal is first converted to a raw PV signal (PVRAW) whose units can be percent, ratio, millivolts,
microvolts, or milliohms depending on the entry made for the SENSRTYP parameter. The PVRAW signal is
then converted to the engineering units. The engineering unit conversions that are performed in the HLAI,
HLAIHART, LLAI and LLMUX points are listed in the previous table and described in the following sections.
Tip
The LLMUX points include points built against the LLMUX IOP as well as the RHMUX IOP. The RHMUX does
not have a unique point type. The RHMUX IOP does not support RTD.
17.1.3 Linear Conversions

The PVRAW value is converted to a floating-point number the output value of the linear conversion is
PVCALC, which is calculated based on the raw input span (for slidewire and 0-100 mV sensor types only), and
the engineering unit span. The state of the input direction parameter (INPTDIR) is taken into consideration
during the calculation of PVCALC as follows:
• For slidewire and 0 to 100 millivolts sensor types, when INPTDIR is Direct:
• For 0 to 5 Volts, 0.4 to 2 Volts, and 1 to 5 Volts sensor types, when INPTDIR is Direct:
• For slidewire and 0 to 100 millivolts sensor types, when INPTDIR is Reverse:
• For 0 to 5 Volts, 0.4 to 2 Volts, and 1 to 5 Volts sensor types, when INPTDIR is Reverse:
17.1.4 Square root conversion

The square-root calculation is applied to the PVRAW input such that 100 percent of span equals 1.0 . The
square-rooted value is then converted to Engineering Units based on the configured PV engineering-unit range
values. (For example, square root of 100 percent equals 100 percent; square root of 50 percent equals
70.71percent.) The output value of the square-root conversion is PVCALC, which is calculated based on the
state of the input direction parameter (INPTDIR) as follows:
• If PVRAW is equal or greater than 0.0 and INPTDIR is Direct:
• If PVRAW is less than 0.0 and INPTDIR is Direct:
• If PVRAW is equal or greater than 0.0 and INPTDIR is Reverse:
• If PVRAW is less than 0.0 and INPTDIR is Reverse:
17.1.5 Thermal conversion

Thermal linearization is performed on thermocouple and RTD input types and is selectable by PVCHAR
parameter. The thermocouples and RTDs listed in the PVCHAR parameter are supported by the analog input
point.
235
The range of the thermocouple type used with the AI-LLMUX channel can be increased by selecting Extended
as the entry for the TCRNGOPT parameter. Refer to the Experion documentation for more information about
the normal and extended ranges.
The AI-LLMUX channels calculate the reference junction compensation from the measured reference junction
output level. This value is stored and then later converted back to micro volts, with respect to 0 degrees C, for
each thermocouple that is to be compensated. The cold-junction reference compensation (PVREFJN) parameter
is expressed in micro volts for the specified thermocouple and is added to the micro volt value for PVRAW.
Refer to PVEXEULO for normal and extended range details.
For an RTD, the AI-LLMUX channels calculate the lead-wire compensation and then subtract the value from
PVRAW. The maximum allowable lead-wire resistance and intrinsic safety barrier resistance for the RTDs are
listed in the following table.
Attention
Proper compensation for lead-wire resistance depends on the resistance being equal in each leg of the RTD. This
includes resistance due to lead-wire resistance and intrinsic safety barriers. No provision is made to compensate for
lead-wire resistance mismatch or intrinsic-safety-barrier resistance mismatch. Both the lead resistance and the
intrinsic-safety-barrier resistance are allowed simultaneously when connected to an RTD in a Division 1 area.
RTD Type Maximum Allowable Lead Maximum Allowable Intrinsic

Resistance Safety Barrier Resistance
Entire Loop Per Leg Entire Loop Per Leg
Pt: 100 ohm DIN Characterization 20 ohms 10 ohms 18 ohms 18 ohms
Pt: 100 ohm JIS Characterization 20 ohms 10 ohms 18 ohms 18 ohms
NI: 120 ohm Edison Type 7 Characterization 20 ohms 10 ohms 18 ohms 18 ohms
Cu: 10 ohm SEER Standard Characterization 20 ohms 10 ohms 0 ohm 0 ohm
17.2 Smart Transmitter Interface Point
Related topics
“Smart Transmitter support” on page 237
“Multivariable transmitter support” on page 237
“Transmitter parameters and database access” on page 238
“STI parameter comparisons” on page 238
“Transmitter communication mode” on page 239
“STI IOP commands” on page 239
“Point states” on page 240
“STI IOP functions” on page 241
“STI PV characterization” on page 241
“STI linear conversion” on page 242
“STI square root conversion” on page 243
“STI thermal conversion” on page 243
“STI PV range checking and filtering” on page 243
17.2.1 Smart Transmitter support

The Smart Transmitter Interface (STI) point provides an interface to Honeywell's family of Smart Transmitters.
The STI point can support the following Smart Transmitter types:
• ST3000 Smart Pressure Transmitter for differential, gauge, and absolute pressure measurements
• STT3000 Smart Temperature Transmitter for temperature, millivolts, and ohms measurements, and
• MagneW 3000 Smart Magnetic Flow Transmitter for flow measurements
The STI points are located on the STI IOPs. Each STI IOP has a maximum of 16 inputs, and it can
communicate bi-directionally with up to 16 Smart transmitters, regardless of the mix of transmitter types
(pressure, temperature, or flow) using Honeywell's Digitally Enhanced (DE.) protocol.
The bidirectional digital communication allows the user to configure, view, and modify the transmitter database
through the Analog Input Channel block associated with the STI IOP in the Monitor mode of Control Builder or
the IOP's Detail display in Station. This digital protocol allows a more precise PV value to be transferred,
thereby permitting more accurate control of the process. In addition, the transmitter can also send a secondary
variable such as the transmitter temperature, cold junction temperature, or totalized value, depending on the
transmitter type.
17.2.2 Multivariable transmitter support

The STIMV IOP supports all the Smart Transmitters listed above and multi-PV Smart Transmitter types such as
the following:
• SCM3000 Smart Flow Transmitter (Coriolis method)
• Drexelbrook SLT Level Transmitter
• SMV 3000 Multivariable Pressure Transmitter
• SGC 3000 Gas Chromatograph
An STIMV IOP allows up to four multi-PV transmitters or a mix of multi-PV and single PV transmitter inputs
that total no more than 16. A multi-PV transmitter is configured as if it were in “n” contiguous slots where
“n“ equals the number of PVs expected. The STITAG parameter value for each contiguous slot must be
identical.
237
17.2.3 Transmitter parameters and database access

The transmitter database can be configured through the Smart Transmitter tab on the Analog Input Channel
block's configuration form in Monitoring mode of Control Builder and loaded to the transmitter. The transmitter
database can also be uploaded to the STI IOP as required, when the STI point is in the inactive state. During
normal operation (when the STI point is in the active state), each time that the transmitter broadcasts the PV
value to the STI IOP, it also sends the one byte of its database (depending on the selected DECONF mode) to
the STI IOP. This allows the STI IOP to compare the stored database to the newly received database to check
for database mismatches. If a mismatch is detected, the PV is set to NaN and the status is set to DBChange. The
user can easily correct the discrepancy by downloading the database stored in the STI IOP.
As shown in the following figure, all key transmitter parameters can be accessed from the AI Channel block
configuration form. (The following illustration is used for example purposes only and reflects a Project mode
rather than a Monitor mode condition. )
17.2.4 STI parameter comparisons

The following table shows the comparison between parameters in the Smart Transmitter databases and those in
the STI IOP for reference. These parameters are accessible through the associated AI Channel block
configuration form with Control Builder in Monitor mode.
Smart Transmitter Database Corresponding STI Remarks

Parameter IOP Parameter
Upper Range Value and Lower URV Define the operating range of the transmitter. These values
Range Value correspond to the values for PVEUHI and PVEULO,
LRV
respectively.
Smart Transmitter Database Corresponding STI Remarks

Parameter IOP Parameter
Upper Range Limit and Lower URL These parameters are the respective built-in maximum and
Range Limit minimum limits of the transmitter and they cannot be changed.
LRL
The LRL is a read-only parameter. The URL must be
configured to match the URL value of the transmitter.
PV Damping DAMPING PV damping at the transmitter. Refer to “STI PV range
checking and filtering” on page 243.
Tag Identifier STITAG Transmitter identifier.
Software Version STISWVER Revision level of the software in the transmitter. This is a read-
only parameter.
Serial Number SERIALNO Serial number (PROM) of the transmitter. This is a read-only
parameter.
Secondary Variable SECVAR For a pressure transmitter, the secondary variable is the meter-
body temperature of the transmitter.
For a temperature transmitter, the secondary variable is the
cold-junction temperature.
For a flowmeter, the secondary variable is the totalized value.
This is a read-only parameter.
Linear / Square Root PVCHAR Refer to “STI PV characterization” on page 241.
Characterization
Communication Mode DECONF Refer to the following section.
Cold Junction Compensation CJTACT Applicable to STT 3000 only.
Active
17.2.5 Transmitter communication mode

You can select the transmitter's communication mode through the Digitally Enhanced Mode (DECONF)
parameter on the AI Channel block configuration form the possible selections are listed in the following table
for reference.
If DECONF Selection is . . . Then, Transmitter Communicates . . .

ANALOG nothing - selection is not supported.
PV only the Process Variable (PV) - 4-byte format.
PV_SV the PV and the Secondary Variable (SV) - 4-byte format.
PV_DB the PV and the database - 6-byte format.
PV_SV_DB the PV, SV, and database - 6-byte format.
Attention
We recommend using the PV_DB or PV_SV_DB mode, since they support database mismatch detection and on
process mismatch recovery.
17.2.6 STI IOP commands

You can issue the following commands through the Command (COMMAND) parameter on the Smart
Transmitter tab of the AI Channel block's configuration form. The Control Builder must be in Monitor mode
and the Point Execution State (PTEXECST) must be Inactive.
239
If Command Selection Is . . . Then, Action Initiated Is . . .

NONE none
DnLoadDb downloads the transmitter parameters from the STI point
database into the transmitter.
UpLoadDb uploads the transmitter database from the transmitter into
the STI point.
Set_LRV sets the Lower Range Value.
Set_URV sets the Upper Range Value.
Cor_LRV corrects the Lower Range Value.
Cor_URV corrects the Upper Range Value.
Cor_Inpt corrects the zero point for the Process Variable (PV).
RstCor sets all input calibration parameters to the default values.
Calibrate Refer to the Transmitter's User Manual.
ResetErr Refer to the Transmitter's User Manual.
Restart Refer to the Transmitter's User Manual.
Shutdown Refer to the Transmitter's User Manual.
17.2.7 Point states

You can view the status of the STI IOP and the transmitter through the Current State (STATE) read-only
parameter on the Smart Transmitter tab of the AI Channel block's configuration form. The following table lists
the possible states for reference.
If Current State Is . . . Then, Existing Condition Is . . .

None off net.
Loading loading of the database is occurring between the STI point
and the transmitter.
Loadcomp loading of the database between the STI point and the
transmitter has completed successfully.
Loadfail loading of the database between the STI point and the
transmitter has failed.
Calib the STI point is calibrating certain parameters at the
transmitter.
Calcomp calibration has completed successfully.
Calfail calibration has failed.
OK Normal State - The STI and the transmitter are okay.
Transmitter is updating the Process Variable (PV) value at
the STI point. State remains OK when the point is made
inactive.
DBChange a database mismatch exists between the STI point and the
transmitter. Transmitter is not updating the PV value at the
STI point. State remains DBchange when point is made
inactive
17.2.8 STI IOP functions

The STI IOP performs the following functions as illustrated in the following figure.
• PV Characterization
• Range Checking and PV Filtering
17.2.9 STI PV characterization

The PV signal (PVRAW) received from the transmitter has been characterized by the transmitter in terms of
linear or square root characterization and damping. For the STT 3000, PVRAW is further characterized based
on the entries that the user makes for the SENSRTYP, PVCHAR, and INPTDIR parameters as shown in the
previous figure. The following table lists the PV characterization options available for the various transmitter
(sensor) types.
Transmitter (Sensor) Type PVCHAR Options PVRAW(1,3) PVCALC PV Detection(2)

(SENSRTYP)
Spt_Dp (Differential Linear Percent in Water EU Range check on PVCALC
Pressure)
Square Root
Spt_Gp (Gauge Pressure) Linear Percent in Water EU Range check on PVCALC
Spt_Ap (Absolute Pressure) Linear Percent in Water EU Range check on PVCALC
Stt (Temperature)(4) Linear Percent Millivolts EU Range check on PVCALC
241
Transmitter (Sensor) Type PVCHAR Options PVRAW(1,3) PVCALC PV Detection(2)

(SENSRTYP)
Thermocouple Percent degrees C EU Open thermocouple
detection, and range check
on PVCALC.
RTD Percent degrees C EU Range check on PVCALC
RTD Ohms Percent Ohms EU Range check on PVCALC
Sfm (Flow) Linear Percent cubic meters EU Range check on PVCALC
per hour
Legend: EU = Engineering Units
• PVCALC = Calculated Process Variable
• PVCHAR = Process Variable Characterization
• PVRAW = Process Variable received from transmitter and multiplied by 100 by the
• STI IOP.
Notes:
1. PVRAW is a percentage of the configured range for the sensor type. For Multivariable transmitters, PVRAW
Engineering Units are different for each PV slot.
2. If the transmitter gross status indicates Output mode or Bad, PVRAW of the STI point is set to NaN, and PVSTS is set
to Bad.
3. The normal operating range for PVRAW (0 percent equals PVRAWLO, 100 percent equals PVRAWHI) is configured
by the user.
4. For the supported temperature ranges, refer to the definition of the PVCHAR parameter in the Control Builder
Parameter Reference.
17.2.10 STI linear conversion

If the entry for PVCHAR is Linear, the PVRAW input from the FTA is calculated as a proportion of the input
span in percent, as determined from upper and lower range values URV and LRV. This proportion is then used
in generating an identical proportion of the output span, as determined from PVEULO and PVEUHI shown in
the following figure. The URV and LRV values are the 100 percent and 0 percent values that correspond to the
PVEUHI and PVEULO values, respectively.
17.2.11 STI square root conversion

If square root is selected, this function is performed by the smart transmitter in its computation of PVRAW. The
value for PVCALC is then determined in the same manner as linear conversion. These conversion equations are
provided below.
• For INPTDIR = Direct:
• If INPTDIR = Reverse:
17.2.12 STI thermal conversion

Thermal linearization is available for the thermocouple and RTD inputs of the Stt (temperature) transmitter.
Thermal linearization is selectable by parameter PVCHAR.
The STI point calculates the reference junction compensation from the measured reference junction output
level. This value is stored and then later converted back to millivolts, with respect to 0 degrees C, for each
thermocouple that is to be compensated. The external cold-junction reference compensation (CJTACT)
parameter is expressed in millivolts for the specified thermocouple and is added to the millivolt value for
PVRAW.
For an RTD, the STI point calculates the lead-wire compensation and then subtracts the value from PVRAW.
17.2.13 STI PV range checking and filtering

PV range checking ensures that the PVCALC output of PV characterization is within the limits defined by
parameters PVEXEULO and PVEXEUHI. If either of the limits is violated, the output of the range check is set
to BadPV if clamping has not been specified. If clamping has been specified, the output of the range check is
clamped.
If the range-checked and filtered value is less than the value specified by the user-configured LOCUTOFF
parameter, the final output called PVAUTO is forced to PVEULO.
PV filtering can be implemented at the STI IOP, or at the Smartline Transmitter. At the STI IOP, first-order
filtering is performed on PVCALC, as specified by the user through parameter TF (filter lag time). At a
transmitter, filtering is performed on the PV depending on the value entered for the DAMPING parameter using
the SFC. The user should decide the type of filtering required based on the following guidelines:
• The DAMPING parameter allows for better control accuracy because more PV samples are used in
calculating the filtered PV value at the transmitter.
• TF can be changed on-process from the DI Channel block configuration form. To change the DAMPING
value requires the point to be made inactive and requires the database to be downloaded to the transmitter
after the change has been made.
For better control accuracy, the use of the DAMPING value is preferred over the TF value. The transmitter
accepts only certain DAMPING values from the STI IOP, and the value received must first be converted to one
of the predefined DAMPING values that reside in the transmitter. This conversion is accomplished
automatically by the STI IOP by finding the DAMPING value that is nearest to the desired DAMPING value.
DAMPING values differ between the Smartline Transmitters. The valid DAMPING values for each transmitter
type are contained in the following table.
Valid DAMPING Values in Seconds

Pressure (Spt) Temperature (Stt) Flow (Sfm)
243
Valid DAMPING Values in Seconds

0.0 0.0 0.0
0.16 0.3 0.5
0.32 0.7 1.0
0.48 1.5 2.0
1.00 3.1 3.0
2.0 6.3 4.0
4.0 12.7 5.0
8.0 25.5 10.0
16.0 51.1 50.0
32.0 102.3 100.0
17.3 Analog Output Point
Related topics
“AO functions” on page 245
“AO direct/reverse output” on page 245
“AO output characterization” on page 246
“AO calibration compensation” on page 246
17.3.1 AO functions
The analog output point converts the output value (OP) to a 4-20 mA output signal for operating final control
elements such as valves and actuators in the field. The OP parameter value can be controlled from a regulatory
function block contained in a Control Module. To convert the OP value to a 4-20 mA signal, the analog output
point performs:
• Direct/reverse Output Function
• Nonlinear Output Characterization
An option allows redundant Analog Output points. The following figure is a functional diagram of the analog
output point.
17.3.2 AO direct/reverse output

Parameter OPTDIR allows the user to specify whether the output of the data point is direct acting (where 4 mA
equals 0 percent and 20 mA equals 100 percent or reverse acting (where 4 mA equals 100 percent and 20 mA
equals 0 percent). The default mode is direct acting.
245
17.3.3 AO output characterization

Output characterization allows the user to specify an output transfer function, using configurable X-Y
coordinates that provide five linear segments as shown in the following figure. The length of each segment is
variable according to the coordinates that can be entered as applicable constants for OPOUT1-4 and OPIN1-4
parameters, which are real numbers.
As shown in the following figure, the end points of the curve are fixed at coordinates OPOUT0,OPIN0 (at -6.9
percent) and OPOUT5,OPIN5 (at 106.9 percent). These coordinates are fixed at these values to ensure that
neither the characterization function nor its inverse can provide output values, which are outside the -6.9 to
106.9 percent range.
17.3.4 AO calibration compensation

The final stage of output processing in the analog output point is calibration compensation. This is
accomplished in the data point using internal offset and scale constants. The output value OPFINAL is then
routed to the field through the appropriate FTA.
Attention
Slot or module level soft failures can prevent a point (or points) from outputting to the field. The regulatory control
point will initiate a “Bad Output“ alarm (If configured) when any connection is broken. If all configured point
connections to the field are broken, the regulatory control point driving that analog output slot goes into initialization.
17.4 Digital Input Point
Related topics
“DI functions” on page 247
“DI status point” on page 248
“DI PV source selection” on page 248
“DI off-normal alarming” on page 248
“Alarm delay” on page 249
“Event reporting” on page 250
“DI latched input point” on page 250
“DI sequence of events point” on page 250
“SOE definitions” on page 250
“SOE resolution considerations” on page 251
“DI SOE configuration considerations” on page 251
17.4.1 DI functions
A digital input point converts a digital PVRAW signal received from the field to a PV that can be used by other
data points in the control strategy. A functional diagram of the digital input point is shown in the following
figure.
Control strategies can test for a bad Digital Input PV. Parameter BADPVFL is set ON when:
• The PV source has been switched to Substituted, and the point is inactive or the module status is Idle.
• The PV source is AUTO and the PV is not being updated, because either the point is inactive, the module is
idle, there is a slot soft failure, or the FTA is missing.
The digital input point is a single-input point that can be configured as a status input or a latched input, as
described in the following sections.
247
17.4.2 DI status point

For this digital input type, the PVAUTO value represents the state of the raw input signal after the direct/reverse
conversion is performed. The status digital-input point can be configured for PV source selection, detection of
off-normal alarms, and for reporting any PV state changes to the system. The status digital input point is
selected by entering Status for the DITYPE parameter.
The current state of the PV input is represented on the Station Detail Display as an indicator light. The lights are
lighted or extinguished depending on the current state of PVRAW and the input direction as configured through
the INPTDIR parameter. The current PV state is also available to be used as an input to logic slots, and other
Control Builder control functions.
17.4.3 DI PV source selection

The PV source parameter (PVSOURCE) option determines the source of the PV for a status input point. The
source can be the PV input from the field (PVAUTO), the PV state entered by the operator (PVman), or it can be
supplied by a user program (PVsub). PVSOURCE has no effect on the latched and accumulation options of the
digital input point. If PVSOURCE is PVAUTO, PV tracks PVRAW.
17.4.4 DI off-normal alarming

Off-normal alarming can be selected for the digital input point through the ALMOPT parameter. An off-normal
alarm is generated when the input PV state is different than the configured normal (desired) state for the point as
specified by the PVNORMAL parameter.
Digital Input Status points (and Sequence of Events points) can be configured for Change Of State (COS) alarm
reporting through the ALMOPT parameter. The alarm is generated when the input changes state in either
direction.
COS alarms are removed from the Alarm Summary display following acknowledgement. The Point does not
remain in alarm so there is no Return-to-Normal. Point Detail or Group displays will never show a point in COS
alarm.
Older digital input IOPs may need to have a new firmware chip for COS reporting. Check the IOP's detail
display. For COS reporting the Digital Input IOP firmware revision must be 5.0 or later.
Note that when a point with COS reporting is changed from Inactive to Active, a COS alarm is generated if the
PV equals 1. There is no COS alarm if the PV equals 0. The same alarming occurs if the point is active and the
IOP is put into Run mode.
17.4.5 Alarm delay

When off-normal alarming has been configured and an off-normal alarm is detected, the event is reported to the
system. Further off-normal alarms for the same data point are not reported until the time delay specified by the
DLYTIME parameter expires. When the time delay expires, the time-delay function is disabled and the off-
normal alarm for the data point can again be reported.
When Change Of State alarm has been configured you observe that the COS alarm is reported only when the
time delay expires. If there is a state change before the configured delay time expires the timer is reset and COS
alarm is reported once the delay time expires as shown in scenario 1 in the following figure.
249
17.4.6 Event reporting

The EVTOPT parameter for the status input allows the user to optionally specify that a time stamp be added to
the reported PV state change. For a status input point, EVTOPT has the two possible entries: None or SOE. The
SOE specifies that a time stamp is added to the PV state change to establish a sequence of events.
17.4.7 DI latched input point

To capture the occurrence of momentary digital inputs, such as from pushbuttons, requires the user to configure
the digital input point as a latched digital input point. Configuring the point as a latched point is accomplished
by entering Latched for the DITYPE parameter.
When configured as a latched input point, an input pulse that is on for a minimum of 40 milliseconds is latched
true for 1.5 seconds. This ensures that any control function that needs to monitor this event will execute at least
once during the time that the signal is latched on.
The current state of the latched PV input is represented as indicator light on the Station Detail display. The
lights are lighted or extinguished depending on the current state of PVRAW and the input direction as
configured through the INPTDIR parameter. The current PV state is also available to be used as an input to
other control strategies. .
17.4.8 DI sequence of events point

Sequence of Events (SOE) points are used to report the order of occurrence of digital state changes. The SOE
digital input IOPs can use the same type FTAs as digital input cards, but the best overall performance is
obtained when using the high resolution 24 Vdc Digital Input FTAs.
SOE events are recorded in a journal with a timestamp so that you can determine, for example, which event
started an upset and the progression of events thereafter. The record includes the point ID, point descriptor, state
text unit, and time of occurrence to one millisecond resolution.
17.4.9 SOE definitions

In practice, the capture of physical digital state changes is less precise than the nominal 1 millisecond time
stamping that is degraded by other system factors. This means that time stamps in logs must differ by multiple
milliseconds before the correct order can be determined. The following definitions will be helpful reference in
applying the specifications associated with SOE generation in the IOP and I/O Link Interface Module (IOLIM).
Term Definition
Resolution (Tres) The smallest increment of real time that can separate two consecutive
SOE time-stamped events. The resolution of the field-connected
equipment which first stamps an event limits the inherent resolution of
the system.
Sequence Stamp Difference (SSD) The minimum difference in logged time stamps that guarantees the
order of two time stamps.
Minimum Physical Event Separation (MPES) The smallest interval between two ideal (bounceless) physical events,
so the events can be correctly ordered by the Sequence Stamp
Difference.
Skew (Tskew) The sum of all factors which cause differing time stamps to be applied
to the same physical event, if wired into two different places in the
system.
17.4.10 SOE resolution considerations

The IOLIM synchronizes the I/O Link every 2 seconds. Consider the following values when determining SOE
resolution. In general terms, the resolution is X milliseconds; the time stamps that differ by Y milliseconds or
more indicate true event sequence; and real-world events must occur Z milliseconds or more apart to be
assigned time stamps that differ by Y milliseconds.
For points in one IOP
• Skew: 0+0.2+0.04+0.2+0.2+0.1+0.5 = 1.24 msec
• SSD: N = 7, (7+1) * 0.200 = 1.6 msec
• MPES: 1.6 + 1.24 = 2.84 msec
For points in one IOLIM
• Skew: 0+0.2+0.04+0.2+0.2+0.2+0.5 = 1.34 msec
• SSD: N = 7, (7+1) * 0.200 = 1.6 msec
• MPES: 1.6 + 1.34 = 2.94 msec
For points in redundant IOLIMs
• Skew: 0.5*+0.4+0.04+0.2+0.2+0.2+0.5=2.04
• SSD: N = 11, (11+1) * 0.200 = 2.4
• MPES: 2.4 + 2.04 = 4.44
*Estimated value.
This means that time stamps that differ by 2, 2, 3 milliseconds in the SOE journal show order for events that
differ by 3.8, 3.8, 5.8 milliseconds, respectively.
The specification for the Sequence Stamp Difference (SSD) and the Minimum Physical Event Separation
(MPES) can be updated on completion of the Unit or FIT test for the following cases.
• Two events within the same DI-SOE module.
• Two events within the same C300 IOLink using multiple DI-SOE modules.
• Two events within the same C300 (different IO Links) using multiple DI-SOE modules.
17.4.11 DI SOE configuration considerations

Digital input SOE IOP points are configured through configuration tab of the DI Channel block for loaded
control strategy and Control Builder in Monitoring mode. The configuration considerations are similar to those
described for the conventional digital input point with the following additions for events, as shown in the
following figure. (The following illustration is used for example purposes only and reflects a Project mode
rather than a Monitor mode condition.)
251
Choose STATUS as the Digital Input Type (DITYPE). You can use the DISOE IOP as a conventional digital
input, if you choose LATCHED.
The Contact Debounce time (DEBOUNCE) parameter specifies the time interval used to debounce an input
from mechanical contacts of a field input source. It is defined as the length of time following an input state
change during which the input must remain unchanged in the new state to declare it a valid event. DEBOUNCE
has a range of - 50 milliseconds in one-millisecond increments. The default value of 10 ms should suffice for
most contacts. If not, choose a value slightly longer than the manufacturer's specified contact bounce time.
The following figures illustrate the debounce operation.
This waveform represents the field input. Tick marks across the waveform indicate the 200 microsecond scan
intervals of the DISOE IOP hardware. Assume that the input state changes at point A.
At point B, the state change is detected. At this point, the current time and old state are recorded. The debounce
timer is started.
• If the input remains at a steady state until the debounce timer expires, then an event is generated with a
timestamp corresponding to the time of detection (point B).
• If the input changes before the debounce timer expires (point c), then the change of state event detected at B
is discarded, the timer is restarted and runs for the full debounce time:
– If a new input detected at D remains in a steady state until the debounce timer expires (point F), then an
event is generated with a timestamp corresponding to the original time of detection (point D).
– If the input has returned to the old state (dotted line at E) when the debounce timer runs out (point F), no
event is generated.
The PV Hold Delay (PVCHGDLY) parameter specifies the time of separation in seconds for reporting two
consecutive PV change events from the same input source. It is intended to prevent repeated rapid reporting of
PV change events (i.e., chattering). It can be configured over a 0 to60 second range in one second increments. It
applies to points configured as SOE only. Ideally, PVCHGDLY and DLYTIME should have the same value.
When a PV state change is detected, the change is reported and the PV change delay timer is started.
• If the PV does not change before the delay timer runs out, no further action is taken.
• If the PV state changes only once before the delay timer runs out, this second event is noticed and time
stamped with the actual time of detection, but it is not reported until the delay timer expires.
• If the PV state changes more than once before the PV change delay timer runs out, only the last state change
is noticed and time stamped but not yet reported. When the delay timer expires:
– If the PV state is different from the state that started the timer, this event is reported.
– If the PV state is the same as the original PV state that started the timer, no event is reported.
253
17.5 Digital Output Point
Related topics
“DO functions” on page 254
“Pulse Width Modulated (PWM) Output Type” on page 255
“Status Output Type” on page 255
“Initialization request flag” on page 255
17.5.1 DO functions
The digital output point provides a digital output to the field based on the origin of the input and the configured
parameters. A functional diagram of the digital output point is shown in the following figure. The digital output
point does not have any modes.
There are two types of digital output points: pulse-width modulated (PWM) output and status output. Selection
of the output type is accomplished through the DOTYPE parameter shown in the previous figure. The PWM
type is used in combination with regulatory control block algorithms to provide true proportional control. The
status type output is the normal configuration for digital outputs that are linked to Device Control block points.
Actual output action can be status, latched or momentary, depending on the configuration of the Device Control
point. The default for untagged component DO points is Status.
17.5.2 Pulse Width Modulated (PWM) Output Type

The pulse width modulated output type can receive its input from a regulatory PID block through a user-
configured output connection. The length of the pulse is derived from the OP parameter provided by the
regulatory point. Because OP is in percent, the percent value becomes the percent on time for the pulse whose
period (1 to 120 seconds) is specified by the PERIOD parameter, as shown in the timing diagram in previous
figure.
The output direction of the output signal can be configured to be direct or reverse acting by using the OPTDIR
parameter.
The pulse on time for direct and reverse acting outputs is calculated as follows:
For direct action:
For reverse action:
If the value of OP is less than 0 percent, it is clamped to 0 percent; an OP with a value greater than 100 percent
is clamped to 100 percent.
17.5.3 Status Output Type

The status output type can be controlled from a Device Control block output, a logic slot output, or a Position
Proportional block, as determined by the output connection. The output latch function is obtained by linking
Device Control block output connections to the SO parameter. Pulsed operation (pulse-on or pulse-off) can be
obtained by linking the output connections to the ONPULSE and OFFPULSE parameters, respectively.
The ONPULSE parameter sets SO to On for the specified duration. At the end of the pulse time, SO is set to
Off. If ONPULSE is specified as 0.0, SO is immediately set to Off. This also applies to the OFFPULSE, except
that the OFFPULSE sets SO to Off.
If SO is received from a logic slot, the SO output of the digital output point tracks the SO output provided by
the logic slot.
17.5.4 Initialization request flag

When ON, this parameter indicates (for Status Output type points) that control strategies in the Controller
cannot manipulate the output. Parameter INITREQ is set ON when:
• a PWM type output is configured
• a Status Output type is configured and:
– the point is inactive
– the module is idle
– there is a soft failure such that the point is not working.
255
18 Component Categories and Types
Related topics
“About categories” on page 258
“Function block types and data organization” on page 259
257
18 COMPONENT CATEGORIES AND TYPES
18.1 About categories

For data organizational purposes, we divide the Control Builder components into these two major categories:
• Hardware Relation Category
• Functional Relation Category
These categories are explained in the Experion Control Builder Components Reference in Hardware Relation
Category and Functional Relation Category. In brief, the Hardware Category consists of self-standing type
blocks and the Functional Category consists of container and component type blocks. Note that self-standing
type blocks are referred to as physical equipment type blocks, and container and component type blocks are
referred to as functional type blocks.
18.2 Function block types and data organization

The remainder of this document is organized according to the following grouping of function block types.
• “Regulatory Control” on page 261
• “UCN Interface” on page 667
• “Exchange Functions” on page 685
• “Auxiliary Functions”
• “Data Acquisition Functions” on page 785
• “Pulse Input” on page 805
• “Device Control” on page 815
• “Logic Functions” on page 843
• “Math Functions” on page 897
• “Power Generation Functions”
• “Utility Functions” on page 1049
• “Sequential Control” on page 1093
• “Thermodynamic Utility Functions” on page 1019
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 Control Builder Components Reference.
259
19 Regulatory Control
Related topics
“Regulatory Control Blocks” on page 262
“About Safety Interlock Function” on page 278
“About Red Tagging” on page 280
“AUTOMAN (Auto Manual) Block” on page 281
“ENHREGCALC (Enhanced Regulatory Control Calculator) Block” on page 300
“FANOUT Block” on page 330
“OVRDSEL (Override Selector) Block” on page 349
“PID Block” on page 369
“PID-PL (Profit Loop PKS) Block” on page 402
“PIDER (PID with External Reset Feedback) Block” on page 433
“PIDFF (PID with Feedforward) Block” on page 462
“LEGACYGAP Option in R300” on page 495
“POSPROP (Position Proportional) Block” on page 498
“PULSECOUNT Block” on page 516
“PULSELENGTH Block” on page 519
“RAMPSOAK Block” on page 522
“RATIOBIAS Block” on page 539
“RATIOCTL (Ratio Control) Block” on page 558
“REGCALC (Regulatory Control Calculator) Block” on page 580
“REEOUT (Remote EEOUT) Block” on page 605
“REGSUMMER (Regulatory Summer) Block” on page 608
“REMCAS (Remote Cascade) Block” on page 625
“SWITCH Block” on page 647
261
19 REGULATORY CONTROL
19.1 Regulatory Control Blocks

Note:With R410, you can configure on-delay time, off-delay time, deadband, and deadband units, for each
alarm in the REGCTL block such as AUTOMAN, PID, PID-PL, and so on.
Experion Regulatory Control blocks offer a veritable “toolkit” of process control functions. Each block is
configured to perform a single control function, and multiple blocks may be connected to form complex control
strategies.
The following table presents the various functions that can be performed through the configuration of the
associated Regulatory Control block.
Function Block Description

Auto Manual “Tuning Conversions from Provides a “bumples” output following initialization or
Interactive to Non- mode changes; typically used in a cascade where one of the
Interactive PID” on upstream blocks may not accept an initialization request.
page 276
Enhanced Regulatory Control “ENHREGCALC Provides enhancements over the REGCALC block. The
Calculator (Enhanced Regulatory enhancements include:
Control Calculator) Block”
• Expands existing arrayed input parameters XSTS and X
from six to ten.
• These arrayed parameters are added to correspond to
each of the ten inputs.
– Input Description
– Enable/Disable Switch
– XSUB Substitute Parameter
See the block section for other enhancements.
Fanout “FANOUT Block” Sends one input to many outputs, whereby a different gain
and bias may be assigned to each output.
Override Selector “OVRDSEL (Override Selects one input from many based on the highest or lowest
Selector) Block” input value; the OVRDSEL block always forces the
unselected inputs to track the selected inputs, but provides
two methods for doing so:
• Propagate override feedback data to the unselected
inputs.
• Continually initialize the unselected inputs.
Proportional, Integral & “PID Block” Provides an implementation of the PID algorithm, using the
Derivative Ideal form, whereby the following combinations of control
terms may be configured:
• Proportional-only (acts on the error PV -SP)
• Integral-only (acts on the error PV -SP)
• Proportional & integral (act on error PV - SP), &
derivative (acts on changes in PV)
• Proportional & derivative (act on changes in PV), &
integral (acts on the error PV - SP)
• Proportional, integral & derivative (act on the error PV -
SP)
Proportional, Integral & “PID-PL (Profit Loop PKS) Provides PID control using a model predictive control
Derivative with Profit Loop Block” package called Profit Loop PKS that incorporates robust
PKS control techniques to enhance control performance despite
process model uncertainty and measurement error.

Proportional, Integral & “PIDER (PID with External Operates as a proportional-integral-derivative (PID)
Derivative with External Reset Feedback) Block” controller that accepts a reset feedback signal, a tracking
Reset Feedback value, and a tracking control switch. It supports the same
Ideal form of calculating the PID terms as the PID block. It
also prevents windup when the secondary does not
propagate windup status or control initialization data back
to the primary of a remote (foreign) controller
Proportional, Integral & “PIDFF (PID with Provides the same classic PID function as outlined above
Derivative with Feedforward Feedforward) Block” with the ability to accept a “feedforwar” signal. You can
configure the feedforward signal to be added to or
multiplied by the PID's incremental output to meet varying
control requirements.
Position Proportional Control “POSPROP (Position Provides two digital outputs for pulse control of a final
Proportional) control element. It accepts process variable (PV) and set
Block”Proportional) Block point (SP) inputs.
Pulse Count “PULSECOUNT Block” Provides pulse waveform generation on its four main
outputs using a pulse control algorithm that relates the
waveform to the configurable period and requested pulse
time parameters. Typically, used in conjunction with a
POSPROP block.
Pulse Length “PULSELENGTH Block” Provides pulse waveform generation on its four main
outputs using a pulse control algorithm that relates the
waveform to the requested pulse time parameter. Typically,
used in conjunction with a POSPROP block.
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 and Bias “RATIOBIAS Block” Provides a calculated output based on the ratio of the input
variables plus a fixed and/or a floating bias. Typically, used
between two PID blocks to implement a form of ratio
control.
Ratio Control “RATIOCTL (Ratio Accepts the actual value of the controlled flow (X1), the
Control) Block” 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
flows (PV) as outputs.
Regulatory Control Calculator “REGCALC (Regulatory Lets you write up to eight expressions for creating custom
Control Calculator) Block” algorithms for Calculated Variable (CV) calculations.
Provides an interface to windup, initialization and override
feedback processing, so you can add user-defined control
blocks to your control strategies.
Remote EEOut “REEOUT (Remote Used in conjunction with the Inter Cluster Gateway to
EEOUT) Block” support regulatory cascades between ACE nodes residing in
two separate Experion clusters.
Regulatory Summer “REGSUMMER Calculates an output value which is the sum of up to four
(Regulatory Summer) inputs. Each of the inputs may be individually scaled. The
Block” output may be scaled by an overall gain, and an overall bias
may be added to the result.
Remote Cascade “REMCAS (Remote Provides automatic switching between a primary (remote)
Cascade) Block” and backup (local) cascade; typically used with a PID that
normally gets its set point from a remote source, but sheds
to a local source when the remote cascade is broken.
263

Switch “SWITCH Block” Operates as a single-pole, 8-position rotary switch that may
be positioned by the operator, user program or another
block. Typically used to assign different primary to a
secondary; allows user to select one from as many as 8
inputs and outputs the selected value.
19.1.1 Common regulatory control functions for C200/C200E and ACE controllers without insertion
points
Attention
The Regulatory Control blocks can interact with Sequential Control Modules (SCM) to provide interactive control
action. Refer to the Sequential Control Module User's Guide for more information on this function.
Listed below are the major functions performed by all Regulatory Control blocks along with a brief functional
description for each. Functional descriptions for each block are given in the following subsections.
Major Function Description

Input Processing Provides these functions for all Regulatory Control function blocks to be used as
needed.
PV Processing - Regulatory control blocks that have PV input use this function to
fetch the input value, status, and update the appropriate PV parameters.
SP Processing - Regulatory Control blocks that have a SP input use this function for
SP limit checking.
SP/PV Processing - Regulatory Control blocks that have SP and PV inputs use this
function for SP target value processing, PV tracking, deviation alarming, and
advisory deviation alarming. These functions are configurable.
PUSHSP Parameter Processing - You can use the PUSHSP parameter only to enable
SP value to be pushed from another block. This parameter helps in configuring
cascade control offering of inter-cluster peer-to-peer regulatory controls. When the
PushSP option is enabled on the block, no wired or parameter reference connection
should be made to the SP pin on the block.
Mode Processing “Mode” identifies who may store to certain Regulatory Control parameters (for
example, SP and OP). Possible choices of who may store are the operator, another
function block, or a user program. Mode Processing checks for the following
conditions and sets the mode as appropriate:
External requests for mode switch, and
Mode switch requests due to safety interlocks
Initial Control Processing If a Regulatory Control block is in a Cascade strategy, this function checks if the
cascade has been broken. If it has, this function initializes the block and builds an
initialization request for its primary or primaries.
Algorithm Calculation This involves calculations that are unique to each Regulatory Control block (for
example, PID calculation). These calculations are described more fully for each
individual block in the remainder of this section.
Output Processing This function derives the control output (OP) from the algorithm's calculated
variable (CV). Among other things, it applies an output bias, compares against
output limits, and if necessary, clamps OP to those limits. This function also
performs OP limit alarming.

Feedback Propagation If a Regulatory Control block is in a cascade strategy, this function may propagate
windup, initialization and override information to upstream blocks. This information
is used to constrain the output of the upstream blocks when a limiting condition
exists downstream. Windup status is used by PID blocks to turn integral control on
or off; and override is used to prevent windup when an output of a PID has been
disconnected from the process (by an OVRDSEL block).
19.1.2 Common regulatory control functions for ACE controllers with insertion points
In systems running R210 or greater, you can insert Control Algorithm Block (CAB) programs at the following
predefined locations in a regulatory control block that is associated with a control strategy to be run in an ACE
Controller.
Insertion Type Description

Post_Input Insert CAB instance after input processing
Pre_Alg Insert CAB instance before the execution of the algorithm.
Ctl_Alg Insert CAB instance to replace the regulatory control algorithm.
Post_Alg Insert CAB instance after algorithm processing.
Post_Ctlout Insert CAB instance after the execution of control output processing.
The following illustration shows where you can insert CAB programs in relation to the regulatory control
block's major functions. This means that you can use CAB programs to enhance aspects of the block's execution
but still take advantage of the more complex system functions such as initialization, anti-reset windup, range-
checking and alarming integral to the native block.
265
Table 7: CAB insertion locations in regulatory control block major functions
19.1.3 CAB insertion configuration considerations for regulatory control blocks

• You cannot use CAB insertion programs with the following Regulatory Control blocks.
– POSPROP
– PULSECOUNT
– PULSELENGTH
– REGCALC
• You can insert up to 10 CAB programs in a regulatory control block.
• 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 that of 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 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 Regulatory Control block.
19.1.4 Insertion type functional characteristics for regulatory control blocks

The following table summarizes the functional characteristics for a given insertion type.
Insertion Type Function

Post Input (Post_Input) Provides the capability of performing custom functions such
as:
• Custom calculations on inputs,
• Custom timeout processing function, and
• Enable/disable external mode switching based on input
values.
It is normally used to perform calculations on the fetched
input data. This means that Post Input insertion programs
must check if the fetched input data is valid before using the
data in calculations. The fetched data is valid only if the
associated input status is Normal. For example, before
performing calculations using X1, the parameter X1STS
should be checked for Normal status. If the status is not
normal, the fetched X1 value is not valid.
Pre Algorithm (Pre_Alg) Provides the capability of implementing custom
initialization strategies..
Control Algorithm (Ctl_Alg) Provides the capability of replacing the standard regulatory
control block algorithm with user custom one written in a
CAB program.
If you use a CAB program as the algorithm, the program
must calculate and store the Regulatory Control point output
value CV. You must use parameter references in the CAB
instance to acquire inputs for the CAB program. You should
include the following items in the algorithm program:
• Bad input handling (CV gets set to bad when input is
bad).
• CV calculation for the various control states
(FORWARD, MAN and INIT).
• INITVAL calculation.
• Override feedback handling, if the block is part of an
override strategy.
• Input timeout processing, if required.
• Floating bias implementation, if output transfers are to
be bumpless.
See the following paragraph Functional requirements for
custom CAB algorithm for regulatory control block for more
information.
Post Algorithm (Post_Alg) Provides the capability of implementing custom calculation
for output values.
267

Post Control Output (Post_Ctlout) Provides the capability of implementing custom windup
calculations. You can use parameters ARWNETIN and
ARWOPIN to modify windup states.
19.1.5 Functional requirements for Custom CAB algorithm for regulatory control block
The following table summarizes the functional requirements you need to consider when creating a custom CAB
algorithm for a 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.
The regulatory control block algorithm generates a BADCTL alarm during control
output processing when CV is NaN.
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.
Windup The CAB program must set the COMPUTEARW parameter to True to initiate
recomputation of windup when process conditions change.
The windup state of the regulatory control block is computed after the control output
has been computed.
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 IF PRIM.INITIALIZABLE { if primary is initializable}

PRIMDATA.OROFFSET = SECDATAIN.OROFFSET PRIMDATA.HISELECT =
SECDATAIN.HISELECT
PRIMDATA.PROPOVRD = TRUE IF ORFBSTS = NOTSELECTED{If the override
status is not selected } PRIMDATA.ORFBVAL = SECDATAIN.ORFBVAL
Calculate
ORFBVAL for primary and store the value in PRIMDATA.ORFBVAL ELSE{if
the status is selected } PRIMDATA.ORFBVAL = NaN IF CV = Nan {if the
CV value is bad, propagate Notconnected status and a feedback value
of NaN } PRIMDATA.ORFBSTS = NOTCONNECTED PRIMDATA.ORFBVAL = NaN
ELSE{
If CV is good, propagate the status received from secondary }
PRIMDATA.ORFBSTS
= SECDATAIN.ORFBSTS END
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.
The standard regulatory control block algorithms store the calculated floating bias
value in the parameter OPBIAS.FLOAT. This parameter allows CAB write access, so
it is available for use in CAB programs.
Timeout If the input timeout function is needed, the CAB program must implement the timeout
processing as part of the program.
19.1.6 CAB insertions for Regulatory Control block parameters

In R210 system or greater, the access level/lock for the following regulatory control block parameters is now
Continuous Control (CONTCONTROL). This provides write access for CAB programs to these parameters.
This means you can modify and/or enhance other built-in regulatory control block features by inserting user
written CAB programs for one or more of these parameters. The CAB programs must be configured for an
access level of Continuous Control (CONTCONTROL).
Parameter Description Associated Block

INITREQ[1..8] Initialization Request Flags. There is one flag for each All Regulatory Control
primary. blocks that support insertion
points
INITVAL[1..8] Initialization Value. There is one value for each primary. All Regulatory Control
blocks that support insertion
points
OPBIAS.FLOAT Floating Output Bias in Engineering Units ENHREGCALC,
PIDER,
RATIOCTL,
REGSUMMER
OPBIAS[1..8].FLOAT Total Output Bias for function blocks with Multiple Outputs FANOUT
PV Process Variable Pid,
Pidff,
PVSTS Status of Process Variable. Pid,
Pidff,
RAMPSOAK,
RATIOCTL
TMOUTFL Timeout Flag. Indicates if an initializable input has timed-out. All Regulatory Control
blocks that support insertion
points
X [..] Input Value for blocks with multiple inputs Ovrdsel,
REGSUMMER,
Switch
XKB[..] X-Input Gain (K) and Bias (B) ENHREGCALC
X1 Input Value Automan, Fanout, Ratiobias
ratioctl, Remcas
X2 Input Value RATIOCTL,
REMCAS
X1STS Status of Input Value Automan, Fanout
ratioctl
X2STS Status of Input Value for blocks with multiple inputs RATIOCTL
19.1.7 Pin connections to inserted CAB instances

Normally, inserted CAB instances do not have outside pin connections to their custom data parameters (CDPs).
Inserted CAB instances usually share data only with their calling block, which is the block that is using the
CAB as an insertion program. In this case, block connections are created between the calling block and the
269
inserted CAB blocks, during the load of insertion points configuration for configured parameter references. The
parameter references ensure that data flow occurs in the proper sequence with respect to the execution of the
calling block and the CAB program.
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).
19.1.8 Insertion status and fail alarm for regulatory control blocks
The following table summarizes failure considerations when a CAB program encounters an exception or
termination condition. When the program completes execution normally, the CAB instance returns an execution
status of NORMAL. When any of the insertions is in a non-normal status, the insertion fail flag (INSFAILFL) is
set to TRUE. The flag is reset to FALSE, when all the abnormal programs return to normal status
Failure Type Considerations

Program Termination CAB programs in general must not be repetitious. If repetitive calculations must be used,
be sure you carefully design and thoroughly test them to be sure that excessive execution
time is not required. CAB programs that take longer than one half of the ACE base cycle
(250ms), are automatically terminated. CAB programs can also terminate, if the CAB
program consumes excessive memory during runtime.
When a program terminates, the CAB instance issues a terminated status to the calling
master. You must correct the program defect and reload the CAB instance before
reactivating the control strategy. The CAB remains in the terminated condition until it is
restarted by an operator.
Exception Failures If the inserted CAB program encounters an exception failure condition, the program is
terminated in the current cycle but will execute in the next cycle. The insertion fail flag
(INSFAILFL) is set to TRUE. The flag will be reset to FALSE, when the program runs till
completion and returns a normal status.
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
19.1.9 Handling of insertion failure on regulatory control block

If the CAB program inserted on a regulatory block fails (returns a non-normal status), the block sets its control
initialization condition (INITMAN) to True and skips all the remaining processing of the block.
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.
19.1.10 CAB insertion on regulatory control block configuration examples
Single CAB insertion

The following figure and its companion callout description table show a sample configuration that uses a PID
block with an insertion type from a single CAB instance.
Table 8: Configuration example using single CAB insertion for regulatory control block
Callout Description
1 The Control Module contains a PID block named pida.
2 The pida block is configured to include an insertion type Ctl_Alg from a CAB instance named
CAB_1A.
3 The CAB instance named CAB_1A is added to the Control Module containing the pida block.
4 During configuration, the ORDERINCM parameter for CAB_1A is changed to match the setting of
ORDERINCM for the pida block. Also, the insertion point parameter (INSMASTER) for CAB_1A is
turned On or set to True and shows the tag name of the pida block on the CAB configuration form.
5 Once the Control Module and its components is loaded to an ACE controller and activated, the pida
block controls the execution of the CAB_1A instance as required. If the CAB_1A instance runs
successively with no failures, the cycle is repeated during every Control Module execution cycle. In
this case, the CAB_1A instance returns a NORMAL status.
During Control Module execution, only the pida block is executed. The CAB_1A instance executes
only when the pida block calls the execute function.
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.
Exception Failure Scenario
271
Callout Description
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.
Termination Failure Scenario
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 will remain 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.
Multiple CAB insertions

The following figure and its companion callout description table show a sample configuration that uses a
AUTOMAN block with insertion types from four CAB instances.
Table 9: Configuration example using multiple CAB insertions for regulatory control block
Callout Description
1 The Control Module contains a AUTOMAN block named AUTOMANA.
2 The AUTOMANA block is configured to include an insertion type Post_Input from a CAB instance
named CAB_1A, insertion type Ctl_Alg from a CAB instance named CAB_2A, insertion type
Post_Alg from a CAB instance named CAB_3A, and insertion type Post_Ctlout from a CAB instance
named CAB_4A
3 The CAB instances named CAB_1A, CAB_2A, CAB_3A, and CAB 4A are added to the Control
Module containing the AUTOMANA block.
4 During configuration, the ORDERINCM parameters for CAB_1A, CAB_2A, CAB_3A, and
CAB_4A are changed to match the setting of ORDERINCM for the AUTOMANA block. Also, the
insertion point parameters (INSMASTER) for all four CAB instances are turned On or set to True and
show the tag name of the AUTOMANA block on their configuration forms.
273
Callout Description
5 Once the Control Module and its components is loaded to an ACE controller and activated, the
AUTOMANA block controls the execution of all CAB instances as required. If all CAB instances run
this case, all CAB instances return a NORMAL status.
If any of the CAB instances return a non-normal status, the insertion fail flag (INFAILFL) is set to
TRUE and the INITMAN parameter of AUTOMANA block is set to TRUE, causing the block to go
into its INIT state. The execution steps that follow the failure are skipped.
If a CAB 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.
CAB _1A Failure Scenario
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. This means that the output values (CV and OP) will
remain 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 will remain 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.
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..
Two CAB insertions of same type

DATAACQ block with the same insertion type from two CAB instances.
Table 10: Configuration example using two CAB insertions of the same type for regulatory control block
Callout Description
1 The Control Module contains a PID block named pida.
2 The pida block is configured to include insertion type Post_Alg from CAB instances named CAB_1A
and CAB_2A
3 The CAB instances named CAB_1Aand CAB_2A are added to the Control Module containing the
pida block.
4 During configuration, the ORDERINCM parameters for CAB_1A and CAB_2A are changed to
match the setting of ORDERINCM for the pida block. Also, the insertion point parameters
(INSMASTER) for both CAB instances are turned On or set to True and the show the tag name of the
pida block on their configuration forms.
275
Callout Description
5 Once the Control Module and its components is loaded to an ACE controller and activated, the pida
block controls the execution of both CAB instances as required. Since the CAB instances are both
inserted at Post_Alg, the instances will be executed in the order in which they were configured. For
example, if CAB instance CAB_1A was added to the CM before CAB_2A, CAB_1A is executed
first. If both CAB instances run successively with no failures, the cycle is repeated during every
Control Module execution cycle. In this case, both CAB instances return a NORMAL status.
If either of the CAB instances returns a non-normal status, the insertion fail flag (INFAILFL) is set to
TRUE and the INITMAN parameter of pida block is set to TRUE, causing the block to go into its
INIT state. The execution steps that follow the failure are skipped. For example, if CAB_1Aexecution
returns a non-normal status, CAB_2A will not be executed and the subsequent steps namely windup
and feedback processing are skipped.
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.
19.1.11 Tuning Conversions from Interactive to Non-Interactive PID

Use the following information to convert PID algorithms used in Honeywell's TDC system for use in an
Experion system.
Equation PID Type Equation

Reference
Number
PID algorithms are implemented from the following transfer functions:
1 Interactive
2 Non-Interactive
If the rate limiters are ignored, the transfer functions take on the following forms:
3 Interactive
4 Non-Interactive
Equation 3 can be arithmetically manipulated to obtain the form of equation 4 as follows:

5
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:
Equation PID Type Equation

Reference
Number
where,
Kni - non-interactive gain (CEE)
TI - non-interactive integral time constant (CEE)
TD - non-interactive derivative time constant (CEE)
K - interactive gain
T1 - interactive integral time constant
T2- interactive derivative time constant
277
19.2 About Safety Interlock Function

The Safety Interlock flag (SIFL) is an optional input to every regulatory control block. It lets you create safety
interlocks for one or more control strategies. For example, you may create a Logic block which sets a Boolean
based on some safety conditions, and the strategies may be configured to go off control when the Boolean is
true.
19.2.1 Safety Interlock processing

If a SIFL connection exists, the regulatory control fetches the flag and checks for a change of state. When SIFL
is ON, the regulatory control block does the following:
• Checks if a Safety Interlock alarm should be issued.
• Sets MODE and OP according to the user-specified Safety Interlock Option (SIOPT). The SIOPT indicates
what to do if SIFL is ON. The choices are as listed in the following table.
If SIOPT Is. . . Then, Action Is . . .

NoShed Do nothing: Keep MODE and OP at their current value. This means that the
Operator can change the MODE, MODEATTR and OP.
ShedHold Set MODE to Manual and MODEATTR to Operator, disable External Mode
Switching, and hold OP at the last good value.
This is the default setting.
ShedLow Set MODE to Manual and MODEATTR to Operator, disable External Mode
Switching, and set OP to its extended low limit (OPEXLOLM).
ShedHigh Set MODE to Manual and MODEATTR to Operator, disable External Mode
Switching, and set OP to its extended high limit (OPEXHILM).
ShedSafe Set MODE to Manual and MODEATTR to Operator, disable External Mode
Switching, and set OP to the configured safe value (SAFEOP).
If SAFEOP is NaN, OP is held at the last good value.
19.2.2 Safety Interlock processing considerations

The following table summarizes some things to consider for a given SIFL condition.
If Condition Is . . . Then, Consider This . . .

While SIFL is ON, • MODE, MODEATTR, ESWENB and OP cannot be directly changed by
the user.
• If mode was shed, the user is prevented from changing it until SIFL goes
OFF. However, the following should be noted:
– If the Reg Control block cannot successfully fetch SIFL, it will turn
SIFL OFF. (Possible reasons for not being able to fetch SIFL include;
communication error, the regulatory control block is disconnected
from the SI source, or the SI source block is deleted.)
– If the user sets the regulatory control block inactive, SIFL will be
turned OFF.
If Condition Is . . . Then, Consider This . . .

While SIFL is On and the block has Shed A change in SAFEOP/OPEXHILM/OPEXLOLM will dynamically update the
once, OP (based on the SIOPT) only in the following cases:
• After each execution, when there is a wired connection to SIFL and the
flag is ON.
• After each store, when there is a program store to SIFL pulsed to set it
ON.
If the block is in initialization in the The OP value will not be impacted by any change other than the INITVAL
previous scenarios, from the secondary. The OP will be dynamically updated based on the SIOPT,
only after the block comes out of initialization.
When there is a Program store configured • A change in SAFEOP/OPEXHILM/OPEXLOLM thereafter will not
to set the SIFL to ON, and when the block dynamically update the OP.
has Shed once, • The user has to execute the program to pulse the SIFL to ON again, for the
OP to be updated.
When there is a Program store configured • The Mode will be shed but the OP will not be set based on the Shed
to set the SIFL to ON once and if the option.
block is in initialization, • The OP will be equal to the INITVAL from the secondary in this case.
• The user has to execute the program to pulse the SIFL to ON, after the
block comes out of initialization to update the OP based on the Shed
Option.
When SIFL changes from ON to OFF, • The function block clears the Safety Interlock alarm (if one 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 .
19.2.3 Safety Interlock Alarming

The Safety Interlock Alarm Option (SIALM.OPT) indicates if SI alarming is enabled or not as follows:
• If SI alarming is enabled, and SIFL is ON, an alarm indicator will appear next to SIFL on the function block
detail display. In addition, the regulatory control block will issue an alarm when SIFL goes ON, and clear
the alarm when it goes OFF. (If the user sets the alarm priority (SIALM.PR) to “NoAction”, no alarm will be
issued. However, an alarm indicator will still appear next to SIFL on the detail display.)
• If SI alarming is disabled, an alarm indicator will notappear on the detail display and an alarm will not be
issued.
279
19.3 About Red Tagging

A point can be “red tagged” to indicate that it requires maintenance. This is accomplished by setting the
REDTAG parameter “On.” Typically, the operator sets the output of the point to a desired safe value before
turning on the red tag. Once red tagged, the mode, mode attribute, external mode switching state, and output
cannot be changed.
The REDTAG parameter is specific to the following blocks.
• Regulatory Control blocks - AutoMan, Fanout, OvrdSel, PID, PIDFF, PosProp, PulseCount, PulseLength,
RampSoak, RemCas, RatioBias, RegCalc, RegSummer, and Switch.
• Device Control block
• Drive Control Blocks - HT Motor, LT Motor, Solenoid Valve, Valve/Damper
• Series C I/O - AOCHANNEL, DOCHANNEL
19.3.1 Function of Red Tagging

The Red Tag function prevents changes to the output on a point that has the REDTAG parameter set to ON, but
it may still be possible to change the output connected to the field. For example, even if a Digital Composite
point has REDTAG set to ON, a program/Logic Block can still change the state of the Digital Output.
19.3.2 Before red tagging a point

The mode and the mode attribute of the point must be changed to Man and Oper respectively. To red tag a
digital composite point, the output of the point must not be configured for the momentary state.
A block with external mode switching (ESWENB) enabled cannot be RedTagged. External Mode Switching
must be disabled, prior to setting REDTAG to ON.
19.4 AUTOMAN (Auto Manual) Block

The AUTOMAN (Auto Manual) 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. It looks like this graphically:
With R410, you can configure the on-delay time, off-delay time, deadband value, and deadband unit for the
individual alarms. For example, you can use the following parameters to configure the on-delay time, off-delay
time, deadband values, and deadband units for the OPHIALM parameter.
• OPHIALM.TM
• OPHIALM.TMO
• OPHIALM.DB
• OPHIALM.DBU
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.
281
Configuration Tab Description

Main • Name - Block (Tag) name of up to 16 characters long. Must be unique within the
CM block containing it.
• Description (DESC) - Block descriptor of up to 132 characters long.
• Engineering Units (EUDESC) - Lets you specify a text string of up to 16
characters to identify the variable values associated with this block. For example,
you could specify DEGF for temperature values in degrees Fahrenheit. This
name is used on any associated displays and generated reports.
• Execution Order in CM (ORDERINCM) - Specifies the execution order of the
block in the CM relative to other blocks contained in this CM. Enter as a number
between 1 to 32767. The default value is 10. Refer to the Function Block
Execution Schedules section in the beginning of this document for more
information.
• 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).
• Normal Mode (NORMMODE) - Lets you specify the MODE the block is to
assume when the Control to Normal function is initiated through the Station
display. Selections are MANual, AUTOmatic, CAScade, BackupCAScade and
NONE. All selections are not valid for a given block. The default selection is
NONE.
• Normal Mode Attribute (NORMMODEATTR) - Lets you specify the mode
attribute (MODEATTR) the block is to assume when the Control to Normal
function is initiated through the Station display. Selections are NONE,
OPERATOR and PROGRAM. The default selection is NONE.
• Mode (MODE) - Lets you set the block's current MODE. The selections are
MANual, AUTOmatic, CAScade, BackupCAScade, NONE, and NORMAL. All
selections are not valid for a given block. The default selection is MANual.
MODE identifies who may store values to the block's initializable inputs or
output. Blocks strictly enforce the MODE assignment. Some function blocks
perform automatic mode switching (or mode shedding), while others require
manual intervention. The block's MODE is derived at “runtime” based on
current conditions. MODE processing checks for the following conditions, and
changes the block's MODE as appropriate.
– External request for MODE switching.
– Safety interlock request.
• Mode Attribute (MODEATTR) - Lets you set the block's mode attribute. The
selections are NONE, OPERATOR, PROGRAM, and NORMAL. The default
selection is OPERATOR. MODEATTR identifies who may store values to the
output (OP), when the block's MODE is MANual.
• Permit Operator Mode Changes (MODEPERM) - Lets you specify if operators
are permitted to make MODE changes or not. The default is Enabled (checked).
A store to MODE does not change the NORMMODE.
• Permit External Mode Switching (ESWPERM) - Lets you specify if external
MODE switching through user configured interlocks is permitted or not, if you
have at least an Engineering access level. The default is Disabled (unchecked).
• Enable External Mode Switching (ESWENB) - Lets you specify if external
MODE switching through user configured interlocks is enabled or not, if
ESWPERM is checked (Permitted). The default is Disabled (unchecked).
• Enable Secondary Initialization Option (SECINITOPT) - Lets you specify if the
block is to ignore initialization and override requests from the secondary or not.
The default selection is Enabled (checked, do not ignore).
• 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 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.
• Safety Interlock Option (SIOPT) - Lets you specify MODE and OP block is to
assume upon a safety interlock alarm. The selections are NO_SHED,
SHEDHOLD, SHEDLOW, SHEDHIGH, and SHEDSAFE. The default selection
is SHEDHOLD.
• Bad Control Option (BADCTLOPT) - Lets you specify MODE and OP block is
to assume if CV goes BAD. The selections are NO_SHED, SHEDHOLD,
SHEDLOW, SHEDHIGH, and SHEDSAFE. The default selection is NOSHED.
• Bad Output Connection Option (BADOCOPT) - Lets you specify a time delay
for the regulatory control blocks to shed the control mode in the event of an IO
communication loss. The selections are NaN, 0, and 1 - 60 seconds. The default
selection is 0. This is configurable only if the Enable Bad Output Connection
Option is enabled.
• Enable Bad Output Connection Option (BADOCOPTENB) - Lets you to
optionally enable the functionality of specifying a time delay for the regulatory
control blocks to shed the control mode in the event of an IO communication
loss. The default selection is Disable.
283

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
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).
-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 rate of the control element to the control
dynamics. We recommend that you configure this value before you tune the
loop, so tuning can accommodate any slowdown in response time caused by this
rate limiting. This check is not applied for a function block that is in the
MANual mode. The default value is Not a Number (NaN), which means no rate
limiting is applied.
• Minimum Change (%) (OPMINCHG) - Lets you specify an output minimum
change limit as a percent of the Calculated Variable range (CVEUHI -
CVEULO). This lets you define how much the OP must change before the
function block outputs a new value. It filters out changes that are too small for
the final control element to respond to. This check is not applied for a function
block that is in the MANual mode. The default value is 0, which means no
change limiting is applied.
• Safe OP (%) (SAFEOP) - Lets you specify the safe output value as a percent of
the Calculated Variable range (CVEUHI - CVEULO). For example, If the CV
range is 0 to 500 and you enter a Safe OP of 50%, the safe output value in
engineering units is 50% times 500 or 250. The default value is Not a Number
(NaN), which means the OP is held at its last good value.
• Output Bias (OPBIAS.FIX) - Lets you specify a fixed bias value in engineering
units that is added to the Calculated Variable (CV) output value. 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.RATE) - Lets you specify an output floating bias
ramp rate in engineering units per minute. 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.
• Gain (K) - Lets you specify a gain (K) value to be factored into the equation for
calculating the CV output value. See the equation following this table for details.
The default value is 1.

• Gain High Limit (GAINHILM) - Lets you specify gain high limit value. Gain
(K) is clamped to this value, if the specified gain exceeds it. The default value is
240.
• Gain Low Limit (GAINLOLM) - Lets you specify gain low limit value. Gain
(K) is clamped to this value, if the specified gain is less than it is. The default
value is 0.
285

Alarms • Type - Identifies the types of alarm this block supports. Of course, these alarms
also interact with other block configuration options such as the Safety Interlock
Option (SIOPT) and Bad Control Option (BADCTLOPT). The types are:
– Safety Interlock (SIALM.FL)
– Bad Control (BADCTLALM.FL)
– OP High (OPHIALM.FL)
– OP Low (OPLOALM.FL)
• Enable Alarm (SIALM.OPT) - Lets you enable or disable Safety Interlock alarm
type. A check in the box means the alarm is enabled. The default selection is a
checked box or enabled (Yes).
ou can also configure the SIALM.OPT parameter as a block pin, a configuration
and/or a monitoring parameter so it appears on the block in the Project and
Monitoring tree view, respectively.
• Trip Point - Lets you specify the OP High Alarm (OPHIALM.TP) and OP Low
Alarm (OPLOALM.TP) trip points in percent. The default value is NaN, which
disables the trip point.
• Priority - Lets you set the desired priority level individually for each alarm type
(SIALM.PR, BADCTLALM.PR, OPHIALM.PR, and OPLOALM.PR). The
default value is LOW. The levels are:
– NONE - Alarm is neither reported nor annunciated.
– JOURNAL - Alarm is logged but it does not appear on the Alarm Summary
display.
– LOW, HIGH, URGENT - Alarm is annunciated and appears on the Alarm
Summary display.
• Severity - Lets you assign a relative severity individually for each alarm type
(SIALM.SV, BADCTLALM.SV, OPHIALM.SV, and OPLOALM.SV) as a
number between 0 to 15, with 15 being the most severe. This determines the
alarm processing order relative to other alarms. The default value is 0.
• Deadband Value (ALMDB/xxxxALM.DB) - Defines the minimum value that
needs to be added to or subtracted from trip point before reporting an RTN. By
specifying a deadband value, you can prevent nuisance alarms due to noise at
values near the trip point. The default value is 1. For a high alarm, RTN is
reported only when the OP value is less than the trip point - deadband value. For
a low alarm, RTN is reported only when the OP value is more than the trip point
+ deadband value.
Prior to R410, once the deadband value was configured, this value was loaded to
the individual alarm parameters (for example, OPHIALM.DB and
OPLOALM.DB) when the CM was loaded. If you configured the individual
alarm parameters as Monitoring Parameters for the block, you could change the
individual alarm value while monitoring the loaded block in CB.
With R410, deadband value can be individually configured for each alarm. For
example, you can configure OPHIALM.DB as 5 and OPLOALM.DB as 3.
However, if you are migrating from pre-R410 to later release, refer to “Impact of
migration on alarm attributes”.
• Deadband Time (ALMTM/xxxxALM.TM) - Defines the duration in seconds
during which a process alarm reporting is suppressed. This helps in preventing
the nuisance alarms from being reported repeatedly during the process upset and
improves the efficiency of the operator. Once you configure this value for an
alarm, the alarm is reported on the Station only if the alarm condition continues
to exist even after this value expires. The default time is 0; that is the alarm is
reported as soon as the alarm condition occurs.
Prior to R410, once configured, this value was loaded to the individual alarm
parameters (for example, OPHIALM.TM and OPLOALM.TM) when the CM
was loaded. If you configured the individual alarm parameters as Monitoring

parameters for the block, you could change the individual alarm value while
monitoring the loaded block in CB.
With R410, the deadband time can be individually configured for each alarm.
For example, you can configure OPHIALM.TM as 5 seconds and
OPLOALM.TM as 3 seconds. However, if you are migrating from pre-R410 to
later releases, refer to “Impact of migration on alarm attributes”.
• Deadband Units (ALMDBU/xxxxALM.DBU) - Defines the unit for the
deadband value - percent or engineering units. The default value is percent.
parameters (for example, OPHIALM.DBU and OPLOALM.DBU) when the CM
With R410, you cannot individually configure the deadband unit for the
AUTOMAN block. If you configure the deadband unit as “EU or Percent” for an
alarm, this configuration is identical for the all other alarms in the AUTOMAN
block. However, if you are migrating from pre-R410 to later releases, refer to
“Impact of migration on alarm attributes”.
You must configure identical deadband units for all alarms in the AUTOMAN block.
• Uncmd Mode Change (UNCMDCHGALM) - Lets you specify if an alarm is to
be notified in the alarm summary whenever a mode shed happens in the event of
an IO communication loss. The selections are:
– Enable - An alarm is notified in the alarm summary whenever a mode shed
happens in the event of an IO communication loss. The alarm returns to
normal state after you revert the mode setting manually.
– Disable - An alarm is not notified whenever a mode shed happens in the
event of an IO communication loss.
This parameter is available for configuration only if the Enable Bad Output
Connection Option is enabled.
• Off-delay Time (xxxxALM.TMO) - Defines the duration in seconds during
which an RTN reporting is suppressed even though the alarm condition does not
exist. The RTN is reported on the Station only after this time expires and the
alarm condition has returned to normal. The default time is 0; that is RTN is
reported as soon as the alarm condition returns to normal. If a deadband value is
also configured, the RTN is reported only when the OP value is less than trip
point - deadband for the configured Off-delay time. However, if you are
migrating from pre-R410 to later releases, the alarm off-delay time will be set as
default value (0).
287

SCM • SCM Mode Tracking Option (MODETRACK) - Lets you select the desired
Mode Tracking function for the SCM associated with this block's Control
Module. It defines how the FB will set the state of the MODEATTR based upon
the MODE of the SCM. See the Sequential Control Module User's Guide for
more information on this function. The default selection is ONESHOT. The
selections are:
– None
– ONESHOT
– SEMICONT
– CONTRTN
– CONT
• Option Type - Lets you specify the action the function block is to take when the
SCM goes into an abnormal state. The Starting State Option (STARTOPT)
applies when the SCM state is Checking, Idle, or Complete. The Stop/Abort
State Option (STOPOPT) applies when the SCM state is Stopping or Stopped,
Aborting or Aborted. The Hold State Option (HOLDOPT) applies when the
SCM state is Holding or Hold. The Restart State Option (RESTARTOPT)
applies when the SCM state is Resume or Run. The NONE and LASTREQ are
the only selections for the Restart State Option. You can select from one of these
types for the other options as applicable for the given regulatory control function
block:
– NONE - No changes.
– MAN - Set MODEREQ = MANUAL.
– AUTO - Set MODEREQ = AUTOMATIC (not applicable to this block).
– CAS - Set MODEREQ = CASCADE.
– FIXEDOP - Set OPREQ = Configured Value.
– HOLDPV - Set SPREQ = PV.
– FIXED SP - Set SPREQ = Configured Value and SPRATEREQ = NaN.
– RAMPEDSP - Set SPTVREQ = Configured Value and SPRATEREQ =
Configured Rate.
• Value (STARTVAL, STOPVAL, HOLDVAL) - Depending upon Option Type
selection, lets you specify an output or set point value within the respective
range. For output, within OPLOLM to OPHILM and within SPLOLM to
SPHILM, for set point. The default value is NaN (Not a Number).
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 Parameters Lets you select the available parameters that you want to 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.
Block Preferences Lets you change several block-viewing preferences including the color of the block's
faceplate.
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:
K = gain for CV (user specified)
X1 = input value
OPBIAS.FIX = fixed output bias (user specified)
OPBIAS.FLOAT = floating output bias (calculated)
• 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:
OPBIAS.FLOAT = CVINIT - [K*X1 + OPBIAS.FIX]
where: CVINIT = initialization value from the secondary
19.4.1 Function-AUTOMAN
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:
• has one primary and one secondary.
• requests the primary to initialize when mode changes from CAScade to MANual.
19.4.2 Configuration example-AUTOMAN

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.
289
Table 11: Example of CB configuration using AUTOMAN block.
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.
Callout Description
3 The primary purpose of this AUTOMAN block is to ensure a bumpless output upon return to Cascade
mode. The AUTOMAN block is typically used between a FANOUT block and a final control element.
Upon a return to Cascade, each secondary provides an initialization request to its primary. In most cases,
the primary adjusts its output accordingly. However, if the primary is a FANOUT block, it may ignore the
initialization request, since all of its secondaries may not be requesting it. In this case, the AUTOMAN
block compensates for this by applying a floating bias to the output.
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)
19.4.3 Inputs-AUTOMAN
The AUTOMAN block requires one input - X1:
• X1 = initializable input which, if used, must be pulled from another block (it cannot be stored to).
• An engineering unit range for X1 (XEUHI and XEULO) must be specified.
• 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
(Note that this block applies no range checks and assumes that X1 is within the XEUHI and XEULO range.)
19.4.4 Output-AUTOMAN
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.
The default OP connection pin is exposed on the blocks and the implicit/hidden connection function automatically
makes the appropriate value/status parameter connection when required. For example, if you connect the output from
an AUTOMAN block (AUTOMAN1.OP) to the set point of a PID block (PIDB.SP), the implicit/hidden connection is
made to AUTOMAN1.OPX to provide value/status data.
19.4.5 Initializable inputs and outputs for AUTOMAN

“Initializable input” and “initializable output” are variable attributes, similar to data type or access level. A
parameter with the “initializabl” attribute has an associated BACKCALC parameter. When a connection
between an initializable input and initializable output is created, you can also create a BACKCALC connection
between them. Control Builder automatically builds the required BACKCALC connections, so you don't have
291
to create them manually. These “implici” build connections are “hidde” from view and the related parameter
pins are not exposed on the control chart.
For example,if you connect OP from an AUTOMAN block to a PID block or an AOCHANNEL block, Control
Builder automatically creates the BACKCALCOUT to BACKCALCIN connection.
Tip
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).
19.4.6 Output ranges of AUTOMAN

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.
19.4.7 Output bias-AUTOMAN

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 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). 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 OPBIAS.FLOAT is calculated as follows.
OPBIAS.FLOAT = CVINIT - (CVUNBIASED + OPBIAS.FIX)

Where:
CVINIT = initialization value received from the secondary
CVUNBIASED = unbiased calculated value (based on input from the primary)
OPBIAS.FIX = fixed bias (user-specified)
• 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, 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.
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:
cycles_per_min = number of times the function block executes per minute (calculated)
• 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.
19.4.8 Output Indication function for AUTOMAN

This block supports the Output Indication (OUTIND) parameter that lets you specify how the output (OP)
parameter is accessed and whether display indications are shown on the block's faceplate display.
You choose from the following configuration selections to tailor the block's output to meet your particular
operation and display requirements.
293
If OUTIND Enumeration Selection Is … Then, Its Function Is …

Direct No value reversal - output range is 0 to 100 percent, and no display indications
- neither Closed nor Open is shown at the 0 and 100 percent points on the OP
(This is the default selection, so legacy
bar graph on the faceplate display.
OP values remain the same.)
Reverse Value reversal - output range is 100 to 0 percent, and no display indications -
neither Closed nor Open is shown at the 0 and 100 percent points on the OP
bar graph on the faceplate display
DirectDispInd No value reversal - output range is 0 to 100 percent, and display indications
Closed and Open are shown at the 0 and 100 percent points on the OP bar
graph on the faceplate display, respectively.
ReverseDisplnd No value reversal - output range is 0 to 100 percent, and display indications
graph on the faceplate, respectively.
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.
Considerations for OUTIND Reverse selection-AUTOMAN

When you set the OUTIND parameter to its REVERSE selection, access to the parameters listed in the
following table by any data mechanism get the reversed value as shown.
A Get of This Parameter … Equals This …

OP 100.0 - Actual OP
OPEU Engineering Units of (100.0 - Actual OP)
OPHILM 100.0 - Actual OPLOLM
OPEXHILM 100.0 - Actual OPEXLOLM
OPLOLM 100.0 - Actual OPHILM
OPEXLOLM 100.0 - Actual OPEXHILM
OPHIFL and OPLOFL Reverse of Actual OPHIFL and OPLOFL
OPHIALM.TP 100 - Actual OPLOALM.TP
OPLOALM.TP 100 - Actual OPHIALM.TP
OPHIALM.PR and .SV, and OPLOALM.PR and .SV Reverse of Actual OPHIALM.PR and .SV, and
OPLOALM.PR and .SV
OPHIALM.FL and OPLOALM.FL Reverse of Actual OPHIALM.FL and OPLOALM.FL
OPHIALM.DB, .DBU, and .TM, and Reverse of Actual OPHIALM.DB and .DBU, and
OPLOALM.DB, .DBU, and .TM OPLOALM.DB and .DBU
OPROCPOSFL AND OPROCNEGFL Reverse of Actual OPROCPOSFL and OPROCNEGFL
SAFEOP 100 - Actual SAFEOP
STARTVAL, STOPVAL, HOLDVAL 100 - Actual STARTVAL, STOPVAL, HOLDVAL
(Applicable only when corresponding option is FixedOp.)
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.
Migration and Checkpoint support for OUTIND-AUTOMAN

On Migration from an legacy block without the OUTIND parameter support, the OUTIND parameter defaults to
its DIRECT selection and the existing OP values remain 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 windup status considerations

The values of the Anti Reset Windup Status on Output (ARWOP) and related windup parameters (ARWNET/
ARWNETIN/ARWOPIN) will not be reversed when the OUTIND parameter is set to REVERSE.
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 Experion high or low 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.
19.4.9 Mode Handling-AUTOMAN

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.
19.4.10 Timeout Monitoring-AUTOMAN

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)
• Enable timeout monitoring by setting TMOUTTIME to a non-zero value.

• Disable timeout monitoring by setting TMOUTTIME to zero.
295
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.
19.4.11 Control Initialization-AUTOMAN

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 so CV = initialization value from the secondary
• Builds an initialization request for the X1 primary as follows:
INITREQ(X1) = On
• Where:
INITREQ(X1) = initialization request flag for the X1 primary

INITVAL(X1) = initialization value for the X1 primary
CV = calculated value
K = Output gain
OPBIAS.FIX = user specified fixed bias
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.
19.4.12 Secondary initialization option-AUTOMAN

If a BACKCALC connection is made, the primary always brings initialization data over this connection.
However, you can configure the block to ignore this data by not selecting the Enable Secondary Initialization
Option on the block's parameter 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 and override
requests from the secondary.
• If SECINITOPT equals Disable, it means the function block should ignore initialization and override
19.4.13 Override feedback processing-AUTOMAN

If the AUTOMAN block is in a Cascade strategy with a downstream OVRDSEL (Override Selector) block, it
receives override feedback data. This data consists of an override status, override feedback value and an
override offset flag (for PID block strategies). The status indicates if the block is in the selected or unselected
strategy (as determined by the OVRDSEL block).
When the override status changes from selected to unselected, the AUTOMAN block:
• does not initialize its CV, and
• computes a feedback value for its primary as follows:
feedback value for primary = (override feedback value from secondary - OPBIAS.FIX - OPBIAS.FLOAT) /
K
19.4.14 Windup processing-AUTOMAN

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.
If the Value is … Then, the Associated Parameter …

Normal is free to move in either direction.
Hi is at its high limit and it may only be lowered.
Lo is at its low limit and it may only be raised.
HiLo may not move in either direction.
Manual Mode Interaction

When the MODE of a regulatory control block is changed to Manual (Man), the block sets its windup status
(ARWNET) to HiLo. This means that every block upstream in a cascade strategy will set its windup status
(ARWNET and ARWOP) to HiLo.
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.
If Any of the Following are True … Then, ARWOP Equals …

This block is inactive. HiLo
A secondary exists but this block cannot fetch secondary
data from it (communications or configuration error).
A secondary exists and its windup state equals HiLo
This block is in initialization (INITMAN = On).
A secondary exists and it is requesting this block to
initialize.
A secondary exists and its windup state equals Hi. Hi
This block's output is at its high limit (OPHIFL = On).
A secondary exists and its windup state equals Lo. Lo
This block's output is at its low limit (OPLOFL = On).
297
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.
If Any of the Following are True … Then, ARWNET Equals …

The ARWOP equals HiLo.
This block is in Manual mode (MODE = Man)
The calculated value (CV) range (CVEUHI / CVEULO) is
NaN.
The CV is NaN
This block is connected to a non-initializable primary
The ARWOP equals Hi Hi
(Pid function blocks have a configurable Control Action
option (CTLACTN). If CTLACTN = Reverse , ARWNET
will track ARWOP; but if CTLACTN = Direct , ARWNET
will be the opposite of ARWOP.)
The input from the primary is at a high limit. For example,
SPHIFL = On.
This block's output has reached its positive rate-of-change
limit (OPROCPOSFL = On)
The ARWOP equals Lo LO
Input from the primary is at a low limit. For example,
SPLO.FL = On.
This block's output has reached its negative rate-of-change
limit (OPROCNEGFL = On)
19.4.15 Anti-Reset Windup Status-AUTOMAN

The anti-reset windup network in (ARWNETIN) and anti-reset windup output in (ARWOPIN) parameters are
added in the standard anti-reset windup (ARW) computation logic. They are user configurable and allow stores
from Sequential Control Modules (SCMs) and Custom Algorithm Block (CAB) programs.
The ARWNETIN and ARWOPIN parameters would be ORed into the existing standard logic so it is not lost.
The following table summarizes the influence the ARWNETIN and ARWOPIN parameters have on the
ARWNET and ARWOP parameters, which are not user configurable.
ARWNETIN or ARWOPIN Parameter Is… Standard Computation Logic Is … ARWNET or ARWOP Parameter Is …
NORMAL NORMAL NORMAL
NORMAL HI HI
NORMAL LO LO
NORMAL HILO HILO
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 NORMAL HILO
HILO HI HILO
HILO LO HILO
HILO HILO HILO
19.4.16 AUTOMAN parameters

Refer to the Control Builder Components Reference for a complete list of the parameters used with the
AUTOMAN block.
299
19.5 ENHREGCALC (Enhanced Regulatory Control Calculator) Block

The ENHREGCALC block provides the following enhancements over the REGCALC block.
• Expands existing arrayed input parameters XSTS and X from six to ten.
• These arrayed parameters are added to correspond to each of the ten inputs.
– XSUB Substitute Parameter
• An initializable Set Point (SP) input parameter with limit checking and SP ramping is added. Also, the X[1]
input is converted to a general purpose input
• Mode can be placed in Automatic so operator or program can supply SP.
• Both the ENHREGCALC and REGCALC blocks are optimized so that expressions use memory based on
the number of expressions configured, pcode size of each expression and the number of references in the
expression.
It looks like this graphically.
• OPHIALM.TM
• OPHIALM.TMO
• OPHIALM.DB
• OPHIALM.DBU
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.
•

is SHEDHOLD.
information.
NONE.
OPERATOR, and PROGRAM. The default selection is NONE.
manual intervention. The block's MODE is derived at “runtim” based on current
conditions. MODE processing checks for the following conditions, and changes
the block's MODE as appropriate.
301

Option is enabled.
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.
• Setpoint Engineering Units High Range (SPEUHI) - Lets you specify the high
SP input range value in Engineering Units that represents 100% full scale input.
• Setpoint Engineering Units Low Limit (SPEULO) - Lets you specify the low SP
input range value in Engineering Units that represents the 0 full scale input. The
default value is 0 (zero).
• 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.
• Enable SP Ramping (SPTVOPT) - Lets you specify if an operator can initiate a
set point ramp action or not. It provides a smooth transition from the current set
point value to a new one. The default selection is box unchecked (disabled). See
the Set point ramping section for this block for more details.
• Normal Ramp Rate (SPTVNORMRATE) - Lets you specify a ramp rate in
engineering units per minute for the SP ramping function, when it is enabled.
This lets an operator start the SP ramping function without specifying a ramp
time. The default selection is Not a Number (NaN). See the Set point ramping
section for this block for more details.
• Enable SP Push: (PUSHSP) - Lets you specify that the ENHREGCALC SP will
be pushed from an Inter Cluster Gateway when the ENHREGCALC is the
secondary of a cascade that extends over two Experion clusters.

Input • X Description (XDESC[1..10]) - Lets you enter a description for a given X
input. The default value is null or blank.
• X Enable (XENABLE[1..10]) - Lets you select whether a given X input is
enabled or disabled. The default value is selected on enabled.
• X Substitute (XSUB[1..10]) - Lets you specify a substitute value to used for the
given X input. The default setting is NaN.
• XK (XK[1..10]) - Lets you specify an individual gain value for each of the ten X
inputs. The default value is 1.
• XB (XB[1..10]) - Lets you specify an individual bias value for each of the ten X
inputs. The default value is 0.00, which means no bias is added.
• XKB (XKB[1..10] - Lets you view the individual input values after individual
biases and gains have been applied to X[1] through X[10]
303

is -5%.
(NaN), which means the OP is held at its last good value. ’
floating bias in non-zero. See the Output Bias section for this function block for
calculating the CV output value. This value helps guarantee that the output is
“bumples” following initialization or mode changes. The default value is 1.

240.
(K) is clamped to this value, if the specified gain is less than it. The default value
is 0.
• CV (CVSRC) - Lets you assign an input or expression result as the source for
the CV. The default selection is NONE.
• CV Initialization (CVINITSRC) - Lets you assign an input or expression result
as the source of the CV initialization. The default selection is NONE.
• CV Override (CVORFBSRC) - Lets you assign an input or expression result as
the source of the CV during override. The default selection is NONE.
• Initialization Request (INITREQSRC) - Lets you assign an input or expression
result as the source of the initialization request flag for the primary. If desired,
you can leave this parameter unassigned. The default selection is NONE. The
ENHREGCALC block uses different values for this parameter depending upon
whether or not a source is assigned and a secondary exists as follows.
– If a source is assigned, this block uses the assigned source value even if a
secondary does exist.
– If no source is assigned and a secondary does exist, this block uses the
corresponding value from the secondary.
– If no source is assigned and there is no secondary, this block uses default
values (NaN for values, OFF for flags).
• Initialization Value (INITVALSRC) - Lets you assign an input or expression
result as the source of the initialization value for the primary. If desired, you can
leave this parameter unassigned. The default selection is NONE. The
ENHREGCALC block uses different values for this parameter depending upon
• Override Feedback Status (ORFBSTSSRC) - Lets you assign an input or
expression result as the source of the override feedback status for the primary. If
desired, you can leave this parameter unassigned. The default selection is
NONE. The ENHREGCALC block uses different values for this parameter
depending upon whether or not a source is assigned and a secondary exists as
follows.
• Override Feedback Value (ORFBVALSRC) - Lets you assign an input or
expression result as the source of the override feedback value for the primary. If
NONE. The ENHREGCALC block uses different values for this parameter
depending upon whether or not a source is assigned and a secondary exists as
follows.
secondary exists.
305

– If no source is assigned and a secondary exists, this block uses the

Alarms • Type - Identifies the types of alarms this block supports. Of course, these alarms
You can also configure the SIALM.OPT parameter as a block pin, a
configuration and/or a monitoring parameter so it appears on the block in the
Project and Monitoring tree view, respectively.
(SIALM.PR, BADCTLALM.PR, OPHIALM.PR, OPLOALM.PR). The default
value is LOW. The levels are:
display.
Summary display.
(SIALM.SV, BADCTLALM.SV, OPHIALM.SV, OPLOALM.SV) as a number
between 0 to 15, with 15 being the most severe. This determines the alarm
processing order relative to other alarms. The default value is 0.
needs to be added to or subtracted from the trip point before reporting an RTN.
By specifying a deadband value, you can prevent the nuisance alarms due to
noise at values near the trip point. The default value is 1. For a high alarm, RTN
is reported only when the OP value is less than the trip point - deadband value.
For a low alarm, RTN is reported only when the OP value is more than the trip
point + deadband value.
With R410, the deadband value can be individually configured for each alarm.
However, if you are migrating from pre-R410 to later releases, refer to “Impact
of migration on alarm attributes”.
307

With R410, the cannot individually configure the deadband unit for the
ENHREGCALC block. If you configure the deadband unit as “EU or Percent”
for an alarm, this configuration is identical for the all other alarms in the
ENHREGCALC block. However, if you are migrating from pre-R410 to later
releases, refer to “Impact of migration on alarm attributes”.
Note: You must configure the identical deadband units for the all alarms in the
ENHREGCALC block.
also configured, the RTN is reported only when the OP value is less than the trip
default value (0).

the MODE of the SCM. See the SCM Interface and CM Interaction section in
this document for selection details. The default selection is ONESHOT. The
selections are:
– None
– ONESHOT
– SEMICONT
– CONTRTN
– CONT
block:
– AUTO - Set MODEREQ = AUTOMATIC.
– HOLDPV - Set SPREQ = PV (not applicable to this block).
– FIXED SP - Set SPREQ = Configured Value and SPRATEREQ = NaN (not
applicable to this block).
Configured.
range. For output, within OPEXLOLM to OPEXHILM and within SPLOLM to
• Rate (STARTRATE, STOPRATE, HOLDRATE) - When the RAMPEDSP option
is selected, lets you specify a rate value (STARTRATE, STOPRATE,
HOLDRATE) for setting the SPRATEREQ for an SP ramping function.
Expr# 1 to Expr# 8 • Expression (C[1..8]) - Lets you write up to eight desired expressions for custom
calculations. You can also write a short descriptive text for each expression.
• See the Guidelines for writing expressions section for this block for more details.
faceplate.
309

information
19.5.1 Function-ENHREGCALC
• 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.
19.5.2 Configuration example-ENHREGCALC

The following figure shows a sample configuration using an ENHREGCALC block in a ratio control loop.
Table 12: Example of CB configuration using ENHREGCALC block.
19.5.3 Operating modes and mode handling for ENHREGCALC

The ENHREGCALC block supports the Manual, Automatic, and Cascade modes of operation.
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.
Cascade (CAS) the SP input comes from another function block.
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.
19.5.4 Inputs-ENHREGCALC
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.
19.5.5 Initializable input-ENHREGCALC

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 Target Value Processing
This function provides a smooth transition (ramp) from the current SP to a target SP. It is invoked through the
configuration option, SPTVOPT.
19.5.6 SP limit checking-ENHREGCALC

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
311
• 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.
19.5.7 SP target value processing-ENHREGCALC

The SP target value processing provides a smooth transition from the current set point value to a new value. It
ramps the SP from the existing value to a desired value over a period of time. It is similar to that of the PID
block except that the ENHREGCALC block does not have Max. Ramp Deviation due to absence of PV
parameter.
The SP target value processing uses the following parameters:
SPTVOPT SP Target Value Option (indicates if SP target value processing is requested)

SPTV target SP value (user-specified)
SPTVNORMRATE normal ramp rate (user-specified)
SPTVRATE calculated ramp rate
SPTVTIME ramp time in minutes (calculated or user-specified)
SPTVSTATE current target value processing state (possible states are Off, Preset, Run) SP target value
processing works as follows:
SP target value processing works as follows:

• At configuration time, you should:
– Enable SP target value processing by setting SPTVOPT to Enable. If SPTVOPT setting is Disable, you
cannot store to any other SPTV parameter.
– Specify a normal SP ramp rate (SPTVNORMRATE). This parameter lets you start SP ramping without
having to specify a ramp time. The SPTVNORMRATE may be NaN or greater than zero. The NaN
means step change or ramp time equals 0).
• To invoke SP ramping, you must do the following:
– Store a target SP value (SPTV). To store to SPTV, target value processing must be enabled but not
running, so SPTVOPT equals Enable, and SPTVSTATE equals Off or Preset. When SPTV is stored, and
the function block is active, the following will occur:
– The system calculates a ramp time (SPTVTIME), based on the normal ramp rate
– SPTVSTATE goes to Preset.
– Set SPTVSTATE equals Run. To store to SPTVSTATE, the function block must be active and to start
ramping, MODE must be Auto. When SPTVSTATE goes to Run, SP begins to ramp toward SPTV, and
SPTVTIME decreases over time. When SPTVTIME reaches zero, SP will equal SPTV, and
SPTVSTATE goes to Off. You may set the ramp time by storing to SPTVNORMRATE or SPTVTIME.
The ramp rate is derived from these two parameters and cannot be changed by the user.
• You may start ramping without specifying a ramp time. If you do, the function block calculates a ramp time
and rate (SPTVTIME and SPTVRATE) as follows:
If SPTVNORMRATE is not NaN:
SPTVRATE = SPTVNORMRATE
SPTVTIME = |(SPTV - SP)| / SPTVRATE
Otherwise,
SPTVRATE = NaN
SPTVTIME = 0, or do a step change
• If you specify a ramp time (SPTVTIME), the function block calculates a ramp rate (SPTVRATE) as follows:
If SPTVTIME is non-zero:
SPTVRATE = |(SPTV - SP)| / SPTVTIME
SPTVTIME = 0, or do a step changeOtherwise,
SPTVRATE = NaN
SPTVTIME = 0, or do a step change
• 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 = SPTVNORMRATESPTVTIME = |(SPTV - SP)| / SPTVRATE
Otherwise,
SPTVRATE = NaN
SPTVTIME = 0 or do a step change
Notes on SP target value processing

• To start ramping to set SPTVSTATE equals Run:
– MODE must be AUTO
– SPTVSTATE must be Preset
• SPTVSTATE automatically goes to Preset when:
– SPTV or SPTVTIME are stored
– MODE changes to Manual while SPTVSTATE is in Run
– The function block is initialized (INITMAN = ON) while SPTVSTATE is in Run
– Control Module goes to Inactive
Tip
A one shot initialization does not cause a change in SPTVSTATE.
• SPTVSTATE automatically goes to Off when:

– SP is stored by the operator, a user program or another function block
– MODE changes to Cascade or Backup Cascade
• SPTV and SPTVTIME can only be stored if:
– SPTVSTATE is Off or Preset, and
– MODE is Auto or Manual
• The SP limits (SPHILM and SPLOLM) cannot be changed unless SPTVSTATE is Off. This is because
SPTV is limit-checked (against the SP limits), and changing the limits could affect SP ramping.
• If the anti-reset windup status (ARWNET) indicates that SP is woundup (Hi, Lo or HiLo), then SP ramping
will stop. When ARWNET indicates that SP has returned to normal, SP ramping will continue from where it
stopped.
Tip
When SP is ramping, ARWNET is not shown on the Group or Detail displays.
313
19.5.8 Initializable outputs-ENHREGCALC

“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 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 ENHREGCALC block to SP on a PID block, Control Builder
automatically creates the BACKCALCOUT to BACKCALCIN connection.
• The ENHREGCALC 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 ENHREGCALC block (ENHREGCALC.OP) to the set point of a
PID block (PIDA.SP), the implicit/hidden connection is made to ENHREGCALC.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 ENHREGCALC output.
19.5.9 Output ranges and limits-ENHREGCALC

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, you must specify the values for CVEUHI and CVEULO.
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.
19.5.10 Assignable outputs-ENHREGCALC

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
19.5.11 Output assignment rules-ENHREGCALC

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.
• The following parameters should be assigned to an input or an expression result

– CVSRC - Since this parameter controls CV under normal conditions, when the block is not initializing
and its mode is CAScade, always assign this parameter. If this parameter is left blank or unassigned, the
Control Module containing the block is allowed to go Active, but CV is NaN and OP has a value of zero.
– CVINITSRC - Since this parameter controls CV when the block is in its initialization state, CV will get
initialized with the initialization value from the secondary, like the other regulatory control blocks, if this
parameter is not assigned. You should only need to assign CVINITSRC when CV needs to be initialized
with a customized value.
If the CV value based on CVINITSRC assignment computes to NaN, it will be replaced by the INITVAL
received from the secondary
If the CV value based on CVINITSRC assignment is used as the INITVAL for the primary and you have
assigned INITVALSRC to compute a customized INITVAL, the INITVAL for the primary will be based
on INITVALSRC.
– CVORFBSRC - Since this parameter controls CV when the block's override status is “unselected”, you
should only need to assign CVORFBSRC when CV needs to be set based on the block's override status.
The PID block is the only one that sets its CV to override the feedback value received from its secondary
when the block's override status is “unselected”. For other regulatory control blocks, CV is not affected
by the block's override status.
• The following parameters are provided to the primary through this block's BACKCALC data.
– INITREQSRC
– INITVALSRC
– ORFBVALSRC
– ORFBSTSSRC
315
– 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.
If a Parameter is . . . And, a Secondary. . . Then, This Block. . .

assigned does or does not exist uses the assigned value.
unassigned exists uses the corresponding value from the
secondary.
unassigned does not exist uses default values, such as NaN for
values and Off for flags.
19.5.12 Control initialization-ENHREGCALC

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:
CV =CVINIT (an assignable 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 will initialize itself with the value 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.
19.5.13 Output bias-ENHREGCALC

• 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 mode changes to Auto or Cascade.
Attention
recomputed.
occurs:

Where:
CVININT and OPBIAS.FLOAT will be zero. In most cases, OPBIAS.FLOAT will be zero. However, if the
parameter.
– 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:
parameter.
executes.

Where:
• NaN:
• After initialization, the ENHREGCALC block calculates the floating bias using the following equation.
317
OPBIAS.FLOAT = CVINIT - (Cvunbiased + OPBIAS.FIX)

Where:
CVunbiased = unbiased CV (It equals K*X[1], if X[1] is assigned to CV.)
OPBIAS.FIX = fixed output bias (user specified)
19.5.14 Output Indication Function-ENHREGCALC

If OUTIND Enumeration Selection Is . . . Then, Its Function Is . . .

Attention
Considerations for OUTIND Reverse selection

A Get of This Parameter . . Equals This . . .

OPLOALM.PR and .SV
A Get of This Parameter . . Equals This . . .

OPHILM = 100 - 20.
Attention
Migration and Checkpoint support for OUTIND


19.5.15 Timeout monitoring-ENHREGCALC

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.
319

19.5.16 Timeout processing-ENHREGCALC

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
19.5.17 Mode shedding on timeout-ENHREGCALC

• The ENHREGCALC 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 fetches 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.
• If you want to disable the automatic return to CAScade, you may do one of the following:
– Store to MODE, which causes the CASREQFL to be cleared.
– Store to CASREQFL.
• If a block sheds to MANual mode, it will not set CASREQFL. Consequently, it will not return to CAScade
when it fetches a good value from the primary.
19.5.18 Override feedback processing-ENHREGCALC

If the ENHREGCALC block is in a cascade strategy with a downstream OVRDSEL (Override Selector) block,
it receives override feedback data. The data consists of an override 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 ENHREGCALC block does the following:
CV = CVORFB (an assignable output)
• Computes a feedback value for its primary:
feedback value for primary = ORFBVAL (an assignable output)

feedback status for primary = ORFBSTS (an assignable 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:
feedback value for primary = feedback value received from secondary.
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.
ORFBVALSRC - Like ORFBSTSSRC, if you make an ORFBVALSRC parameter assignment, the
ENHREGCALC 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.
CVORFBSRC - If you make a CVORFBSRC parameter assignment, the ENHREGCALC block computes the
CV override feedback value based on the assignment and it sets its CV equal to the CVORFB, when the
override status for the block is “unselected”. The override status could be based on the default status received
from the secondary, when the ORFBSTSSRC parameter is unassigned, or a computed customized status based
on the CVFBSTSSRC parameter assignment.
You can write incremental (like PID block) or non-incremental (like AUTOMAN block) expressions for CV, but
certain configuration combinations may cause misleading block behavior - especially, when the expression for
CV is non-incremental. For example, if you assign CVSRC to X[1] and CVORFBSRC to C[1] with C[1]
configured as X[2], assume that at some moment X[1] is 10.0 and X[2] is 50.0, and the override status for the
block is “unselected”. This configuration produces different values for the block's CV and OP parameters.
Based on X[1], the first CV value is computed as 10.0 and the resulting OP value is 10.0. But, based on X[2],
the CVORFB value is computed as 50.0 and the block overwrites the previous CV value of 10.0 with 50.0,
resulting in different CV and OP values. In this case, assigning CVSRC to X[1] was the wrong configuration to
use. You can eliminate this type of discrepancy by assigning the CVSRC to an expression that calculates a CV
incrementally, such as CV + Delta (CV) so that Delta (CV) is the incremental value added to its previous value
of CV.
19.5.19 Windup handling-ENHREGCALC

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.
If XWLOFL and/or XWHIFL are. . . And a Secondary. . . Then, the Block Derives ARWOP
from . . .
True does or does not exist CV, XWHIFL, and XWLOFL.
False exists CV and secondary's windup status.
False does not exist CV only.
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.
321
Attention
The ARWNET[1] computation is independent of whether gain (K) is positive or negative.
19.5.20 Windup processing-ENHREGCALC

parameters.
If the Value is . . . Then, the Associated Parameter . . .


ARWOP computation
If Any of the Following are True . . . Then, ARWOP Equals . . .

initialize.
ARWNET computation
If Any of the Following are True . . . Then, ARWNET Equals . . .

NaN.
The CV is NaN
SPHIFL = On.
SPLO.FL = On.
19.5.21 Anti-Reset Windup Status-ENHREGCALC

from Sequential Control Modules (SCMs) and control algorithm block (CAB) programs.
ARWNETIN or ARWOPIN Parameter Is. . . Standard Computation Logic Is . . . ARWNET or ARWOP Parameter Is . . .
NORMAL HI HI
NORMAL LO LO
NORMAL HILO HILO
HI NORMAL HI
HI HI HI
HI LO HILO
HI HILO HILO
LO NORMAL LO
LO HI HILO
323
LO LO LO
LO HILO HILO
HILO NORMAL HILO
HILO HI HILO
HILO LO HILO
HILO HILO HILO
19.5.22 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.
Table 13: Expression operators, functions, and strings reference
Operators Description
Unary +-
Binary Arithmetic + -* / MOD (x MOD y) ^ (x^y)
Logical AND OR NOT
Relational = <> <= >= < >
Conditional ? : (For example, X ?Y : Z; similar to IF, THEN, ELSE)
Parenthesis ()
Array Syntax []
Unary Functions
ABS absolute value LOG Base 10 logarithm of a number
ATN arc tangent RND round value
COS1 cosine SGN sign of value (returns -1,0 or +1)
EXP e to the power of x SIN1 sine
INT convert to integer SQR square of a number
ISFIN is finite SQRT square root
ISNAN is Not a Number TAN1 tangent
LN Natural logarithm of a number (log to
the base of e)
Multiple Argument Functions
MIN minimum of n arguments (ignore bad MID medium value of n arguments (average of
values). middle values for even n).
If this function has a NAN argument If this function has a NAN argument (bad
(bad value), it returns NaN. value), it returns NaN.
MAX maximum of n arguments (ignore bad MUL product of n arguments.
values).
This function ignores NaN values. However,
If this function has a NAN argument if all arguments are NaN, then it returns 1.
(bad value), it returns NaN.
AVG average of n arguments. SUM sum of n arguments.
This function ignores NaN values. This function ignores NaN values. However,
However, if all arguments are NaN, if all arguments are NaN, then it returns 0.
then it returns NaN.
String Support Functions
LEN Returns an integer length of the string NUMSTR Takes the input parameter, casts it to a
Float64 and converts it to a string
MIDS Takes a string, an integer starting STRNUM Takes the string input parameter and converts
position and an integer length. The it to a Float64
function returns the specified portion
of the original string.
Time Support Functions
ABSTOD Takes an absolute time data type and DTIMNUM Takes a delta TIME data type and returns a
strips off the year and date and 64-bit float representing the number of
returns a 64-bit float representing the milliseconds.
time of day in milliseconds.
NOW Returns the current local date and NUMDTIM Takes a 64-bit float representing some
time as an absolute time data type number of milliseconds and converts it to a
delta TIME data type.
NUMTIM Takes a 64-bit float representing the STRTIM Takes a string input parameter and converts
number of milliseconds since Jan 1, it to an Absolute time. The string must be in
1972 and converts it to absolute the same format as an Absolute time
TIME data type. constant.
TOD Returns the current local time of day TIMNUM Takes an Absolute TIME data type and
as Time of Day data type returns a 64-bit float representing the total
number of milliseconds since Jan 1, 1972.
UTCTOD Returns the current UTC time of day UTCNOW Returns the current UTC date and time of
as Time of Day data type day as an absolute time data type
1Be sure you specify the trigonometric functions cosine, sine, and tangent in radians and not degrees.
Case Sensitive Strings for Special Value Constants

NAN IEEE NaN value
+INF IEEE + Infinity value
-INF IEEE - Infinity value
PI PI (3.14159. . .)
E e (2.718. . .)
19.5.23 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 effect, tag names allow
expressions to have an unlimited number of inputs, and work with any data type. Customer is concerned that the
325
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.
Expressions support the single quote character, ‘, as a special delimiter that can be used to surround the OPC
Server namespace portion of an external/OPC reference.
For example, OPCTag.‘tag.Param(1)’ can be used so that the parenthesis characters do not confuse the
expression parser.
Attention
When the expression is sent to the external reference component, the delimiters are removed: TagName.‘text’ becomes
TagName.text.
19.5.24 Guidelines for Writing Expressions

• Must include full tag.parameter name for X inputs in the expression and enclose identification number in
brackets instead of parentheses. For example, CM151.REGCALC_1.X[1] * CM151.REGCALC_2.X[2] is
valid.
• Expressions cannot contain an assignment operation (a colon followed by an equal sign with the current
syntax) For example, “PID1.MODE:=X[1]” is invalid.
Each expression produces a single value (arithmetic or logical which is automatically stored in a “C”
parameter. For example, if you write four expressions, the result of the first expression is stored in C[1], the
result of the second is stored in C[2], etc. You can use these results, by name, in succeeding expressions. In
this example, you could use C[1] as an input to expressions 2, 3, and 4.
• 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.
• You must configure calculator expressions contiguously (without breaks) in the arrays. For example, a
sample expression for calculating the average between minimum and maximum values would be as follows:
– AVG (MIN(CM1.REGCALC.X[1], CM1.REGCALC.X[2], CM1.REGCALC.X[3]),
MAX(CM1.REGCALCX[1], CM1.REGCALC.X[2], CM1.REGCALC.X[3]))
Attention
Prior to R400 releases, NUMERIC blocks were used for configuring the constant values to the Calculator blocks. With
R400 release, 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]).
CM1.CALC1.CONST[1] * CM1.CALC1.X[2] + CM2.REGCALCA.CV
• The expression constant parameters (CONST[1..8]) support runtime indexing in the expressions.
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.
Attention
When you migrate from a prior release (Pre-R400), the value of EXPRDESC[1..8] parameter is blank by default.
When you migrate to a future release, the EXPRDESC[1..8] parameter retains its values.
• With R410, when you write the expressions using the TPS point's parameter references, ensure that the TPS
reference parameter is configured using the parentheses “()”to specify array index. However, when you write
the expressions using the other non-CEE points you can use the brackets “[].”
19.5.25 Enable/Disable switch example expression

The Enable/Disable switch is used as a flag in the following user expressions.
Example 1
MIN((CM.ENHREGCALCA.XENABLE[10] = 1) ? CM.ENHREGCALCA.X [10]:<user-entered default>,
value2, value3).
Example 2
CM.ENHREGCALCA.X[1]<CM.ENHREGCALCA.X[2] and say X[1] is disabled then the CEE will evaluate
the expression as CM.ENHREGCALCA.XSUB[1]<CM.ENHREGCALCA.X[2].
In this case, if an input is disabled, the corresponding substitute value is used in the expressions.
19.5.26 String data support in expressions

The following operators can have string constants and/or string references as operands.
Operator Description
:= Assignment - used only in the SCM Step Output blocks to assign the results of an expression to a
reference.
CM.block.mystringparam := “This is a string constant”
CM.block.mystringparam := CM.desc
+ Concatenation
CM.block.mystringparam + CM.desc
= Equal to
CM.block.mystringparam = CM.desc
<> Not equal to
CM.block.mystringparam <> “This is a string”
327
19.5.27 Time support in expressions
Time data types

The following time data types are supported in expressions.
• Absolute Time - Is stored as a 64-bit integer representing the number of tenths of milliseconds since
1/1/1972.
• Delta Time - Is also stored as a 64-bit integer and it represents an Absolute time difference in tenths of
milliseconds.
• Time of Day - is an unsigned 32 -bit integer that represents a time of day in tenths of milliseconds.
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.
Time related operators

The following operators can have time constants and/or time references as operands:
Table 14: 1The DAY, HOURS, MINS, SECS Operators are not case specific.
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.
- Absolute Time can be subtracted from Absolute time, which results in a Delta Time. Delta time or
Time of Day can be subtracted from an absolute time, which results in absolute time. Time of Day can
be subtracted from Delta Time, which results in a Delta Time. See the following section Subtracting
time data types.
=, <>, <=, >=, <, Compares two operands of type time. Both operands must be of the same time data type.
>
DAYS1 Takes operand and returns equivalent delta time value.
HOURS1 Takes operand and returns equivalent delta time value.
MINS1 Takes operand and returns equivalent delta time value.
SECS1 Takes operand and returns equivalent delta time value
Adding time data types

The following table shows results of adding the various time data types
Operand 2 Data Type Operand 1 Data Type

Absolute Time Delta Time Time of Day
Absolute Time Absolute Time Absolute Time Absolute Time

Delta Time Absolute Time Delta Time Delta Time
Time of Day Absolute Time Delta Time Time of Day
Subtracting time data types

The following table shows results of subtracting the various time data types
Subtrahend Data Type Minuend 1 Data Type

Absolute Time Delta Time N/A N/A
Delta Time Absolute Time Delta Time N/A
Time expression examples

The following are examples of some valid time expressions.
• MYCM.block.elapsedtime > 5 MINS
• CEE01.CURRTIME + 2 DAYS
• CEE01.CURRTIME > 10/30/2002
• CEE01.CURRTIME + CM.TIMER.SP SECS
• (CEE01.CURRTIME - 1/01/2002 10:15:01) *2.
• STRTIM("12/01/2002") > CEE01.CURRTIME
• TIMNUM(CEE01.CURRTIME)
• NUMTIM(1000.0)=NOW
• NOW - MyCM.myblock.todparam
• ABSTOD(CEE01.CURRTIME)
The following are examples of invalid expressions.
• CEE01.CURRTIME + 2
• CEE01.CURRTIME > 5.0
Refer to “Time Support in Experion System” for more information about time support in the system
19.5.28 Restart or point activation

Initialization takes place when the block is activated or inactivated. Initialization also takes place when the ACE
controller node is repowered.
19.5.29 ENHREGCALC parameters

ENHREGCALC block.
329
19.6 FANOUT Block

The FANOUT block has one input and up to eight initializable outputs. It may also have up to eight secondaries,
since there is one secondary per initializable output. You may specify a separate gain, bias, and rate for each
output. Each specified value can be fixed or external. A fixed value is stored manually or by a program, and an
external value comes from another function block. This block calculates a separate floating bias for each output
following an initialization or mode change. This provides a “bumples” transition for each output. It looks like
this graphically:
With R410, the following parameters are introduced for configuring the on-delay time and off-delay time for
BADCTL alarms.
• BADCTLALM.TM
• BADCTLALM.TMO
Each FANOUT block supports the following user configurable attributes. The following table lists the given

information. This is the block's parameter.
NONE.
is SHEDHOLD.
331

Option is enabled.
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.

Common Output • High Limit (%) (OPHILM) - Lets you specify the output high limit as a percent
is -5%.
240.
is 0.
• Independent Output Initialization (INDPTOUTINIT) - Enabling this parameter
allows the FANOUT to respond to initialization requests on a per output basis.
Using this feature removes the need for an AUTOMAN at the output of the
FANOUT to provide a bump less output after any mode change.
333

Note
To prevent an output bump, the OPBIAS.RATE configuration is
required for the output of the FANOUT. The value of the
OPBIAS.RATE configuration (in Engineering Units per minute) must
be an appropriate value other than 0.0 (zero) or NaN (not a Number) to
enable the ramping function for the floating bias.
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).

(SIALM.PR, BADCTLALM.PR). The default value is LOW. The levels are:
display.
Summary display.
(SIALM.SV, BADCTLALM.SV) as a number between 0 to 15, with 15 being
the most severe. This determines the alarm processing order relative to other
alarms. The default value is 0.
• Deadband Time (BADCTLALM.TM) -
With R410, this parameter is introduced to define the duration in seconds during
which a process alarm reporting is suppressed. This helps in preventing the
nuisance alarms from being reported repeatedly during the process upset and
You configure the individual deadband time for BADCTLALM. However, if you
are migrating from pre-R410 to later releases, refer to “Impact of migration on
alarm attributes”.
• Off-delay Time (BADCTLALM.TMO) - With R410, this parameter is
introduced to define the duration in seconds during which an RTN reporting is
suppressed even though the alarm condition does not exist. The RTN is reported
on the Station only after this time expires and the alarm condition has returned to
normal. The default time is 0; that is RTN is reported as soon as the alarm
condition returns to normal. However, if you are migrating from pre-R410 to
later releases, the alarm off-delay time will be set as default value (0).
335

selections are:
– None
– ONESHOT
– SEMICONT
– CONTRTN
– CONT
Option Type - Lets you specify the action the function block is to take when
the SCM goes into an abnormal state. The Starting State Option
(STARTOPT) applies when the SCM state is Checking, Idle, or Complete.
The Stop/Abort State Option (STOPOPT) applies when the SCM state is
Stopping or Stopped, Aborting or Aborted. The Hold State Option
(HOLDOPT) applies when the SCM state is Holding or Hold. The Restart
State Option (RESTARTOPT) applies when the SCM state is Resume or
Run. The NONE and LASTREQ are the only selections for the Restart State
Option. You can select from one of these types for the other options as
applicable for the given regulatory control function block:
– AUTO - Set MODEREQ = AUTOMATIC (Not applicable for this block).
– HOLDPV - Set SPREQ = PV (Not applicable for this block).
– FIXED SP - Set SPREQ = Configured Value and SPRATEREQ = NaN (Not
applicable for this block).
– RAMPEDSP - Set SPREQ = Configured Value and SPRATEREQ =
Configured Rate (Not applicable for this block).
faceplate.
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
K(n) = gain for output CV(n) (user-specified)
(n) = output channel (number1 to 8)
OPBIAS(n).FIX = fixed bias for output CV(n) (user-specified)

OPBIAS(n).FLOAT = floating bias for output CV(n) (calculated)
• 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 CV may be used to calculate the OP which is given by:
OP = (CV - CVEULO) /CVEUSPANBY100
where:
CVEUSPANBY100 = (CVEUHI-CVEULO)/ 100.
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:
(n) = output channel (number 1 to 8)

CVINIT(n) = CV(n) during initialization
Attention
The FANOUT block is the only Regulatory Control Block that can have multiple secondaries.
19.6.1 Function-FANOUT block

The FANOUT block provides a “bumpless” output for each of up to eight outputs following initialization or
mode changes.
19.6.2 Configuration example-FANOUT block

See the previous figure Example of CB configuration using AUTOMAN block for an example of a FANOUT
block being used to provide multiple outputs from a single PID block.
19.6.3 Inputs-FANOUT block

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.
337
Attention
The FANOUT block:
• has 1 input and as many as 8 initializable outputs, and
• has 1 primary and up to 8 secondaries.
It requests the primary to initialize when mode changes from CAScade to MANual.
19.6.4 Outputs-FANOUT block

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.
19.6.5 Initializable inputs and outputs for FANOUT block

parameter with the “initializable” attribute has an associated BACKCALC parameter and, when a connection
to create them manually. These “implicit” build connections are “hidden” from view and the related parameter
For example, if you connect OP from a FANOUT block to an AUTOMAN block or an AOCHANNEL block,
Control Builder automatically creates the BACKCALCOUT to BACKCALCIN connection.
• For a given secondary, a connection to OP or OPEU may be created, but not to both. (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.)
• A separate gain and bias may be specified for each output.
• The FANOUT block applies a separate floating bias to each output.
• Gain limits may be configured with negative values, thereby making it possible to reverse outputs by using
negative gains.
• The FANOUT block provides the X1 input range (XEUHI/XEULO) to the primary through BACKCALC.
The primary uses this for its output range (CVEUHI/CVEULO).
19.6.6 Output ranges for FANOUT block

• 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.
– OP is clamped to these limits if the algorithm's calculated result (CV) exceeds them or another function
block or the user program attempts to store an OP value that exceeds them. However, the operator may
store an OP value that is outside these limits.
These are user-specified values. The same limits apply to all outputs. The operator is prevented from storing
an OP that exceeds these limits.
19.6.7 Output bias-FANOUT block

is later checked against OP limits and, if no limits are exceeded, 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.
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
– When the mode changes to Cascade (as applicable for the given block).
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.
occurs:
The OPBIAS.FLOAT is calculated as follows.

Where:
339
parameter.
• You configure the OPBIAS.RATE to apply a ramprate to the OPBIAS.FLOAT. It is only used when the
– Zero:
– Non-zero:
parameter.
– The function block ramps the OPBIAS.FLOAT to zero by applying the following calculation each time it
executes.

Where:
• NaN:
19.6.8 Mode handling-FANOUT block

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).
19.6.9 Timeout monitoring-FANOUT block

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).
• Sets the input value to Bad (NaN - Not a Number).
• Requests the X1 primary to initialize (through X1BACKCALCOUT).
The FANOUT block does not support mode shedding on timeout.
• Disable timeout monitoring by setting TMOUTTIME to zero
Attention
19.6.10 Control initialization-FANOUT block

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
Note
The gain value should be greater than zero.
• Where:
(last) = last or most recent secondary to request initialization. When more than one
secondary requests initialization simultaneously and the FANOUT initializes,
“las” will be the secondary with the lowest index number from the secondaries
that requested initialization.
CV calculated value
OPBIAS(last).FIX = fixed output bias for the last secondary
K(last) = gain for the last secondary
Note
INITREQ(X1) = initialization request flag for the X1 primary

INITVAL(X1) = initialization value for the X1 primary
341
Attention
• SECINITOPT may be used to ignore initialization requests from selected secondaries.
• When more than one secondary initializes simultaneously and the FANOUT block initializes, the “LAST” in the
previous equation represents the secondary corresponding to the lowest numbered output that requested
initialization.
• The FANOUT block performs initialization only if all of the secondaries are requesting it. As long as one
secondary is not requesting initialization, the FANOUT block ignores all requests. Therefore, one of the following
is recommended:
– Use an AUTOMAN block between a FANOUT block output and a given AOCHANNEL block to provide a
bumpless output after any mode change. However, to prevent a bump in the output, you must configure the
OPBIAS.RATE parameter in AUTOMAN block 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.
– Configure Independent Output Initialization (INDPTOUTINIT) for the FANOUT to provide a bumpless
output after any mode change. Additionally, you must configure the FANOUT block output with an
OPBIAS.RATE parameter with 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.
• When FANOUT block comes out of initialization, it calculates INITVAL(X1) as follows:
• Where:
(Index) = output channel number (1 to 8) corresponding to the secondary which is not

requesting initialization any more. If more than one secondary stops requesting
initialization simultaneously, “Inde” represents the secondary corresponding to
the lowest numbered output that stopped requesting initialization.
19.6.11 Secondary initialization option-FANOUT block

• If SECINITOPT equals Enable, it means the function block should accept initialization and override
• If SECINITOP equals Disable, it means the function block should ignore initialization and override requests
from the secondary.
Since the FANOUT block can have up to eight secondaries, you can selectively enable/disable the
SECINITOPT for each output.
19.6.12 Override feedback processing-FANOUT block

The FANOUT block does not propagate override data to its primaries.
19.6.13 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:
1. 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.
2. Refer to Windup Processing below.
19.6.14 Output Indication Function


Attention

A Get of This Parameter . . . Equals This . . .

343

OPLOALM.PR and .SV
OPHILM = 100 - 20.
Attention


Examples of OUTIND coordination with OPTDIR and CTLACTN parameters

The OUTIND, OPTDIR and CTLACTN parameters affect the view of OP parameters, the OP value sent to the
valve, and control action where the OP should increase or decrease as a result of change in the error value.
The following example scenarios show how OUTIND on a PID block can be used in conjunction with the
Output Direction (OPTDIR) parameter of an AOCHANNEL block to achieve the desired configuration. The
Control Action (CTLACTN) parameter on the PID block is normally chosen independent of the OUTIND and
OPTDIR values, so CTLACTN is not included in the examples.
For This Scenario . . . Typical Settings Are . . .

Fail close valve; air to open - normal case • PID OUTIND = Direct
• AOCHANNEL OPTDIR = Direct
• PID OP 0% translated to 4 mA by the AO,
corresponding to the valve closed
corresponding to the valve open
• Unpowered state of AO results in 0 mA and valve
closed
Fail open valve; air to close - reversal handled in AO • PID OUTIND = Direct
channel • AOCHANNEL OPTDIR = Reverse
• Unpowered state of AO results in 0 mA and valve open
Fail open valve; air to close - display indications highlight • PID OUTIND = ReverseDispInd
reverse acting valve • AOCHANNEL OPTDIR = Direct
19.6.15 Windup processing in FANOUT block

Windup is propagated only if all secondaries agree. The FANOUT block uses the windup status from all
secondaries regardless of SECINITOPT. The FANOUT block only propagates a high or low windup status to its
primary under the following conditions:
• If all secondaries are in high windup, the FANOUT block propagates a high windup status to its primary
(ARWNET = Hi).
• 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 wind up on that output will be 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.
19.6.16 Windup processing in Regulatory blocks

parameters.
345


ARWOP computation

initialize.
ARWNET computation

NaN.
The CV is NaN

SPHIFL = On.
SPLO.FL = On.
19.6.17 Anti-Reset Windup Status

NORMAL HI HI
NORMAL LO LO
NORMAL HILO HILO
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 NORMAL HILO
HILO HI HILO
HILO LO HILO
347
HILO HILO HILO
19.6.18 FANOUT parameters

FANOUT block.
19.7 OVRDSEL (Override Selector) Block

The OVRDSEL block accepts up to four inputs (primaries) and selects the one with the highest or lowest value.
It looks like this graphically:
• OPHIALM.TM
• OPHIALM.TMO
• OPHIALM.DB
• OPHIALM.DBU
Each OVRDSEL block supports the following user configurable attributes. The following table lists the given
349

information.
• Control Equation (CTLEQN) - Lets you select Equation A or B to define if the
block is to select the highest or the lowest non-bypassed inputs. The default
selection is EQA, which means the block selects the highest non-bypassed
inputs.
• Enable Override Option (OROPT) - Lets you specify if the override option is to
be enabled or not. This determines if the block propagates override feedback
data to the non-selected inputs or not. The default selection is disabled
(unchecked or OFF), which means the feedback data is not propagated.
• Enable Override Offset (OROFFSET) - Lets you specify if an upstream PID
block should apply a calculated offset to the propagated feedback value or not.
This only applies when the OROPT is enabled (checked or ON). The default
selection is disabled (unchecked or OFF), which means the PID block does not
apply an offset to the feedback value.
The default selection is enabled (checked, do not ignore).
NONE.

is SHEDHOLD.
Option is enabled.
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.
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.
• Description - Lets you enter up to a 15-character description for each input
(X[1..4]). The description is stored in the XDESC[1..4] parameter and is copied
to the SELXDESC parameter when the corresponding input is selected. This
means SELXDESC is automatically updated whenever SELXINP is updated.
• Bad Input Option (BADINPTOPT[1..4]) - Lets you specify whether the block is
to include or ignore an input with bad values in its selection process. The default
selection is INCLUDEBAD, which means the block's CV value is set to NaN
(Not a Number).
• Bypass (ORBYPASSFL[1..4]) - Lets you specify whether a given input is to be
bypassed or not. If a given input flag is ON (checked), this input is not used in
the block's selection process. The default selection is OFF (unchecked), which
means the input is not bypassed.
If all inputs are bypassed, the block holds its CV at its last value.
351

is -5%.
481.05 + 50 (CVEULO) equals 531.05. The default value is 106.9%.
+ 50 (CVEULO) equals 18.95. The default value is -6.9%.

display.
Summary display.
353

OVRDSEL block. If you configure the deadband unit as “EU or Percent” for an
alarm, this configuration is identical for the all other alarms in the OVRDSEL
Note: You must configure identical deadband units for all alarms in the
OVRDSEL block.
Note: This parameter is available for configuration only if the Enable Bad Output
default value (0).

selections are:
– None
– ONESHOT
– SEMICONT
– CONTRTN
– CONT
block:
– AUTO - Set MODEREQ = AUTOMATIC (Not applicable for this block).
– HOLDPV - Set SPREQ = PV (Not applicable for this block).
– FIXED SP - Set SPREQ = Configured Value and SPRATEREQ = NaN (Not
applicable for this block).
Configured Rate (Not applicable for this block).
faceplate.
information
19.7.1 Function-OVRDSEL block

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.
355
If OROPT is . . . Then, . . .
ON This block propagates override feedback data to the unselected inputs. And, if the inputs come
from cascade strategies, this block provides override feedback data to every upstream block in
every unselected path.
OFF The feedback value is not propagated but behaves as a simple high-low selector. However, the
unselected primaries are kept from winding up by propagating a windup status opposite to the
override equation. This windup propagation prevents the unselected primaries of the selector
from winding up in the direction opposite to the selector equation.
The windup propagation is done whether OROPT is ON or OFF.

The override feedback method of tracking is different from tracking by initialization in the following way:
• With initialization, the upstream blocks set their output based solely on the initialization value from their
secondary. They do not fetch inputs or perform their normal algorithm calculations.
• Override feedback is a two-step process.
1. The override feedback data is propagated to all of the blocks in an upstream cascade and they set their
outputs accordingly. The data consists of an override status (FBORSTS, which indicates if the primary is
selected or not), an override feedback value (internal, which is calculated to prevent “wind-up” in unselected
primaries), and an override offset flag (internal), which indicates how the feedback value should be
calculated.
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.
• The advantages are, there are no limitations on the number of blocks in an override strategy or where the blocks
reside.
• The disadvantage is, if propagation is interrupted, the blocks above the interrupt point will be using override data
that is older than the blocks below it. Override data above this point will typically lag by one or two cycles.
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.
19.7.2 Configuration example-OVRDSEL block

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.
Table 15: Example of CB configuration using OVRDSEL block.
The following table includes descriptions of the callouts in figure above.
Callout Description
1 Use the PV parameter connection to carry data from the analog input to the PID block. The default PV
value/status parameter (PVVALSTS) when it is required.
2 When monitoring Control Module, the FBORSTS parameter shows whether the PID block is selected or
not. You must configure the FBORSTS parameter to appear on the faceplate of the block through the
Monitoring Parameters tab in the block configuration form.
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.
357
Callout Description
4 Use the BACKCALCIN/BACKCALCOUT connection to carry secondary data from the OVRDSEL block
to the primary PID block. The individual BACKCALCIN/BACKCALCOUT connections for each output
used are automatically built by Control Builder as implicit/hidden connections.
The secondary data includes this information.
• Anti-Reset Windup Status: Indicates if the secondary's initializable input (which is this block's output)
is at its high or low limit.
• Initialization Request Flag: Used to request continuous initialization. If the flag is set (and this block is
configured to accept secondary initialization), this block initializes itself for one cycle, and resumes
normal processing on the next.
• Oneshot Initialization Flag: Used to request one shot initialization. If the flag is set (and this block is
• Initialization Value: Used for continuous and one shot initialization.
• Override Status: If a block is in an override strategy, this flag indicates whether it is the selected
strategy or not. If the block is in an unselected strategy (and configured to accept secondary
initialization), it invokes its override feedback processing.
• Override Feedback Value: Similar to initialization value; this is calculated to prevent “wind-up” in
unselected primaries.
• Override Offset: Only applies to PID type function blocks. If a PID is in an unselected override
strategy, this flag indicates how it should calculate its output.
• Engineering Units: The engineering units (EU) of the secondary's initializable input. For example, If
the secondary's input is SP, it sends SPEUHI and SPEULO to the primary. The primary then sets its CV
range (CVEUHI and CVEULO) to this.
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.
19.7.3 Configuration considerations-OVRDSEL block

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.
19.7.4 Inputs-OVRDSEL block

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.)
19.7.5 Input ranges for OVRDSEL block

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.
19.7.6 Input descriptors-OVRDSEL block

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.
19.7.7 Initializable outputs-OVRDSEL block

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
The OVRDSEL 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 to 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 connection when required. For example, if you
connect the output from a PID block (PIDA.OP) to the input of an OVRDSEL block (OVRDSEL1.X1), the
implicit/hidden connection is made to PIDA.OPX to provide value/status data.)
359
19.7.8 Output ranges and limits for OVRDSEL block

• CVEUHI and CVEULO define the full range of CV in engineering units.
• This block doesn't have CVEUHI and CVEULO as configurable parameters for the reasons given below:
– If this block has a secondary, it brings the secondary's input range through BACKCALCIN and sets its
CV range to that.
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
– 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.
19.7.9 Output Indication Function-OVRDSEL block

You choose from the following configuration selections to tailor the block#39;s output to meet your particular

Attention


OPLOALM.PR and .SV
OPHILM = 100 - 20.
Attention


361
19.7.10 Mode handling-OVRDSEL block

This function block supports the Cascade and Manual modes.
If MODE is . . . Then, . . .
Cascade All inputs must be pulled from another function block.
Manual OP may be stored by the operator or a user program. (All inputs are ignored.)
CAScade.
19.7.11 Timeout monitoring-OVRDSEL block

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.
19.7.12 Timeout processing-OVRDSEL block

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
19.7.13 Bypass processing-OVRDSEL block

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.
19.7.14 Bad input option

The block can include or ignore inputs with bad values (NaN) per input, by setting the parameter
BADINPTOPT[1..4].
• BADINPTOPT- Bad Input Option enable. Indicates if the function block should include bad inputs (NaN) in
the selection process.
• BADINPTOPT has the following options:
– IgnoreBad (Ignore bad inputs)
– IncludeBad (Include bad inputs)
When an input goes bad and its BADINPTOPT(i) is set to IncludeBad, then the OVRDSEL's CV is set to NaN.
When an input goes bad and its BADINPTOPT(i) is set to IgnoreBad, then the OVRDSEL ignores that input in
its processing and will select one of the other inputs based on its configured equation (High or Low selector).
19.7.15 OVRDSEL 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:
CV = the highest input + OPBIAS.FIX + OPBIAS.FLOAT
• Equation B - select the lowest of the non-bypassed inputs:
CV = the lowest input + OPBIAS.FIX + OPBIAS.FLOAT
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].
19.7.16 Input switching

This block provides bumpless switching by applying a floating bias to the output, regardless of whether OROPT
is On or Off.
19.7.17 Output bias-OVRDSEL

• 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)
363
Where:
cycles_per_min=number of times the function block executes per minute (calculated)
• NaN:
19.7.18 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:
• resets the Bad Control flag (BADCTLFL)
• requests the bypassed primaries to initialize (i.e., sets INTREQ(n) to On when ORBYPASSFL(n) is On)
19.7.19 Control initialization-OVRDSEL

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:
CV = initialization value from the secondary
• sets SELXINP = None
• builds initialization requests for the primaries:
If this block is in the Manual mode, it requests all primaries to initialize. Otherwise, it only requests the
bypassed primaries to initialize. It builds initialization requests as follows:
• INITREQ(n) = On
• INITVAL(n) = CV
where:
(n)=dentifies the primary to be initialized
INITREQ=initialization request flag for primary
INITVAL=initialization value for primary
19.7.20 Restart or function block activation

When this function block is activated, or on a warm restart, it does the following:
• Sets CV = initialization value from the secondary, and
• Requests all primaries to initialize (That is set all INTREQ flags On, and set INITVAL = CV).
19.7.21 Override feedback propagation

This block propagates override feedback data to the upstream blocks if it is,
• in the Cascade mode,
• not initializing, and
• OROPT is ON.
If these conditions are true, this block provides the following data to every upstream block:
• Override status - This status indicates if the upstream block is on the selected input path or not. Possible
values are:
Value Sent to
SEL (Selected) all blocks on the selected input path.
NotCon (Not Connected) all blocks on bypassed input paths.
NotSel (Not Selected) blocks on unselected, non-bypassed paths.
• 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.
– Additionally, the Gain *(PVP - SPP) term is set to 0.0; If:
– Gain *(PVP - SPP) > 0.0 and the downstream OVRDSEL block is a High selector. Or,
– Gain *(PVP - SPP) < 0.0 and the downstream OVRDSEL block is a Low selector.
19.7.22 Recommendations on configuring override strategies

• While PIDs in an override strategy can be configured with proportional and derivative action, use of these
actions should be carefully considered because undesired results may occur, such as momentary oscillations
caused by “kicks” in the error.
• We do not recommend using a PID with External Reset Feedback in an override strategy.
• If override propagation is interrupted, the blocks above the interrupt point are using override data that is
older than the blocks below it. Override data above this point typically lags by one or two function block
cycles.
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 seven blocks in each input cascade.
19.7.23 Windup processing

parameters.

365

ARWOP computation

A secondary exists and its windup state equals HiLo.
initialize.
PVSTS = MAN and PVMANOPT = NO_SHED.
ARWNET computation

This block is in Manual mode (MODE = MAN).
NaN.
The CV is NaN.
This block is connected to a non-initializable primary.

will be the opposite of ARWOP).
SPHIFL = On.
limit (OPROCPOSFL = On).
SPLO.FL = On.
limit (OPROCNEGFL = On).

NORMAL HI HI
NORMAL LO LO
NORMAL HILO HILO
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 NORMAL HILO
HILO HI HILO
HILO LO HILO
HILO HILO HILO
367
19.7.25 OVRDSEL parameters

OVRDSEL block.
19.8 PID Block

The PID block is a regulatory control block that operates as a proportional-integral-derivative (PID) controller.
It supports the Ideal form of calculating the PID terms. The Ideal form is often called the digital-computer
version of the PID controller. The PID block looks like this graphically:
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
• Integral (I) only
• Proportional (P) only
The PID block may be used in a single control loop or with multiple PIDs in a cascade strategy. The following
figure shows two PID controllers being used for simple cascade control where the output of a temperature
controller is used as the set point of a flow controller.
369
Table 16: Simple cascade control loop example.
• OPHIALM.TM
• OPHIALM.TMO
• OPHIALM.DB
• OPHIALM.DBU
The following parameters can be used for configuring the on-delay time and off-delay time for the
BADCTLALM alarm.
• BADCTLALM.TM
• BADCTLALM.TMO
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.

information.
• PVEU Range High (PVEUHI) - Lets you specify the high input range value in
engineering units that represents 100% full scale PV input for the block. The
default value is 100.
• PVEU Range Low (PVEULO) - Lets you specify the low input range value in
engineering units that represents the 0 full scale PV input for the block. The
• Manual PV Option (PVMANOPT) - Lets you specify the mode and output the
block is to assume when PVSTS changes to MANual. The selections are:
– NOSHED - No changes.
– SHEDHOLD - Sets MODE to MANual and MODEATTR to Operator,
disables external mode switching (ESWPERM), and holds output at the last
good value.
– SHEDLOW - Sets MODE to MANual and MODEATTR to Operator,
disables external mode switching (ESWPERM), and sets output to its
extended low limit (OPEXLOLM) value.
– SHEDHIGH - Sets MODE to MANual and MODEATTR to Operator,
extended high limit (OPEXHILM) value.
– SHEDSAFE - Sets MODE to MANual and MODEATTR to Operator,
disables external mode switching (ESWPERM), and sets output to the
configured safe output (SAFEOP) value.
• The default selection is SHEDHOLD.
• The block requests its primary to initialize after a mode shed or lets the primary
know that it is woundup, if it does shed its mode. An operator can change the
block's mode after it is shed, but, the operator must first set PVMANOPT to
NOSHED, so the mode doesn't shed again.
When PVSTS returns to normal, the block clears its primary initialization
request but remains in MANual mode after a mode shed. An operator must
return the block to its normal mode. If mode was not shed, the block clears its
windup condition and does a one shot initialization. It also requests the primary
to do a one shot initialization.
NONE.
371

output. Blocks strictly enforce the MODE assignment. For example, if the
MODE is CAScade and the block is getting its SP from another block, an
operator is prevented from overwriting the SP value. However, If there is a
breakdown in the cascade loop, the MODE can be changed so an operator can
write a value to the SP. Some function blocks perform automatic mode switching
(or mode shedding), while others require manual intervention. The block's
MODE is derived at “runtime” based on current conditions. MODE processing
checks for the following conditions, and changes the block's MODE as
appropriate.
is SHEDHOLD.
Option is enabled.

Algorithm • Control Equation Type - Lets you select the control equation the block is to use.
The selections are EQA, EQB, EQC, EQD, and EQE. See the PID Equations
section for this block for details. The default selection is EQA.
• Control Action - Lets you specify if the block is to provide direct or reverse
control action. The default selection is REVERSE, which means output
decreases as input increases.
• T1 (minutes) (T1) - Lets you set integral time to be used for the integral term in
the control equation.
• T1 High Limit (minutes) (T1HILM) - Lets you define the high limit value in
minutes for the integral time setting. The default limit is 1440.
• T1 Low Limit (minutes) (T1LOLM) - Lets you define the low limit value in
• T2 (minutes) (T2) - Lets you set the derivative time to be used for the derivative
term in the control equation.
minutes for the derivative time setting. The default limit is 1440.
• High Gain Limit (GAINHILM) - Lets you set a high limit for the gain (K) value.
If this value is exceeded, K is clamped to this limit. The default value is 240.
• Low Gain Limit (GAINLOLM) - Lets you set a low limit for the gain (K) value.
If K is less than this value, it is clamped to this limit. The default value is 0.
• Gain Options (GAINOPT) - Lets you select the type of gain term to be used in
the PID equation. The default value is LIN. The selections are:
– LIN - The LINear gain option provides a proportional control action that is
equal to a constant (K) time the error (PV -SP). This applies to equations A,
B, and C.
– GAP - The GAP gain option reduces the sensitivity of the control action
when the PV is in a user-specified band (gap) around the set point. This
applies to equations A, B, and C.
– NONLIN - The NONLIN gain option provides a proportional control action
that is equal to the square of the error, rather than the error itself. This
– EXT - The EXTernal gain option modifies the gain (K) by an input value
from either the process, another function block, or a user program. You can
use this option to compensate for nonlinear process gain - lets you tune the
PID gain independent of the normal operating point of the process. For
example, If you are controlling the level of tank whose cross-section is not
constant, you can use the EXT option to modify the gain to compensate for
the nonlinear rate of level change, which is caused by the changing shape of
the tank. This applies to equations A, B, and C.
• Overall Gain (K) - Lets you set the overall gain value used to calculate the
proportional term in the PID equation. The default value is 1.
• Gap High Limit (GAPHILM) - Lets you define the high limit value in PV
engineering units to be used when calculating GAP gain.
• Gap Low Limit (GAPLOLM) - Lets you define the low limit value in PV
• Gap Gain Factor (KMODIFGAP)- Lets you specify the value to be used for
calculating overall gain (K) when the PV input is within the user specified band
(GAPLOLM - GAPHILM) around the SP. The value range is 0.0 to 1.0.
• Linear Gain Factor (KLIN) - Lets you specify the value to be used for
calculating the overall gain (K) in association with GAP, NONLIN, or EXT gain
option.
373

• Non-Linearity Form (NLFORM) -Lets you specify the non-linearity form (0 or
1) to be used for calculating gain (K) based on the formula shown for Non
Linear Gain in the Gain Options section. The default value is 1.
• Non-Linear Gain Factor (NLGAIN) -Lets you specify the non-linear gain value
to be used for calculating gain (K) based on the formula shown for Non Linear
Gain in the Gain Options section. The default value is 0.
• External Gain Factor (KMODIFEXT) - Lets you specify an input value from
either the process, another function block, or a user program to be used to
modify the gain (K) calculation per this formula:
K = KLIN *KMODIFEXT
See External Gain in the Gain Options section for more details. The default
value is 1.
• Legacy Gap: An option which allows the user to revert back to older GAP and
Nonlinear gain calculations so that there is no change in behavior after migration
from TPS to Experion The option when enabled will allow the Experion
controllers to have the same behavior as the TPS xPM controller. See

SetPoint • SP (SP) - Lets you specify an initial set point value. The default value is 0.
MANual.
• 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.
• Enable PV Tracking (PVTRAKOPT) - Lets you specify if PV tracking is to be
applied to this block or not. When PV tracking is enabled, this option sets the SP
equal to PV when the operation of a cascade loop is interrupted by either
initialization, operator or program operation (such as, setting the MODE to
MANual). This option is normally enabled for PIDs in a cascade loop. The
default selection is unchecked (disabled). See the PV tracking section for this
block for more details.
• Enable PV Tracking in Auto/Init (PVTRAKOPTAI) - Lets you specify if PV
Tracking option for the specific case when the block is in Auto mode and it is
undergoing initialization (INITMAN is ON) is be enabled or not. The default
selection is unchecked (disabled).
• Max. Ramp Deviation (SPTVDEVMAX) - Lets you specify a maximum ramp
deviation value in engineering units per minute for the SP ramping function,
when it is enabled. Keeps PV within the specified deviation range for a ramping
SP by stopping the SP ramp until the PV input catches up with the SP value. The
default value is NaN, which means no ramp deviation check is made. See the Set
point ramping section for this block for more details
375

• Enable SP Push: (PUSHSP) - Lets you specify that the PID SP will be pushed
from an Inter Cluster Gateway when the PID is the secondary of a cascade that
extends over two Experion clusters.

is -5%.
(NaN), which means the OP is held at its last good value. ‘
• CVEU Range High (CVEUHI) -Lets you specify the high output range value in
engineering units that represents 100% full scale CV output for the block. The
• CVEU Range Low (CVEULO) - Lets you specify the low output range value in
engineering units that represents the 0 full scale CV output for the block. The
377


– Deviation High (DEVHIALM.FL)
– Deviation Low (DEVLOALM.FL)
– Advisory Deviation (ADVDEVALM.FL)
• Enable Alarm (ADVDEVOPT and SIALM.OPT ) - Lets you enable or disable
Advisory Deviation and/or Safety Interlock alarm types. A check in the box
means the alarm is enabled. The default selections are unchecked or Disabled for
Advisory Deviation and checked or Yes (enabled) for Safety Interlock.
You can also configure the ADVDEVOPT and SIALM.OPT parameters as a
block pins, configuration and/or monitoring parameters so they appear on the
block in the Project and Monitoring tree views, respectively.
• Trip Point - Lets you specify the following trip points for the given alarm. The
default value is NaN, which disables the trip point.
– OPHIALM.TP (Output High Alarm Trip Point)
– OPLOALM.TP (Output Low Alarm Trip Point
– DEVHIALM.TP (Deviation High Alarm Trip Point)
– DEVLOALM.TP (Deviation Low Alarm Trip Point)
– ADVDEVALM.TP (Advisory Deviation Alarm Trip Point)
(OPHIALM.PR, OPLOALM.PR, DEVHIALM.PR, DEVLOALM.PR,
ADVDEVALM.PR, SIALM.PR, BADCTLALM.PR,). The default value is
LOW. The levels are:
display.
Summary display.
(OPHIALM.SV, OPLOALM.SV, DEVHIALM.SV, DEVLOALM.SV,
ADVDEVALM.SV, SIALM.SV, BADCTLALM.SV,) as a number between 0 to
15, with 15 being the most severe. This determines the alarm processing order
relative to other alarms. The default value is 0.
379

• Deadband Time (xxxxALM.TM) - Defines the duration in seconds during which
a process alarm reporting is suppressed. This helps in preventing the nuisance
alarms from being reported repeatedly during the process upset and improves the
efficiency of the operator. Once you configure this value for an alarm, the alarm
is reported on the Station only if the alarm condition continues to exist even after
this value expires. The default time is 0; that is the alarm is reported as soon as
the alarm condition occurs.
late releases, refer to “Impact of migration on alarm attributes”.
With R410, you cannot individually configure the deadband unit for the PID
block. If you configure the deadband unit as “EU or Percent” for an alarm, this
configuration is identical for the all other alarms in the PID block. However, if
you are migrating from pre-R410 to later releases, refer to “Impact of migration
on alarm attributes”.
You must configure identical deadband units for all alarms in the PID-PL block.
default value (0).

selections are:
– None
– ONESHOT
– SEMICONT
– CONTRTN
– CONT
block:
Configured Rate.
faceplate.
information
381
19.8.1 Function-PID Block

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 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.
19.8.2 Functional scenario-PID Block

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.
Table 17: Functional block diagram of typical PID cascade operation.
The functional steps associated with this PID operating scenario are listed in the following table.
1. The PID1 provides a value to the PID2 SP variable (before the PID1 executes).
2. The PID1's “Execute” method is called by the CEE (Control Execution Environment). The PID execution
period is configurable.
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.
5. The PID1 checks SI, ESWAUTO, ESWCAS and ESWMAN to see if an external source wants to invoke
Safety Interlock processing or change the Mode.
6. The PID1 reads BACKCALCIN from the secondary, and decides if windup or initialization processing is
required. The BACKCALOUT to BACKCALIN connection is hidden.
7. The PID1 performs SP processing. (SP processing options are specified at configuration time.)
8. The PID1 calculates an output, based on PV and SP values and the configured algorithm.
9. The PID1 performs limit checking and alarming (if required) on OP.
10. The PID1 stores OP to the secondary.
11. The PID1's “Execute” method completes.
19.8.3 Configuration examples-PID Block

• 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 quick reference. The view in following
figure depicts a loaded configuration in Monitoring mode.
383
Table 18: Example of CB configuration using a PID block for single loop control.
1. Use the PV parameter connection to carry data from the analog input to the PID block. The default PV
2. Use the BACKCALCIN/BACKCALCOUT connection to carry secondary data from the AOC block to the
primary PID block. If the PIDA block were a secondary block, its BACKCALCOUT pin connection would
be connected to the BACKCALCIN pin connection on its primary PID block. The individual
BACKCALCIN/BACKCALCOUT connections for each output used are automatically built by Control
Builder as implicit/hidden connections.
The secondary data includes this information.
• Anti-Reset Windup Status: Indicates if the secondary's initializable input (which is this block's output) is
at its high or low limit.
• Initialization Request Flag: Used to request continuous initialization. If the flag is set (and this block is
• Oneshot Initialization Flag: Used to request one shot initialization. If the flag is set (and this block is
• Initialization Value: Used for continuous and one shot initialization.
• Override Status: If a block is in an override strategy, this flag indicates whether it is the selected strategy
or not. If the block is in an unselected strategy (and configured to accept secondary initialization), it
invokes its override feedback processing.
• Override Feedback Value: Similar to initialization value; this is calculated to prevent “wind-up” in
unselected primaries.
• Override Offset: Only applies to PID type function blocks. If a PID is in an unselected override strategy,
this flag indicates how it should calculate its output.
• Engineering Units: The engineering units (EU) of the secondary's initializable input. For example, If the
secondary's input is SP, it sends SPEUHI and SPEULO to the primary. The primary then sets its CV
range (CVEUHI and CVEULO) to this.
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.
Table 19: Example of CB configuration using two PID blocks for cascade loop control.
1. Use the PV parameter connection to carry data from the analog input to the PID block. The default PV
2. Use the OP parameter connection to send output data to another 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.
385
3. Use the BACKCALCIN/BACKCALCOUT connection to carry secondary data from the AOC block to the
secondary PID block and from the secondary PID block to the primary PID block. The individual
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.
19.8.4 Operating modes and mode handling-PID Block

The PID block operates in the following modes:
• MAN (MANual)
– If mode is MANual, OP may be stored by the operator or a user program; PV and SP are ignored - if a
primary exists, it goes to the initialized state.
• AUTO (AUTOmatic)
– If mode is AUTOmatic, SP (or SPP) may be stored by the operator or a user program; if a primary exists,
it goes to the initialized state. SP contains set point value in engineering units and SPP contains the value
in percent.
• 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 PID block invokes timeout processing.
19.8.5 Required inputs-PID Block

The required number of inputs is determined by the mode of the PID 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 or a user program.
– The PID block may have one primary or none, depending on whether SP is configured or not; there is
one primary per initializable input.
19.8.6 Input ranges and limits-PID Block

• You must specify a PV engineering unit range, PVEUHI and PVEULO.
– PVEUHI and PVEULO define the full range of PV in engineering units.
– PVEUHI represents the 100% of full scale value.
– PVEULO represents the 0% of full scale value.
– PVEUHI and PVEULO also define the engineering unit range of SP - PV and SP are assumed to have
the same range.
• The PID 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 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.
19.8.7 Initializable outputs-PID Block

variable with the “initializable” attribute has an associated BACKCALC variable, and when a connection is
Control Builder automatically builds the required BACKCALC connections, so you don't have to create them
For example, if you connect OP from a PID block to a PID block or an AOCHANNEL block, Control Builder
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
multiple connections from a single PID output.
19.8.8 Control initialization-PID Block

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
– sets initialization request parameters for its primary
INITREQ = On
INITVAL = SP
19.8.9 Output bias-PID Block

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.
387
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
Attention
recomputed.
occurs:
OPBIAS.FLOAT=CVINIT - (CVUNBIASED + OPBIAS.FIX)
Where:
CVINIT=initialization value received from the secondary
CVUNBIASED= unbiased calculated value (based on input from the primary)
OPBIAS.FIX=fixed bias (user-specified)
parameter.
– Zero:
– Non-zero:
parameter.
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.
19.8.10 Output ranges and limits-PID Block

– If the PID block has a secondary, its CV range must be the same as the secondary's input range - if this
PID function has a secondary, it brings the secondary's input range through BACKCALC and sets its CV
range to that.
– If the PID block has no secondary, CVEUHI and CVEULO must be specified.
– Note that this PID 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
– 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.
19.8.11 Direct or reverse control-PID Block

A PID block may be configured for direct-control action or reverse-control action.
Changing the control action effectively changes the sign of the gain.
• With direct-control action, an increase in the error (PV - SP) increases the PID output (CV).
• With reverse-control action, an increase in the error (PV - SP) decreases the PID output (CV).
For example, if SPP = 50% and PVP = 51%, then the error is 1%.
• With direct-control action, if PVP changes to 52%, the error increases causing CV to increase.
• With reverse-control action, if PVP changes to 52%, the error increases causing CV to decrease. .
19.8.12 Set Point Ramping-PID Block

The Set Point Ramping option lets you ramp from the current set point value to a target set point value. You
enable this option by selecting the Enable SP Ramping check box on the block's parameter configuration form.
This is equivalent to setting the SPTVOPT parameter to Enable. You can also configure the following related
parameters through the configuration form or the equivalent parameters.
389
Normal Ramp Rate Normal ramp rate value in engineering units that you enter. The value can be Not a
(SPTVNORMRATE) 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.
This parameter lets you start SP ramping without specifying a ramp time. This
function block calculates a ramp time (SPTVTIME) and ramp rate (SPTVRATE)
as follows, when SP ramping is enabled:
• If SPTVNORMRATE is a value other than zero or NaN:
• Otherwise,:
SPTVRATE = NaN
SPTVTIME = 0 (That is, do a step change.)
Max. Ramp Deviation Lets you specify a maximum deviation in engineering units per minute allowed
(SPTVDEVMAX) 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.
If the maximum ramp deviation value is other than NaN, SP ramping stops when
the absolute value of the deviation (|PV - SP|) exceeds the maximum deviation.
And also SP Ramping will pause/stops when the calculated SP increment would
cause the SP to exceed the deviation limit, the SP is paused at the current value,
which may be less than the deviation limit value.
The deviation flag (SPTVDEVFL) is set, and SP ramping state (SPTVSTATE)
remains in Run. Ramping resumes as soon as the absolute value of the deviation
returns within the maximum deviation limit. This also resets the deviation flag
(SPTVDEVFL).
If you have entered a ramp time (SPTVTIME) and ramping is interrupted by
maximum ramp deviation, the actual ramp time (SPTVTIME) will be greater than
the time you specified.
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.
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).
• The SPTVSTATE goes to Preset.
• A “P” modifier appears next to the SP value on the PID detail display in Station.
SPTVDEVFL SP target value deviation flag indicates when deviation exceeds the maximum ramp
deviation limit.
SPTVRATE SP target value ramp rate. This rate is calculated as shown above for the
SPTVNORMRATE and as follows:
• If you specify a ramp time (SPTVTIME) value other than zero:
Otherwise:
SPTVRATE = NaN
• If you change the SPTVNORMRATE, this block recalculates the ramp time
(SPTVTIME) and ramp rate (SPTVRATE) as follows:
If ramp time (SPTVTIME) is a value other zero:
Otherwise,:
SPTVRATE = NaN
SPTVTIME SP target value time in minutes. This time is calculated in conjunction with
SPTVRATE as described above or is entered by you. 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.
SPTVSTATE SP target value state. The possible states are:
• Off,
• Preset, or
• Run
You can only set the SPTVSTATE when the Control Module containing this block is
active and the block's mode is Auto. When you set SPTVSTATE to Run from Preset,
this occurs:
• An “R” modifier appears next to the SP value on the PID detail display in
Station.
• SP begins to ramp toward SPTV and SPTVTIME decreases.
When SPTVTIME reaches zero, SP equals SPTV and the SPTVSTATE goes to Off.
391
Table 20: PID block with SP ramping parameters configured for monitoring.
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.
2. The SPTVSTATE automatically goes to Preset, when:
• You set a value for SPTV or SPTVTIME.
• Mode changes to Manual while SPTVSTATE is Run.
• Block is initialized (INITMAN = ON) while SPTVSTATE is Run. However, a one shot initialization
does not cause a change in SPTVSTATE.
• Control Module goes Inactive.
The SPTVSTATE automatically goes to Off, when:
• SP is set by you, a program or another function block.
• Mode changes to Cascade or Backup Cascade.
3. You can only set a value for SPTV and SPTVTIME, when:
• SPTVSTATE is Off or Preset, and
• Mode is Auto or Manual.
Attention
• When SP ramping is Enabled, the SPTVSTATE must be Off before you can make changes to the SP limits
(SPHILM and SPLOLM).
• If the anti-reset windup status (ARWNET) indicates that SP is woundup (Hi, Lo or HiLo), SP ramping stops.
When ARWNET indicates that SP has returned to normal, SP ramping continues from where it stopped.
19.8.13 PV tracking-PID Block

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 PID block sets SP equal to PV (subject to SP limits) when either of the
following conditions exist:
• PID block is in Manual mode
• PID block is initializing and not in Auto mode.
Attention
• PV tracking does not occur on recovery from a bad PV.
• PV tracking does not occur if PID block is in Auto mode.
• If PID block is in Auto mode, it means SP is normally stored by the user.
• If PV tracking is initiated, this value is lost.
• The PVTRAKOPTAI parameter provides a PV Tracking option for the specific case when the block is in Auto
mode and it is undergoing initialization (INITMAN is On). The PV Tracking option parameter (PVTRAKOPT)
does not include the Auto/Init case, but does cover several other situations as noted above.
19.8.14 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:
• Equation B - the proportional and integral terms act on the error (PV - SP) and the derivative term acts on
changes in PV as follows:
• 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
• This equation provides the smoothest and slowest response to SP changes.

• Equation D - integral control only as follows:
• Equation E - proportional only as follows:
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.
CV = K(PV - SP) + OPBIAS.FIX + OPBIAS.FLOAT

• 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.
• Reverse-control action causes the sign of the unbiased CV to be reversed.

• If both options are selected, the unbiased CV is reversed first, and then the fixed and floating bias are added
- neither the bias nor the final CV are reversed
Where:
393
CV = output of PID (Equations A, B, C, D) in percent or output of P-controller (Equation

E only) in engineering units
K = gain (proportional term)
L-1 = inverse of the LaPlace transform
PV = process input value in engineering units
PVP = PV in percent
a = 1/16 fixed rate amplitude
s = La Place operator
SP = set point value in engineering units
SPP = SP in percent
T1 = integral time constant in minutes
T2 = derivative time constant in minutes
OPBIAS.FIX = fixed bias (Equation E only)
OPBIAS.FLOAT = floating bias (Equation E only)
19.8.15 Gain options-PID block

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:
KLIN Linear (normal) gain - to be used when PV is outside the gap.

KMODIFGAP Gain-modification factor - to be used when PV is inside the gap. Range of
KMODIFGAP = 0.0 to 1.0.
GAPLOLM Lower limit of gap - in same engineering units as PV.
GAPHILM Upper limit of gap - in same engineering units as PV.
• Gain (K) is derived as follows:
When PV is outside the gap:

K = KLIN
When PV is inside the gap (SP - GAPLOLM <= PV <= SP + GAPHILM):
K = KLINKMODIFGAP
• 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:
Where:
KLIN = linear (normal) gain (user-configured)
NLFORM = nonlinear gain form (user-configured; may be 0 or 1)
NLGAIN = nonlinear gain (user-configured)
• 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.
K=KLIN*KMODIFEXT
Where:
KMODIFEXT = external gain modifier (such as from a user program)
19.8.16 Tuning Constant Change Considerations

Attention
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.
19.8.17 Timeout monitoring-PID block

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.
19.8.18 Timeout processing-PID block

If mode is CAScade and SP times out, the PID block does the following:
• Keeps SP at its last good value.
• Changes the mode to a user-specified TMOUTMODE.
• Requests the primary to initialize.
395
The PID 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.
Attention
19.8.19 Output Indication Function-PID block


Attention



OPLOALM.PR and .SV
OPHILM = 100 - 20.
Attention


397


closed
19.8.20 Windup handling-PID block

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:
• PID block has a secondary and the secondary is in windup.
• PID block's output exceeds one of the user-specified output limits (OPHILM, OPLOLM).

parameters.



ARWOP computation

initialize.
ARWNET computation

NaN.
The CV is NaN.
399

SPHIFL = On.
SPLO.FL = On.

NORMAL HI HI
NORMAL LO LO
NORMAL HILO HILO
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 NORMAL HILO
HILO HI HILO
HILO LO HILO
HILO HILO HILO
19.8.23 Override feedback processing-PID block

If the PID block is in a cascade strategy with a downstream OVRDSEL (Override Selector) block, it receives
override feedback data. The data consists of an override 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.
Note: SECINTOPT may be used to ignore override requests from the secondary.
When the override status changes from selected to unselected, the PID block does the following:
• Recomputes CV:
– If the override offset flag is Off:
CV=override feedback value from secondary
– If the override offset flag is On:
– For PID with Equation D,
Offset=(PVP-SPP)
– For PID with any other Equation(A,B,C,E)
Offset=K * (PVP-SPP)
– If PID is using reverse control action:
– then Offset = -Offset
– If the PID is using direct control action:
– then Offset = Offset
– Additionally, the Offset term is set to 0.0 if
– → Offset > 0.0 and the downstream OvrdSel block is a High selector, or
– → Offset < 0.0 and the downstream OvrdSel block is a Low selector
CV=override feedback value from secondary + Offset
The CV is clamped to OPHILM if it is greater than OPHILM and to OPLOLM if it is less than
OPLOLM.
– Computes a feedback value for its primary:
feedback value for primary =PV
Where:
K=overall gain
PV=PV in engineering units
PVP=PV in percent
SPP=SP in percent
19.8.24 PID parameters

Refer to the Control Builder Components Reference for a complete list of the parameters used with the PID
block.
401
19.9 PID-PL (Profit Loop PKS) Block

The PID-PL block is a regulatory control block combining the functionality of PID controller with a robust,
model-based, predictive controller and optimizer, Profit Loop PKS. This block inherits all the design features of
a PID easily replacing the PID block in any control scheme. As such, it may be used in a single control loop,
cascaded to other controllers, and configured for cross node supervisory control in an ACE.
• OPHIALM.TM
• OPHIALM.TMO
• OPHIALM.DB
• OPHIALM.DBU
BADCTLALM and Predicted PV alarms.
• BADCTLALM.TM
• BADCTLALM.TMO
• PREDPVHIALM.TM
• PREDPVHIALM.TMO
• PREDPVLOALM.TM
• PREDPVLOALM.TMO
In many cases, Profit Loop PKS provides superior control and should be used in place of the standard PID
algorithms. These cases include:
– Processes with significant delay or inverse (wrong-way) response
– Property control employing infrequent measurement updates (such as from a gas chromatograph)
– Noisy processes where valve wear is problematic
– Dynamically changing processes
– 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 setpoint
Additional descriptive details are provided in the following discussions:
• “Graphic presentation”
• “Modes”
• “Configurable attributes”
Benefits
Key benefits of Profit Loop PKS include:
Benefit Discussion
Superior control Because it is a predictive controller, Profit Loop PKS directly accounts for transportation delays and
other difficult to control behavior. This approach leads to superior control of processes with
significant deadtime, inverse response, or noisy measurement.
Valve life extension A well-designed robust controller maintains a balance between aggressive control performance and
insensitivity to model uncertainty / noise. To achieve this balance, Profit Loop PKS employs a
minimum movement algorithm. The control solution makes the least amount of movement to the
control valve in order to meet the control objectives.
This algorithm dramatically reduces valve chattering and stem reversals, especially when there is
significant process measurement noise, which, in turn, leads to longer valve life.
Benefit Discussion
Single tuning Uses a single tuning “knob,” the performance ratio. If the controller is sluggish and unresponsive,
handle 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.
Using a single handle as compared to the traditional three mode PID controller dramatically
simplifies retuning of the loop while in service.
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.
Efficiency Specially designed implementation of model predictive control technology for small applications.
The design minimizes the computations required, leading to more controllers per node running at
faster execution speeds.
Profit Controller Based on Honeywell's award-winning Profit Controller technology.
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
setpoint), 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 setpoint, 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 “optimizatio” objective may be imposed to drive the process to an optimal state.
Dual objective The key advantage of optimization over setpoint control is that the response of the optimizer and
control controller can be tuned separately, providing dual objective control.
Discrete analysis As a predictive controller, Profit Loop PKS models the behavior of the PV 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.
Profit Loop PKS's ability to compensate for missing process measurement data makes it ideal for
control of processes with discrete analyzers, such as gas chromatographs. Using the internal model,
Profit Loop PKS avoids inter-sample integral wind-up associated with a PID controller.
Graphic presentation
The PID-PL block looks like this graphically:
403
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” on page 369 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 setpoint
controller. Profit Loop PKS calculates a control output (OP) that drives the process variable (PV) to the
setpoint (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” on page 369 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 Control Building Guide in Experion documentation,
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 response to open loop response. Note:
– The default performance ratio of 1.0 represents steady-state control and reaches the
control objective at the natural process response time.
– Decreasing this ratio (PRFRATIO< 1) leads to faster, more aggressive, control. The
process will be driven to its setpoint more quickly than its natural open loop
response.
– Increasing the ratio (PRFRATIO> 1) leads to slower, but more robust, control. The
process will be driven to its setpoint more slowly than its natural open loop response.
– For integrating processes, use Closed-loop response (see below) to specify integrator
performance. In this case, Performance Ratio is set to 1.
• ProfitLoop Closed-Loop Response (CLOSEDLOOPRESP) - Enter a time of greater than
0.1 minute for the desired closed-loop response time. This is the expected settling time
for the control loop, which is the amount of time required to line out the controller after a
setpoint change or large disturbance.
For non-integration processes, CLOSEDLOOPRESP is the product of the open loop
response time, OPENLOOPRESP, and the performance ratio, PRFRATIO. For details on
non-integrating processes, see the Performance Ratio entry above.
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” on page 369 in this
document.
405

SetPoint Many attributes configured on this tab are the same as those for the PID block. Attributes
• 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 (SPLORAMPRATE) - For PID-
PL blocks with a Control Mode of RANGE, enter the ramp rate to be applied to external
(operator or program) changes in the lower control limit, SPLO. The rate must be greater
than 0 and expressed in Engineering Units/minute.
When the active low limit, SPLOACTIVE, is below the operator-set value (SPLO), the
active limit ramps toward SPLO at the rate specified here.
Setting this rate to NaN disables ramping.
• ProfitLoop Range Control Ramping, SPHI Ramp Rate (SPHIRAMPRATE) - For PID-
PL blocks with a Control Mode of RANGE, enter the ramp rate to be applied to external
(operator or program) changes in the higher control limit, SPHI. The rate must be greater
than 0 and expressed in Engineering Units/minute.
When the active high limit, SPHIACTIVE, is above the operator-set value (SPHI), the
active limit ramps toward SPHI at the rate specified here.
Setting this rate to NaN disables ramping.
block, refer to either the online Help for Control Builder, or to Reference Data for Functional
Block Types, Regulatory Control Blocks, “PID Block” on page 369 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:
Valve Travel Reduction (VALVETRAVELRDCT) - Allows you to select the level of noise
filtering to be applied to model bias. Possible selections are:
• NORMAL: Apply no additional noise filtering.
• MODERATE: Apply some additional filtering.
• FULL: Apply maximum additional filtering.
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.
This filter complements the PV filter on the data acquisition block.
block, refer to either the online Help for Control Builder, or to Reference Data for
Functional Block Types, Regulatory Control Blocks, “PID Block” on page 369 in this
document.
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 transfer function model
of process dynamics to be used in the control of your process. Use this form if you have a
Model area
good understanding of the math and concepts involved in model predictive control and you
do not wish to use the Profit Loop PKS Assistant.
Entries or changes in this area are treated differently, depending on whether you are working
in Project view or Monitoring view:
• For Project mode: If entries or changes are made in the Model area, the parameter values
are updated in the Engineering Repository Database (ERDB) immediately.
• For Monitoring mode: If entries or changes are made in the Model area , they are
displayed, but the function block is not updated until the Update Model command is
selected.
Attributes and actions possible on this tab should be considered. Attributes include the
following:
• Transfer Function # of Numerator Coefficients - The number of numerator coefficients,
from 1 to 5, in the Laplace transfer function model of the process. This number should
be at least one less than the number of denominator coefficients.
• Transfer Function Numerator Coefficients - The desired value for each coefficient in the
array defining the numerator polynomial in the Laplace transfer function model of the
process. N[1] is the coefficient preceding the s∧0 (constant) term, while N[5] is the
coefficient preceding the s∧4 term. If the coefficient will not be used, enter a value of 0.
• Transfer Function # of Denominator Coefficients - The number of denominator
coefficients, from 1 to 5, in the Laplace transfer function model of the process. This
number should be at least one greater than the number of numerator coefficients.
• Transfer Function Denominator Coefficients - The desired value for each coefficient in
the array defining the denominator polynomial in the Laplace transfer function model of
the process. D[1] is the coefficient preceding the s 0 (constant) term, while D[5] is the
coefficient preceding the s∧4 term.
• Process Gain - A nonzero value, for the gain associated with the Laplace transfer
function model of the process. Use the value corresponding to the defined process gain
units, which are indicated in the label of this field. Process gain units may be defined in
percentage, %PV/%OP or Engineering Units, PVEU/OPEU.
• Deadtime - A value of 0 - 3000 execution intervals, for the process deadtime
(transportation lag) as defined in the Laplace transfer function model. Your entry
depends on the execution period on the Control Module.
• Process Gain Units - The units to be used in conjunction with the process gain:
– PVEU/OPEU: Gain expressed in engineering units.
– %PV/%OP: Gain expressed as a percentage of range.
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.
This button is inactive if the model in the configuration form matches the model in the
active controller.
• Reset Model (RESETMODEL) - The model in the PID-PL configuration form can be
reset to match the model in the active 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.
This button is inactive if the model in the configuration form matches the model in the
active controller.
• Launch Assistant - The Profit Loop PKS Assistant, a companion intended to simplify
your Profit Loop PKS configuration activities, can be started from the Advanced tab.
The Assistant provides several tools to help you with the model definition process.
407

IMPORTANT! If you have a defined model in the Control Builder, PID-PL
configuration form (Advanced tab), and you use the Profit Loop PKS Assistant to
redefine the model, then download the model from the Assistant to the controller, the
models will be different. As with other types of changes to the controller, you can upload
the controller configuration to store the changes in Control Builder's Monitor-side
Engineering Repository Database (ERDB), and then perform an update to store the
changes in the Project-side ERDB. Refer to the Control Building Guide in Experion
documentation for information on performing these procedures.

Advanced, Optimization With range control, because the process is no longer constrained to a setpoint, you are free to
area choose the ultimate resting value for the process. The process may completely float within
the range, or you may wish to impose a secondary “optimization” objective to drive the
process to an optimal state. Use this area to do so. For details on how optimization works,
see the Control Builder online Help, Profit Loop PKS topic, “Understanding Optimization.”
• Optimizer Mode - When the Control Mode is set to Range (on the Algorithm form), you
can allow the process to completely float within the range, or you may impose a
secondary “optimizatio” objective to drive the process to an optimal state. Allowing the
process to float within the range may be acceptable for dynamic control, but it may not
be suitable for planning and long-term operations. The desired optimization modes are:
– NONE: No optimization.
– MINIMIZE: Optimize toward the lower limit of the range (minimize the PV).
– MAXIMIZE: Optimize toward the upper limit of the range (maximize the PV).
– OPTTARGET: Optimize toward a specific target value (a user-specified SP).
– DUALRANGE: Strive to keep the optimal solution between optimization limits,
SPLOLMOPT and SPHILMOPT.
All modes except OPTTARGET calculate the optimization limits as deviations from
the PID-PL block's high and low operating range (SPHI and SPLO). In contrast, the
OPTTARGET mode calculates the optimization limits as deviations from setpoint
(SP).
• Optimizer Speed - Dictates how fast the optimizer drives the process towards the optimal
target. Enter a value of 0.1 to 10.0 to . This is a unit less value.
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 “offse”). The optimized low limit is then calculated as
follows:
SPLOLMOPT = SPLO + SPLOOPTOFFSET
The impact of this offset depends on the selected Optimizer Mode.
• SP Offset, High Limit (SPHIOPTOFFSET) - Profit Loop PKS can be configured to
normal control range bounded by SPLO and SPHI. To do this,
409

– Set the SP high limit for optimization by entering the amount by which you want to
restrict the higher limit (the “offset”). The optimized high limit is then calculated as
follows:
SPHILMOPT = SPHI - SPHIOPTOFFSET
• OP Offset, Low Limit(OPLOOPTOFFSET) - Profit Loop PKS can be configured to
normal control range bounded by OPLOLM and OPHILM. To do this,
– Set the OP 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:
OPLOLMOPT = OPLOLM + OPLOOPTOFFSET
– The impact of this offset depends on the selected Optimizer Mode.
• OP Offset, High Limit (OPHIOPTOFFSET) - Profit Loop PKS can be configured to
normal control range bounded by OPLOLM and OPHILM. To do this,
– Set the OP high limit for optimization by entering the amount by which you want to
restrict the higher limit (the “offset”). The optimized high limit is then calculated as
follows
OPHILMOPT = OPHILM - OPHIOPTOFFSET
Advanced, Async PV Option (PVASYNCOPT) -This setting tells the function block when not to expect
a new PV measurement (when not to expect a change), so that the function block does not
PV Configuration area
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.
IMPORTANT! Do not select ONPVCHANGE if noise alters the PV value between
analyzer updates.
• EXTERNALSYNC: The PV measurement is updated when an external flag, connected
to NEWSAMPLE, is set.
IMPORTANT! Use logic blocks to set and reset the NEWSAMPLE flag. Users are
responsible for designing and constructing the appropriate logic.

Alarms Most attributes configured on this tab are the same as those for the PID block. Attributes
• 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.
– JOURNAL: The alarm is written to the event file, where it can be accessed for alarm
and event reports, or event displays on a Station. JOURNAL priority alarms do not
appear in the Alarm Summary display.
– LOW, HIGH, URGENT: These selections cause the alarm to be displayed in the
alarm zone at the bottom of a Station display to bring new alarms to the attention of
operators and/or directed to an alarm/event printer. The alarm also appears in the
Alarm Summary display, in the color specified here:
1. LOW: Low-intensity yellow.
2. HIGH: Yellow.
3. URGENT: Red
– Note that the default selection is LOW, and that alarm levels are prioritized as
follows: JOURNAL --> LOW --> HIGH --> URGENT (highest priority)
• Predicted PV High - Severity (PREDPVHIALM.SV) - A relative severity to the
predicted PV high alarm can be assigned by specifying a weight in the range of 0 to 15.
The specified weight determines when the specified alarm is processed relative to other
alarms. Tips and notes:
– Generally, 15 is considered most severe when specifying alarm severity.
– The default value is 0.
• Predicted PV Low - Trip Point (PREDPVLOALM.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 low alarm can be used to indicate when the predicted steady-state
PV value drops below a particular value (entered on the PID-PL Block Parameters -
Algorithm form) for more than a specified time.
– Enter a value greater than or equal to zero, to enable the predicted PV low alarm trip
point.
– Enter NaN (Not a Number) to disable the predicted PV low alarm.
• Predicted PV Low - Priority (PREDPVLOALM.PR) - Select the appropriate priority
level for the corresponding alarm type based on the following categories:
– NONE: The alarm is not reported to the system and is not annunciated.
– JOURNAL: The alarm is written to the event file, where it can be accessed for alarm
and event reports, or event displays on a Station. JOURNAL priority alarms do not
appear in the Alarm Summary display.
– LOW, HIGH, URGENT: These selections cause the alarm to be displayed in the
alarm zone at the bottom of a Station display to bring new alarms to the attention of
operators and/or directed to an alarm/event printer. The alarm also appears in the
Alarm Summary display, in the color specified here:
1. LOW: Low-intensity yellow
2. HIGH: Yellow
3. URGENT: Red
411

– Note that the default selection is LOW, and that alarm levels are prioritized as
follows: JOURNAL --> LOW --> HIGH --> URGENT (highest priority)
• Predicted PV Low - Severity (PREDPVLOALM.SV) - A relative severity to the
predicted PV low alarm can be assigned by specifying a weight in the range of 0 to 15.
The specified weight determines when the specified alarm is processed relative to other
alarms. Tips and notes:
– Generally, 15 is considered most severe when specifying alarm severity.
– The default value is 0.
• Bad PV Shed Time (Sec) (BADPVALM.TP) - If the PID-PL block PV falls out of range
(PVSTS changes to Bad), you can specify an amount of time (greater than zero, in
seconds) that the block will be allowed to run before a bad PV alarm is generated. In this
case, Profit Loop PKS discontinues bias updating and operates strictly from its model
predictions, for the specified amount of bad PV shed time.
This approach offers additional flexibility not found with other regulatory control blocks
(which, by necessity freeze their output and issue a bad control alarm).
CAUTION! because the model prediction is no longer synchronized with the process,
the prediction can wander; therefore control action should be stopped after some period
of time.
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
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
Identification Lets you view information pertinent to the qualification and version control system and enter
block comments, if desired.
Dependencies Lets you view block hierarchical information.
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 Parameters Lets you select the available parameters that you want to 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.
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
19.9.1 Function-PID-PL
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:
• “Auxiliary Functions”
• “Data Acquisition Functions”
• “Pulse Input”
• “Device Control”
• “Logic Functions”
• “Math Functions”
• “Power Generation Functions” on page 905
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 d1 are the process dynamics.
The Laplace variable, s, has units of min -1, requiring dynamics and deadtimes to be entered in minutes.
PID-PL buffers user entered model changes to prevent partial updating of the model. Model changes are not
accepted on a running function block until the UPDATEMODEL flag has been set. This flag will automatically
clear on completion of the update.
If you decide to abort the model update, the RESETMODEL flag can be set. This flag resets the user interface
to the active model and clears itself.
413
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.
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.
415
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.
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.
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.
417
Similar offsets, OPLOOPTOFFSET and OPHIOPTOFFSET, limit the OP range, OPLOLM and OPHILM, for
optimization.
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.
External gain updating

PID-PL supports the external updating of the process model gain (gain scheduling). This is similar to the EXT
gain option of a PID function block, except that the process model gain (and not the PID function block gain) is
altered. You can use this option to compensate for nonlinear process gain changes. For example, if you are
controlling the level of a tank whose cross-section is not constant, you can use this option to modify the model
gain compensating for the nonlinear rate of level change caused by the changing shape of the tank.
The PID-PL block supports two methods for updating the gain:
• An operator or another function block changes a process gain multiplier, PROCGAINMULT. The actual
process gain (active gain) is then computed as shown in the following equation:
• 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:
• A user program or another function block changes the active value, PROCDEADTIMEACT, directly. To
ensure safe operation, the active deadtime is restricted between 0% and 120% of the engineer-entered
deadtime, PROCDEADTIME.
19.9.2 Configuration examples-PID-PL

Four examples are discussed in the following paragraphs:
• “Utility Functions”
• “Device Control”
• “Sequential Control”
• “ENHREGCALC (Enhanced Regulatory Control Calculator) Block” on page 300
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.
The following table explains the callouts in the preceding figure.
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.
4 Use the OP connection to transfer control block output to analog output.
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.
419
The following table explains the callouts in the preceding table.
Callout Description
1 Configuration is nearly identical to setpoint control configuration. Use block pins SPHI and SPLO to allow
on-line change of the control range. SP is not used in this case.
2 CTRLMODE is set to RANGE.
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 wo 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
1 Because the analyzer maintains a set of control signals, PVASYNCOPT is set to ExternalSync to force bias
updating only when the analyzer indicates that a new reading is available.
2 The analyzer signals are accessed through two digital-input channels.
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.
421
Callout Description
1 For clarity, the tank level is shown as a separate independent block connection. In practice, the input to the
regulatory control block may be connected to the output of the data acquisition block.
2 A regulatory control algorithm is employed to calculate an appropriate base gain multiplier based on the
geometry of the tank and the level in the tank.
3 The gain multiplier is connected to the PROCGAINMULT parameter on the PID-PL block. This input
requires the gain multiplier to be between 0.01 and 100.
An alternative approach connects a raw gain to the PROCGAINACT parameter (not shown). This approach
circumvents the range restrictions on tiplier.
19.9.3 Operating modes and mode handling-PID-PL

The PID-PL block operates in the following modes:
• MAN (MANual) - If mode is MANual, OP may be stored by the operator or a user program; PV and SP are
ignored. If a primary exists, it goes to the initialized state.
• AUTO (AUTOmatic) - If mode is AUTOmatic, SP (or SPP) may be stored by the operator or a user
program; if a primary exists, it goes to the initialized state. SP contains the setpoint value in engineering
units and SPP contains the value in percent.
• 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, this block invokes timeout processing.
These modes apply regardless of whether the control equation is set for PID control or Profit Loop PKS.
In addition to the block mode, Profit Loop PKS operates in the following control modes:
• SETPOINT - Controller alters OP so PV tracks the SP.
• RANGE - Controller alters OP so PV is constrained between SPLO and SPHI.

If range control is employed, Profit Loop PKS uses the optimization mode to determine the desired steady-
state operating conditions:
• NONE - PV is allowed to freely float between SPHI and SPLO. If projected to remain in range, no
additional control action is taken.
• MINIMIZE - At steady-state, PV is minimized.
• MAXIMIZE - At steady-state, PV is maximized.
• OPTTARGET (OPTimize to TARGET) - At steady-state, PV equals SP.
• DUALRANGE - At steady-state, PV is constrained between SPLOLMOPT and SPHILMOPT, but may float
anywhere within this optimization range. The optimization range is more constraining than the control
range, SPLO to SPHI.
19.9.4 Required inputs-PID-PL

The PID-PL block requires two inputs: PV and SP. See “Required inputs-PID Block” on page 386 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.
19.9.5 Input ranges and limits-PID-PL

For PID or Profit Loop PKS setpoint control, the PID range limits apply. See “Input ranges and limits-PID
Block” on page 386 for the PID block for details.
For range control,
• PVEUHI and PVEULO define the engineering unit range for MODELPV, SP, SPHI, and SPLO.
• SPHILM and SPLOLM define the operating limits in engineering units for SPHI, and SPLO. If a value is
entered outside these limits but within the engineering unit range, this block clamps the value at its
appropriate limit. Otherwise, an out of bounds error is generated.
• SPHI and SPLO define the operating limits in engineering units for SP. The operator is prevented from
storing a setpoint 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 primary's windup status.
19.9.6 Initializable outputs-PID-PL

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-ENHREGCALC” on page 314 for the
PID block for more details.
19.9.7 Control initialization-PID-PL

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:
CV = initialization value from the secondary.
– uses the initialized CV value in model predictions
423
INITREQ = On
INITVAL = SP
• If a PID-PL block configured for range control is cascaded to a primary and OPTMODE does not equal
OPTTARGET, then the primary has no bearing on the operation of its secondary. Under these circumstances,
an initialization request is sent to the primary.
19.9.8 Output bias-PID-PL

Profit Loop PKS does not support an output bias. For details on the biasing of PID algorithms, see “Output bias-
PID Block” on page 387 for the PID block.
19.9.9 Output ranges and limits-PID-PL

The output range of a PID-PL block is identical to the PID block. See “Output ranges and limits-
ENHREGCALC” on page 314 for the PID block for details.
19.9.10 Direct or reverse control-PID-PL

A PID-PL block may be configured for direct-control action or reverse-control action, effectively changing the
sign of the controller gain. See “Direct or reverse control-PID Block” on page 389 for the PID block for
implementation details.
With Profit Loop PKS, the sign of the controller gain is determined by the sign of the process model gain. To
prevent mismatch between the model gain and control action, changes to CTLACTN are not allowed.
Furthermore, when the model gain changes (including initial loading of the function block), CTLACTN is set to
match the new gain direction.
• A positive process model gain leads to reverse control action.
• A negative process model gain leads to direct control action.
19.9.11 Set Point Ramping-PID-PL

The Set Point Ramping option lets you ramp from the current setpoint value to a target setpoint value. For Profit
Loop PKS, this option is applicable to setpoint control and range control when OPTMODE is OPTTARGET
only. See “Set Point Ramping-PID Block” on page 389 for the PID block for implementation details.
19.9.12 Range Control Ramping-PID-PL

For range control, range control limit ramping provides a smooth transition from the current SPHI and SPLO
limits to newly entered values by ramping range limit changes 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.
19.9.13 PV tracking-PID-PL
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-
PID Block” on page 392 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
• If SPHI is less than SP then set SPHI equal to SP
Attention
• SPHI and SPLO track the current SP (and only indirectly the PV).
• Range limits are sensitive to transient changes in the SP/PV. Once a range limit is relaxed, it is not re-constricted.
However, in contrast with setpoint control, an operator can alter the SPHI or SPLO limit, subject to the above
limitations, while PV tracking is active.
19.9.14 PV Bad Value Handling

When the PV status (PVSTS) is BAD, Profit Loop PKS discontinues bias updating and operates strictly off of
its model predictions. This offers additional flexibility not found with other regulatory control blocks that, by
necessity, freeze their output and issue a BadCtl alarm. However, because the model prediction is no longer
synchronized with the process, the prediction can wander and, generally, control action should be stopped after
some user specified period of time.
For Profit Loop PKS, the PID-PL block supports a Bad PV duration alarm. This alarm trips if the PV is BAD
for longer than the user-entered duration. Tripping of this alarm leads to bad control (BadCtl).
For PID control, the Bad PV duration is reset to 0 tripping on the first detection of a bad 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.
19.9.15 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
425
such recalibration causes undesirable control action. A calibration flag, CALIBRATION, is provided for this
purpose.
When CALIBRATION is set, Profit Loop PKS:
• Disables updating of bias between model prediction and PV
• Continues control action based on model prediction only
19.9.16 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.
• The PID-PL block makes no attempt to set or reset this flag.
• It is a good practice to buffer the external update signal with an FTRIG (RTRIG) block. This block sets the
NEWSAMPLE flag on leading edge (lagging edge) change in the external signal and automatically resets the
NEWSAMPLE flag after one execution period.
19.9.17 Control Equations-PID-PL block

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” on page 393 for the PID block.
19.9.18 Output Indication Function


Attention


OPLOALM.PR and .SV
427

OPHILM = 100 - 20.
Attention




closed

Attention
19.9.20 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.
19.9.21 Windup handling-PID-PL block

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.
429
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.

parameters.


ARWOP computation

initialize.
ARWNET computation

NaN.
The CV is NaN.
SPHIFL = On.
SPLO.FL = On.

NORMAL HI HI
NORMAL LO LO
NORMAL HILO HILO
431
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 NORMAL HILO
HILO HI HILO
HILO LO HILO
HILO HILO HILO
19.9.24 Override feedback processing-PID-PL block

If the PID-PL block is in a cascade strategy with a downstream OVRDSEL (Override Selector) block, it
receives override feedback data. The data consists of an override 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).
When the override status changes to unselected, Profit Loop PKS uses the override feedback value instead of
the OP in its model predictions. In this manner, it prevents an anomalous bias due to unrealized control action.
For more details on override feedback processing, see “Override feedback processing-PID block” on page 401
for the PID block.
19.9.25 PID-PL parameters

Refer to the Control Builder Components Reference for a complete list of the parameters used with the PID-PL
block.
19.10 PIDER (PID with External Reset Feedback) Block

The PIDER block is a regulatory control block that operates as a proportional-integral-derivative (PID)
controller that accepts a reset feedback signal, a tracking value, and a tracking control switch. It supports the
same Ideal form of calculating the PID terms as the PID block. It also prevents windup when the secondary
does not propagate windup status or control initialization data back to the primary of a remote (foreign)
controller. The PIDER block looks like this graphically:
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).
The PIDER block may be used in a single control loop or with multiple PIDs in a cascade strategy.
433
individual alarms. For example, you can use the following parameters to configure the on-delay time, off-
delay time, deadband values, and deadband units for the OPHIALM parameter.
• OPHIALM.TM
• OPHIALM.TMO
• OPHIALM.DB
• OPHIALM.DBU
BADCTLALM alarm.
• BADCTLALM.TM
• BADCTLALM.TMO
19.10.1 Configuration example-PIDER block

The following illustration shows a PIDER block configured in a cascade control strategy.
Table 21: PIDER block used in a cascade control strategy with PID, AUTOMAN, and NUMERIC blocks
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.

• Item Name - The name of the Entity that the Control Module containing the
block will be associated with in the Enterprise Model Builder hierarchy.
information.
good value
• The default selection is SHEDHOLD.
• The block requests its primary to initialize after a mode shed or lets the primary
know that it is woundup, if it does shed its mode. An operator can change the
block's mode after it is shed, but, the operator must first set PVMANOPT to
NOSHED, so the mode doesn't shed again.
return the block to its normal mode. If mode was not shed, the block clears its
windup condition and does a one shot initialization. It also requests the primary
to do a one shot initialization.
NONE.
435

appropriate.
is SHEDHOLD.

The selections are EQA, EQB, EQC, and EQD. See the PID Equations section
for this block for details. The default selection is EQA.
B, and C.
option.
437

K = KLIN*KMODIFEXT
value is 1.
controllers to have the same behavior as the TPS xPM controller. See

MANual.
point ramping section for this block for more details.
439

• Enable SP Push: (PUSHSP) - Lets you specify that the PIDER SP will be pushed
from an Inter Cluster Gateway when the PIDER is the secondary of a cascade
that extends over two Experion clusters.

is -5%.
441


• OPHIALM.TP (Output High Alarm Trip Point)
• OPLOALM.TP (Output Low Alarm Trip Point
• DEVHIALM.TP (Deviation High Alarm Trip Point)
• DEVLOALM.TP (Deviation Low Alarm Trip Point)
• ADVDEVALM.TP (Advisory Deviation Alarm Trip Point)
display.
Summary display.
ADVDEVALM.SV, SIALM.SV, BADCTLALM.SV,) as a number between 0 to
specifying a deadband value, you can prevent the nuisance alarms due to noise at
+ deadband value.
443

With R410, the cannot individually configure the deadband unit for the PIDER
configuration is identical for the all other alarms in the PIDER block. However,
if you are migrating from pre-R410 to later releases, refer to “Impact of
Note: You must configure identical deadband units for all alarms in the PIDER
block.
Note: This parameter is available for configuration only if the Enable Bad
Output Connection Option is enabled.
default value (0).

selections are:
– None
– ONESHOT
– SEMICONT
– CONTRTN
– CONT
block:
Configured Rate.
faceplate.
information
445
19.10.2 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 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.
change the PIDER's Mode:
– 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
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.
19.10.3 Operating modes and mode handling-PIDER block

The PIDER block operates in the following modes:
• MAN (MANual)
– If mode is MANual, OP may be stored by the operator or a user program; PV and SP are ignored - if a
primary exists, it goes to the initialized state.
in percent.
• CAS (CAScade)
initializing) or the connection is bad, the PIDER block invokes timeout processing.
19.10.4 Required inputs-PIDER block

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.
– 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.
19.10.5 Input ranges and limits-PIDER block

– PVEUHI and PVEULO define the full range of PV in engineering units. PVEUHI represents the 100%
of full scale value. PVEULO represents the 0% of full scale value.
the same range.
• The PIDER block assumes PV is within PVEUHI and PVEULO - it applies no range check - however, PV
user program attempts to store a value outside of the limits, the PIDER block clamps it to the appropriate
– 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).
447
– 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.
19.10.6 Initializable outputs-PIDER block

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
19.10.7 Control initialization-PIDER block

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
• If the secondary is requesting initialization, the PID block:
INITREQ = On
INITVAL = SP
19.10.8 Output bias-PIDER block

If the PIDER block algorithm is configured as Equation A, B, C, or D, no output bias (OPBIAS) is applied.
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

Attention
recomputed.
occurs:
Where:
CVUNBIASED=unbiased calculated value (based on input from the primary)
parameter.
– Zero:
– Non-zero:
parameter.
executes.
Where:
– NaN:
449
19.10.9 Output ranges and limits-PIDER block

– CVEUHI and CVEULO must be specified by the user. The specified values must match the engineering
units (EU) range of the RFB and TRFB signals, which are the range of the remote (foreign) controller or
secondary.
user program attempts to store an OP value that exceeds them.
– The operator may store an OP value that is outside of 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.
19.10.10 Direct or reverse control-PIDER block

A PIDER block may be configured for direct-control action or reverse-control action.
• With direct-control action, an increase in the error (PV - SP) increases the PIDER output (CV).
• With reverse-control action, an increase in the error (PV - SP) decreases the PIDER output (CV).
19.10.11 Set Point Ramping-PIDER block

(SPTVNORMRATE) 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.
function block calculates a ramp time (SPTVTIME) and ramp rate (SPTVRATE) as
follows, when SP ramping is enabled:
• SPTVRATE = SPTVNORMRATE
• SPTVTIME = |(SPTV - SP)| / SPTVRATE
Otherwise,:
• SPTVRATE = NaN
• SPTVTIME = 0 (That is, do a step change.)
If the maximum ramp deviation value is other than NaN, SP ramping stops when the
absolute value of the deviation (|PV - SP|) exceeds the maximum deviation. The
deviation flag (SPTVDEVFL) is set, and SP ramping state (SPTVSTATE) remains
in Run. Ramping resumes as soon as the absolute value of the deviation returns
within the maximum deviation limit. This also resets the deviation flag
(SPTVDEVFL).
The block calculates a ramp time (SPTVTIME).
The SPTVSTATE goes to Preset.
A “P” modifier appears next to the SP value on the PIDER detail display in Station.
deviation limit.
451
Otherwise:
SPTVRATE = NaN
Otherwise,:
SPTVRATE = NaN
Auto or Manual.
• Off,
• Preset, or
• Run
this occurs:
• An “R” modifier appears next to the SP value on the PIDER detail display in
Station.
Table 22: PIDER block with SP ramping parameters configured for monitoring.
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
2. The SPTVSTATE automatically goes to Preset, when:
3. You can only set a value for SPTV and SPTVTIME, when:
Attention
19.10.12 PV tracking
The PV Tracking option sets SP equal to PV when a cascade is broken due either to function block initialization
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 if block is in Auto mode.
• If block is in Auto mode, it means SP is normally stored by the user.
• If PV tracking is initiated, this value is lost.
19.10.13 PID equations for PIDER block

The PIDER block provides four different equations for calculating the PID - the CTLEQN parameter is used to
• Equation A - all three terms (Proportional, Integral, Derivative) act on the error (PV - SP) as follows:
453

Attention

Where:
CV = output of PID (Equations A, B, C, D) in percent

PVP = PV in percent
SPP = SP in percent
19.10.14 PIDER equation variations

In addition to the PID equations above, the PIDER block supports the following variations depending on the
status of the tracking switch (S1).
If the tracking switch S1 is Off, this block combines RFB with the PID output as follows:
If PID equation A, B, or C is configured, the following variation applies:
If PID equation D is configured, the following variation applies:
If the tracking switch (S1) is On, the PIDER block forces CV to track the tracking value (TRFB) input as follows:
Where:
CV = full value output in percent , PID combined with CVRFB.

CVPID = full value output of the PID block. This is an internal calculated parameter and is not
available to user-written programs.
K1 External reset feedback gain (scaling factor that is applied to RFB).
K1 is clamped between the limits 0.0 and 1.0.
RFB = the external reset feedback value in engineering units (input).
rfb =
S1 = the tracking control switch (input)
TRFB = the tracking value (input)
T1 = PID integral time constant in minutes (configured)
19.10.15 Gain options

If equation A, B, or C is selected, any of the following gain equations may be chosen:
1.0.
455


K = KLIN
K = KLIN*KMODIFGAP
itself.
Where:
tank.
K = KLIN*KMODIFEXT
Where:
19.10.16 Output Indication Function- PIDER block


Reverse1 Value reversal - output range is 100 to 0 percent, and no display indications -
1 The PIDER block does not support the Reverse option selection.
Attention



closed
457


Attention
19.10.18 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.
19.10.19 Timeout processing

If mode is CAScade and SP times out, the block does the following:
• Holds SP at its last good value.
• Sheds to the user-specified timeout mode (MODE = TMOUTMODE).
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
• Updates the SP.
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
19.10.20 Windup handling

When a windup condition is reached, the block stops calculating the integral term, but continues to calculate the
proportional and derivative term.
– PID block has a secondary and the secondary is in windup.
– PID block's output exceeds one of the user-specified output limits (OPHILM, OPLOLM).

parameters.


ARWOP computation

459

initialize.
ARWNET computation

NaN.
The CV is NaN.
SPHIFL = On.
SPLO.FL = On.

NORMAL HI HI
NORMAL LO LO
NORMAL HILO HILO
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 NORMAL HILO
HILO HI HILO
HILO LO HILO
HILO HILO HILO
19.10.23 Override feedback processing-PIDER block

The PIDER block does not support override feedback processing.
19.10.24 Error handling for RFB and TRFB inputs

• If the tracking control switch (S1) is Off and the reset feedback value (RFB) is bad, this block sets CV to
NaN (Bad).
– When the RFB returns to good, CV is initialized, and the dynamic PID terms are returned to steady-state.
• 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.
19.10.25 Restart or point activation

Initialization takes place when the block is activated or inactivated. Initialization also takes place when the ACE
controller node is repowered.
19.10.26 PIDER parameters

Refer to the Control Builder Components Reference for a complete list of the parameters used with the PIDER
block.
461
19.11 PIDFF (PID with Feedforward) Block

The PIDFF block is like the PID block but it accepts a feedforward signal as an additional input. You can
configure the PIDFF block so the feedforward signal is added to or multiplied by the normal PID algorithm's
incremental output to meet your particular control requirements. This lets you implement a feedforward control
function through a single function block. The PIDFF block looks like this graphically:
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 signal (FF) is included in the calculation of the PID's incremental
output before the full value output is accumulated.
• 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.
Table 23: Simple PID with feedforward control loop example.
• OPHIALM.TM
• OPHIALM.TMO
• OPHIALM.DB
• OPHIALM.DBU
BADCTLALM alarm.
• BADCTLALM.TM
• BADCTLALM.TMO
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.
463

information.
engineering units that represents the 0% full scale PV input for the block. The
good value.
The default selection is SHEDHOLD.
The block requests its primary to initialize after a mode shed or lets the
primary know that it is woundup, if it does shed its mode. An operator can
change the block's mode after it is shed, but, the operator must first set
PVMANOPT to NOSHED, so the mode doesn't shed again.
return the block to its normal mode. If mode was not shed, the block clears
its windup condition and does a one shot initialization. It also requests the
primary to do a one shot initialization.
NONE.

appropriate.
is SHEDHOLD.
Option is enabled.
– Enable Bad Output Connection Option (BADOCOPTENB) - Lets you to
optionally enable the functionality of specifying a time delay for the
regulatory control blocks to shed the control mode in the event of an IO
communication loss. The default selection is Disable.
465

The selections are EQA, EQB, EQC, EQD, and EQE. See the PID Equations
section for this block for details. The default selection is EQA.
B, and C.
option.

K = KLIN * KMODIFEXT
value is 1.
controllers to have the same behavior as the TPS xPM controller See
• Feedforward Type (FFOPT) - Lets you specify whether the feedforward signal is
to be added to (ADD) or multiplied by (MULTIPLY) the incremental PID
output. The default value is ADD.
• Gain (KFF) - Lets you specify the desired gain for the feedforward input. It is
clamped between GAINLOLM and GAINHILM. The default setting is 1.
• Bias (BFF) - Lets you specify the desired bias value for the feedforward input.
The default setting is 0.
467

• Low Limit (SPLOLM) - Lets you specify a low limit value for the SP. If the SP
MANual.

• Enable SP Push: (PUSHSP) - Lets you specify that the PIDFF SP will be pushed
from an Inter Cluster Gateway when the PIDFF is the secondary of a cascade
that extends over two Experion clusters.
469

of the Calculated Variable range (CVEUHI - CVEULO). For example, if the CV
is -5%.
(NaN), which means the OP is held at its last good value. ’
engineering units that represents 100% full scale CV output for the block, if the
block has no secondary. The default value is 100.
engineering units that represents the 0 full scale CV output for the block, if the
block has no secondary. The default value is 0 (zero).

471

• OPLOALM.TP (Output Low Alarm Trip Point
display.
Summary display.
ADVDEVALM.SV, SIALM.SV, BADCTLALM.SV) as a number between 0 to
+ deadband value.

With R410, you cannot individually configure the deadband unit for the PIDFF
configuration is identical for the all other alarms in the PIDFF block. However,
if you are migrating from pre-R410 to later releases, refer to “Impact of
You must configure identical deadband units for all alarms in the PIDFF block.
default value (0).
473

the MODE of the SCM. See the Sequential Control Module User Guide for more
information on this function. The default selection is ONESHOT. The selections
are:
– None
– ONESHOT
– SEMICONT
– CONTRTN
– CONT
block:
Configured Rate.
faceplate.
information
19.11.1 Function-PIDFF block

A PIDFF requires up to three inputs - a process variable (PV), a set point (SP), and a feedforward (FF):
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.
change the PID's Mode:
– 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
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.
19.11.2 Functional scenario-PIDFF block

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.
475
Table 24: Functional block diagram of typical PID feedforward operation.
The functional steps associated with this PIDFF operating scenario are listed in the following table.
1. The Operator provides a value to the PIDFF1 SP variable (before the PIDFF1 executes).
2. The PIDFF1's “Execute” method is called by the CEE (Control Execution Environment). The PID execution
period is configurable.
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.
4. The PIDFF pulls the FF from the LEADLAG block.
5. The PIDFF1 checks SI, ESWAUTO, ESWCAS and ESWMAN to see if an external source wants to invoke
Safety Interlock processing or change the Mode.
6. The PIDFF1 performs SP processing. (SP processing options are specified at configuration time.)
7. The PIDFF1 calculates an output, based on PV and SP values and the configured algorithm plus FF (FF
processing option is specified at configuration time).
8. The PIDFF1 performs limit checking and alarming (if required) on OP.
9. The PIDFF1 stores OP to the AOCHANNEL.
10. The PIDFF1's “Execute” method completes.
19.11.3 Operating modes and mode handling-PIDFF block

The PIDFF block operates in the following modes:
• MAN (MANual)
– If mode is MANual, OP may be stored by the operator or a user program; PV, FF, and SP are ignored - if
a primary exists, it goes to the initialized state.
in percent.
• CAS (CAScade)
initializing) or the connection is bad, the PIDFF block invokes timeout processing.
19.11.4 Required inputs-PIDFF block

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.
19.11.5 Input ranges and limits-PIDFF block

the same range.
• The PIDFF block assumes PV is within PVEUHI and PVEULO - it applies no range check - however, PV
user program attempts to store a value outside of the limits, the PID block clamps it to the appropriate
19.11.6 Initializable outputs-PIDFF block

For example, if you connect OP from a PIDFF block to a PID block or an AOCHANNEL block, Control
477
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
19.11.7 Control initialization-PIDFF block

The PIDFF block brings initialization requests from its secondary through BACKCALC. In addition, the
• If the secondary is requesting initialization, the PIDFF block:
INITREQ = On
INITVAL = SP
INITMAN = On
19.11.8 Output bias-PIDFF block

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.
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
Attention
recomputed.
occurs:

Where:
parameter.
– Zero:
– Non-zero:
parameter.
executes.

Where:
• NaN:
479
19.11.9 Output ranges and limits-PIDFF block

– If the PIDFF block has a secondary, its CV range must be the same as the secondary's input range - if this
PIDFF function has a secondary, it brings the secondary's input range through BACKCALC and sets its
CV range to that.
– If the PIDFF block has no secondary, you can configure the CVEUHI and CVEULO values. The default
values are 100 and 0, respectively.
– 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).
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.
19.11.10 Direct or reverse control for PIDFF block

A PIDFF block may be configured for direct-control action or reverse-control action.
• With direct-control action, an increase in the error (PV - SP) increases the PID output (CV).
• With reverse-control action, an increase in the error (PV - SP) decreases the PID output (CV).
19.11.11 Set Point Ramping-PIDFF block

• Otherwise:
SPTVRATE = NaN
(SPTVDEVFL).
• The block calculates a ramp time (SPTVTIME).
deviation limit.
481
Otherwise:
SPTVRATE = NaN
If ramp time (SPTVTIME) is a value other zero
Otherwise:
SPTVRATE = NaN
SPTVRATE as described above or is entered by you. You can only set SPTVTIME
when the SPTVOPT is Enabled, the SPTVSTATE is Off or Preset, and the block's
mode is Auto or Manual.
• Off,
• Preset, or
• Run
this occurs:
Station.
Callout Description
1 Block's mode must be Auto and SPTVSTATE must be Preset, before you can start SP ramping by setting
2 The SPTVSTATE automatically goes to Preset, when:
3 You can only set a value for SPTV and SPTVTIME, when:
Attention
19.11.12 PV tracking-PIDFF block

The PV tracking option sets SP equal to PV when a cascade is broken due either to function block initialization
PV tracking is configured by setting PVTRAKOPT = Track.
483
Typically, PV tracking is configured for PIDFF 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 PIDFF block sets SP equal to PV (subject to SP limits) when either of the
following conditions exist:
• PIDFF block is in Manual mode
• PIDFF block is initializing and not in Auto mode.
Attention
• PV tracking does not occur if PID block is in Auto mode.
1. If PIDFF block is in Auto mode, it means SP is normally stored by the user.
2. If PV tracking is initiated, the stored SP value is lost.
19.11.13 Feedforward add or multiply action and equations-PIDFF block

The PidFF block supports the same equations as the normal PID. In addition, the feedforward signal is applied
to the PID's incremental output (DELCV), when the control equation A, B, C, or D is configured; and it is
applied to the PID's full value output (CV), when the control equation E is configured.
• If the configured control equation (CTLEQN) is A, B, C, or D and the feedforward action is Additive, then:
– If the feedforward value (FFn) is good (symbols are defined below):
CVn = Cvn-1 + DELCV + KFF* (FFn - FFn-1 )
– If the status of FFn or FF n-1 is Bad:
CVn = Cvn-1 + DELCV
• If the configured control equation (CTLEQN) is E and the feedforward action is Additive, then:
– If the feedforward value (FFn) is good:
CVn = CVn + KFF* FFn
(The CVn is computed based on equation E using SP and PV and includes the OPBIAS terms.)
– If the status of FFn is Bad:
CVn = CVn + KFF* FFLGV
(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.)
• If the configured control equation (CTLEQN) is A, B, C, or D and the feedforward action is Multiplicative,
then:
CVPID = CVPID + DELCV
CV = CVPID * (KFF* FFn + BFF)
CV = CVPID * (KFF* FFLGV + BFF)
(Note: FFLGV is initialized to 1.0. Therefore, if FFn is Bad from the start, then:
CV = CVPID * (KFF + BFF)
Do not change the KFF and BFF parameters online.)
– 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:
CVPID = CV / (KFF *FFn + BFF)

(Do not change the KFF and BFF parameters online.)
• If the configured control equation (CTLEQN) is E and the feedforward action is Multiplicative, then:
CV = CVPID * (KFF *FFn + BFF)
(Where CVPID is computed based on equation E using SP and PV and includes the OPBIAS terms.)
CV = CVPID * (KFF *FFLGV + BFF)
(Note: FFLGV is initialized to 1.0. Therefore, if FFn is Bad from the start, then:
CV = CVPID * (KFF + BFF) )
– 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:
CVPID = CV / (KFF*FFn + BFF)
Where:
BFF = Bias of the feedforward input
CV = Full-value output with FF term included
CVPID = full-value output of the PID block without the FF term (This is a calculated value and not
a user-visible parameter.)
DELCV = Incremental output of the PID function
KFF = Gain of the feedforward input that is clamped between GAINLOLM and GAINHILM.
FF = Feedforward input value
FFLGV = Last good value of FF (This is a calculated value and not a user-visible parameter.)
n = Notation to indicate value of this pass
n-1 = Notation to indicate value of preceding pass
19.11.14 Feedforward value status-PIDFF block

If the value status of the feedforward signal goes bad, the multiplicative feedforward component of the output
value is frozen at the last good value or the additive feedforward component of the output is left out, and normal
PID processing continues.
When the value status of the feedforward signal returns to normal, the feedforward action resumes. This does
not cause a bump in the output because any change from the last good value is internally absorbed and the PID
dynamics are not affected. The floating, full-value output continues as if there were no feedforward change, but
the contribution of the feedforward action continues from that point.
19.11.15 PID equations-PIDFF block

The PIDFF block provides five different equations for calculating the PID - the CTLEQN parameter is used to
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:
485

• Equation E - proportional only as follows:
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.
CV = K * (PV - SP) + OPBIAS.FIX + OPBIAS.FLOAT

• 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

Where:
CV = output of PID (Equations A, B, C, D) in percent or output of P-controller (Equation E

only) in engineering units
PVP = PV in percent
SPP = SP in percent

OPBIAS.FIX = fixed bias (Equation E only)
OPBIAS.FLOAT = floating bias (Equation E only)
19.11.16 Gain options-PIDFF block

If PID equation A, B, or C is selected, any of the following gain equations may be chosen:
1.0.


K = KLIN
K = KLIN * KMODIFGAP
itself.
Where:
tank.
487
K = KLIN*KMODIFEXT
Where:
19.11.17 Output Indication Function-PIDFF block


DirectDisplnd No value reversal - output range is 0 to 100 percent, and display indications
Attention



OPLOALM.PR and .SV
OPHILM = 100 - 20.
Attention



489

closed
19.11.18 Tuning Constant Change Considerations-PIDFF block

Attention
19.11.19 Timeout monitoring-PIDFF block

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.
19.11.20 Timeout processing-PIDFF block

If mode is CAScade and SP times out, the PIDFF block does the following:

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
• Updates the SP.
• Clears CASREQFL.
Attention
19.11.21 Windup handling-PIDFF block

When a windup condition is reached, the PIDFF block stops calculating the integral term, but continues to
calculate the proportional and derivative term.
– 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).
19.11.22 Windup processing-PIDFF block

parameters.


ARWOP computation
491

initialize.
PVSTS = MAN and PVMANOPT = NO_SHED
ARWNET computation

NaN.
The CV is NaN.
SPHIFL = On.

SPLO.FL = On.
19.11.23 Anti-Reset Windup Status-PIDFF block

NORMAL HI HI
NORMAL LO LO
NORMAL HILO HILO
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 NORMAL HILO
HILO HI HILO
HILO LO HILO
HILO HILO HILO
19.11.24 Bypassing feedforward control action-PIDFF block

An operator or a user program may bypass the feedforward action as follows.
• If the feedforward signal comes from an Auxiliary function block (Data Acquisition or Auxiliary
Calculator), set the Auxiliary block’s PVSOURCE parameter to MANual and do not manually change the
PV. To resume feedforward action, change the PVSOURCE to AUTOmatic.
• If the feedforward signal comes from another Regulatory Control block, set the mode of the other block to
MANual and do not manually change the output (OP), which is the FF input to the PIDFF block. To resume
feedforward action, switch the other block’s mode to AUTOmatic or CAScade.
493
19.11.25 Override feedback processing-PIDFF block

Override feedback processing for the PIDFF block is the same as the normal PID block except, if multiplicative
feedforward action is configured, a feedforward term is added to the output calculation as follows. Refer the
“Override feedback processing-AUTOMAN” on page 296 section for the PID Block for more information.
• If the override offset flag is Off and the PID is using either direct or reverse control action, then:
CV=(override feedback value from secondary)
CVPID=(override feedback value from secondary) / (KFF*FF + BFF)
• If the override offset flag is On and the PID is using direct control action, then:
CV=(override feedback value from secondary) + K*(PVP - SPP)*(KFF*FF + BFF)
CVPID=(override feedback value from secondary) / (KFF*/>FF + BFF) + K*(PVP - SPP)
• If the override offset flag is On and the PID is using reverse control action, then:
CV=(override feedback value from secondary) - K* (PVP - SPP)*(KFF*FF + BFF)
CVPID=(override feedback value from secondary) / (KFF*FF + BFF) - K*(PVP - SPP)
Where:
CV=Full-value output of this function block with FF term included
CVPID=full-value output of the PID block without the FF term (This is a calculated value and not a user-
visible parameter.)
BFF=Bias of the feedforward input
K=Overall gain
KFF=Gain of the feedforward input that is clamped between GAINLOLM and GAINHILM.
FF=Feedforward input value
PVP=PV in percent
SPP=SP in percent
Attention
19.11.26 PIDFF parameters

Refer to Control Builder Components Reference for a complete list of the parameters used with the PIDFF
block.
19.12 LEGACYGAP Option in R300

The PID algorithm in Experion controllers is calculated in incremental form. That is, the output CV of the PID
algorithm is calculated incrementally during each execution cycle.
The equation for CV calculation of the PID algorithm in incremental form is as follows: During each execution
cycle, the incremental output value is added to the accumulated output value.
CV (t) = CV(t- l) + Del_CVt
where
CV (t) is the current CV value
CV(t- l) is the CV at the end of previous execution cycle
Del_CVt is the incremental output in the current cycle.
Del_CVt is made up of 3 components. : Proportional increment, integral increment and the derivative increment.
Del_CV =K*( DelCp + Del_Ci + Del_Cd)
Where K = gain
DelCp = proportional component of the incremental value
DelCi = integral component of the incremental value
DelCd = Derivative component of the incremental value
The gain value K may change during each execution cycle in a PID Gap equation based on the value of PV. It
was felt that including a gain change component will result in a more accurate CV value for non linear gain
algorithms such as gap. So in Experion the CV calculation included a gain change component in the CV
calculation when configured for GAP or nonlinear gain. Even though theoretically this is accurate, users
migrating from TPS systems to Experion noticed a change in behavior in PID GAP algorithms.
Experion provides an option to revert back to the older calculation so that there is no change in behavior after
migration. The option when enabled will allow the Experion controllers to have the same behavior as the TPS
xPM controller.
19.12.1 Legacy gap gain option

To provide a solution a new Boolean Configuration parameter LEGACYGAP has been added to PID type
function blocks beginning with R300. The default value for this parameter is FALSE in which case the Experion
PID function block will calculate CV as currently implemented.
If the user sets this parameter to TRUE, the CV will be calculated similar to the xPM controllers. In this case the
gain change component will not be included in the calculation and cause the PID Gap algorithm in the Experion
controller to have the same behavior as the xPM controller.
This parameter is applicable to the following PID type blocks namely PID, PIDFF, PIDER and PID-PL. The
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 following configuration form. The user will have to check this box during configuration to
enable the LEGACYGAP gain option.
19.12.2 Equation-LEGACYGAP
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
495
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.
19.12.3 Configuration-LEGACYGAP
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.
19.12.4 Migration-LEGACYGAP
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.
497
19.13 POSPROP (Position Proportional) Block

The POSPROP (Position Proportional) block provides pulsed digital outputs to drive a final control element to
the desired position. The only valid output destinations are to Digital Output Channel blocks or the Pulse Count
and Pulse Length blocks.
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:
With R410, youYou can configure the on-delay time, off-delay time, deadband value, and deadband unit for the
time, deadband values, and deadband units for the DEVHIALM parameter.
• DEVHIALM.TM
• DEVHIALM.TMO
• DEVHIALM.DB
• DEVHIALM.DBU
The following parameters can be used for configuring the on-delay time and off-delay time for BADCTL
alarms.
• BADCTLALM.TM
• BADCTLALM.TMO
Each POSPROP block supports the following user configurable attributes. The following table lists the given

information.
• PVEU Range Hi (PVEUHI) - Lets you specify the high input range limit that
represents 100% full scale input for the block. The default value is 100.
• PVEU Range Lo (PVEULO) - Lets you specify the low input range limit that
represents the 0 full scale input for the block. The default value is 0 (zero).
– NO_SHED - Idle.
– SHEDHIGH - Raise.
– SHEDLOW - Lower
– SHEDSAFE - Depends on Safe State.
– SHEDHOLD - Idle
NONE.
499

is SHEDHOLD.

Algorithm • Cycle Time (CYCLETIME) - Lets you specify a pulse cycle time in seconds.
The default value is 10 seconds.
• Extra Pulse Time Option (EXTRAPULSE) - Lets you specify whether or not to
include the extra pulse time (EXTRAPULSETM) calculated over a maximum
pulse in the algorithm. The default selection is OFF.
• [Raise] Output Desc (RAISEDESC) - Lets you specify a description of up to 15
characters for the raise output.
• [Raise] Overall Gain (KR) - Lets you specify an overall gain for the raise pulse
generation. The default value is 1.
• [Raise] Output Stroke Rate (RAISERATE) - Lets you specify a rate in percent
per second for the raise stroke for the final control element. The default value is
100.
• [Raise] Stiction Compensation (STICTIONR) - Lets you specify a stiction
compensation in seconds for raising the final control element. The default value
is 0.
• [Raise] Backlash Compensation (BACKLASHR) - Lets you specify a backlash
compensation when raising the final control element. The default value is 0.
• [Raise] Min. Pulse Time (MINPULSER) - Lets you specify the minimum pulse
time in seconds for the raise pulses. The default value is 0.
• [Raise] Max. Pulse Time (MAXPULSER) - Lets you specify the maximum pulse
time in seconds for the raise pulses. The default value is 60.
• [Raise] Error Deadband (ERRORDBR) - Lets you specify the error deadband in
percent for the raise pulses.
• Safe Output Command (SAFEOPCMD) - Lets you select the output mode to
shed to for Bad control condition. The default selection is Idle.
• Manual Pulse Time (MANPULSETIME) - Lets you specify the pulse time in
seconds to be used in Manual mode. The default value is 1.
• No Command (PULSECMDTEXT[0]) - Lets you specify a text description for
the no command condition. The default text is Idle.
• Low Command (PULSECMDTEXT[1] - Lets you specify a text description for
the Raise Command condition. The default text is Raise.
• Raise Command (PULSECMDTEXT[2]) - Lets you specify a text description
for the Low Command condition. The default text is Low.
• [Lower] Output Desc (LOWERDESC) - Lets you specify a description of up to
15 characters for the lower output.
• [Lower] Overall Gain (KL) - Lets you specify an overall gain for the lower pulse
generation. The default value is 1.
• [Lower] Output Stroke Rate (LOWERRATE) - Lets you specify a rate in percent
per second for the lower stroke for the final control element. The default value is
100.
• [Lower] Stiction Compensation (STICTIONL) - Lets you specify a stiction
compensation in seconds for lowering the final control element. The default
value is 0.
• [Lower] Backlash Compensation (BACKLASHL) - Lets you specify a backlash
compensation when lowering the final control element. The default value is 0.
• [Lower] Min. Pulse Time (MINPULSEL) - Lets you specify the minimum pulse
time in seconds for the lower pulses. The default value is 0.
• [Lower] Max. Pulse Time (MAXPULSEL) - Lets you specify the maximum
pulse time in seconds for the lower pulses. The default value is 60.
• [Lower] Error Deadband (ERRORDBL) - Lets you specify the error deadband in
percent for the lower pulses.
501

MANual.
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.

(DEVHIALM.PR, DEVLOALM.PR, ADVDEVALM.PR, SIALM.PR,
BADCTLALM.PR,). The default value is LOW. The levels are:
display.
Summary display.
(DEVHIALM.SV, DEVLOALM.SV, ADVDEVALM.SV, SIALM.SV,
BADCTLALM.SV,) as a number between 0 to 15, with 15 being the most
severe. This determines the alarm processing order relative to other alarms. The
default value is 0.
• Deadband Value (ALMDB) - Lets you specify a deadband value that applies to
all analog alarms to prevent nuisance alarms due to noise at values near the trip
point. The default value is 1.
Note that this value is loaded to the individual alarm parameters (for example,
DEVHIALM.DB and DEVLOALM.DB) when the CM is loaded. If you
configure the individual alarm parameters as Monitoring Parameters for the
block, you can change the individual alarm value while monitoring the loaded
block in CB.
• Deadband Time (ALMTM) - Lets you specify a time in seconds to define how
long an analog alarm must exist before it is set true. The default value is 0,
which means the alarm is set true as soon as the value exceeds the deadband
value.
DEVHIALM.TM and DEVLOALM.TM) when the CM is loaded. If you
block in CB.
• Deadband Units (ALMDBU) - Lets you specify if the deadband value represents
percent or engineering units. The default value is percent.
503

DEVHIALM.DBU and DEVLOALM.DBU) when the CM is loaded. If you
block in CB.
selections are:
– None
– ONESHOT
– SEMICONT
– CONTRTN
– CONT
block:
– FIXEDOP - Set OPREQ = Configured Value (Not applicable to this block).
Configured Rate.
faceplate.

information
19.13.1 Function-POSPROP block

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.
Table 26: Example of Position Proportional loop for controlling valve position.
505
Table 27: Example of Position Proportional loop for controlling valve position through pulse length or pulse count function.
19.13.2 Operating modes and mode handling-POSPROP block

The POSPROP block operates in the following modes:
• MAN (MANual)
– If mode is MANual, output may be stored by the operator through group or detail display in Station
using designated Raise/Lower keys or buttons; PV and SP are ignored - if a primary exists, it goes to the
initialized state.
in percent.
• CAS (CAScade)
– If mode is CAScade, SP is pulled from another function block; if the other block is off-control (that is,
inactive or initializing) or the connection is bad, the POSPROP block invokes timeout processing.
19.13.3 Required inputs-POSPROP block

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.
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.
19.13.4 Input ranges and limits-POSPROP block

• You must specify a PV engineering unit range through the configurable PVEUHI and PVEULO parameters.
• The POSPROP 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.
– 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 POSPROP block clamps it to the
appropriate limit and sets the input windup status.
19.13.5 Output-POSPROP block

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 RAISETIME or LOWERTIME 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 PULSETIME output to these parameters.)
19.13.6 Initializable inputs and outputs-POSPROP block

parameter with the “initializable” attribute has an associated BACKCALC parameter. When a connection
For example, if you connect OP from a PID block to SP of a POSPROP block, Control Builder automatically
creates the BACKCALCOUT to BACKCALCIN connection. In this case, the POSPROP block provides the SP
input range (PVEUHI and PVEULO) to the primary PID block through the BACKCALC connection. The PID
block uses this for its output range (CVEUHI/CVEULO).
507
19.13.7 Output ranges-POSPROP block

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.)
19.13.8 Set Point Ramping-POSPROP block

• Otherwise,:
SPTVRATE = NaN
And also SP Ramping will pause/stops when the calculated SP increment would
cause the SP to exceed the deviation limit, the SP is paused at the current value,
which may be less than the deviation limit value.
(SPTVDEVFL).
Control Builder or the Point Detail display in Station.
• The block calculates a ramp time (SPTVTIME) .
deviation limit.
Otherwise:
SPTVRATE = NaN
Otherwise:
SPTVRATE = NaN
Auto or Manual.
• Off,
• Preset, or
• Run
this occurs:
Station.
509
Callout Description
1 Block's mode must be Auto and SPTVSTATE must be Preset, before you can start SP ramping by setting
2 The SPTVSTATE automatically goes to Preset, when:
3 You can only set a value for SPTV and SPTVTIME, when:
Attention
19.13.9 Timeout monitoring-POSPROP block

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.

19.13.10 Timeout processing-POSPROP block

If mode is CAScade and SP times out, the POSPROP block does the following:
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:
• Updates the SP.
Attention
19.13.11 Equations-POSPROP block

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:
RAISETIME=(KR*(SPP - PVP) / RAISERATE + RAISEDEADTM + EXTRAPULSETM
• If PVP is greater than (SPP + ERRORDBL) and the Lower limit flag (LOWERLMFL) is OFF, then issue a
Lower pulse with a duration of:
LOWERTIME=(KL*(PVP - SPP) / LOWERRATE + LOWERDEADTM + EXTRAPULSETM
Where:
EXTRAPULSETM=The extra pulse time leftover from the last control interval, if you configured the Extra
Pulse Time Option (EXTRAPULSE) to be ON.
KL=Overall gain for Lower pulse generation.
KR=Overall gain for Raise pulse generation.
LOWERDEADTM=Lower dead time in seconds. This is STICTIONL, if the last pulse was also a lower
pulse; or is BACKLASHL, if the last pulse was a Raise pulse.
LOWERRATE=Lower stroke rate in percent per second.
LOWERTIME=Lower pulse time in seconds.
PVP=PV in percent.
RAISEDEADTM=Raise dead time in seconds. This is STICTIONR, if the last pulse was also a Raise pulse;
or is BACKLASHR, if the last pulse was a Lower pulse.
RAISERATE=Raise stroke rate in percent per second.
RAISETIME=Raise pulse time in seconds.
511
SPP=SP in percent.
• The PULSETIME output is set to either the RAISETIME or -LOWERTIME, when either RAISETIME or
LOWERTIME is non-zero.
19.13.12 Control Initialization-POSPROP block

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.
19.13.13 Secondary initialization option-POSPROP block

• 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.
19.13.14 Override feedback processing for POSPROP block

The POSPROP block does not propagate override feedback data. It ignores any override feedback requests.
19.13.15 Raise/Lower limit switches of POSPROP block

You can use the Raise and Lower limit flags (RAISELMFL and LOWERLMFL) to indicate the status of valve
position limit switches. These flags are usually set by bringing limit indicators from a SWITCH or Logic block.
When the RAISELMFL is ON, the POSPROP block does not output Raise pulses; and when the LOWERLMFL
is ON, the block does not output Lower pulses.
19.13.16 Bad control processing-POSPROP block

The action the POSPROP takes during Bad control conditions depends upon how you have configured the Bad
Control Option (BADCTLOPT) as follows:
If Bad Control Option is… Then, control processing is…

NO_SHED The PULSECMD equals Idle. The POSPROP block issues no more output pulses.
SHEDHOLD The PULSECMD equals Idle. The mode sheds to MANual, but the POSPROP issues no
new Raise or Lower pulse - the output changes to zero.
If Bad Control Option is… Then, control processing is…

SHEDLOW The mode sheds to MANual and POSPROP issues a Lower pulse (LOWERTIME) that
equals 10 times the Manual Pulse Time (MANPULSETM) and PULSETIME output
equals - LOWERTIME until the PV is less than or equal to the PVEULO or the Lower
limit flag (LOWERLMFL) is ON. If the PV is bad, the test for PV less than or equal to
PVEULO is ignored. Note that the POSPROP output ignores MINPULSER/
MINPULSEL.
SHEDHIGH The PULSECMD equals Raise. The mode sheds to MANual and POSPROP issues a
Raise pulse (RAISETIME) that equals 10 times the Manual Pulse Time
(MANPULSETM) and PULSETIME output equals -RAISETIME until the PV is greater
than or equal to the PVEUHI or the Raise limit flag (RAISELMFL) is ON. If the PV is
bad, the test for PV less than or equal to PVEUHI is ignored. Note that POSPROP clamps
the output at MAXPULSER/MAXPULSEL or CYCLETIME, whichever is less.
SHEDSAFE The mode sheds to MANual. The output of the POSPROP block depends on how you
configured the Safe Output Command (SAFEOPCMD) as follows:
If SAFEOPCMD equals Idle, the POSPROP generates no more output pulses.
If the SAFEOPCMD equals Raise, the POSPROP issues Raise pulses until PV is greater
than or equal to PVEUHI or the Raise limit flag (RAISELMFL) comes ON. If the PV is
bad, the test for PV is greater than or equal to PVEUHI is ignored.
If the SAFEOPCMD equals Lower, the POSPROP issues Lower pulses until the PV is
less than or equal to PVEULO or the Lower limit flag (LOWERLMFL) comes ON. If the
PV is bad, the test for PV is less than or equal to PVEULO is ignored.
19.13.17 Windup processing-POSPROP block

parameters.


ARWOP computation
513

initialize.
ARWNET computation

NaN.
The CV is NaN.
SPHIFL = On.
SPLO.FL = On.
19.13.18 Anti-Reset Windup Status-POSPROP block

NORMAL HI HI
NORMAL LO LO
NORMAL HILO HILO
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 NORMAL HILO
HILO HI HILO
HILO LO HILO
HILO HILO HILO
19.13.19 POSPROP parameters

POSPROP block.
515
19.14 PULSECOUNT Block

The PULSECOUNT block generates pulses according to its pulse count control algorithm. The pulsed outputs
are usually fed to Digital Output Channel blocks.
The PULSECOUNT block requires a pulse time parameter and a user configurable pulse output period as its
inputs. The digital outputs are pulsed in relation to the configured period and the pulse time that is requested. It
looks like this graphically:
Each PULSECOUNT block supports the following user configurable attributes. The following table lists the

information.
• Direction Change Delay (PDELAYDIRCHG) - Lets you specify the delay time
in seconds before starting a pulse output (PORAISE,POLOWER, PO) after a
change in direction. This gives the final control element time to react to an
upcoming change in direction. The default value is 0.
• Pulse Output Period (POPERIOD) - Lets you specify the pulse output period in
seconds. This generates 50% duty cycle pulses in the requested pulse time. The
default value is 0.01.
faceplate.
information
19.14.1 Function-PULSECOUNT block

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.
Table 29: Example of pulse count control algorithm outputs
19.14.2 Required inputs-PULSECOUNT block

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.
517
19.14.3 Output-PULSECOUNT block

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.
19.14.4 Initializable inputs and outputs-PULSECOUNT block

For example, if you connect PORAISE from a PULSECOUNT block to SO of a DOCHANNEL block, Control
Builder automatically creates the BACKCALCOUT to BACKCALCIN connection. In this case, the back
calculation input for PORAISE is BCALCINPOR.
19.14.5 PULSECOUNT parameters

Refer to Control Builder Components Reference for a complete list of the parameters used with the
PULSECOUNT block.
19.15 PULSELENGTH Block

The PULSELENGTH block generates pulse trains according to its pulse length control algorithm. The pulsed
outputs are usually fed to Digital Output Channel blocks.
The PULSELENGTH block requires a pulse time parameter as its input. The digital outputs are pulsed in
relation to the pulse time that is requested. It looks like this graphically:
Each PULSELENGTH block supports the following user configurable attributes. The following table lists the

information.
• Direction Change Delay (PDELAYDIRCHG) - Lets you specify the delay time
in seconds before starting a pulse output (PORAISE,POLOWER, PO) after a
change in direction. This gives the final control element time to react to an
upcoming change in direction. The default value is 0.
faceplate.
information
19.15.1 Function-PULSELENGTH block

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
519
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).
Table 30: Example of pulse length control algorithm outputs
19.15.2 Required inputs-PULSELENGTH block

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.
19.15.3 Output-PULSELENGTH block

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.
19.15.4 Initializable inputs and outputs-PULSELENGTH block

For example, if you connect PORAISE from a PULSELENGTH block to SO of a DOCHANNEL block,
Control Builder automatically creates the BACKCALCOUT to BACKCALCIN connection. In this case, the
back calculation input for PORAISE is BCALCINPOR.
19.15.5 PULSELENGTH parameters

PULSELENGTH block.
521
19.16 RAMPSOAK Block

The RAMPSOAK block provides an output that tracks a user configured set point versus time profile. The
block supports up to 99 separate profiles with up to 50 user configured ramp and soak segment pairs per profile.
This lets you implement a set point program control function by driving the set point of another regulatory
control function block. The RAMPSOAK block looks like this graphically:
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.
With R, you can configure the on-delay time, off-delay time, deadband value, and deadband unit for the
• OPHIALM.TM
• OPHIALM.TMO
• OPHIALM.DB
• OPHIALM.DBU
Each RAMPSOAK block supports the following user configurable attributes. The following table lists the given

information.
• High Limit (PVEUHI) - Lets you specify the high input range value in
• Low Limit (PVEULO) - Lets you specify the low input range value in
display. Selections are MANual, AUTOmatic, CAScade, BackupCAScade, and
NONE.
the block's MODE as appropriate. (Note that the AUTOmatic mode is not a
valid initial configuration mode for the RAMPSOAK block, since the block's
mode must be MANual after it is loaded to the Controller and the Control
Module containing it is activated.)
523

The default selection is Enabled (checked, do not ignore
• Reset Segment Timers on Profile (RESETTIMER) - Lets you control the
segment timers when restarting a profile. When checked (or ON), all timers
(event timers, soak timer, and so on) are reset, when the profile starts. When
unchecked (or OFF), all timers resume with their previous values when the
profile starts. The default is checked (or ON). (Note that whenever a new profile
is loaded the RESETTIMER parameter is automatically set to ON and the
TIMEPASTTHISSEG is not reset since it is used to compute the values of
statistic parameters ACTRAMPRATE and ACTSOAKTIME.)
• Safety Interlock Option (SIOPT) - Lets you specify MODE and OP the block is
to assume upon a safety interlock alarm. The selections are NO_SHED,
is SHEDHOLD.
Option is enabled.

Profile • Profile ID - List box shows the configured profiles. The New, Copy, and Delete
buttons let you manipulate profiles as desired.
• Description (PROFILEDESC[n]) - Lets you enter a unique profile name of up to
16 characters long for the profile selected in the list box. The default name is
Profilen. Where “n” equals the assigned profile number from 1 to 99.
• Max Ramp Dev (MAXRAMPDEV[n]) - Lets you specify a desired maximum
ramp deviation value between PV and OP to assure a guaranteed ramp rate. You
can specify a different value for each profile. The default value is NaN (Not-a-
Number), which means no ramp rate checking is done.
• Max Hi Soak Dev (MAXHISOAKDEV[n] - Lets you specify a desired
maximum high soak deviation value between PV and OP to assure a guaranteed
soak. You can specify a different value for each profile. The default value is NaN
(Not-a-Number), which means no high soak value checking is done.
• Max Lo Soak Dev (MAXLOSOAKDEV[n] - Lets you specify a desired
maximum low soak deviation value between PV and OP to assure a guaranteed
soak. You can specify a different value for each profile. The default value is NaN
(Not-a-Number), which means no low soak value checking is done.
• Starting OP Value (STARTOP[n]) - Lets you specify a desired starting output
(OP) value for each profile. The default value is 0.
• Starting Segment ID (STARTSEG[n]) - Lets you specify the starting segment for
each profile. The ramp segments have odd numbers and the soak segments have
even numbers. The default value is 1.
• Cycle Option (CYCLEOPT) - Lets you select how you want the profiles to be
cycled. The SINGLE selection means that the selected (running) profile will stop
after it executes its last ramp/soak pair. The CYCLIC selection means that the
selected (running) profile will continuously cycle from start to end. This means
it will restart at the starting segment once it executes the last ramp/soak pair. The
ROUNDROBIN selection means that after executing the last ramp/soak
segment, the RAMPSOAK block will start execution of the next profile in the
order. Every consecutive profile configured for ROUNDROBIN is executed in
order. This means that execution will never stop until the next profile is
configured for SINGLE or CYCLIC Cycle Option action. For example, after the
last ramp/soak pair in the last profile is executed, the execution of the first
profile begins and so on until the next profile is configured for SINGLE or
CYCLIC action.
• RampSoak Pair ID - Lets you configure ramp/soak pairs for the selected profile
by entering desired Ramp Rate (RAMPRATE[n,s]), Soak Value
(SOAKVAL[n,s]), and Soak Time (SOAKTIME[n,s]) in minutes. Where “s”
equals the number of the ramp/soak pair from 1 to 50.
• Even ID - Lets you configure up to 16 event flags (EVENTFL[n,e]) for segments
in the selected profile by entering the segment number (EVENTSEGID[n,e]), the
start time (EVENTBGNTIME[n,e]) in minutes counted from the beginning of
the selected segment when the event flag is turned ON, and the stop time
(EVENTENDTIME[n,e]) in minutes counted from the beginning of the selected
segment when the event flag is turned OFF. Where “e” equals the number of the
event from 1 to 16.
Profile Graph • Graph - Shows you a graphic representation of the configured set point versus
time profile.
• Profile ID - List box shows configured profiles that you can select for display in
the graph.
• No. of Segments - Number of segments in selected profile.
• Target Profile Time (TOTALTIME[n]) - Total time in minutes to complete the
selected profile.
• Static - Provides an array of the configured event flags. A number in a box
represents a configured event. Click the numbered box to display the event
markers on the graph.
525

Active Profile Graph • Graph - Shows you a graphic representation of the configured set point versus
time profile with real time data when profile is running in CB Monitoring tab.
• Mode (MODE) - Shows current mode selection and lets you change the mode of
running profile in CB Monitoring tab.
• Current Profile ID (CURPROFILEID) - Shows number of profile currently
running.
• No. of Segments - Shows the total number of segments in the current profile.
• Current Segment ID (CURSEGID) - Shows the number of the segment currently
being executed in the selected profile.
• Total Elapsed Time (TOTELAPSEDTM) - Shows the total elapsed time for
current profile execution. It includes time for stopped timers due to deviation
exceeding limits.
• Net Elapsed Time (NETELAPSEDTM) - Shows the net elapsed time for current
profile execution. It does not include the time for stopped timers due to deviation
exceeding limits.
• Rem Soak Time (REMSOAKTIME) - Shows the remaining soak time for the
current soak segment.
• Soak Duration - Shows the duration of the current soak segment.
• Events - Shows an array of the configured event flags for the current segment.
Click the numbered box to display the event markers on the graph.

default value is 105%. (Note that you cannot change this value through
Monitoring mode after the configuration is loaded in the Controller.)
is -5%. (Note that you cannot change this value through Monitoring mode after
the configuration is loaded in the Controller.)
block that is in the MANual mode. The default value is 106.9%. (Note that you
cannot change this value through Monitoring mode after the configuration is
loaded in the Controller.)
is in the MANual mode. The default value is -6.9%. (Note that you cannot
change this value through Monitoring mode after the configuration is loaded in
the Controller.)
527

Option (SIOPT). The types are:
• Enable Alarm SIALM.OPT ) - Lets you enable or disable Safety Interlock alarm
type. A check in the box means the alarm is enabled. The default selection is
checked or Yes (enabled).
You can also configure the SIALM.OPT parameter as a block pin, configuration
and/or monitoring parameter so it appears on the block in the Project and
Monitoring tree views, respectively.
• OPLOALM.TP (Output Low Alarm Trip Point)
SIALM.PR). The default value is LOW. The levels are:
display.
Summary display.
SIALM.SV) as a number between 0 to 15, with 15 being the most severe. This
determines the alarm processing order relative to other alarms. The default value
is 0.
+ deadband value.

RAMPSOAK block. If you configure the deadband unit as “EU or Percent” for
an alarm, this configuration is identical for the all other alarms in the
RAMPSOAK block. However, if you are migrating from pre-R410 to later
You must configure identical deadband units for all alarms in the RAMPSOAK
block.
default value (0).
529

selections are:
– None
– ONESHOT
– SEMICONT
– CONTRTN
– CONT
block:
– HOLDPV - Set SPREQ = PV. (Not applicable for RAMPSOAK block)
– FIXED SP - Set SPREQ = Configured Value and SPRATEREQ = NaN. (Not
applicable for RAMPSOAK block)
Configured Rate. (Not applicable for RAMPSOAK block)
faceplate.
information
19.16.1 Function-RAMPSOAK block

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.
Table 31: Functional diagram of ramp and soak (set point) programmer in PID control loop.
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].
531
19.16.2 Required inputs-RAMPSOAK block

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.
19.16.3 Input ranges and limits-RAMPSOAK block

• You must specify a PV engineering unit range, PVEUHI and PVEULO. The default range is 0 to 100.
• The PID block assumes PV is within PVEUHI and PVEULO - it applies no range check - however, PV
typically comes from an auxiliary or data acquisition (DATAACQ) block which applies its own limit and
range checks.
19.16.4 Initializable outputs-RAMPSOAK block

variable with the “initializabl” attribute has an associated BACKCALC variable, and when a connection is
For example, if you connect OP from a RAMPSOAK block to SP on a PID block, Control Builder
connect the output from a RAMPSOAK block (RAMPSOAK.OP) to the set point of a PID block (PIDA.SP),
the implicit/hidden connection is made to RAMPSOAK.OPX to provide value/status data.)
19.16.5 Output ranges and limits-RAMPSOAK block

– If the RAMPSOAK block has a secondary, it brings the secondary's input range through BACKCALC
and sets its CV range to that.
– If the RAMPSOAK block has no secondary, you can configure CVEUHI and CVEULO to specify the
desired range values. The default values are 100 and 0, respectively, for a default range of 0 to 100.
• OPHILM and OPLOLM define the normal high and low limits for OP as a percent of the CV range. You can
also configure values for these limits. The default limits are 105% and -5%, respectively.
user program attempts to store an OP value that exceeds them.
You can also configure values for these limits. The default limits are 106.9% and -6.9%, respectively.
(Note that the RAMPSOAK block does not apply a floating bias to the output.)
19.16.6 Mode handling-RAMPSOAK block

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
19.16.7 Hold command-RAMPSOAK block

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.
19.16.8 CEE idle or Control Module inactivate command-RAMPSOAK block

When you change the CEE from Run to Idle or the Control Module from Active to Inactive, the contained
RAMPSOAK block does the following.
• Sets mode to MANual.
• Sets CV to NaN.
• Resets internal ramp/soak timers.
• Sets current profile ID to 1 (first profile).
• Sets current segment ID to 1 (first ramp segment).
19.16.9 Profile statistics-RAMPSOAK block

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.
533
• 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.
19.16.10 Guaranteed ramp rate-RAMPSOAK block

If you configure a maximum ramp deviation (MAXRAMPDEV[n]) value for a given profile, the RAMPSOAK
block makes sure that the calculated output (CV) value does not deviate from the input (PV) by more than the
configured deviation value. If it does deviate, the block stops the ramping action until PV catches up with CV.
The RAMPSOAK block will stop the ramping action for the following condition.
• The Absolute Value of CV-PV is greater than the maximum ramp deviation (MAXRAMPDEV[n]. Where
“n” is the number of the current profile.
If the maximum ramp deviation (MAXRAMPDEV[n]) value is NaN, the RAMPSOAK block ignores the above
condition.
(Note that you can also stop the ramping by setting the hold command (HOLDCMD) to ON. This lets an
operator, a user program, or a logic type function block stop the ramping until some other condition is satisfied.)
19.16.11 Guaranteed soak time-RAMPSOAK block

If you configure the maximum high soak deviation (MAXHISOAKDEV[n]) and/or the maximum low soak
deviation (MAXLOSOAKDEV[n]) value, the RAMPSOAK block makes sure the calculated output (CV) value
is at the proper value before it starts the soak timer. The RAMPSOAK block verifies that the CV and input PV
are within the configured deviation limits and it will not start the soak timer for the following conditions.
• If the input (PV) is greater than the CV.
• If the PV is less than the CV.
If the deviation exceeds the limit during a soak, the block stops the soak timer until the deviation returns to
within limits and then it automatically restarts the timer.
If the MAXHISOAKDEV[n] and/or the MAXLOSOAKDEV[n] value is NaN, the RAMPSOAK block ignores
the above condition or conditions, as applicable.
(Note that you can also keep the soak timer from starting by setting the hold command (HOLDCMD) to ON.
This lets an operator, a user program or a logic type function block put a hold on the stop timer until some other
condition is satisfied.)
19.16.12 Event timer functions-RAMPSOAK block

You can configure up to 16 event flags (EVENTFL[n,e]) to provide Boolean outputs for a specified time during
a given ramp or soak segment in a given profile. This means you can have up to 16 events per profile or a total
of 160 events in 10 profiles.
The following parameters are associated with each event flag.
EVENTSEGID[n,e] - Identifies the segment in a given profile to which the event applies.
EVENTBGNTIME[n,e] - The user-configured time in minutes measured from the start of the segment when the
given event turns ON. This is also called the start time.
EVENTENDTIME[n,e] - The user-configured time in minutes measured from the start of the segment when the
given event turns OFF. This is also called the stop time.
Note that you can configure the start time (EVENTBGNTIME[n,e] to be greater than or equal to the stop time
(EVENTENDTIME[n,e], but such a configuration results in no event action.
19.16.13 Control initialization-RAMPSOAK block

The RAMPSOAK block brings initialization requests from its secondary through BACKCALC. In addition, the
• If the secondary is requesting initialization, the RAMPSOAK block:
19.16.14 Override feedback processing-RAMPSOAK block

The RAMPSOAK block does not propagate override feedback data. It ignores any override feedback requests it
receives.
19.16.15 Output Indication Function-RAMPSOAK block


Reverse1 Value reversal - output range is 100 to 0 percent, and no display indications -
1 The RAMPSOAK block does not support the Reverse option selection.

535
19.16.16 Windup processing-RAMPSOAK block

parameters.


ARWOP computation

initialize.
ARWNET computation

NaN.
The CV is NaN
SPHIFL = On.
SPLO.FL = On.
19.16.17 Anti-Reset Windup Status-RAMPSOAK block

NORMAL HI HI
NORMAL LO LO
NORMAL HILO HILO
HI NORMAL HI
HI HI HI
HI LO HILO
HI HILO HILO
LO NORMAL LO
LO HI HILO
537
LO LO LO
LO HILO HILO
HILO NORMAL HILO
HILO HI HILO
HILO LO HILO
HILO HILO HILO
19.16.18 RAMPSOAK parameters

RAMPSOAK block.
19.17 RATIOBIAS Block

The RATIOBIAS block accepts a ratio value input (RT) and an input value (X1) to provide a calculated output
based on the ratio of the input variables plus a fixed and/or a floating bias. It looks like this graphically:
• OPHIALM.TM
• OPHIALM.TMO
• OPHIALM.DB
• OPHIALM.DBU
The following parameters can be used for configuring the on-delay time and off-delay time for BADCTL
alarms.
• BADCTLALM.TM
• BADCTLALM.TMO
Each RATIOBIAS block supports the following user configurable attributes. The following table lists the given
name of the “Ta” in the parameter configuration form and then briefly describes the attributes associated with
539

• Ratio (RT) - Lets you specify a value between 0.001 and 100 to be used for the
RT input when the block is in its AUTOmatic mode. The default value is 1.
information.
• X1 High Limit (XEUHI) - Lets you specify the high input range value in
engineering units that represents 100% full scale input for the block. The default
value is 100.
• X1 Low Limit (XEULO) - Lets you specify the low input range value in
engineering units that represents the 0 full scale input for the block. The default
value is 0 (zero).
• Ratio High Limit (RTHILM) - Lets you specify the high ratio limit value in
engineering units. The default value is 100.
• Ratio Low Limit (RTLOLM) - Lets you specify the low ratio limit value in
engineering units. The default value is 0.001.
NONE.

is SHEDHOLD.
SHEDLOW, SHEDHIGH, and SHEDSAFE. The default selection is NO_SHED.
Option is enabled.
MANual.
541

is -5%.

display.
Summary display.
543

RATIOBIAS block. If you configure the deadband unit as “EU or Percent” for
RATIOBIAS block. However, if you are migrating from pre-R410 to later
RATIOBIAS block.
default value (0).

selections are:
– None
– ONESHOT
– SEMICONT
– CONTRTN
– CONT
block:
Configured Rate (not applicable to this block).
faceplate.
insertion configuration considerations for regulatory control blocks”for more
information
545
19.17.1 Function-RATIOBIAS block

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.
19.17.2 Configuration example-RATIOBIAS block

RATIOBIAS block to form a ratio control loop for quick reference. The view in the following figure depicts a
configuration in Project mode.
Table 32: Example CB configuration using RATIOBIAS block.
Callout Description
1 Use the PV parameter connection to carry data from the analog input to the other block. The default PV
2 Use the DATAACQ block to define input range values and provide alarm monitoring on the analog input.
3 Use the RATIOBIAS block in cascade mode to accept X1 and RT primary inputs from other blocks.
Callout Description
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.
6 Control Builder creates the X1BACKCALOUT and RTBACKCALOUT hidden connections to carry
BACKCAL (secondary) data from the RATIOBIAS block to the BACKCALCIN connections on X1 and
RT primary blocks , respectively. The individual BACKCALCIN/BACKCALCOUT connections for each
output used are automatically built by Control Builder as implicit/hidden connections.
19.17.3 Operating modes and mode handling-RATIOBIAS block

The RATIOBIAS block supports the Manual, Automatic, and Cascade modes of operation.
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.
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.
19.17.4 Required inputs-RATIOBIAS block

A RATIOBIAS block requires one or two inputs depending on the block's Mode, as follows.
If Mode is. . . Then, block requires. . .

Cascade both X1 and RT inputs.
Auto only X1 input.
• 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.
19.17.5 Input ranges and limits-RATIOBIAS block

• You must specify an X1 engineering unit range, XEUHI and XEULO.
– XEUHI and XEULO define the full range of X1 in engineering units.
547
• This block assumes X1 is within XEUHI and XEULO - it applies no range check
• You must specify RTHILM and RTLOLM to define the ratio limits in engineering units. RT cannot exceed
these limits. The maximum RTHILM value is 100.0 and the minimum RTLOLM value is 0.001, so the RT
range must be between 0.001 and 100.0.
– 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.
19.17.6 Initializable outputs-RATIOBIAS block

parameter with the “initializable” attribute has an associated BACKCALC parameter, and when a connection is
For example, if you connect OP from a RATIONBIAS block to SP on a PID block, Control Builder
• The RATIOBIAS block has the following initializable outputs:
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
multiple connections from a single RATIOBIAS output.
19.17.7 Output ranges and limits-RATIOBIAS block

that. If it has no secondary, CVEUHI and CVEULO track the X1 input range (XEUHI and XEULO).
Attention
OPHILM and OPLOLM define the normal high and low limits for OP, as a percent of the CV range. These are
user-specified values.
OPHILM and OPLOLM define the extended high and low limits for OP, as a percent of the CV range. These
This block calculates CV using this equation:

• CV = X1 * RT + OPBIAS.FIX + OPBIAS.FLOAT
19.17.8 Control initialization-RATIOBIAS block

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:
– 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.)
• requests both primaries to initialize:
– INITREQ[1] = ON
– INITREQ[2] = ON
Where:
OPBIAS.FIX = fixed output bias
INITREQ[2] = initialization request flag for the RT primary
INITVAL[2] = initialization value for the RT primary
INITREQ[1] = initialization request flag for X1 primary
INITVAL[1] = initialization value for X1 primary
19.17.9 Ratio bias option-RATIOBIAS block

The following table summarizes block operation for given ratio bias option (RBOPTION) selection.
If RBOPTION Selection Then, Block Behavior Is. . .

Is . . .
FixedRatioBias During initialization, it is back calculated as follows,
INITVAL (X1) = (OP - OPBIAS.FIX) / RT
INITVAL (RT) = (OP - OPBIAS.FIX) / X1
In Auto mode, the RT and BIAS values are set by the operator or a user program.
In Cascade mode, the RT value is fetched from the upstream function block only. The BIAS is
set by the operator or a user program.
549
If RBOPTION Selection Then, Block Behavior Is. . .

Is . . .
AutoRatio During initialization, the RT value is not fetched or settable. It is back calculated as follows:
RT = (OP - OPBIAS.FIX) / X1.
If X1 is zero in Auto mode, RT = INITVAL(RT).
Clamp RT within RT limits.
The BIAS can be set by the operator or a user program.
INITVAL (X1) = (OP - OPBIAS.FIX) / RT
AutoBias During initialization, BIAS is not fetched or settable. It is back calculated as follows:
BIAS = OP - (RT * X1)
Clamp BIAS within BIAS limits.
INITVAL (X1)= (OP - OPBIAS.FIX) / RT
In Auto mode, the RT value is set by the operator or a user program only.
In Cascade mode, the RT value is fetched from the upstream function block only.
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.
19.17.10 Output bias-RATIOBIAS block

RATIOBIAS block only applies OPBIAS.FLOAT to the output for the latter two conditions, when it is the
first initializable block.)
Attention
recomputed.
Attention
When the Ratio Bias Option (RBOPTION) is set to FixedRatioBias, the OPBIAS.FIX value is limited to a range
between BSLOLM and BSHILM (-50.0 to 50.0, by default). If you enter any values outside this range for
OPBIAS.FIX, the following error appears “RATIOBIASA.OPBIAS.FIX: Limit or Range Exceeded
[EPKS_E_RangeLimitEr (2L.101.2058)].”
occurs:
Where:
parameter.
– Zero:
– Non-zero:
parameter. The function block ramps the OPBIAS.FLOAT to zero by applying the following calculation
each time it executes.
Where:
– NaN:
551
19.17.11 Timeout monitoring-RATIOBIAS block

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.
19.17.12 Timeout processing-RATIOBIAS block

• 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
19.17.13 Override feedback processing

If the RATIOBIAS block is in a cascade strategy with a downstream OVRDSEL (Override Selector) block, it
OVRDSEL block). The offset flag only applies to PID-type blocks.
When the override status changes from selected to unselected, the RATIOBIAS block does the following:
• Computes a feedback value for the X1 and RT primaries:
feedback value for X1 primary=(ORFBVAL - OPBIAS.FIX - OPBIAS.FLOAT) / RT
feedback value for RT primary=(ORFBVAL - OPBIAS.FIX - OPBIAS.FLOAT) / override feedback value
for X1 primary
Where:
ORFBVAL=override feedback value received from secondary
OPBIAS.FIX=fixed output bias
OPBIAS.FLOAT=floating output bias
Attention
19.17.14 Output Indication Function-RATIOBIAS block


Attention


OPLOALM.PR and .SV
553

OPHILM = 100 - 20.
Attention


19.17.15 Windup handling-RATIOBIAS block

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.)
If OP is. . . ARWOP =. . . And Secondary's Windup = And Secondary's Windup =

Lo; then, ARWOP =. . . Hi; then, ARWOP =. . .
not clamped NORMAL Lo Hi
clamped at its high limit Hi HiLo Hi
clamped at is low limit Lo Lo HiLo
The ARWNET[1] parameter indicates if X1 is woundup. This is a copy of the ARWOP, which means; if OP is
woundup, then X1 is also woundup.
The ARWNET[2] parameter indicates if RT input is woundup. RT winds up, if it is clamped or OP is woundup.
ARWNET[2] is computed as follows.
If RT is. . . And ARWOP = Normal; then, And ARWOP = Lo; then, And ARWOP = Hi; then,
ARWNET[2] =. . . ARWNET[2] =. . . ARWNET[2] =. . .
19.17.16 Windup processing-RATIOBIAS block

parameters.


ARWOP computation

555

initialize.
ARWNET computation

NaN.
The CV is NaN
SPHIFL = On.
SPLO.FL = On.
19.17.17 Anti-Reset Windup Status-RATIOBIAS block

ARWNETIN or ARWOPIN Parameters Standard Computation Logic Is . . . ARWNET or ARWOP Parameter Is . . .

is…
NORMAL HI HI
NORMAL LO LO
NORMAL HILO HILO
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 NORMAL HILO
HILO HI HILO
HILO LO HILO
HILO HILO HILO
19.17.18 RATIOBIAS parameters

RATIOBIAS block.
557
19.18 RATIOCTL (Ratio Control) Block

The RATIOCTL block accepts the actual value of the controlled 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 flows (PV) as outputs. This block is typically used to control one flow as the
ratio of another. It looks like this graphically:
• OPHIALM.TM
• OPHIALM.TMO
• OPHIALM.DB
• OPHIALM.DBU
BADCTLALM alarm.
• BADCTLALM.TM
• BADCTLALM.TMO
Each RATIOCTL block supports the following user configurable attributes. The following table lists the given

information.
NONE.
is SHEDHOLD.
559

Option is enabled.
The selections are EQA, EQB, EQC, and EQD. See the “Equations-RATIOCTL
block” on page 570 section for this block for details. The default selection is
EQA.
• X1 High Limit (XEUHI) - Lets you specify the high input range value in
engineering units that represents 100% full scale input for the block. The default
value is 100.
• X1 Low Limit (XEULO) - Lets you specify the low input range value in
engineering units that represents the 0 full scale input for the block. The default
value is 0 (zero).
• X1 Input Bias (X1BIAS) - Lets you specify a bias value for the X1 input.
• X2 Input Bias (X2BIAS) - Lets you specify a bias value for the X2 input.
• X1 Scale Factor (K1) - Lets you specify a scaling factor for the X1 input.
• X2 Scale Factor (K2) - Lets you specify a scaling factor for the X2 input.

Set Point • SP (SP) - Lets you specify an initial set point value. The default value is 0.
MANual.
specified “advisor” SP value. The default selection is unchecked (Disabled).
• Enable SP Push: (PUSHSP) - Lets you specify that the RATIOCTL SP will be
pushed from an Inter Cluster Gateway when the RATIOCTL is the secondary of
a cascade that extends over two Experion clusters.
561

is -5%.

• Process Variable (PV) - Lets you view the actual ratio between inputs X1 and
X2.
• OP Tolerance Limit in % - Lets you specify a tolerance limit in percent for the
OP output.
563

checked box or enabled (Yes). You can also configure the SIALM.OPT
parameter as a block pin, a configuration and/or a monitoring parameter so it
appears on the block in the Project and Monitoring tree view, respectively.
display.
Summary display.
By specifying a deadband value, you can prevent nuisance alarms due to noise at
+ deadband value.
• With R410, the deadband value can be individually configured for each alarm.

• With R410, the deadband time can be individually configured for each alarm.
deadband value - percent or engineering units. The default value is percent. Prior
to R431, once configured, this value was loaded to the individual alarm
RATIOCTL block. If you configure the deadband unit as “EU or Percent” for an
alarm, this configuration is identical for the all other alarms in the RATIOCTL
RATIOCTL block.
default value (0).
565

selections are:
– None
– ONESHOT
– SEMICONT
– CONTRTN
– CONT
block:
Identification Lets you view the template properties for the block. You need the Template license
to use this form.
faceplate.
information
19.18.1 Function-RATIOCTL block

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.
19.18.2 Configuration example-RATIOCTL block

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.
Figure 16: Example CB configuration using RATIOCTL block.
Possible fuel flow application

In a furnace, the air supply might be controlled as a ratio of the fuel supply. If more heat is required to maintain
combustion efficiency, the fuel flow is increased and the air flow can be increased as a ratio of the fuel-flow
increase.
Possible blend application

It a blend operation, you might want to mix an orange juice concentrate with water in a controlled ratio. You can
easily set a ratio value, which ranges from 0 to 50 gallons of water for each gallon of juice concentrate. This
algorithm helps to produce different concentrations of orange juice by controlling the ratio set point.
567
19.18.3 Operating modes and mode handling-RATIOCTL block

The RATIOCTL block supports the Manual, Automatic, and Cascade modes of operation.
If Mode is … Then,
Manual (MAN) the block does not compute OP; it maintains the user-specified OP value and ignores
all input.
When MODE is changed to Man, the block:
• sets its input windup status (ARWNET) to HiLo. As a result, every block
upstream in a cascade strategy will set its windup status (ARWNET and
ARWOP) to HiLo.
• requests its primaries to initialize. As a result, every block upstream will go to
the initialized state or INITMAN = On.
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
Cascade (CAS) The function block fetches its intializable input (SP) from the primary, and calculates
OP. The primary may be on-node or off.
19.18.4 Required inputs-RATIOCTL block

• 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
19.18.5 Input ranges and limits-RATIOCTL block

• You must specify X1 and X2 engineering unit range, XEUHI and XEULO.
– XEUHI and XEULO define the full range of the X inputs in engineering units.
• This block assumes X inputs are within XEUHI and XEULO - it applies no range check
• You must specify SPHILM and SPLOLM to define the set point limits, expressed as a ratio. 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 the limits, this block will clamp it to the appropriate limit and set the input windup
status.
19.18.6 Initializable outputs-RATIOCTL block

parameter with the “initializable” attribute has an associated BACKCALC parameter, and when a connection is
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:
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
multiple connections from a single RATIOCTL output.
19.18.7 Output ranges and limits-RATIOCTL block

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 must be specified by the user.
Attention
The primary sets its output range (CVEUHI/CVEULO) to the SP range (SPEUHI/SPEULO) of the secondary.
The RATIOCTL block monitors SP for time-out.
OPHILM and OPLOLM define the normal high and low limits for OP, as a percent of the CV range. These are
user-specified values.
19.18.8 Control initialization-RATIOCTL block

The RATIOCTL block brings initialization requests from its secondary through BACKCALC. In addition, the
If the secondary is requesting initialization, the RATIOCTL block:
• Builds an initialization request for its primary based on CTLEQN selected as follows:
569
If CTLEQN And, Initialization Then, Initialization Value for the Primary Is…
Is… Request for
Primary
Is…
A On
B On
C On
D On
Where:
K1 = gain for X1
K2 = gain for X2
X1BIAS = bias for X1
X2BIAS= bias for X2
19.18.9 Equations-RATIOCTL block

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:
Equation D - For this equation, actual ratio = (uncontrolled flow) / (controlled flow + uncontrolled flow).
Then:
Where:
K1 = scaling factor for X1

K2 = scaling factor for X2
OPBIAS.FLOAT = floating output bias
X1 sb (scaled-and-biased value of X1) = K1 * X1 + X1BIAS
X2 sb (scaled-and-biased value of X2) = K2 * X2 + X2BIAS
19.18.10 Output bias-RATIOCTL block

• OPBIAS is recomputed under the following conditions to avoid a bump in the output.
571
Attention
recomputed.
occurs:

Where:
parameter.
– Zero:
– Non-zero:
parameter.
executes.

Where:
• NaN:
19.18.11 Timeout monitoring-RATIOCTL block

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.
19.18.12 Timeout processing-RATIOCTL block

If MODE is Cascade and SP times-out, the RATIOCTL block does the following:
• 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.
About CASREQFL processing

• The RATIOCTL block only sets CASREQFL if the original mode was Cascade, the SP input times-out, and
TMOUTMODE = Auto.
• 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
19.18.13 Override feedback processing-RATIOCTL block

If this block is in a cascade strategy with a downstream Override Selector block, it will receive override
feedback data when any of the following occur.
• the block's windup state changes
• the block is requested to do a one shot initialization
• the block's override status changes
The data consists of an override 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 Selector block). The offset flag only
applies to PID-type function blocks.
Attention
573
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:
If CTLEQN Then, Feedback Value for Primary Is …

Is …
A
B
C
D
Where:
K1 = gain for X1
K2 = gain for X2
X2BIAS= bias for X2
19.18.14 Output Indication Function-RATIOCTL block


Attention


OPLOALM.PR and .SV
OPHILM = 100 - 20.
Attention


575

19.18.15 Windup handling-RATIOCTL block

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.)
If OP is… And Secondary's Windup = And Secondary's Windup = And Secondary's Windup =
Normal; then, ARWOP =… Lo; then, ARWOP =… Hi; then, ARWOP =…
The ARWNET[1] parameter indicates if X1 is woundup. This is a copy of the ARWOP, which means; if OP is
woundup, then X1 is also woundup.
The ARWNET[2] parameter indicates if RT input is woundup. RT winds up, if it is clamped or OP is woundup.
ARWNET[2] is computed as follows.
If RT is… And ARWOP = Normal; then, And ARWOP = Lo; then, And ARWOP = Hi; then,
ARWNET[2] =…
ARWNET[2] =… ARWNET[2] =…
19.18.16 Windup processing-RATIOCTL block

parameters.


ARWOP computation

initialize.
ARWNET computation

NaN.
The CV is NaN
SPHIFL = On.
577

SPLO.FL = On.
19.18.17 Anti-Reset Windup Status-RATIOCTL block

NORMAL HI HI
NORMAL LO LO
NORMAL HILO HILO
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 NORMAL HILO
HILO HI HILO
HILO LO HILO
HILO HILO HILO
19.18.18 Restart or point activation-RATIOCTL block

On a warm restart or when a RATIOCTL block is activated or inactivated, initialization takes place.
Initialization also takes place when the ACE controller/node is repowered.
19.18.19 Error handling-RATIOCTL block

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:
19.18.20 RATIOCTL parameters

RATIOCTLblock.
579
19.19 REGCALC (Regulatory Control Calculator) Block

Lets you write up to eight expressions for creating custom algorithms for Calculated Variable (CV) calculations;
primary block initialization status and value calculations (PRIMDATA(1).INITSTS, PRIMDATA(1).INITVAL);
and primary block override initialization status and value calculations (PRIMDATA(1).ORFBSTS,
PRIMDATA(1).ORFBVAL).
Provides an interface to windup, initialization and override feedback processing, so you can add user-defined
control blocks to your control strategies.
• OPHIALM.TM
• OPHIALM.TMO
• OPHIALM.DB
• OPHIALM.DBU
BADCTLALM alarm.
• BADCTLALM.TM
• BADCTLALM.TMO
Each REGCALC block supports the following user configurable attributes. The following table lists the given

information.
NONE.
When an operator changes the mode (MODE), then Mode Attribute
(MODEATTR) is changed to OPERATOR automatically. This allows single
button access by the operator.
Option is enabled.
581

(zero).
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, which means no bias is added.

is -5%.
calculating the CV output value. This value helps guarantee that the output is
“bumpless” following initialization or mode changes. The default value is 1.
583

240.
is 0.
• CV (CVSRC) - Lets you assign an input or expression result as the source for
the CV. The default selection is NONE.
Note:Be aware that selecting NONE causes the CV value to default to NaN and
the block to generate a BadControl alarm.
• CV Initialization (CVINITSRC) - Lets you assign an input or expression result
as the source of the CV initialization. The default selection is NONE.
Note: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.
• CV Override (CVORFBSRC) - Lets you assign an input or expression result as
the source of the CV during override. The default selection is NONE.
Note: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
• Initialization Request (INITREQSRC) - Lets you assign an input or expression
result as the source of the initialization request flag for the primary. The default
selection is NONE. The REGCALC block uses different values for this
parameter depending upon whether or not a source is assigned and a secondary
exists as follows.
– If a source is assigned, this block uses the assigned source flag to initiate
initialization of its output and to request initialization of its primary block.
– If no source is assigned (NONE configured) and the block is connected to an
initializable input of a secondary block, this block uses the corresponding
value from the secondary (SECDATAIN.INITSTS).
– If no source is assigned (NONE configured) and there is no secondary or the
secondary input is not initializable, this block uses the default value of OFF
and will not propagate initialization to its primary in CAS mode. In MAN,
the block will request initialization regardless of configuration.
Note: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
• Initialization Value (INITVALSRC) - Lets you assign an input or expression
result as the source of the initialization value for the primary
(PRIMDATA(1).INITVAL). The default selection is NONE. The REGCALC
block uses different values for this parameter depending upon whether or not a
source is assigned and a secondary exists as follows.
– If a source is assigned, this block uses the assigned source value to set the
primary initialization value (PRIMDATA(1).INITVAL).
– If no source is assigned and a secondary does exist and the block is
connected to an initializable input of a secondary block, this block copies the
corresponding value from the secondary (SECDATA.INITVAL) to its
primary initialization parameter (PRIMDATA(1).INITVAL).
– If no source is assigned and there is no secondary or the secondary input is
not initializable, this block uses the OP value to set the primary initialization
parameter (PRIMDATA(1).INITVAL).

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.
If CV = f(x(1), .., X(n) , y,z)
Then x(1) = f(CV ,..X(n),y,z)
Where:
CV = SECDATAIN.INITIVAL
PRIMDATA(1).INITVAL = x(1)
• Override Feedback Status (ORFBSTSSRC) - Lets you assign an input or
expression result as the source of the override feedback status for the primary.
The default selection is NONE.
The REGCALC block uses different values for this parameter depending upon
– If a source is assigned, this block uses the assigned source flag to set the
primary override initialization flag (PRIMDATA(1).ORFBSTS).
– If no source is assigned and the block is connected to an initializable input of
the secondary block, this block uses the corresponding status from the
secondary (SECDATA.OVFBSTS).
• Override Feedback Value (ORFBVALSRC) - Lets you assign an input or
expression result as the source of the override feedback value for the primary. If
NONE. The REGCALC block uses different values for this parameter depending
upon whether or not a source is assigned and a secondary exists as follows.
secondary exists.
– If no source is assigned and a secondary exists, this block uses the
– If no source is assigned and there is no secondary or the secondary input is
not initializable, this block uses default values (NaN for values, OFF for
flags).
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.
If CV = f(x(1), .., X(n) , y,z)
Then x(1) = f(CV ,..X(n),y,z)
Where:
CV = SECDATAIN.ORFBVAL
PRIMDATA(1)ORFBVAL = x(1)
The expression for the primary override input value is usually identical to
that for the primary initialization value and the input to that expression
(SECDATAIN.ORFBVAL) is equal to the input to the initialization
expression (SECDATAIN.INITVAL). This means that ORFBVALSRC can
point to the same expression as INITVALSRC.
585

display.
Summary display.

REGCALC block. If you configure the deadband unit as “EU or Percent” for an
alarm, this configuration is identical for the all other alarms in the REGCALC
Note:You must configure identical deadband units for all alarms in the
REGCALC block.
Disable - An alarm is not notified whenever a mode shed happens in the
default value (0).
587

selections are:
– None
– ONESHOT
– SEMICONT
– CONTRTN
– CONT
block:
Expr# 1 to Expr# 8 Expression (C[1..8]) - Lets you write up to eight desired expressions for custom
calculations. You can also write a short descriptive text for each expression.
See the Guidelines for writing expressions section for this block for more details.
faceplate.
information
19.19.1 Function-REGCALC block

• 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.
19.19.2 Operating modes and mode handling-REGCALC block

The REGCALC block supports the Manual and Cascade modes of operation.
If Mode is … Then,
Manual (MAN) the output can be set by the operator or a user program. The X1 input is ignored.
Cascade (CAS) the X1 input comes from another function block.
CAScade.
19.19.3 Inputs-REGCALC block

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.
19.19.4 Input ranges and limits-REGCALC block

• If this block has a primary, you must specify an X[1] engineering unit range, XEUHI and XEULO. These
only apply to initializable input.
– XEUHI and XEULO define the full range of X1 in engineering units.
• This block assumes X[1] is within XEUHI and XEULO - it applies no range check. If this function is
required, you must write an expression for it.
589
19.19.5 Initializable outputs-REGCALC block

parameter with the “initializabl” attribute has an associated BACKCALC variable, and when a connection is
manually. These “implici” build connections are “hidde” from view and the related parameter pins are not
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:
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
multiple connections from a single REGCALC output.
19.19.6 Output ranges and limits-REGCALC block

that. If it has no secondary, you must specify the values for CVEUHI and CVEULO.
Attention
OPHILM and OPLOLM define the normal high and low limits for OP, as a percent of the CV range. You must
specify these values.
You must specify these values.
19.19.7 Assignable outputs-REGCALC block

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.
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
19.19.8 Output assignment rules-REGCALC block

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.
• The following parameters should be assigned to an input or an expression result

– CVSRC - Since this parameter controls CV under normal conditions, when the block is not initializing
and its mode is CAScade, always assign this parameter. If this parameter is left blank or unassigned, the
Control Module containing the block is allowed to go Active, but CV is NaN and OP has a value of zero.
– CVINITSRC - Since this parameter controls CV when the block is in its initialization state, CV will get
initialized with the initialization value from the secondary, like the other regulatory control blocks, if this
parameter is not assigned. You should only need to assign CVINITSRC when CV needs to be initialized
with a customized value.
If the CV value based on CVINITSRC assignment computes to NaN, it will be replaced by the INITVAL
received from the secondary
If the CV value based on CVINITSRC assignment is used as the INITVAL for the primary and you have
assigned INITVALSRC to compute a customized INITVAL, the INITVAL for the primary will be based
on INITVALSRC.
– CVORFBSRC - Since this parameter controls CV when the block's override status is “unselecte”, you
should only need to assign CVORFBSRC when CV needs to be set based on the block's override status.
The PID block is the only one that sets its CV to override the feedback value received from its secondary
when the block's override status is “unselecte”. For other regulatory control blocks, CV is not affected by
the block's override status.
• The following parameters are provided to the primary through this block's BACKCALC data.
– INITREQSRC
– INITVALSRC
– ORFBVALSRC
– 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.
591
If a Parameter is … And, a Secondary… Then, This Block…

assigned does or does not exist uses the assigned value.
unassigned exists uses the corresponding value from the
secondary.
unassigned does not exist uses default values, such as NaN for
values and Off for flags.
19.19.9 Control initialization-REGCALC block

The REGCALC block brings initialization requests from its secondary through BACKCALC. In addition, the
If the secondary is requesting initialization, the REGCALC block:
CV =CVINIT (an assignable 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. This means that 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.
19.19.10 Output bias-REGCALC block

REGCALC block only applies OPBIAS.FLOAT to the output for the latter two conditions, when it is the
first initializable block.)
Attention
recomputed.
occurs:
Where:
parameter.
– Zero:
– Non-zero:
parameter.
executes.
Where:
cycles_per_min
=
number of times the function block executes per minute (calculated)
– NaN:
• After initialization, the REGCALC block calculates the floating bias using the following equation.
593
OPBIAS.FLOAT=CVINIT - (Cvunbiased + OPBIAS.FIX)

Where:
CVunbiased=unbiased CV (It equals K*X[1], if X[1] is assigned to CV.)
OPBIAS.FIX=fixed output bias (user specified)
19.19.11 Timeout monitoring-REGCALC block

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.

19.19.12 Timeout processing-REGCALC block

If X[1] times out, the REGCALC block does the following:
• Sets the input timeout flag (TMOUTFL).
• Requests the X[1] primary to initialize.
Attention
19.19.13 Override feedback processing-REGCALC block

If the REGCALC block is in a cascade strategy with a downstream OVRDSEL (Override Selector) block, it
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:
CV=CVORFB (an assignable output)
• Computes a feedback value for its primary:
feedback value for primary=ORFBVAL (an assignable output)
feedback status for primary=ORFBSTS (an assignable 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:
feedback value for primary=feedback value received from secondary.
Attention
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.
CVORFBSRC - If you make a CVORFBSRC parameter assignment, the REGCALC block computes the CV
override feedback value based on the assignment and it sets its CV equal to the CVORFB, when the override
status for the block is “unselecte”. The override status could be based on the default status received from the
secondary, when the ORFBSTSSRC parameter is unassigned, or a computed customized status based on the
CVFBSTSSRC parameter assignment.
You can write incremental (like PID block) or non-incremental (like AUTOMAN block) expressions for CV, but
certain configuration combinations may cause misleading block behavior - especially, when the expression for
CV is non-incremental. For example, if you assign CVSRC to X[1] and CVORFBSRC to C[1] with C[1]
configured as X[2], assume that at some moment X[1] is 10.0 and X[2] is 50.0, and the override status for the
block is “unselecte”. This configuration produces different values for the block's CV and OP parameters. Based
on X[1], the first CV value is computed as 10.0 and the resulting OP value is 10.0. But, based on X[2], the
CVORFB value is computed as 50.0 and the block overwrites the previous CV value of 10.0 with 50.0,
resulting in different CV and OP values. In this case, assigning CVSRC to X[1] was the wrong configuration to
use. You can eliminate this type of discrepancy by assigning the CVSRC to an expression that calculates a CV
incrementally, such as CV + Delta (CV) so that Delta (CV) is the incremental value added to its previous value
of CV.
19.19.14 Output Indication Function-REGCALC block


Attention
595
Considerations for OUTIND Reverse selection-REGCALC block


OPLOALM.PR and .SV
OPHILM = 100 - 20.
Attention
reversal of values will be done only on a subsequent change to the OUTIND value, if appropriate. 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.


19.19.15 Windup handling-REGCALC block

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.
If XWLOFL and/or XWHIFL are… And a Secondary… Then, the Block Derives ARWOP from …
True does or does not exist CV, XWHIFL, and XWLOFL.
False exists CV and secondary's windup status.
False does not exist CV only.
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.
19.19.16 Windup processing-REGCALC block

parameters.


ARWOP computation
597

initialize.
ARWNET computation

NaN.
The CV is NaN
SPHIFL = On.

SPLO.FL = On.
19.19.17 Anti-Reset Windup Status-REGCALC block

NORMAL HI HI
NORMAL LO LO
NORMAL HILO HILO
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 NORMAL HILO
HILO HI HILO
HILO LO HILO
HILO HILO HILO
19.19.18 Expressions-REGCALC block

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.
599
Table 33: Expression operators, functions, and strings reference
Unary +-
Binary Arithmetic + -* / MOD (x MOD y) ^ (x^y)
Logical AND OR NOT
Relational = <> <= >= < >
Conditional ? : (For example, X ?Y : Z; similar to IF, THEN, ELSE)
Parenthesis ()
Array Syntax []
Unary Functions
ABS absolute value LOG Base 10 logarithm of a number
ATN arc tangent RND round value
COS1 cosine SGN sign of value (returns -1,0 or +1)
EXP e to the power of x SIN1 sine
INT convert to integer SQR square of a number
ISFIN is finite SQRT square root
ISNAN is Not a Number TAN1 tangent
LN Natural logarithm of a number (log to
the base of e)
Multiple Argument Functions
MIN minimum of n arguments (ignore bad MID medium value of n arguments (average of
values). middle values for even n).
If this function has a NAN argument If this function has a NAN argument (bad
(bad value), it returns NaN. value), it returns NaN.
MAX maximum of n arguments (ignore bad MUL product of n arguments.
values).
This function ignores NaN values. However,
If this function has a NAN argument if all arguments are NaN, then it returns 1.
(bad value), it returns NaN.
AVG average of n arguments. SUM sum of n arguments.
This function ignores NaN values. This function ignores NaN values. However,
However, if all arguments are NaN, if all arguments are NaN, then it returns 0.
then it returns NaN.
String Support Functions
LEN Returns an integer length of the string NUMSTR Takes the input parameter, casts it to a
Float64 and converts it to a string
MIDS Takes a string, an integer starting STRNUM Takes the string input parameter and converts
position and an integer length. The it to a Float64
function returns the specified portion
of the original string.
Time Support Functions
ABSTOD Takes an absolute time data type and DTIMNUM Takes a delta TIME data type and returns a
strips off the year and date and returns 64-bit float representing the number of
a 64-bit float representing the time of milliseconds.
day in milliseconds.
NOW Returns the current local date and NUMDTIM Takes a 64-bit float representing some
time as an absolute time data type number of milliseconds and converts it to a
delta TIME data type.
NUMTIM Takes a 64-bit float representing the STRTIM Takes a string input parameter and converts it
number of milliseconds since Jan 1, to an Absolute time. The string must be in the
1972 and converts it to absolute same format as an Absolute time constant.
TIME data type.
TOD Returns the current local time of day TIMNUM Takes an Absolute TIME data type and
as Time of Day data type returns a 64-bit float representing the total
number of milliseconds since Jan 1, 1972.
UTCTOD Returns the current UTC time of day UTCNOW Returns the current UTC date and time of day
as Time of Day data type as an absolute time data type
1Be sure you specify the trigonometric functions cosine, sine, and tangent in radians and not degrees.
Case Sensitive Strings for Special Value Constants

NAN IEEE NaN value
+INF IEEE + Infinity value
-INF IEEE - Infinity value
PI PI (3.14159. . .)
E e (2.718. . .)
19.19.19 Parameters in Expressions-REGCALC block

You must specify a parameter by its full tag name (for example, “CM25.PumpASelect.PVFL”, or
The expression syntax has been expanded. Delimiters (') can be used in an expression containing an external
will understand. If this text is incorrect, runtime errors will occur.
Attention
TagName.text.
19.19.20 Guidelines for Writing Expressions-REGCALC block

• Must include full tag.parameter name for X inputs in the expression and enclose identification number in
brackets instead of parentheses. For example, CM151.REGCALC_1.X[1] * CM151.REGCALC_2.X[2] is
valid.
601
Tip
• You must configure calculator expressions contiguously (without breaks) in the arrays. For example, a sample
expression for calculating the average between minimum and maximum values would be as follows:
– AVG (MIN(CM1.REGCALC.X[1], CM1.REGCALC.X[2], CM1.REGCALC.X[3]),
MAX(CM1.REGCALCX[1], CM1.REGCALC.X[2], CM1.REGCALC.X[3]))
Attention
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.
Attention
19.19.21 String data support in expressions-REGCALC block

The following operators can have string constants and/or string references as operands.
reference.
CM.block.mystringparam := “This is a string constant”
CM.block.mystringparam := CM.desc
+ Concatenation
CM.block.mystringparam + CM.desc
= Equal to
CM.block.mystringparam = CM.desc
<> Not equal to
CM.block.mystringparam <> “This is a string”
19.19.22 Time support in expressions-REGCALC block

Time data types
The following time data types are supported in expressions.
• Absolute Time - Is stored as a 64-bit integer representing the number of tenths of milliseconds since
1/1/1972.
• Delta Time - Is also stored as a 64-bit integer and it represents an Absolute time difference in tenths of
milliseconds.
• Time of Day - is an unsigned 32 -bit integer that represents a time of day in tenths of milliseconds.
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.
Time related operators

The following operators can have time constants and/or time references as operands:
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.
- Absolute Time can be subtracted from Absolute time, which results in a Delta Time. Delta time or
Time of Day can be subtracted from an absolute time, which results in absolute time. Time of Day can
be subtracted from Delta Time, which results in a Delta Time. See the following section Subtracting
time data types.
=, <>, <=, >=, <, Compares two operands of type time. Both operands must be of the same time data type.
>
DAYS1 Tskes operand and returns equivalent delta time value.
HOURS1 Takes operand and returns equivalent delta time value.
MINS1 Takes operand and returns equivalent delta time value.
SECS1 Takes operand and returns equivalent delta time value
1The DAY, HOURS, MINS, SECS Operators are not case specific.
Adding time data types

The following table shows results of adding the various time data types
603

Absolute Time Absolute Time Absolute Time Absolute Time
Delta Time Absolute Time Delta Time Delta Time
Subtracting time data types

The following table shows results of subtracting the various time data types
Subtrahend Data Type Minuend 1 Data Type

Absolute Time Delta Time N/A N/A
Delta Time Absolute Time Delta Time N/A
Time expression examples

The following are examples of some valid time expressions.
• MYCM.block.elapsedtime > 5 MINS
• CEE01.CURRTIME + 2 DAYS
• CEE01.CURRTIME > 10/30/2002
• CEE01.CURRTIME + CM.TIMER.SP SECS
• (CEE01.CURRTIME - 1/01/2002 10:15:01)*2.
• STRTIM(“12/01/2002”") > CEE01.CURRTIME
• TIMNUM(CEE01.CURRTIME)
• NUMTIM(1000.0)
• NOW - MyCM.myblock.todparam
• ABSTOD(CEE01.CURRTIME)
The following are examples of invalid expressions.
• CEE01.CURRTIME + 2
• CEE01.CURRTIME > 5.0
Refer to the section “Time Support in Experion System” for more information about time support in the system
19.19.23 REGCALC parameters

REGCALC block.
19.20 REEOUT (Remote EEOUT) Block

The REEOUT function block is used in conjunction with the Inter Cluster Gateway to support regulatory
cascades between ACE nodes residing in two separate Experion clusters. It looks like this graphically:
Each REEOUT block supports the following user configurable attributes. The following table lists the given
that TAB. This data is only provided as a quick document reference, since this same information is included in

Main • Name - Block (Tag) name of up to 16 characters long. Must be unique within
the CM block containing it.
block in the CM relative to other blocks contained in this CM. Enter as a
number between 0 and 32767. The default value is 10. Refer to the Function
Block Execution Schedules section in the beginning of this document for
more information.
Identification Lets you view information pertinent to the qualification and version control
system and enter block comments, if desired.
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.
Block Preferences Lets you change several block-viewing preferences including the color of the
block's faceplate.
19.20.1 Function-REEOUT block

The only function of the REEOUT block is to act as the interface between regulatory FBs in an Experion cluster
and secondary FBs residing in a second Experion cluster. It does so in conjunction with the OPC Gateway and
the Inter Cluster Gateway.
605
19.20.2 Configuration Example-REEOUT block

A sample usage of the block in conjunction with the Inter Cluster Gateway is shown in the following figure:
19.20.3 Inputs-REEOUT block

The only input which the user is required to specify is SPPIN, the SP value in %, which is read from a
regulatory control FB in the primary cluster.
The block has two other inputs:
• BACKCALCOUT: The ACE BACKCALC structure is a hidden connection that is automatically made by
the system.
• SECDATAIN: The SECDATA from the regulatory FB in the other cluster, in support of back initialization
and anti-reset propagation, is provided by a hidden connection that is automatically made by the system.
19.20.4 Outputs-REEOUT block

The user is required to specify the output to the secondary's regulatory point as a parameter connector associated
with the SPOUT parameter. The connector is of the form <OPC Gateway in cluster containing REEOUT> .
<Target control module in secondary cluster> . <Target regulatory FB.SP>
19.20.5 Push of SP to secondary cluster's regulatory FBs-REEOUT block

In order to be used as the secondary of the REEOUT block, a regulatory FB must be configured to allow its SP
to be stored (pushed) from the ICG. The parameter which permits this (PUSHSP) is configurable in the PID,
PID-PL, PIDER, PIDFF, EnhRegCalc, and RatioCtl FBs.
19.20.6 REEOUT parameters

REEOUT block.
607
19.21 REGSUMMER (Regulatory Summer) Block

This function block calculates an output value which is the sum of up to four inputs. Each of the inputs may be
individually scaled. In addition, the output may be scaled by an overall gain, and an overall bias may be added
to the result. The REGSUMMER block looks like this graphically:
• OPHIALM.TM
• OPHIALM.TMO
• OPHIALM.DB
• OPHIALM.DBU
BADCTLALM alarm.
• BADCTLALM.TM
• BADCTLALM.TMO
Each REGSUMMER block supports the following user configurable attributes. The following table lists the
given name of the “Ta” in the parameter configuration form and then briefly describes the attributes associated

between 1 and 32767. The default value is 10. Refer to the Function Block
information.
NONE.
• Permit External ModeSwitching (ESWPERM) - Lets you specify if external user
configured interlocks is permitted or not, if you have at least an Engineering
access level. The default is Disabled (unchecked). Enable External Mode
Switching (ESWENB) - Lets you specify if external MODE switching through
user configured interlocks is enabled or not, if ESWPERM is checked
(Permitted). The default is Disabled (unchecked).
is SHEDHOLD.
609

Option is enabled.
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.
• XDESC[1..4] - Lets you specify a text string of up to 23 characters to identify
inputs 1..4.
• XK(1)..XK(4) - Lets you specify the scaling factors for inputs 1..4

is -5%.
the Calculated Variable range (CVEUHI - CVEULO). For example, if the CV
• Output Tolerance (OPTOL) - Lets you specify a limit for operator entered output
changes in %. Operator-entered values greater than OPTOL will result in a
warning to the operator which must be overridden to permit the value to be
entered.
611

calculating the CV output value. See the equation following this table for details.
240.
(K) is clamped to this value, if the specified gain is less than it is. The default
value is 0.

Alarms • Type - Identifies the types of alarm this block supports. Of course, these alarms
checked box or enabled (Yes). You can also configure the SIALM.OPT
parameter as a block pin, a configuration and/or a monitoring parameter so it
appears on the block in the Project and Monitoring tree view, respectively.
(SIALM.PR, BADCTLALM.PR, OPHIALM.PR, and OPLOALM.PR). The
default value is LOW. The levels are:
display.
Summary display.
(SIALM.SV, BADCTLALM.SV, OPHIALM.SV, and OPLOALM.SV) as a
number between 0 and 15, with 15 being the most severe. This determines the
alarm processing order relative to other alarms. The default value is 0.
613

deadband value - percent
or engineering units. The default value is percent. Prior to R410, once
configured, this value was loaded to the individual alarm parameters (for
example, OPHIALM.DBU and OPLOALM.DBU) when the CM was loaded. If
you configured the individual alarm parameters as Monitoring parameters for the
block, you could change the individual alarm value while monitoring the loaded
block in CB.
REGSUMMER block. If you configure the deadband unit as “EU or Percent” for
REGSUMMER block. However, if you are migrating from pre-R410 to later
Note:You must configure identical deadband units for all alarms in the
REGSUMMER block.
Note:This parameter is available for configuration only if the Enable Bad
default value (0).

selections are:
– None
– ONESHOT
– SEMICONT
– CONTRTN
– CONT
block:
Configured Rate.
faceplate.
information
Identification Lets you view information pertinent to the qualification and version control system
and enter block comments, if desired.
615
19.21.1 Equation-REGSUMMER block

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 (i.e., OPBIAS.FIX + OPBIAS.FLOAT)
X(1..4) = Current full values of each X-input in use.
19.21.2 Function-REGSUMMER block

The REGSUMMER function block is typically used where two or more primary PIDs are used to determine the
set point of a secondary PID.
19.21.3 Configuration example-REGSUMMER block

The following screen shot depicts the scenario wherein the REGSUMMER block is used:
19.21.4 Inputs-REGSUMMER block

The RegSummer block accepts up to four inputs -- X(1) through X(4).
• X(1) is an initializable input; all others are non-initializable. This 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 to them.
• 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 saying “At least input one needs to be connected”
• NUMXINPT represents the number of input connections that has been made to this block
19.21.5 Outputs-REGSUMMER block

The REGSUMMER block has the following initializable outputs:
• OP - Calculated output, in percent
• OPEU - Calculated output, in engineering units
617
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.
19.21.6 Initializable inputs and outputs-REGSUMMER block

“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 the user creates
a connection between an initializable input and initializable output, the system will also create a BACKCALC
connection. For example, X1 is an initializable input with an associated X1BACKCALOUT, and OP is an
initializable output with BACKCALCIN. If the user creates a connection between X1 and OP, the system will
also create a connection between X1BACKCALOUT and BACKCALCIN.
19.21.7 Output Ranges-REGSUMMER block

• 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 via 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 (i.e., 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.
• 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
• 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.
19.21.8 Output bias-REGSUMMER block

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:
OPBIAS.FLOAT = CV - [K * [ K(1) * X(1) + K(2) * X(2) + K(3) * X(3) + K(4) * X(4)] + OPBIAS.FIX]
where:
OPBIAS.FLOAT = floating output bias
19.21.9 Mode handling-REGSUMMER block

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 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.
19.21.10 Control initialization-REGSUMMER block

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 via BACKCALC. In addition, the secondary may
propagate one shot initialization requests to this block.
Attention
SECINITOPT may be used to ignore initialization requests from the secondary.

• Initializes its output:
– If the initialization value received from the secondary is within the output limits of this function block:
– Otherwise, CV is clamped to the appropriate limit.
Builds an initialization request for the X(1) primary as follows:
INITREQ = On
Where:
OPBIAS.FIX = Fixed output bias
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
619
Note
When the cascade resumes, the internal ramping bias value OPBIAS.FLOAT is calculated
OPBIAS.FLOAT = CVlast - K*(XK(1)*X(1) + XK(2)*X(2) + XK(3)*X(3) + XK(4)*X(4)) -OPBIAS.FIX
Where CVlast is the last calculated CV before initialization.
When only the X1 input is used:
INITVAL = (CV - OPBIAS.FIX)/K
OPBIAS.FLOAT = CVlast - K * X1 - OPBIAS.FIX
19.21.11 Override feedback processing-REGSUMMER block

feedback data. The data consists of an override 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 Selector block). The
offset flag only applies to PID-type function blocks.
Attention
SECINITOPT may be used to ignore override requests from the secondary.
• Calculates a feedback value for its primary:
primary feedback =
Note
where:
OPBIAS.FIX = Fixed output bias
OPBIAS.FLOAT = Floating output bias
When only the X1 input is used:
19.21.12 Output Indication Function-REGSUMMER block


Attention
Considerations for OUTIND Reverse selection-REGSUMMER block


621

OPLOALM.PR and .SV
OPHILM = 100 - 20.
Attention


19.21.13 Windup processing-REGSUMMER block

parameters.


ARWOP computation

initialize.
ARWNET computation

NaN.
The CV is NaN
623

SPHIFL = On.
SPLO.FL = On.
19.21.14 REGSUMMER parameters

Refer to Control Builder Components Referencefor a complete list of the parameters used with the
REGSUMMER block.
19.22 REMCAS (Remote Cascade) Block

The REMCAS block provides automatic switching between a remote cascade and a backup cascade. It is
typically used with a PID that normally gets its set point from a remote source, but sheds to a local source if
there is communication failure. It looks like this graphically:
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.
• OPHIALM.TM
• OPHIALM.TMO
• OPHIALM.DB
• OPHIALM.DBU
BADCTLALM alarm.
• BADCTLALM.TM
• BADCTLALM.TMO
Each REMCAS block supports the following user configurable attributes. The following table lists the given
625

between1 to 32767. The default value is 10. Refer to the Function Block
information.
NONE.
are permitted to make MODE changes or not. The default is Enabled (checked) .
100% full scale input for the block. The default value is 100.
the 0 full scale input for the block. The default value is 0 (zero).
• X1 (XDESC[1]) - X1 input descriptor of up to 15 characters long.
• X2 XDESC[2]) - X2 input descriptor of up to 15 characters long.
• Enable Tracking Option (TRACKING) - Lets you select if the unselected input
is to track the selected input or not. The default selection is box checked, which
means TRACKING is ON.
– When TRACKING is ON, the block only propagates to the selected input.
627

– When TRACKING is OFF, the block propagates changes in the windup
status and override feedback data to all inputs.
is SHEDHOLD.
Option is enabled.

is -5%.
629

display.
Summary display.

REMCAS block. If you configure the deadband unit as “EU or Percent” for an
alarm, this configuration is identical for the all other alarms in the REMCAS
You must configure identical deadband units for all alarms in the REMCAS block.
default value (0).
631

selections are:
– None
– ONESHOT
– SEMICONT
– CONTRTN
– CONT
block:
faceplate.
information
19.22.1 Function-REMCAS block

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.
Table 34: Functional block diagram of typical remote cascade operation.
19.22.2 Configuration example-REMCAS block

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 Monitoring mode.
633
Table 35: View A - Remote Primary Control Loop
Table 36: Example of CB configuration using REMCAS block
The following table includes descriptions of the callouts in Views A and B of the figure above.
Callout Description
1 Control Builder connects the X1BACKCALOUT parameter of the REMCAS_1 block to the
BACKCALCIN parameter for the PID_PRIMARY block in another Control Module (CM). The individual
2 This control loop represents a remote cascade primary located in a different CM. Typically, this loop is also
located in a different controller. This loop serves as the remote primary for the REMCAS_1 block located
in another CM. The REMCAS_1 block uses the output from this loop as its primary input (X1), as long as
this loop provides a valid output value. If a communication or some other problem interrupts this loop's
output, the REMCAS_1 block switches to the output from the backup/local primary loop.
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.
635
Callout Description
6 The PID_BACKUP block serves as a backup/local primary source for the remote primary source
(PID_PRIMARY) located in another CM. The REMCAS_1 block switches to this backup source, if there is
a problem with the output from the PID_PRIMARY.
7 The INITMAN function remains ON in the PID_BACKUP block.
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.
9 Use the parameter connector function to connect the OP parameter of the PID_PRIMARY block in another
Control Module (CM) to the X1 parameter on this REMCAS_1 block. See callout 3 in View A for the
location of the OPEUX 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.
19.22.3 Inputs-REMCAS block

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.)
19.22.4 Input ranges and limits-REMCAS block

• You must specify an X-input engineering unit range, XEUHI and XEULO.
XEUHI and XEULO define the full range of the inputs; XEUHI is the value that represents 100% of full
scale, and XEULO is the value that represents 0%.
• XEUHI and XEULO apply to both inputs (X1 and X2).
• This block assumes both inputs are within XEUHI and XEULO; it applies no range-checks.
19.22.5 Input descriptors-REMCAS block

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.
19.22.6 Outputs-REMCAS block

The REMCAS block has the following initializable outputs:
For example, if you connect the output from a REMCAS block (REMCAS.OP) to the set point of a PID block
(PIDA.SP), the implicit/hidden connection is made to REMCAS.OPX to provide value/status data.)
19.22.7 Output ranges and limits-REMCAS block

If this block has a secondary, it brings the secondary's input range through BACKCALCIN and sets its CV
range to that. If it has no secondary, CVEUHI and CVEULO track the X-input range (XEUHI and XEULO).
This block brings the secondary's input range regardless of SECINITOPT This means regardless of whether
the secondary's initialization and override data will be used.
OP will be clamped to these limits, if the algorithm's calculated result (CV) exceeds them or another
19.22.8 Output Indication Function-REMCAS block


Attention

637

OPLOALM.PR and .SV
OPHILM = 100 - 20.
Attention




The following example scenarios show how OUTIND on a Regulatory Control (REGCTL) block can be used in
conjunction with the Output Direction (OPTDIR) parameter of an AOCHANNEL block to achieve the desired
configuration. The Control Action (CTLACTN) parameter on the REGCTL block is normally chosen
independent of the OUTIND and OPTDIR values, so CTLACTN is not included in the examples.

Fail close valve; air to open - normal case • REGCTL OUTIND = Direct
• REGCTL OP 0% translated to 4 mA by the AO,
closed
Fail open valve; air to close - reversal handled in AO • REGCTL OUTIND = Direct
Fail open valve; air to close - display indications highlight • REGCTL OUTIND = ReverseDispInd
19.22.9 Mode handling-REMCAS block

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.
639
19.22.10 Timeout monitoring-REMCAS block

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.
19.22.11 Timeout processing-REMCAS block

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, (i.e., X1 just changed from bad to good) , the block:
– sets SELXINP to X1
– changes MODE to Cascade
19.22.12 Input switching-REMCAS block

You may force the unselected input to track the selected input through the TRACKING option:
When TRACKING is Off, this block propagates changes in windup status and override 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.
19.22.13 Equations-REMCAS block

The REMCAS block computes CV as follows:
CV = X(n) + OPBIAS.FIX + OPBIAS.FLOAT
Where:
OPBIAS.FLOAT = floating bias, calculated using the following equation:
OPBIAS.FLOAT = (CV( from last cycle) - X(n)) - OPBIAS.FIX
X(n) = the currently-selected input (n = 1 or 2)
19.22.14 Output bias-REMCAS block

REMCAS block only applies OPBIAS.FLOAT to the output for the latter two conditions, when it is the first
Attention
When the function block goes Active or the Mode changes to Cascade, OPBIAS and OPBIAS.FLOAT are
recomputed.
641
occurs:

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.
parameter.
– Zero:
– Non-zero:
parameter.
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.
19.22.15 Control Initialization-REMCAS block

This block brings initialization requests from its secondary through BACKCALCIN. In addition, the secondary
You may use SECINITOPT to ignore initialization requests from the secondary.
• builds an initialization request for the X1 primary as follows:
INITREQ[1] = On
INITVAL[1] = CV - OPBIAS.FIX
• Parameters are defined below.

– builds an initialization request for the X2 primary:
INITREQ[2] = On
INITVAL[2] = CV - OPBIAS.FIX
Where:
INITREQ[1] = initialization request flag for the X1 primary
INITVAL[1] = initialization value for the X1 primary
INITREQ[2] = initialization request flag for the X2 primary
INITVAL[2] = initialization value for the X2 primary
19.22.16 Override feedback processing-REMCAS block

feedback data. The data consists of an override 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 Selector block). The
offset flag only applies to PID-type function blocks.
You may use SECINITOPT to ignore override requests from the secondary.
• Computes a feedback value for the selected primary:
feedback value for selected primary = BACKCALOUT.ORFBVAL-OPBIAS.FIX -

OPBIAS.FLOAT
• The unselected primary is propagated with the “not connected” status.

The Selected input of the REMCAS block gets the propagated ORFBSTS status of either ‘Selected or Not-
Selected’ from the Override Selector secondary while the unselected primary of the REMCAS block always
gets non-connected status for Override Feedback status by the REMCAS block, regardless of whether
19.22.17 Windup processing-REMCAS block

parameters.

643


ARWOP computation

initialize.
ARWNET computation

NaN.
The CV is NaN

SPHIFL = On.
SPLO.FL = On.
19.22.18 Anti-Reset Windup Status-REMCAS block

NORMAL HI HI
NORMAL LO LO
NORMAL HILO HILO
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 NORMAL HILO
HILO HI HILO
HILO LO HILO
HILO HILO HILO
645
19.22.19 REMCAS parameters

REMCAS block.
19.23 SWITCH Block

The SWITCH block accepts up to eight initializable inputs and operates as a single-pole, eight-position rotary
switch. The switch position may be changed by the operator, a user program, or another function block. It looks
like this graphically.
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.
• OPHIALM.TM
• OPHIALM.TMO
• OPHIALM.DB
• OPHIALM.DBU
BADCTLALM alarm
• BADCTLALM.TM
• BADCTLALM.TMO
Each SWITCH block supports the following user configurable attributes. The following table lists the given
647

between 1 to 32767. The default value is 10. Refer to the “Function Block
Execution Schedules” section in the beginning of this document for more
information.
• Control Equation (CTLEQN) - Lets you select Equation A, B, or C to define
how the block is to select an input. The default selection is EQA, which means
you must store the number of the input to be selected to the SELXINP
parameter. See the Function and Equation sections for this block for more details
about the equations.
• Enable Tracking Option (TRACKING) - Lets you select if the unselected input
is to track the selected input or not. The default selection is box checked, which
means TRACKING is ON.
– When TRACKING is ON, the block continually initializes the unselected
inputs. This means the block requests the unselected primaries to initialize
and set their output to the selected input value.
– When TRACKING is OFF, the block does not initialize the unselected
inputs.
NONE.

is SHEDHOLD.
Option is enabled.
(zero).
• Time (sec) (TMOUTTIME) - Lets you specify a time in seconds that must expire
• Description - Lets you enter up to a 15-character description for each input
(X[1..8]). The description is stored in the XDESC[1..8] parameter and is copied
to the SELXDESC parameter when the corresponding input is selected. This
means SELXDESC is automatically updated whenever SELXINP is updated.
• Bad Input Option (BADINPTOPT[1..8]) - Lets you specify whether the block is
to include or ignore an input with bad values in its selection process. The default
selection is INCLUDEBAD, which means the block's CV value is set to NaN
(Not a Number).
649

is -5%.
is in the MANual mode. The default value is -6.9%

display.
Summary display.
651

SWITCH block. If you configure the deadband unit as “EU or Percent” for an
alarm, this configuration is identical for the all other alarms in the SWITCH
SWITCH block.
default value (0).

selections are:
– None
– ONESHOT
– SEMICONT
– CONTRTN
– CONT
block:
– AUTO - Set MODEREQ = AUTOMATIC (not applicable to this block)..
faceplate.
information
653
19.23.1 Function-SWITCH block

This block lets you select one input from as many as eight, and outputs 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 Monitoring mode.
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.
Table 37: Example CB configuration using a SWITCH block to assign a different primary to a secondary.
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.
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.
Table 38: Example CB configuration using multiple SWITCH blocks to assign a primary to a different secondary.
19.23.2 Inputs-SWITCH block

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 to 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.)
19.23.3 Input ranges and limits-SWITCH block

• You must specify an engineering unit range for the X inputs, by entering values for XEUHI and XEULO.
• XEUHI and XEULO define the full range of the inputs. XEUHI is the value that represents 100% of full
scale, and XEULO is the value that represents 0%.
• XEUHI and XEULO apply to all of the X inputs.
• This block assumes all of the X inputs are within XEUHI and XEULO; it applies no range checks.
655
19.23.4 Input descriptors-SWITCH block

This block lets you define a 15-character descriptor (name) for each X-input. The descriptors reside in the
XDESC parameter, and when an input is selected, the corresponding descriptor is copied to SELXDESC.
19.23.5 Initializable Outputs-SWITCH block

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.
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.)
19.23.6 Output ranges and limits-SWITCH block

If this block has a secondary, it brings the secondary's input range through BACKCALCIN and sets its CV
range to that. If it has no secondary, CVEUHI and CVEULO track the X-input range (XEUHI and XEULO).
This block brings the secondary's input range regardless of SECINITOPT This means regardless of whether
the secondary's initialization and override data will be used.
OP will be clamped to these limits if the algorithm's calculated result (CV) exceeds them, or another
19.23.7 Mode handling-SWITCH block

This block supports the Cascade and Manual modes:
• If MODE = Cascade, all inputs are pulled from other function blocks.
• If MODE = Manual, OP may 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.
19.23.8 Timeout monitoring-SWITCH block

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.
19.23.9 Timeout processing-SWITCH block

If MODE is Cascade and an input times out, this block does the following :
• Requests the input's primary to initialize
Attention
19.23.10 Equations-SWITCH block

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:
CV = X(n) + OPBIAS.FIX + OPBIAS.FLOAT
Where:
OPBIAS.FIX=fixed output bias
OPBIAS.FLOAT=floating bias
X(n)=currently selected input (n = 1 to 8)
Equation A prevents you from storing to the selection flags (SELXFL[1..8]).
• 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],
657
– selects the first input whose flag is On depending on following conditions:

if BADINPTOPT(i)=IgnoreBad, a “bad” input is not selected, it will be ignored.
if BADINPTOPT(i)=IncludeBad, a “bad” input may be selected.
– updates SELXINP and SELXDESC.
– calculates CV as noted above for Equation A.
The input selection is changed by storing On or Off to the selection flags as follows:
SELX SELX SELX SELX SELX SELX SELX SELX Given Selection Flag States Select Input…
FL[1] FL[2] FL[3] FL[4] FL[5] FL[6] FL[7] FL[8]
On NA NA NA NA NA NA NA X[1]
Off On NA NA NA NA NA NA X[2]
Off Off On NA NA NA NA NA X[3]
Off Off Off On NA NA NA NA X[4]
Off Off Off Off On NA NA NA X[5]
Off Off Off Off Off On NA NA X[6]
Off Off Off Off Off Off On NA X[7]
Off Off Off Off Off Off Off On X[8]
“NA” means On or Off does not affect the input selection

Equation C prevents you from storing to SELXINP.
19.23.11 Bad input handling-SWITCH block

The BADINPTOPT[1..8] parameter specifies the Bad Input handling option (InlcudeBad or IgnoreBad) on a per
input basis. The block uses BADINPTOPT[1..8] in a consistent manner, regardless of the configured equation -
A, B, or C.
If the selected input “i” goes Bad (either the value being fetched is NaN, or the Switch sets the value to NaN
because of a timeout), then the Switch does the following, based on the value of BADINPTOPT(i):
BADINPTOPT(i) = IncludeBad:
CV is set to NaN,
the selected input does not change (no automatic switching).
BADINPTOPT(i) = IgnoreBad
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 as with Equations A and B.
19.23.12 Bypass processing-SWITCH block

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.
19.23.13 Input switching-SWITCH block

You may force the unselected inputs to track the selected input through the TRACKING option:
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.
19.23.14 Output bias-SWITCH block

SWITCH block only applies OPBIAS.FLOAT to the output for the latter two conditions, when it is the first
659
Attention
When the function block goes Active or the Mode changes to Cascade, OPBIAS and OPBIAS.FLOAT are
recomputed.
occurs:
OPBIAS.FLOATCVINIT - (CVUNBIASED + OPBIAS.FIX)
Where:
parameter.
– Zero:
– Non-zero:
parameter.
– The function block ramps the OPBIAS.FLOAT to zero by applying the following calculation each time it
executes.
OPBIAS.FLOATOPBIAS.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.
19.23.15 Error handling-SWITCH block

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.
19.23.16 Control initialization-SWITCH block

This block brings initialization requests from its secondary through BACKCALC. In addition, the secondary
You may use SECINITOPT to ignore initialization requests from the secondary.
CV=initialization value from the secondary
• builds an initialization request for the selected primary as follows:
INITREQ(s)=On
INITVAL(s)=CV - OPBIAS.FIX
where:
(s)=identifies the selected input
INITREQ(s)=initialization request flag for the selected input
INITVAL(s)=initialization value for the selected input
• 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:
(n)=identifies the unselected inputs
INITREQ(n)=initialization request flag for the unselected
INITVAL(n)=initialization value for the unselected inputs
19.23.17 Override feedback processing-SWITCH block

feedback data. The data consists of an override status; override feedback value and an override offset flag. The
status indicates if this block is in the selected or unselected strategy.
You may use SECINITOPT to ignore override requests from the secondary.
• Computes a feedback value for the selected primary:
feedback value for selected primary = BACKCALCOUT.ORFBVAL - OPBIAS.FIX - OPBIAS.FLOAT
• Propagates the unselected primaries with “not connected” status.
The Selected input of the SWITCH block gets the propagated ORFBSTS status of either ‘selected or Not-
Selected’ from the Override Selector secondary while the unselected primary of the SWITCH always gets non-
connected status for Override Feedback status by the Switch block, regardless of whether TRACKING is On or
Off.
If this block and a primary are on the same node, this block propagates the override data to the primary. If a
primary is on a different node, this block stores the data in the BACKCALC packet for that primary, which the
primary brings on its next execution.
661
19.23.18 Output Indication Function-SWITCH block


Attention


OPLOALM.PR and .SV

OPHILM = 100 - 20.
Attention


19.23.19 Windup processing-SWITCH block

parameters.

663

ARWOP computation

initialize.
ARWNET computation

NaN.
The CV is NaN
The ARWOP equals Hi (Pid function blocks have a Hi
configurable Control Action option (CTLACTN). If
CTLACTN = Reverse , ARWNET will track ARWOP; but
if CTLACTN = Direct , ARWNET will be the opposite of
ARWOP.)
SPHIFL = On.

The ARWOP equals Lo (Pid function blocks have a LO
configurable Control Action option (CTLACTN). If
CTLACTN = Reverse , ARWNET will track ARWOP; but
if CTLACTN = Direct , ARWNET will be the opposite of
ARWOP.)
SPLO.FL = On.
19.23.20 Anti-Reset Windup Status-SWITCH block

NORMAL HI HI
NORMAL LO LO
NORMAL HILO HILO
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 NORMAL HILO
HILO HI HILO
HILO LO HILO
HILO HILO HILO
19.23.21 SWITCH parameters

SWITCH block.
665
20 UCN Interface
Related topics
“Universal Control Network (UCN) Interface Block Library” on page 668
“UCNOUT/EUCNOUT block” on page 669
667
20 UCN INTERFACE
20.1 Universal Control Network (UCN) Interface Block Library

Starting with Experion R430, the UCN Interface block library contains a configurable block for creating
regulatory control cascade strategies between the ACE/C300 supervisory controller and the Enhanced High-
Performance Process Manager (EHPM) controllers residing on an Enhanced Universal Control Network
(EUCN) in a connected TPS system.
Note
The EUCNOUT block does not require an OPC gateway or a TPN server to communicate with the EHPM.
This library includes the UCNOUT and the EUCNOUT function blocks that provide configurable connections
and compatible data mapping between controllers. The following subsection provides a functional description
of the EUCNOUT block.
20 UCN INTERFACE
20.2 UCNOUT/EUCNOUT block

The UCNOUT function block supports Setpoint Control (SPC), Direct Digital Control (DDC), Remote Setpoint
Control (RSP) and Direct Digital Control with Remote Setpoint (DDCRSP) remote cascade types between the
regulatory control function blocks included in an ACE supervisory controller control strategy and the regulatory
control points included in a Process Manager controller. It looks like this graphically in a Control Module as
shown in the following image.
Starting with Experion R430, the EUCNOUT function block supports Setpoint Control (SPC), Direct Digital
Control (DDC), Remote Setpoint Control (RSP) and Direct Digital Control with Remote Setpoint (DDCRSP)
remote cascade types between the regulatory control function blocks included in an ACE/C300 supervisory
controller control strategy and the regulatory control points included in an EHPM Controller. It looks like this
graphically in a Control Module as shown in the following image.
The following table lists the major functions the UCNOUT/EUCNOUT block performs along with a brief
description of the function.
669
20 UCN INTERFACE
Translates secondary data (SECDATA) from Process The data structures for SECDATA and BACKCALC pass
Manager regulatory control points to ACE/C300 controller information back up the control path from secondaries to
compatible back calculation (BACKCALC) data. primaries. They contain data like initialization request,
initialization value, and anti-reset windup status.
Since SECDATA does not provide override feedback
propagation data, the UCNOUT/EUCNOUT block cannot
use BACKCALC to forward this data to its primary. This
means override strategies are not possible between the ACE/
C300 supervisory controller and the UCN based Process
Manager/EHPM Controller.
Participates in Remote Cascade Request protocol for a If Process Manager/EHPM regulatory control point is
Process Manager/EHPM regulatory control point MODE configured for Remote Cascade and the MODE is changed
changes. to Cascade, the MODE does not change immediately. The
UCNOUT/EUCNOUT block receives the Remote Cascade
request and then stores Cascade to the MODE for the
Process Manager point to complete the formation of the
cascade strategy.
Forwards inputs from primary regulatory control blocks in The Process Manager/EHPM point uses the Engineering
ACE/C300 supervisory controller to a Process Manager/ Units obtained from the SECDATA fetch to convert stores
EHPM regulatory control point. to its regulatory control point setpoint to Engineering Units.
The BACKCALC structure supports the same Engineering
Units information function for ACE/C300 regulatory control
blocks.
20.2.1 About remote cascade - UCNOUT/EUCNOUT block

The following table provides an overview of the four types of remote cascades that the UCNOUT/EUCNOUT
block supports. Refer to applicable Experion documents for more information about Experion system and TPS
system regulatory control functions.
Table 39: UCNOUT block
Remote Cascade Type Description

SPC - Setpoint Control Used for Supervisory to Level 1 controller cascade - UCNOUT block writes to the
setpoint (SP) of the Process Manager regulatory control point, when the point is in
Cascade (CAS) mode.
DDC - Direct Digital Control Used for Supervisory store to Output directly - UCNOUT block writes to the
output (OP) of the Process Manager regulatory control point, when the point is in
Cascade (CAS) mode.
RSP - Remote Setpoint Control Used for Supervisory to Level 1 controller cascade with a backup primary also
existing in Level 1 - UCNOUT block writes to the setpoint (SP) of the local
backup Process Manager regulatory control point, when the point is in Automatic
Mode and being initialized by its secondary, which is in either SPC or DDC
control by ACE supervisory controller.
DDCRSP - Direct Digital Control Used for Supervisory store to Output directly - UCNOUT block writes to output
with Remote Setpoint (OP) of the Process Manager regulatory control point, when the point is in
Cascade (CAS) mode. UCNOUT block also writes to the setpoint (SP) of the same
Process Manager regulatory control point to supply a backup SP.
20 UCN INTERFACE
Table 40: EUCNOUT block

SPC - Setpoint Control Used for Supervisory to Level 1 controller cascade - The ACE/C300 control
strategy writes to the setpoint (SP) of the EHPM regulatory control point, when
the point is in Cascade (CAS) mode. This option is configured by setting
RCASOPT to SPC.
DDC - Direct Digital Control Used for Supervisory store to Output directly - The ACE/C300 control strategy
writes to the output (OP) of the EHPM regulatory control point and the OP of the
EHPM analog output, when the point is in CAS mode. The output limits are not
applicable in this case. The SP cannot be written by the ACE/ C300 control
strategy to the regulatory control point.
If the control algorithm is a PID type and is configured for PV tracking, the SP is
set equal to the PV when in CAS mode. This option is configured by setting
RCASOPT to DDC.
RSP - Remote Setpoint Control Used for Supervisory to Level 1 controller cascade with a backup primary also
existing in Level 1 - The ACE/C300 control strategy writes to the SP through an
ACE/C300 output connection, subject to the SP limits, when the point is in
Automatic Mode and being initialized by its secondary (that is, INITMAN flag is
ON).
If RSP is selected, PV tracking is not performed in Automatic mode when
INITMAN is ON. This option is available for only PID-type algorithms and is
configured by setting RCASOPT to RSP.
DDCRSP - Direct Digital Control Used for Supervisory store to Output directly - The ACE/C300 control strategy
with Remote Setpoint writes to the OP of the EHPM regulatory control point, when the point is in CAS
mode. The ACE/C300 also writes to the SP of the same EHPM regulatory control
point subject to the SP limits.
PV tracking is not performed in CAS mode. This option is used primarily when a
single PID controller in the EHPM is used as a back up to a higher level control
strategy running in the ACE/C300. The higher level control strategy writes to the
OP and also provides the SP for the backup control strategy. This option is
available for only PID-type algorithms and is configured by setting RCASOPT to
DDCRSP.
For more information on remote cascade, refer to the HPM Control Theory in the TPN/TPS PDF bookset.
20.2.2 Configuration form overview

The following table identifies the tabs and parameters associated with each one for quick reference.
671
20 UCN INTERFACE

Execution Schedules” on page 55 section in the beginning of this document for
more information.
• Remote Cascade Type (REMCASTYPE) - Used for selecting the type of remote
cascade function the UCNOUT/EUCNOUT block is to support. See the previous
section “About remote cascade - UCNOUT/EUCNOUT block” on page 670 for
more information.
• Simulation Mode (SIMMODE) - Used for specifying the type of simulation
mode the block is to support in an ACE controller simulation application. The
default selection is NONE and cannot be changed in an ACE controller that is
operating on process. You can only change this parameter, if the simulation
enable (SIMENABLE) parameter for the ACE Controller is True or ON and the
ACE Controller simulation state (SIMSTATE) parameter has a value other than
SIMNONE. See the SIM-ACE User Guide for more information about defining
simulation levels using SIMMODE.
Block Pins Used for selecting the available parameters that you want to expose as input/output
Configuration Parameters Used for selecting the available parameters that you want to appear on the face of the
Monitoring Parameters Used for selecting the available parameters that you want to appear on the face of the
Block Preferences Used for selecting several block-viewing preferences including the color of the
block's faceplate.
20.2.3 Input/Output - UCNOUT/EUCNOUT block

The remote cascade type (REMCASTYPE) selection determines which UCNOUT/EUCNOUT block inputs to
use as summarized in the following table.
Attention
It is possible to configure and load a Control Module that includes an UCNOUT/EUCNOUT block with connections
that are not consistent for the selected Remote Cascade Type. In this case, you will not be permitted to activate the
Control Module in the Monitoring mode.
If a warning prompt appears about inconsistent UCNOUT/EUCNOUT input and output connections when saving a
Control Module, be sure you have configured the correct inputs and outputs for the selected Remote Cascade Type
before you close the Control Module.
If Remote Cascade Type Is . . . Then, Connect SP Input Or, Connect RSP Input Or, Connect OP Input
(SPPIN) . . . (RSPPIN) . . . (OPIN). . .
SPC - Setpoint Control Yes No No
DDC - Direct Digital Control No No Yes
RSP - Remote Setpoint No Yes No
Control
DDCRSP - Direct Digital Yes No Yes
Control with Remote Setpoint
20 UCN INTERFACE
The secondary data input (SECDATAIN) and the mode output (MODEOUT) connections are required for all
Remote Cascade Types. The following table summarizes the UCNOUT/EUCNOUT block inputs and outputs
needed for the given Remote Cascade Type selection.
If Remote Cascade Type Is . . . And/or, Connect SPOUT . . . And/or, Connect OPOUT . . .

SPC - Setpoint Control Yes No
DDC - Direct Digital Control No Yes
RSP - Remote Setpoint Control Yes No
DDCRSP - Direct Digital Control with Remote Yes Yes
Setpoint
20.2.4 Configuration example - UCNOUT/EUCNOUT block

The following figure shows a configured Control Module assigned to the ACE/C300 supervisory controller with
cascade connections to the UCN/EUCN system. The connections shown are for a Remote Cascade Type
selection of SPC (Setpoint Control). Note that the system automatically creates a BACKCALC connection
between the UCNOUTA/EUCNOUTA block and the primary (pida) based on the forward connection from
pida.OP to UCNOUTA.SPPIN/EUCNOUTA.SPPIN.
673
20 UCN INTERFACE
20 UCN INTERFACE
The SPPIN, RSPPIN, and/or OPIN input to the UCNOUT block is updated as part of each execution of the
Control Module. The SECDATAIN input is gathered at the rate specified by periodic update rate configured for
the referenced OPC server peer environment through the CEEACE block configuration of the peer subscription
period. The SPOUT and/or OPOUT outputs are stored at the rate of the UCNOUT block execution, while the
MODEOUT output is stored whenever necessary (normally a one-time store) to form the cascade with the UCN
point. The monitoring parameter CASSTS shows the status of the remote cascade match between ACE
controller and UCN regulatory control points during execution as follows:
Starting with Experion R430, the SPPIN, RSPPIN, and/or OPIN input to the EUCNOUT block is updated as
part of each execution of the Control Module. The SPOUT and/or OPOUT outputs are stored at the rate of the
EUCNOUT block execution, while the MODEOUT output is stored whenever necessary (normally a one-time
store) to form the cascade with the EUCN point. The monitoring parameter CASSTS shows the status of the
remote cascade match between ACE/C300 Controller and EUCN regulatory control points during execution as
follows:
• CASSTS = CASOK: Shows that remote cascade match is found between ACE/C300 and UCN/EUCN
regulatory control point.
• CASSTS = CASMISMATCH: Shows that remote cascade mismatch was found between ACE/C300 and
UCN/EUCN regulatory point.
• CASSTS = SECDATANOTREAD: Shows that secondary data from UCN/EUCN regulatory control point is
not being fetched.
20.2.5 UCNOUT/EUCNOUT parameters

UCNOUT/EUCNOUT block and the Control Builder Parameter Reference for definitions of each parameter.
675
20 UCN INTERFACE
21 Hiway Interface
Related topics
“Hiway Interface (HIWAYIF) Block Library” on page 678
“HIWAYOUT Block” on page 679
677
21 HIWAY INTERFACE
21.1 Hiway Interface (HIWAYIF) Block Library

The HIWAYIF block library contains blocks for creating regulatory control cascade strategies between the
Application Control Environment (ACE) supervisory controller and Data Hiway controllers residing on a Data
Hiway in a connected TPS system.
This library includes a HIWAYOUT block. The HIWAYOUT block provides configurable connections and
compatible data mapping between ACE and Data Hiway controllers through the OPC in a TotalPlant Process
Network (TPN) server. The following subsections provide a functional description of the HIWAYOUT block
21 HIWAY INTERFACE
21.2 HIWAYOUT Block

The HIWAYOUT function block supports Setpoint Control (SPC) and Direct Digital Control (DDC), remote
cascade types between the regulatory control function blocks included in an ACE supervisory controller control
strategy and the Data Hiway regulatory control points. It participates in Remote Cascade Request protocol for
Data Hiway point mode changes. The block looks like this graphically in a Control Module:
The following table lists the major functions the HIWAYOUT block performs along with a brief description of
the function.
Stores to regulatory points. Translates secondary data (SECDATA) from Data Hiway regulatory
control points to ACE controller compatible back calculation
(BACKCALC) data.
The data structures for SECDATA and BACKCALC pass
information back through the control path from secondaries to
primaries. They contain data like initialization request, initialization
value, and anti-reset windup status.
The block forwards inputs it receives from the primary of a
regulatory control function block in the ACE controller to a Data
Hiway regulatory control point.
Stores to setpoint (SP) Data Hiway Regulatory Control point are
converted to Engineering Units using the Engineering Units range
obtained from the Data Hiway point SECDATA fetch.
679
21 HIWAY INTERFACE
Stores to Analog Output and Composite Points. Participates in Remote Cascade Request protocol for Data Hiway
regulatory control point MODE changes.
If a user or a program attempts to change the MODE of a Data
Hiway point to Cascade (CAS), the MODE does not change
immediately nor is it stored to a box on the Data Hiway. It does set
the cascade request (CASREQ) parameter in the SECDATA
structure to REQ.
Setting the CASREQ value to REQ, triggers the HIWAYOUT block
to set the mode to Cascade when it reads the CASREQ parameter in
the SECDATA. This completes the formation of the cascade strategy.
The MODE now goes to CAS and the CASREQ reverts to its default
value of NOTREQ.
If communications between the ACE controller and the Data Hiway
fail, the MODE goes back to Manual (MAN) and the CASREQ
value is set to REQ.
21.2.1 About remote cascade-HIWAYOUT Block

The following table provides an overview of the two types of remote cascades that the HIWAYOUT block
supports. Refer to applicable Experion documents for more information about Experion system and TPS system
regulatory control functions.

SPC - Setpoint Control Used for Supervisory to Level 1 controller cascade - HIWAYOUT block writes to
the setpoint (SP) of the Data Hiway regulatory control point, when the point is in
Cascade (CAS) mode.
DDC - Direct Digital Control Used for Supervisory store to Output directly - HIWAYOUT block writes to the
output (OP) of the Data Hiway regulatory control, Analog Output (AO), or Analog
Composite (AC) point, when the point is in Cascade (CAS) mode.
21.2.2 Configuration form overview-HIWAYOUT Block

The following table identifies the tabs and parameters associated with each one for quick reference.
21 HIWAY INTERFACE

Execution Schedules” on page 55 section in the beginning of this document for
more information.
• Remote Cascade Type (REMCASTYPE) - Lets you select the type of remote
cascade function the HIWAYOUT block is to support. See the previous section
• “About remote cascade - UCNOUT/EUCNOUT block” on page 670 for more
information.
• Simulation Mode (SIMMODE) - Lets you specify the type of simulation mode
the block is to support in an ACE controller simulation application. The default
selection is NONE and cannot be changed in an ACE controller that is operating
on process. You can only change this parameter, if the simulation enable
(SIMENABLE) parameter for the ACE Controller is True or ON and the ACE
Controller simulation state (SIMSTATE) parameter has a value other than
SIMNONE. See the SIM-ACE User Guide for more information about defining
simulation levels using SIMMODE.
faceplate.
21.2.3 Input/Output-HIWAYOUT Block

The remote cascade type (REMCASTYPE) selection determines which HIWAYOUT block inputs and outputs
to use as summarized in the following table.
Attention
ATTENTION It is possible to configure and load a Control Module that includes a HIWAYOUT block with
connections that are not consistent for the selected Remote Cascade Type. In this case, you will not be permitted to
activate the Control Module in the Monitoring mode.
If a warning prompt appears about inconsistent HIWAYOUT input and output connections when saving a Control
Module, be sure you have configured the correct inputs and outputs for the selected Remote Cascade Type before you
close the Control Module.
If Remote Cascade Type Then, Connect SP Or, Connect OP Input Then, Connect SP Or, Connect OP
Is . . . Input (SPPIN) . . . (OPIN). . . Output (SPOUT). . . Output (OPOUT). . .
SPC - Setpoint Control Yes No Yes No
DDC - Direct Digital No Yes No Yes
Control
681
21 HIWAY INTERFACE
21.2.4 Configuration example-HIWAYOUT Block

The following figures show configured Control Modules assigned to the ACE supervisory controller with
cascade connections to the Data Hiway. The connection from the primary block output (OP) to SPPIN or OPIN
on the HIWAYOUT block depends on its Remote Cascade Type selection as noted above. Note that the system
automatically creates a BACKCALC connection between the HIWAYOUTA block and the primary (pida) based
on the forward connection from pida.OP to HIWAYOUTA.SPPIN.
Use a parameter connector to make output connection to SPOUT or OPOUT on the HIWAYOUT block,
depending on the block's Remote Cascade Type selection as noted above, to the Data Hiway point through the
OPC server block. The other necessary connections, such as SECDATA and MODE, are created automatically.
If the SPPIN parameter comes from a peer, it will be updated at the peer subscription rate.
If the Control Module (CM) peer read option value is configured for PREFETCH, the inputs, including
SECDATA, will be obtained 500 milliseconds before each CM execution.
It is assumed that Control Modules will have an execution PERIOD of 1 second and all peer subscription
periods are set to 500 milliseconds.
Table 41: Example of HIWAYOUT block used to do setpoint control of a regulatory Control Builder point
21 HIWAY INTERFACE
Table 42: Example of HIWAYOUT block used to write to an AO block on the High Level Process Interface Unit (HLPIU) for Direct
Digital Control
21.2.5 Load and Execution-HIWAYOUT Block

You load the HIWAYOUT block as part of its containing Control Module. The HIWAYOUT block executes at
the rate established by the Control Module PERIOD.
The SP or OP input of the HIWAYOUT block is updated as part of each execution cycle of the Control Module.
The SECDATAIN input is fetched at the rate specified for peer subscription.
The HIWAYOUT block's execution determines the store rate for SP and OP outputs. The MODE output is
normally a one-time store that is stored whenever necessary to form the cascade with the Data Hiway point. The
monitoring parameter CASSTS shows the status of the remote cascade match between ACE controller and
HIWAY regulatory control points during execution as follows:
• CASSTS = CASOK: Shows that remote cascade match is found between ACE and HIWAY regulatory
control point.
• CASSTS = CASMISMATCH: Shows that remote cascade mismatch was found between ACE and HIWAY
regulatory point.
• CASSTS = SECDATANOTREAD: Shows that secondary data from HIWAY regulatory control point is not
being fetched.
21.2.6 HIWAYOUT parameters

HIWAYOUT block.
683
21 HIWAY INTERFACE
22 Exchange Functions
Related topics
“Exchange Function Blocks” on page 686
“REQFLAGARRAY Block” on page 687
“REQNUMARRAY Block” on page 691
“REQTEXTARRAY Block” on page 695
“RSPFLAGARRAY Block” on page 699
“RSPNUMARRAY Block” on page 701
“RSPTEXTARRAY Block” on page 703
685
22 EXCHANGE FUNCTIONS
22.1 Exchange Function Blocks

Exchange function blocks provide a variety of configurable functions for storing and retrieving selected control
data.
associated Exchange function blocks. Functional descriptions for each block are given in the following
subsections.

Initiate read/write of multiple two- “REQFLAGARRAY Used to define up to 512 two separate states (Off/On)
state values Block” on page 687 to indicate status of a particular input. CPM initiates
read/write transactions to other connected devices
using either the PCCC or CIP communications
protocol.
Initiate read/write of multiple “REQNUMARRAY Used to store up to 64 floating point values for use in a
floating point values Block” on page 691 control strategy. CPM initiates read/write transactions
to other connected devices using either the PCCC or
CIP communications protocol.
Initiate read/write of multiple text “REQTEXTARRAY Used to store up to 64 ASCII characters for use in a
strings Block” on page 695 control strategy. CPM initiates read/write transactions
to other connected devices using either the PCCC or
CIP communications protocol.
Respond to read/write of multiple “RSPFLAGARRAY Used to define up to 512 two separate states (Off/On)
two-state values Block” on page 699 to indicate status of a particular input. CPM responds
to read/write transactions from other connected devices
using either the PCCC or CIP communications
protocol.
Respond to read/write of multiple “RSPNUMARRAY Used to define up to 64 floating point values for use in
floating point values Block” on page 701 a control strategy. CPM responds to read/write
transactions from other connected devices using either
the PCCC or CIP communications protocol.
Respond to read/write of multiple “RSPTEXTARRAY Used to define up to 64 ASCII characters for use in a
text strings Block” on page 703 control strategy. CPM responds to read/write
transactions from other connected devices using either
the PCCC or CIP communications protocol.
22.2 REQFLAGARRAY Block

The REQFLAGARRAY function block provides storage for up to 512 2-state values. The value can be accessed
as a simple Boolean (Off or On) using the PVFL[n] parameter. Where “n” is the number of the flag. It looks like
this graphically:

information.
• Command (COMMAND) - Lets you set the block's current MODE. The
selections are PLC5TYPREAD, PLC5TYPWRITE, CIPREAD, and CIPWRITE.
(Note that the corresponding communications protocol for a PLC5TYPREAD or
PLCTYPWRITE selection is PCCC (Programmable Controller Communications
Commands) and the CIP (Control and Information Protocol) communications
protocol is used for a CIPREAD or CIPWRITE selection.)
• Number of Flag Values (NFLAG) - Lets you set the amount of Flags you want to
control (1 .. 512).
687

Communications • Path to Device (PATH) - The relative path from the originator (C300 or C200/
C200E Controller) to the target device (or the DHRIO module when the target
device is on DH+) is specified as a comma-separated list of path segments. Each
path segment is specified as an X, Y pair where X can either be 1 (indicating that
this is an ICP Backplane Segment) or 2 (indicating that this is a ControlNet/
Ethernet or FTE Segment) depending on the type of communication network
used between the originator and the target devices.
• For ControlNet communications, when X is 1, Y denotes a slot number in the
range 0 to 16. When X is 2, Y denotes a ControlNet MAC ID in the range 1 to
99. The first path segment must be an ICP Backplane Segment. The path
segment types, MAC IDs and slot numbers must be specified in decimal values.
Binary, octal or hexadecimal values are not supported. IP Addresses are not
supported, when communicating on ControlNet. The following are examples of
valid paths:
1. 1, 5 (Path from the C200/C200E to a device in slot 5 of the same chassis)
2. 1, 0, 2, 3 (Path from the C200/C200E through the CNI in slot 0 to a device
that is on ControlNet with MAC ID 3)
3. 1, 5, 2, 7, 1, 3 (Path from the C200/C200E through the CNI in slot 5 to a
CNI with MAC ID 7 to a device in slot 3)
• For FTE or Ethernet communications, consider the following scenarios:
1. C300 (Originator on FTE) to C300 (Target on FTE) within the same FTE
community but associated with different Experion servers scenario: Only a
single pair of X, Y path segments represents the complete path. The X path
segment should always start with 2 to indicate that it is a FTE segment and
the Y path segment denotes the IP address of the target C300. For example,
– 2, 10.0.0.6 is a valid path segment from an originator C300 to a target
C300 having the IP address 10.0.0.6.
2. C300 (Originator on FTE) to C200/C200E (Target on FTE) within the same
FTE community but associated with different Experion servers scenario: The
X in the first path segment should always start with a 2 to indicate that it is a
FTE segment. The Y path denotes the IP address for the FTEB module in the
target C200/C200E chassis. The second path segment denotes an ICP
backplane segment and X must always be 1. The Y denotes a slot number for
the target module in the chassis in the range 0 to 16. The path segment types
must be specified in decimal values. Binary, octal or hexadecimal values are
not supported. For example,
– 2, 10.0.0.6,1,3 is a valid path from the C300 through the FTEB module
with IP address 10.0.0.6 to the target device in slot 3 in the C200/C200E
chassis.
3. C300 (Originator on FTE) to C200/C200E (Target on ControlNet) scenario:
The X path segment should always start with 2 (Indicating that this is an
FTE segment) and the Y path denotes the IP Address of the FTEB module in
the target C200/C200E chassis. The subsequent X, Y pair must denote path
segments for the ICP Backplane Segment. Where the X path is always 1, and
the Y path denotes a slot number of the target module in the range 0 to 16.
The path segment types must be specified in decimal values. Binary, octal or
hexadecimal values are not supported. For example,
– 2, 10.0.0.6,1,5,2,7,1,3 is a valid path from the C300 through the FTEB
module with the IP address 10.0.0.6 to the CNI in slot 5 to the CNI with
MAC ID 7 on ControlNet to the device in slot 3.
4. C200/C200E (Originator on FTE) to C200/C200E (Target on FTE) within
the same FTE community but associated with different Experion servers
scenario: When the X path is 1, the Y path denotes a slot number in the
range 0 to 16. When X is 2, Y denotes a FTE IP address. The first path
segment must be an ICP Backplane Segment, so the X path is always 1. The
path segment types, IP address and slot numbers must be specified in

decimal values. Binary, octal or hexadecimal values are not supported. For
example,
– 1,5,2,10.0.0.6,1,3 is a valid path from the C200/C200E to a FTEB
module in slot 5 of the same chassis, then through FTE to a FTEB
module with the IP address 10.0.0.6 in the target C200/C200E chassis to
the device in slot 3.
5. (Originator on FTE) to C200/C200E (Target on ControlNet) scenario: When
the X path is 1, the Y path denotes a slot number in the range 0 to 16. When
X is 2, Y denotes a FTE IP address. The first path segment must be an ICP
Backplane Segment, so the X path is always 1. The subsequent X, Y pair
following the IP address, must denote an ICP Backplane Segment through
CNIs to the ControlNet C200/C200E Controller. The path segment types, IP
address and slot numbers must be specified in decimal values. Binary, octal
or hexadecimal values are not supported. For example,
– 1,5,2,10.0.0.6,1,5,2,7,1,3 is a valid path from the C200/C200E to the
FTEB module in slot 5 of the same chassis, then through FTE to the
FTEB module with IP address 10.0.0.6 in the target C200/C200E chassis
to the CNI in slot 5 to the CNI with MAC ID 7 on ControlNet to the
device in slot 3.
When the target device is on the DH+ network, the path is the relative path from the
originator to the DHRIO module. Additional values are used to specify the address
of the target device on the DH+ network. See the following DHFL parameter for
details.
• File Name in Target Device (FILENAME) -The File Name in the target device is
specified as a Logical ASCII Symbolic address without the Logical ASCII
Identifier, when COMMAND is PLC5TYPREAD or PLC5TYPWRITE. For
example, a valid PCCC File Name and Offset in a target device value might be
N7:0.
When COMMAND is CIPREAD or CIPWRITE, this is then the name of the file
in the target device.
• When CIPREAD or CIPWRITE is selected, the FILENAME refers to the
Controller tag associated with the variable in the target device. For example,
HMI_Read is the name of a Numeric array in the CL5555 controller tags.
• Use DH+ through DHRIO? (DHFL) - Lets you specify whether or not the target
device is on an Allen-Bradley Data Highway and is connected through a DHRIO
module. The default selection is UNCHECKED (target device is not on DH+).
The following parameters are only active when the DHFL parameter is selected
(CHECKED).
• DH+ Channel A/B (DHCHANNEL) - Lets you specify which DH+ channel on
the DHRIO to use for this connection. The default selection is A for Channel A.
• DH+ Source Link (DHSRCLINK) - Lets you specify the source link for the DH
+ route when using DH+ Remote Messaging. This parameter should be set to
zero when using DH+ Local Messaging. The default selection is 0.
• DH+ Destination Link (DHDESTLINK) - Lets you specify the destination link
for the DH+ route when using DH+ Remote Messaging. This parameter should
be set to zero when using DH+ Local Messaging. The default selection is 0.
• Target Node Address (octal) (DHNODE) - Lets you specify the node number (0
to 77 octal) of the target node on the DH+ network. The default value is 0
(octal).
Status/Data Process Value, from device (PVFL) - The Status/Data Tab in Configuration Form
contains the initial values of the configured number of flag values. When this is a
“read” block, we cannot write to these values (they will be obtained from the target
device when the block starts executing and a send is triggered.
689

faceplate.
22.2.1 Function-REQFLAGARRAY Block

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)).
22.2.2 Input/Output-REQFLAGARRAY Block

The block has up to 512 output flags (PVFL[n]). But, all block pin parameters are available to be exposed and
connected to using Control Builder graphical connections.
22.2.3 REQFLAGARRAY parameters

REQFLAGARRAY function block.
22.3 REQNUMARRAY Block

The REQNUMARRAY block provides storage for up to 64 floating point values which are accessible through
the corresponding PV configuration parameter (PV[n]). Where “n” is the number of the numeric. It looks like
this graphically:

information.
• Number of Numeric Values (NNUMERIC) - Lets you set the amount of floating
point integers you want to control (1 .. 64).
• Data Type in Target device (TGTDATATYPE) - Lets you specify the type of data
in the target device. The selections are FLOAT32, SIGNEDINT8,
SIGNEDINT16 AND SIGNEDINT 32.
691

valid paths:
– 2, 10.0.0.6 is a valid path segment from an originator C300 to a target
C300 having the IP address 10.0.0.6.
– 2, 10.0.0.6,1,3 is a valid path from the C300 through the FTEB module
with IP address 10.0.0.6 to the target device in slot 3 in the C200/C200E
chassis.
– 2, 10.0.0.6,1,5,2,7,1,3 is a valid path from the C300 through the FTEB

example,
– 1,5,2,10.0.0.6,1,3 is a valid path from the C200/C200E to a FTEB
module in slot 5 of the same chassis, then through FTE to a FTEB
module with the IP address 10.0.0.6 in the target C200/C200E chassis to
the device in slot 3.
5. C200/C200E (Originator on FTE) to C200/C200E (Target on ControlNet)
subsequent X, Y pair following the IP address, must denote an ICP
Backplane Segment through CNIs to the ControlNet C200/C200E
Controller. The path segment types, IP address and slot numbers must be
specified in decimal values. Binary, octal or hexadecimal values are not
supported. For example,
– 1,5,2,10.0.0.6,1,5,2,7,1,3 is a valid path from the C200/C200E to the
FTEB module in slot 5 of the same chassis, then through FTE to the
FTEB module with IP address 10.0.0.6 in the target C200/C200E chassis
to the CNI in slot 5 to the CNI with MAC ID 7 on ControlNet to the
device in slot 3.
details.
N7:0.
(CHECKED).
(octal).
Status/Data Process Value, from device (PV) - The Status/Data tab contains the initial data
values to be written to the target. Control strategies in the CPM can modify these
values at run-time. The operator at run-time can also modify these values.
693

faceplate.
22.3.1 Function-REQNUMARRAY Block

The REQNUMARRAY 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 Number of Numeric Values (NNUMERIC) which lets you specify the desired number of
numeric values to be supported.
22.3.2 Input/Output-REQNUMARRAY Block

The block has up to 64 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.
22.3.3 REQNUMARRAY parameters

REQNUMARRAY function block.
22.4 REQTEXTARRAY Block

The REQTEXTARRAY block provides storage for up to 64 ASCII characters which are accessible through the
corresponding string configuration parameter (STR[n]). Where “n” is the number of the text string. The length
of the text strings is user configurable. It looks like this graphically:

information.
• Number of String Values (NSTRING) - Lets you set the amount of ASCII strings
needed (1..8).
• Char Length of String Values (STRLEN) - Lets you select the length of strings
(1..64) needed. This is based on the NSTRING value. I.E. NSTRING = 4 then
STRLEN = 16. (The product of NSTRING and STRLEN cannot exceed 64.)
695

Note: You cannot use the REQTEXTARRAY block to transfer text data with a
CL5550 PLC.
valid paths:
2, 10.0.0.6 is a valid path segment from an originator C300 to a target C300
having the IP address 10.0.0.6.
2, 10.0.0.6,1,3 is a valid path from the C300 through the FTEB module with
IP address 10.0.0.6 to the target device in slot 3 in the C200/C200E chassis.
2, 10.0.0.6,1,5,2,7,1,3 is a valid path from the C300 through the FTEB

example,
1,5,2,10.0.0.6,1,3 is a valid path from the C200/C200E to a FTEB module in
slot 5 of the same chassis, then through FTE to a FTEB module with the IP
address 10.0.0.6 in the target C200/C200E chassis to the device in slot 3.
5. C200/C200E (Originator on FTE) to C200/C200E (Target on ControlNet)
subsequent X, Y pair following the IP address, must denote an ICP
Backplane Segment through CNIs to the ControlNet C200/C200E
Controller. The path segment types, IP address and slot numbers must be
specified in decimal values. Binary, octal or hexadecimal values are not
supported. For example,
1,5,2,10.0.0.6,1,5,2,7,1,3 is a valid path from the C200/C200E to the FTEB
module in slot 5 of the same chassis, then through FTE to the FTEB module
with IP address 10.0.0.6 in the target C200/C200E chassis to the CNI in slot
5 to the CNI with MAC ID 7 on ControlNet to the device in slot 3.
details.
N7:0.
(CHECKED).
(octal).
Status/Data Process Value, from device (STR) - The Status/Data tab contains the initial data
values to be written to the target. Control strategies in the CPM can modify these
values at run-time. The operator at run-time can also modify these values.
697

faceplate.
22.4.1 Function-REQTEXTARRAY Block

The REQTEXTARRAY block outputs (STR[n]) can be used to provide predefined text strings to other function
blocks.
• A configurable Number of String Values (NSTRING) which lets you specify the desired number of string
values (up to 64) 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 REQTEXTARRAY block supports a maximum size of 64 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 64 two-byte characters of data, will
be rejected.
NSTRING Value STRLEN Value STR[n] Range

1 64 [0]
2 32 [0. .1]
4 16 [0. .3]
8 8 [0. .7]
22.4.2 Input/Output-REQTEXTARRAY Block

The block has up 64 ASCII characters (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.
22.4.3 REQTEXTARRAY parameters

REQTEXTARRAY function block.
22.5 RSPFLAGARRAY Block

The RSPFLAGARRAY function block provides storage for up to 512 2-state values. The value can be accessed
as a simple Boolean (Off or On) using the PVFL[n] parameter. Where “n” is the number of the flag. It looks like
this graphically:

• PCCC File Number (FILENUM) - Lets you specify the file number (0 to 999) to
be emulated when accessing this block through the PCCC (Programmable
Controller Communications Commands) protocol from a remote device. The
default value is 0.
• CIP Tag Name (CIPNAME) - Lets you specify the tag name of this array when
accessing this block through the CIP protocol from a remote device. The default
entry is blank (no name).
• Number of Flag Values (NFLAG) - Lets you set the amount of Flags you want to
control (1 .. 512). The default value is 1.
• Process Value, from device (PVFL) - Contains the values of the configured
number of flag values that are the “target” for a remote device initiated read or
write message request.
faceplate.
22.5.1 Function-RSPFLAGARRAY Block

• Current state of flags can be read using flag value (PVFL[n] (Boolean).
Attention
The Process Values (PVFL[N]) can be overwritten by operators or other programs (SCMs), when the value is also
being written by a remote device as part of a write request type operation. Be sure your control strategy design does
not allow write conflicts.
699
22.5.2 Input/Output-RSPFLAGARRAY Block

The block has up to 512 output flags (PVFL[n]). But, all block pin parameters are available to be exposed and
22.5.3 RSPFLAGARRAY parameters

RSPFLAGARRAY function block.
22.6 RSPNUMARRAY Block

The RSPNUMARRAY block provides storage for up to 64 floating point values which are accessible through
this graphically:

default value is 0.
• Number of Numeric Values (NNUMERIC) - Lets you set the amount of floating
point integers you want to control (1 .. 64). The default value is 1.
• Data Type for PCCC/CIP access (DATATYPE) - Lets you specify the type of
data that can be read from or written to by a remote device. The selections are
FLOAT32, SIGNEDINT8, SIGNEDINT16 and SIGNEDINT 32. The default
value is FLOAT32.
• Process Value, from device (PV) - Contains the data values to be read from or
written to by the remote device.
faceplate.
22.6.1 Function-RSPNUMARRAY Block

The RSPNUMARRAY block outputs (PV[n]) can be used as source parameters to provide predefined analog
Number).
• A configurable Number of Numeric Values (NNUMERIC) lets you specify the desired number of numeric
values to be supported.
701
22.6.2 Input/Output-RSPNUMARRAY Block

The block has up to 64 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.
22.6.3 RSPNUMARRAY parameters

RSPNUMARRAY function block.
22.7 RSPTEXTARRAY Block

The RSPTEXTARRAY block provides storage for up to 64 ASCII characters which are accessible through the

default value is 0.
• Number of String Values (NSTRING) - Lets you set the amount of ASCII strings
needed (1..8).
• Character Length of String Values (STRLEN) - Lets you select the length of
strings (1..64) needed. This is based on the NSTRING value. I.E. NSTRING = 4
then STRLEN = 16. (The product of NSTRING and STRLEN cannot exceed
64.)
• Process Value, from device (STR) - Contains the array of strings to be read from
or written to by the remote device.
faceplate.
22.7.1 Function-RSPTEXTARRAY Block

The RSPTEXTARRAY block outputs (STR[n]) can be used to provide predefined text strings to other function
blocks.
703
The RSPTEXTARRAY block supports a maximum size of 64 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 64 two-byte characters of data, will
be rejected.

1 64 [0]
2 32 [0. .1]
4 16 [0. .3]
8 8 [0. .7]
22.7.2 Input/Output-RSPTEXTARRAY Block

The block has up 64 ASCII characters (STR[n]), depending on the number of string values (NSTRING)
22.7.3 RSPTEXTARRAY parameters

RSPTEXTARRAY function block.
23 Auxiliary Function Blocks
Auxiliary function blocks provide a variety of configurable functions for conditioning, calculating, and
compensating PV data in support of regulatory control functions.
associated Auxiliary function block.
Attention
The ROC block can be used only with C300, C200E, and ACE controllers and it is not supported with C200
controllers.
Block Function Description

“AUXCALC (Auxiliary Compute a PV value Lets you create custom algorithms by writing up to eight
Calculation) Block” expressions. Each expression can contain any valid
combination of inputs, operators and functions; and may
perform arithmetic or logic operations, test conditions,
etc. Optionally, it can accept up six inputs.
“AUXSUMMER Calculate a PV value from up to ten Lets you configure up to ten inputs to provide an overall
(Auxiliary Summer) inputs result that can be scaled and biased.
Block”
“CTUD (COUNTER Counts the inputs values Lets you configure the algorithm to start functioning
UP/DOWN) Block” according to the status of the count on level flag
(CNTLVLFL).
“DEADTIME Block” Delay processing of input value Lets you specify a fixed or a variable “dead-time” before
changes a change in input value is calculated as a corresponding
change in PV.
“ENHAUXCALC Provide enhancements to • Expands existing arrayed input parameters PSTS and
(Enhanced Auxiliary AUXCALC block functions P from six to ten.
Calculation) Block” • These arrayed parameters are added to correspond to
each of the ten inputs.
– Scaling Factor
– PSUB Substitute Parameter
– PP Scaled Input
“ENHGENLIN Generate a linearization output for Computes an output value in PV as a function of values
(Enhanced General an input with non-linear in inputs P1 and ACTLINSEG based on configuration in
Linearization) Block” characteristics and value of the linearization segment table. Typically used to provide a
ACTLINSEG parameter. linearized PV (in engineering units) for a sensor actuator,
or process with nonlinear characteristics.
“FLOWCOMP (Flow Operates on uncompensated flow Computes a flow compensation factor based on variations
Compensation) Block” measurements of liquids, steam, in parameters like temperature, pressure, specific gravity,
gases or vapors. and molecular weight. The block derives a compensated
flow value as its output.
705
23 AUXILIARY FUNCTION BLOCKS

“FANOUT Block” Generate a linearized output for an Computes an output value that is a user-defined function
input with non-linear characteristics. of the input. You may define 2 to 13 coordinates, which,
together, approximate a continuous non-linear function.
Typically used to provide a linearized PV (in engineering
units) for a sensor with nonlinear characteristics.
“LEADLAG Block” Provide lead and lag compensation Provides lead and lag compensation to a change in input
value calculation for corresponding change in PV.
“ROC (Rate of Change) Limits the rate of input and provides Provides computational block intended for use on the
Block” the output variable based on the rate input side of function blocks for limiting the input
trip limits variable to the block (typically SP).
“SIGNALSEL (Signal Select one of up to six input signals The Signal Selector function block accepts as many as six
Selector) Block” or calculate the average of a set of input signals, and may be configured to do one of the
inputs following on these inputs:
Select the input with the minimum value.
Select the input with the maximum value.
Select the median input.
Calculate the average of the inputs.
Select an input based on the value of an external control
signal; i.e., act as a multiplexer. With this option, the
function block accepts two to six inputs
“TOTALIZER Accumulate total flows Periodically adds an input value to an accumulator value,
Block”TOTALIZER sets status flags to indicate when accumulator value is
Block near user-specified target values (“near”, “nearer”,
“actual target value”). Typically used to accumulate total
flows. Block also supports warm restarts.
23.1 Common auxiliary block functions

Listed below are the major functions performed by auxiliary function blocks along with a brief functional
description for each. Functional descriptions for each block are given in the following subsections.

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. Depending of the particular Auxiliary block, additional functions may
be included.
707
23.2 AUXCALC (Auxiliary Calculation) Block

The AUXCALC (Auxiliary Calculation) block lets you write up to eight expressions for computing a PV value.
Each expression may perform arithmetic or logic operations, test conditions, etc. Status information is made
available for both the inputs, as well as the expression results. Through configuration, you can assign the result
of an expression, a status, or an input to PV and PVSTS parameters. It looks like this graphically.
23.2.1 Function-AUXCALC block

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.
Table 43: AUXCALC block major functions
23.2.2 Configuration example-AUXCALC block

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])
709
Table 44: Example CB configuration using AUXCALC block for range conversion.
23.2.3 Input-AUXCALC block

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.
23.2.4 Output-AUXCALC block

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
23.2.5 Expressions-AUXCALC block

and functions. You can also write a short descriptive text for each expression. Table 1( “Expressions-REGCALC
block”) in the REGCALC block section lists the expression operators and functions supported by this block for
reference.
23.2.6 Parameters in Expressions-AUXCALC block

You must specify a parameter by its full tag name (for example. “CM25.PumpASelect.PVFL”, or
will understand. If this text is incorrect runtime errors will occur.
For example, OPCTag.‘tag.Param(1)’ can be used so that the parenthesis characters do not confuse the
expression parser.
Attention
TagName.text.
23.2.7 Guidelines for Writing Expressions-AUXCALC block

• Must include full tag.parameter name for P inputs in the expression and enclose identification number in
brackets instead of parenthesizes. For example, CM151.AUXCALC BLOCK.P[1]*CM151.AUXCALC
BLOCK.P[2] is valid.
Tip
711
Attention
Example:
Example:
The results of the expressions, which use the CONST [1…8] parameters, are affected if you change the
Note: When you migrate from a prior release (Pre-R400), the value of EXPRDESC[1..8] parameter is blank
by default. When you migrate to a future release, the EXPRDESC[1..8] parameter retains its values.
• With R410, whenWhen you write the expressions using the TPS point's parameter references, ensure that the
TPS reference parameter is configured using the parentheses “()”to specify array index. However, when you
write the expressions using the other non-CEE points you can use the brackets “[].”
23.2.8 Assignable Outputs-AUXCALC block

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.
23.2.9 AUXCALC parameters

AUXCALC block.
23.3 AUXSUMMER (Auxiliary Summer) Block

The AUXSUMMER (Auxiliary Summer) block lets you configure up to ten separate inputs to calculate a
process variable (PV) value that can be scaled and biased. Status information is made available for each input,
as well as the PV value. Through configuration, you can define a scale factor, bias value, and description for
each input. You can also choose to disable an input. All inputs are enabled by default. It looks like this
graphically.
23.3.1 Function-AUXSUMMER block

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
Where: CPV = Overall scale factor for PV

DPV = Overall bias for PV
C [i] = Scale factor for input ‘i’
D [i] = Bias for input ‘i’
P [i] = Input value ‘i’
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.
713
23.3.2 Configuration parameters-AUXSUMMER block

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.
Title Parameter Name 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 Factor for CPV Lets you define the scaling factor to be applied to the PV
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 Switch PENABLE[1..10] Lets you enable or disable a given input for the 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 Inputs C[1..10] Lets you define a scaling factor for the given 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.
Input Substitute Value PSUB[1..10] Lets you define a substitute value to be used for the
corresponding disabled 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 NaN (Not a Number).
Bias Values for Inputs D[1..10] Lets you define the bias value to be applied to 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.
Number of Process Input NUMPINPT This is a read-only parameter that shows the number of inputs
Connections connected to the block. This parameter does not appear on the
Main tab. It can be configured as monitoring parameter on the
face of the block.
23.3.3 Configuration example-AUXSUMMER block

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.
Table 45: Example CB configuration using AUXSUMMER block to calculate PV based on three inputs.
23.3.4 Input-AUXSUMMER block

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.
23.3.5 Output-AUXSUMMER block

715
23.3.6 Error handling-AUXSUMMER block

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.
23.3.7 Restart or point activation-AUXSUMMER block

On a warm restart or when the AUXSUMMER block is inactivated or when the ACE controller node is
repowered, the input P[i] is set to NaN and its Status PSTS[i] is set to BAD.
23.3.8 AUXSUMMER parameters

AUXSUMMER block.
23.4 CTUD (COUNTER UP/DOWN) Block

Prior to R400, digital counter function was typically implemented as follows:
• By using a Totalizer or an Auxiliary function block with external additional logic, or
• By using the pulse count function and associated hardware.
With R400, a newgeneral purpose Up-Down Counter (CTUD) is introduced in the Auxiliary library to simplify
event count strategies. The CTUD Block supports pause (PAUSEFL), load (LOADFL) and reset (RESETFL)
operation for the counter. The input values are fetched through wired connection from another function block,
by a program, SCM, or CAB. In addition, CTUD blocks may be cascaded to form larger counters.
The CTUD block can be used with the following control execution environments.
• C300 Controller
• C200E Controller
• ACE Controller
• ACE-T Controller
• SIM-C300
• SIM-C200E
• SIM-ACE
CTUD block is graphically represented in the following figure.
23.4.1 Function-CTUD block

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.
717
23.4.2 Inputs-CTUD block

CTUD block accepts the following input format.
• Integer 32
• Float 64
• Boolean
• Enumeration
By default, FLOAT64 input format is supported.
Selecting ININT32/FLOAT64 input

By default, INFLOAT64 parameter is set as active. However, you can select which IN parameter can be used for
counter pre-load or comparisons by configuring the Input Specifier parameter (SELINT32FL) parameter.
• If SELINT32FL is set to “FALSE”, the float input (INFLOAT64) is used.
• If SELINT32FL is set to “TRUE”, the integer input (ININT32) is used.
Storing input values

The following list illustrates how the different input values are stored.
• Boolean value
– If the input is 0, it is stored as 0.
– If the input is non-zero and the input clamping option INCLAMPOPT is “TRUE”, the input is stored as
“1”. Otherwise, an error is displayed.
• Integer value
Full ranges of signed integer values (- 2,147,483,648 to + 2,147,483,647) are accepted.
• Floating point value
INCLAMPOPT parameter determines whether special handling is required for out of range values or invalid
FLOAT64 values.
For more information on clamping float input parameter values (INFLOAT64), refer to “REEOUT (Remote
EEOUT) Block” table.
• Enumerations
The input values are clamped to the range of acceptable enumeration values.
Note: The valid enumeration values are clamped to a range of acceptable enumeration values.
Input clamping for INFLOAT64

If the selected input is in floating point format, the INCLAMPOPT is consulted to determine whether special
handling is required for out of range or invalid input values. Value clamping, truncation, or substitution is
illustrated in the following table.
Input fetched or tried to INCLAMPOPT FLOAT64 value Value for Counter load Value for limit
store (INFLOAT64) status operation checking
+Infinity TRUE 2,147,483,647.0 2,147,483,647 2,147,483,647
+Infinity FALSE NaN Retain previous The limit comparison
internal counter value is always FALSE
and never load the (NaN).
counter.
Greater than TRUE 2,147,483,647.0 2,147,483,647 2,147,483,647
2,147,483,647.0
Input fetched or tried to INCLAMPOPT FLOAT64 value Value for Counter load Value for limit
store (INFLOAT64) status operation checking
Greater than FALSE NaN Retain previous The limit comparison
2,147,483,647.0 internal counter value is always FALSE
counter.
Between TRUE/FALSE Float value is truncated Float value is truncated Float value is
-2,147,483,648.0 and to integer equivalent. to integer equivalent, truncated to integer
+2,147,483,647.0 then cast to INT32 equivalent, then cast
to INT32
Less than TRUE -2,147,483,648.0 -2,147,483,648 -2,147,483,648
-2,147,483,648.0
Less than FALSE NaN Retain previous The limit comparison
-2,147,483,648.0 internal counter value is always FALSE
counter.
-Infinity TRUE -2,147,483,648.0 -2,147,483,648 -2,147,483,648
-Infinity FALSE NaN Load inhibited. NaN
NaN TRUE/FALSE NaN Retain previous The limit comparison
internal counter value is always FALSE
counter.
Pause, Load, and Reset parameters

• Pause (PAUSEFL) - When this parameter is set to “TRUE”, the CTUD stops counting.
• Load (LOADFL) - When this parameter is set to “TRUE”, the CTUD output value (OUTIINT32/
OUTFLOAT64) assumes the value of the IN parameter value (INIINT32/INFLOAT64). For example, if the
IN value (INIINT32/INFLOAT64) is 60, and the LOADFL is set to “TRUE”, the CTUD output value
(OUTIINT32/OUTFLOAT64) is set to 60.
• Reset (RESETFL) - When this parameter is set to “TRUE”, the CTUD's counter value is set to zero.
Attention
If RESETFL and LOADFL flags are set to “TRUE” at the block execution time, the internal counter value is set to
zero.
23.4.3 Outputs-CTUD block

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.
23.4.4 Edge or Level trigger mechanism-CTUD block

The Up and Down count input flags (CNTUPFL and CNTDNFL) can be evaluated as edge trigger quantities or
level quantities depending on the value of the count level flag parameter, CNTLVLFL.
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.
719
Table 46: Example CNTUPFL parameter configuration using edge-triggered
The following diagram displays how the transition occurs in case of edge-trigger.
Table 47: Example diagram for edge-triggered
Attention
Input edge detection on the count up and countdown 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” does
not generate a count.
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 increment 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 is an example configuration figure for level-triggered count.
Table 48: Example CNTUPFL parameter configuration using level-triggered
The following diagram displays how the transition occurs in case of level trigger.
Table 49: Example diagram for level-triggered
721
23.4.5 Supported algorithms-CTUD block

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.
23.4.6 Counter overflow and underflow conditions-CTUD block

The following table lists the range of each equation, scenarios in which the counter overflow and underflow
conditions occur, and also the results of these conditions for each equation.
Algorithm Range Overflow conditions and results Underflow conditions and results
A, B, E, F 2,147,483,647 to • Condition: If the counter • Condition: If the counter value is
+2,147,483,647 value is greater than lesser than -2,147,483,647.
+2,147,483,647. • Result: The Counter value is set to
• Result: The Counter value is the +2,147,483,647 and the counter
set to the -2,147,483,647 and operation continues.
the counter operation
continues.
C 0 to +2,147,483,647 • Condition: If the counter • Condition: If the counter value is
value is greater than the lesser than zero.
value +2,147,483,647. • Result: The counter value is set to
• Result: The counter value is +2,147,483,647 and continues the
set to zero and continues the operation.
operation.
D 0 to IN • Condition: If the counter • Condition: If the counter value is
value is greater than the IN lesser than zero.
Note: This
parameter values (ININT32/ • Result: The counter value is set to
equation
INFLOAT64). the IN parameter values (ININT32/
requires IN >0
for counting • Result: The Counter value is INFLOAT64) and continues the
correctly set to zero and continues the operation.
operation.
G -2,147,483,648 to 0 • Condition: If the counter • Condition: If the counter value is
value is greater than zero. lesser than -2,147,483,647,
• Result: The Counter value is • Result: The Counter value is set to
set to -2,147,483,647 and zero and continues the operation.
continues the operation.
H IN to 0. • Condition: If the counter • Condition: If the counter value is
value is greater than the IN lesser than the IN parameter
Note: This
value (ININT32/ (ININT32/INFLOAT64) value.
equation
INFLOAT64). • Result: The counter value is set to
requires IN < 0
for counting • Result: The counter value is zero continues the operation.
correctly. set to the IN value
(ININT32/INFLOAT64)
continues the operation.
Attention
The CTUD excludes a gap between zero and IN (INT32/FLOAT64) value for the following scenarios.
• The IN value is greater than zero when using Equation D.
• The IN value is lesser than zero when using Equation H.
The following figure displays the gap excluded between zero and the IN values for the Equation D and H.
Monitoring counter using QUFL and QDFL

The following table illustrates the scenarios in which the QUFL or QDFL parameters are set for each algorithm.
Algorithm QUFL (TRUE) QDFL(TRUE)

A OUT >= IN OUT <= 0
B OUT >= IN OUT ==-2,147,483,648
C OUT >= IN OUT == 0
D OUT == IN OUT == 0
E OUT >= 0 OUT <= IN
F OUT == +2,147,483,647 OUT <= IN
G OUT == 0 OUT <= IN
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.
723
23.4.7 Effects of restart or point activation on CTUD

The counter flag outputs are held on inactivation, Warm Start, and RAM Retention Restart (RRR). The floating
point output is initialized to NaN to match the failsafe value to downstream blocks on communication loss. For
an inactive counter, or a counter undergoing Warm restart or RRR, the previous value is held and can be
retrieved. The integer output is defaulted to zero and retains its previous value on inactivation, Warm Start, and
RRR.
23.4.8 Effects of Import or Export on CTUD

The counter function block strategies can be imported or exported to files using command line, program, and
Windows import/export tools.
23.4.9 Effects of Checkpoint operations CTUD

The counter function block structural data is handled in a similar manner to other function blocks for load and
Checkpoint Restore. Loading order of structural data is designed to accommodate interrelated parameters
without warnings for valid data load in anticipation of following related information, as displayed in the table.
Initialization Values after Checkpoint Restore

Parameter Name Value
Input Parameters
ININT32 0
INFLOAT64 0.0
Count Flags
CNTUPFL FALSE (0)
CNTDNFL FALSE (0)
RESETFL FALSE (0)
PAUSEFL FALSE (0)
LOADFL FALSE (0)
Configuration parameters
CNTLVLFL Configuration entry
CNTEQN Configuration entry
Initialization Values after Checkpoint Restore

Parameter Name Value
SELINT32FL Configuration entry
INCLAMPOPT Configuration entry
Output Flags
QDFL FALSE (0)
QUFL FALSE (0)
CARRYUPFL FALSE (0)
CARRYDNFL FALSE (0)
Output parameters
OUTINT32 0
OUTFLOAT64 NaN
23.4.10 Parameter error handling-CTUD block

• The CTUD evaluates parameter stores on two levels,
– User entries from Property dialogs boxes are assessed against entry limits and immediately reported.
– Parameter stores that occur from load, Checkpoint Restore, Program operations, or normal fetch
operations are assessed in the store methods and error or warning return values are supplied.
• Warnings or errors that occur during load or Checkpoint Restore, and parameter store are displayed in a
dialog box and stored in the Error log.
• Warnings are displayed while storing out-of-range or NaN floating point values.
• You can see errors while entering configuration values or dialog entry failures due to access lock. (For
example, while trying to store a parameter with insufficient access level.)
• Error or warning is notified to the entity, (can be SCM, PushBlock, program store, and so on) which
provides an invalid input to the counter function block.
23.4.11 CTUD parameters

Refer to the Control Builder Components Reference for a complete list of the parameters used with the CTUD
block.
725
23.5 DEADTIME Block

The DEADTIME block provides a user configurable fixed or variable dead-time delay in processing changes in
its input (P1). The variable dead-time function varies as the inverse of a second input (P2) to the block. The
block looks like this graphically:
Each DEADTIME block supports the following user configurable attributes. The following table lists the given

information.
• Overall Scale Factor (CPV) - Lets you specify the overall-scaling factor for the
PV output. The default value is 1.
• Factor for P1 (C1) - Lets you specify the scaling factor for the P1 input. The
default value is 1.
• Factor for P2 (C2) - Lets you specify the scaling factor for the P2 input. This
only applies for the Variable delay type selection. The default value is 1.
• Overall Bias (DPV) - Lets you specify an overall bias for the PV output. The
default value is zero (0).
• Bias for P1 (D1) - Lets you specify a bias for the P1 input. The default value is
zero (0).
• Bias for P2 (D2) - Lets you specify a bias for the P2 input. This only applies for
the Variable delay type selection. The default value is zero (0).
• Delay Type (DELAYTYP) - Lets you select the delay type as either Fixed or
Variable. The default selection is Fixed.
• Delay Time (minutes) (DELAYTIME) - Lets you specify the fixed delay time in
minutes. This only applies for the Fixed selection. The default value is zero (0).
• Delay Table Size (NUMLOC) - Lets you specify the number of locations to be
used in the delay table. This only applies for the Variable selection. The default
value is 60.
• Cutoff Limit (CUTOFF.LM) - Lets you specify the zero-flow cutoff limit for the
P2 input. When the P2 input is below the limit, the block sets the delayed P1
value to 0.0. The default value is NaN (Not-a-Number), which means there is no
cutoff limit.
faceplate.
23.5.1 Function-DEADTIME block

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.
727
23.5.2 Input-DEADTIME block

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.
23.5.3 Output-DEADTIME block

The block produces an output value (PV), a status (PVSTS), and a status flag (PVSTSFL).
23.5.4 PV status-DEADTIME block

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.UNCERTN - if PVSTS = Uncertain, this flag is on; otherwise it is off.
23.5.5 Error handling-DEADTIME block

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.
23.5.6 Delay type-DEADTIME block

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.
DPt=P1(t - DELAYTIME)
PV=CPV*DPt + DPV
Where:
CPV=Overall scale factor for PV
DELAYTIME=Fixed delay time in minutes
DPV=Overall bias for PV
DPt=Delayed P1 value (internal variable, not user accessible)
t=Present time notation only (not a parameter)

• 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.
If CUTOFF.LM is not NaN and P2 is less than CUTOFF.LM:
DPt=0
Otherwise:
DELAYTIME=[C1 / (C2 * P2 + D2)] + D1
DPt=P1(t - DELAYTIME)
And:
PV=CPV * DPt + DPV
Where
C1=Scaling factor in the calculation of the DELAYTIME
C2=Scaling factor for P2
CPV=Overall scale factor for PV
CUTOFF.LM=Cutoff limit, for example, corresponding to zero flow or zero conveyor belt speed.
D1=Bias in the calculation of the DELAYTIME, equivalent to a fixed delay
D2=Bias for P2
DELAYTIME=Fixed delay time in minutes
DPV=Overall bias for PV
DPt=Delayed P1 value (internal variable, not user accessible)
P1=Input value to which the delay is applied
P2=Input value that changes the variable delay
t=Present time notation only (not a parameter)
23.5.7 Delay table-DEADTIME block

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.
DELAYTIME>=Period * NUMLOC
DELAYTIME<=Period * 32000
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.
• P2<=1 / (Period * NUMLOC)
729
• P2>=1 / (Period * 32000)

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.
• You can connect DEADTIME blocks in series to achieve longer delays.
23.5.8 Restart condition-DEADTIME block

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.
23.5.9 DEADTIME parameters

DEADTIME block.
23.6 ENHAUXCALC (Enhanced Auxiliary Calculation) Block

The ENHAUXCALC block provides the following enhancements over the AUXCALC block.
• Expands existing arrayed input parameters PSTS and P from six to ten.
• These arrayed parameters are added to correspond to each of the ten inputs.
– Scaling Factor
– PSUB Substitute Parameter
– PP Scaled Input
• Both the ENHAUXCALC and AUXCALC blocks are optimized so that expressions use memory based on
the number of expressions configured, pcode size of each expression, the number of references in the
expression and the offset needed for each expression.
23.6.1 Function-ENHAUXCALC block

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:
PP[i] = PSUB[i] * CP[i]
• Else: If PENABLE = 1 (Enable), then:
PP[i] = P[i] * CP[i]
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] = The original input
731
PP[i] = P[I] * CP[I]

• Else: If PENABLE = 0 (Disable), then:
P[i] = PSUB[I]
PP[i] = PSUB[i] * CP[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.
Figure 17: ENHAUXCALC block major functions
23.6.2 Configuration parameters-ENHAUXCALC block

The following table provides a summary of the ENHAUXCALC specific parameters that you can configure

PV PVSRC Lets you assign the result of an expression (C[1..8]), a status
value (CSTS[1..8]), an input (P[1..10]) or an input status
(PSTS[1..10]) to output (PV). The default is P[1].

PVSTS PVSTSSRC Lets you assign the result of an expression (C[1..8], a status
value (CSTS[1..8]), an input (P[1..10]) or an input status
(PSTS[1..10]) to output status (PVSTS[1])
Input P[1..10] Lets you fetch values from other function blocks.
Input Description PDESC[1..10] Lets you type your own description for each input.
Enable PENABLE[1..10] Lets you Enable or Disable a corresponding input.
Scaling Factor CP[1..10] Lets you define a scaling factor for a corresponding input. The
default value is 1.
Input Substitute Value PSUB[1..10] Lets you define a substitute value for corresponding input/
scaled input when the input is disabled. The default is NaN.
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.
23.6.3 Input-ENHAUXCALC block

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.
23.6.4 Output-ENHAUXCALC block

• As many as eight expression results (C[1] through C[8]) and their statuses
23.6.5 Expressions-ENHAUXCALC block

and functions. You can also write a short descriptive text for each expression. Table 1( “Expressions-REGCALC
block”) in the REGCALC block section lists the expression operators and functions supported by this block for
reference.
23.6.6 Parameters in Expressions-ENHAUXCALC block

You must specify a parameter by its full tag name (for example. “CM25.PumpASelect.PVFL”, or
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.
733
You can use the following additional arrayed parameters in expressions.

• CP[1..10] PP[1..10] PENABLE[1..10]
• PSUB[1..10] PCODESIZE[1..8] NUMSRCCONN[1..8]
You do not need to associate the PENABLE[1..10] parameter with the corresponding input (p[1..10]) explicitly
in an expression.
• For example: MIN(CM.ENHAUXCALCA.P[1],value2,value3)
• TagName.'text'
will understand. If this text is incorrect runtime errors will occur.
For example, OPCTag.'tag.Param(1)' can be used so that the parenthesis characters do not confuse the
expression parser.
Attention
When the expression is sent to the external reference component, the delimiters are removed: TagName.'text' becomes
TagName.text.
23.6.7 Guidelines for Writing Expressions-ENHAUXCALC block

• Must include full tag.parameter name for P inputs in the expression and enclose identification number in
brackets instead of parenthesizes. For example, CM151.AUXCALC BLOCK.P[1] * CM151.AUXCALC
BLOCK.P[2] is valid.
Tip
Attention
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
Attention
23.6.8 Enable/Disable switch example expression-ENHAUXCALC block

The Enable/Disable switch is used as a flag in the following user expressions.
MIN((CM.ENHAUXCALCA.PENABLE[10] = 1) ? CM.ENHAUXCALCA.P[10]:<user-entered
value> ,value2,value3).
CM.ENHAUXCALCA.P[1]<CM.ENHAUXCALCA.P[2] and say P[1] is disabled then the CEE will evaluate
the expression as CM.ENHAUXCALCA.PSUB[1]<CM.ENHAUXCALCA.P[2]. In this case, if an input is
disabled, the corresponding substitute value is used in the expressions.
23.6.9 Scaled Input example expression-ENHAUXCALC block

The following are examples of expressions using the scaled input parameter (PX).
1
PP[1]*2+P[2]
Here
If PENABLE[1] = 0, C[1] = (PSUB[1]*CP[1])*2+PSUB[2]
Else C[1] = (P [1]*CP [1])*2+P [2]
2
MIN(PP[10],P[2],C[1])
735
3
(PP[7] <> 12)? 10 : PP[7]
4
SQRT(PP[5])
23.6.10 Assignable Outputs-ENHAUXCALC block

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.
23.6.11 ENHAUXCALC parameters

ENHAUXCALC block.
23.7 ENHGENLIN (Enhanced General Linearization) Block

The ENHGENLIN block calculates a linearized output PV value (in engineering units) based on configured
linear coefficients for a sensor having nonlinear characteristics. The linearized output PV value is calculated as
a function of an input value (P1) and ACTLINSEG parameter value. The function is typically represented by a
maximum of 12 continuous, linear segments defined with 13 monotonic value pairs. The ENHGENLIN block is
supported on the following platforms.
• C300 (20 ms CEE and 50 ms CEE)
• C200E
• ACE
• SIM C200E
• SIM C300
The ENHGENLIN block is graphically represented in the Control Module as follows:
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.
i = represents the linearization segment table number determined by ACTLINSEG.
j = represents the co-ordinate number. The “j” value is determined by the P1 value.
n = represents the number of segment in the active curve. The “n” value is determined by NUMSEGS [ACTLINSEG].
737
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.
23.7.1 Function-ENHGENLIN block

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.
Attention
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.
23.7.2 Configuration Parameters-ENHGENLIN block

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.

Number of Tables NUMLINSEG Let you select the maximum number of allowed
linearization segment tables. Maximum four
linearization segment tables are supported.
Active Linearization Segment ACTLINSEG Lets you assign the linearization segment table based
Table on the number of segment tables for PV calculation.
Number of Segments NUMSEGS[INDEX1] Lets you select the number of segments for the
linearization segment table.
View Table VIEWLINSEG Lets you to select the linearization segment table
represented by IN, OUT, TEMPIN, and TEMPOUT for
engineering view in Control Builder.
Input Co ordinate IN [INDEX1] [INDEX2] Lets you to type the input values for the linearization
segment table.
Output Co ordinate OUT [INDEX1] [INDEX2] Lets you to type the output values for the linearization
segment table.
23.7.3 Configuration Example-ENHGENLIN block

The following figure displays a sample configuration using an ENHGENLIN block that fetches an input value
(P1) from a NUMERIC block and an ACTLISEG value from the user to calculate an output value (PV).
The output of the ENHGENLIN block is connected to SVP Regulatory Control block (SVP_REGCTL block)
executed in the Servo Valve Positioner (SVP) IOM.
739
23.7.4 Input-ENHGENLIN block

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.
Attention
The output of the C300 20ms PID block can be connected as an input (P1) to the ENHGENLIN block instead of the
NUMERIC block used in this example.
23.7.5 Output-ENHGENLIN block

• PV.
• Boolean flag (PVSTSFL.BAD) set by PV to indicate to other function blocks, that this block's PV status is
bad.
23.7.6 Error Handling-ENHGENLIN block

• 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.
23.7.7 Strategy Optimization using ENHGENLIN block

A single ENHGENLIN block can replace up to four GENLIN blocks. This results in optimization of the project
engineering and modification of enhgenlin parameters from Monitoring View.
Following is an example of a Governor Valve Sequencing operation where a single ENHGENLIN block
replaces three GENLIN block and two SELReal blocks.
The logic explained in the figure is replaced using a single ENHGENLIN block.
23.7.8 ENHGENLIN block - Usage Scenario

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.
741
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)
Full Arc mode of governing

All the Governor Valves operate simultaneously with the same percentage of opening with respect to the
percentage of the load. The following graph displays the six Governor Valves operation with respect to the load
percentage.
The relation between the load percentage and the Governor Valves opening is gradually increases and it is listed
in the following table.
GVI - SING - DMD

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
GVI - SING - DMD

101 101
Partial Arc mode of governing

The Governor Valves open in a sequence defined by the manufacturer. There are three different Governor
Valves opening sequence.
Sequence Number Governor Valves (GV) Opening Sequence

Sequence 1 (SEQ1) GV 3, 5 and 6 open together then, GV4, GV1, and GV2 open in sequence.
The sequences and the related operation of the Governor Valves operation with respect to the load are explained
in the following table.
Sequence Number Description

SEQ 1 First, the Governor Valves 3, 5, and 6 operation starts in the initial load, then the
Governor Valves 4, 1, and 2 operation starts sequentially in order as the load
increases. The following graph displays, when the load is 60 percentage:
• Governor Valves 3, 5, and 6 are fully opened
• GV4 is opened 25 % (approx)
• GV1 is opened 8% (approx.)
• GV2 is opened 0%
743
Sequence Number Description
The co-ordinates for the Governor Valves for each sequence are explained in the following table.
For Governor Valves 1:
Governor Valve 1 (GV1)

SEQ1 SEQ2 SEQ3
X - COR Y - COR X - COR Y - COR Y - COR X - COR
-1 -1 -1 -1 -1 -1
52 -1 36 0 70 0

SEQ1 SEQ2 SEQ3
X - COR Y - COR X - COR Y - COR Y - COR X - COR
63.67 12.55 47 12.56 81 12.55
68.67 17.6 52 17.6 84.83 17.6
73.67 26.5 57 26.5 89.83 26.5
76.77 32.43 60.1 32.43 92.93 32.43
78.96 37.83 62.29 37.83 95.12 37.83
80.99 46.36 64.32 46.36 97.15 46.36
82 54.21 65.335 54.21 98.17 54.21
82.57 62.9 65.9 62.9 98.73 62.9
83.23 81.57 66.56 81.57 99.39 81.57
83.34 100 66.67 100 100 101
100 101 100 101 101 101.1
For Governor Valve 2:

SEQ1 SEQ2 SEQ3
X - COR Y - COR X - COR Y - COR X - COR Y - COR
-1 -1 -1 -1 -1 -1
70 -1 52 0 36 0
81 12.55 63.67 12.55 47 12.56
84.83 17.6 68.67 17.6 52 17.6
89.83 26.5 73.67 26.5 57 26.5
92.93 32.43 76.77 32.43 60.1 32.43
95.12 37.83 78.96 37.83 62.29 37.83
97.15 46.36 80.99 46.36 64.32 46.36
98.17 54.21 82 54.21 65.335 54.21
98.73 62.9 82.57 62.9 65.9 62.9
99.39 81.57 83.23 81.57 66.56 81.57
100 101 83.34 100 66.67 100
101 101.1 100 101 100 101
For Governor Valve 4:

SEQ1 SEQ2 SEQ3
-1 -1 -1 -1 -1 -1
36 -1 70 0 52 0
47 12.56 81 12.55 63.67 12.55
52 17.6 84.83 17.6 68.67 17.6
745

SEQ1 SEQ2 SEQ3
57 26.5 89.83 26.5 73.67 26.5
60.1 32.43 92.93 32.43 76.77 32.43
62.29 37.83 95.12 37.83 78.96 37.83
64.32 46.36 97.15 46.36 80.99 46.36
65.335 54.21 98.17 54.21 82 54.21
65.9 62.9 98.73 62.9 82.57 62.9
66.56 81.57 99.39 81.57 83.23 81.57
66.67 100 100 101 83.34 100
100 101 101 101.1 100 101
For Governor Valves 3, 5, and 6:

The Governor Valve 3, 5 and 6 operations with the different sequence represent same Valve opening percentage
at the different load percentage.
Governor Valve 3, 5, and 6 (GV 3, 5, and 6)

X - COR Y - COR
-1 -1
0 -1
8.9 12.55
17.825 17.6
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
23.7.9 ENHGENLIN parameters

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 C200E and C300 (20ms CEE and 50ms CEE) controllers, and
ACE controllers. The ENHGENLIN block is not supported in the C200 controller.
23.8 FLOWCOMP (Flow Compensation) Block

The FLOWCOMP (Flow Compensation) block operates on uncompensated flow measurements of liquids,
steam, gases or vapors. It computes a flow compensation factor based on variations in parameters like
temperature, pressure, specific gravity, and molecular weight. The block derives a compensated flow value as its
output. It looks like this graphically.
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.
23.8.1 Function-FLOWCOMP block

The FLOWCOMP block uses the following basic equation to calculate a compensated flow value as its output.
Compensated flow = (uncompensated flow)* COMPTERM
Where:
uncompenated flow = An input
COMPTERM = A calculated compensation term
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.
747
23.8.2 Configuration parameters-FLOWCOMP block

The following table provides a summary of the FLOWCOMP specific parameters that you can configure

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 Factor for CPV Lets you define the overall scaling factor to be applied to the
PV PV value to meet your process requirements. The default
value is 1.
Flow Compensation Factor CF1 Lets you define a compensation factor to use for converting
1 units of measurement for the uncompensated flow to units for
the compensated flow, or correcting for assumed design
conditions The default value is 1.
Flow Compensation Factor CF2 Lets you define a compensation factor to use for converting
2 units of measurement for the uncompensated flow to units for
the compensated flow, or correcting for assumed design
conditions The default value is 1.
Compensation Term High COMPHILM Lets you define a high limit for the flow compensation term
Limit The default value is 1.25.
Compensation Term Low COMPLOLM Lets you define a low limit for the flow compensation term
Limit 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).
PV Characterization Option PVCHAR Lets you specify square root as the PV characterization to use.
The default value is SQUAREROOT.
Bad Comp Term Alarm BADCOMPTERM.PR Lets you specify the priority level for a bad COMPTERM
Priority alarm. The default value is LOW.
Bad Comp Term Alarm BADCOMPTERM.SV Lets you specify the severity level for a bad COMPTERM
Severity 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 Pressure P0 Lets you specify the zero pressure reference value for
equations that require it. The default value is 0.
Zero Ref. for Temperature T0 Lets you specify the zero temperature reference value for
Specific Gravity RG Lets you specify the specific gravity reference value for
Pressure RP Lets you specify the absolute pressure reference value for
Steam Quality RQ Lets you specify the steam quality reference value for
Temperature RT Lets you specify the temperature reference value for equations
that require it. The default value is 1.

Steam Compressibility RX Lets you specify the steam compressibility reference value for
Reference Molecular RMW Lets you specify the molecular weight reference value for
Weight equations that require it. The default value is 1.
23.8.3 Input-FLOWCOMP block

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.
If PVEQN is . . . Then, It Requires These Inputs . . . And, It Is Used For . . .

Equation A (EQA) uncompensated flow (F) and mass-flow or volumetric-flow
compensation of liquids.
specific gravity (G).
Equation B (EQB) uncompensated flow (F), mass-flow compensation of gases or
vapors
pressure (P), and
temperature (T).
Equation C (EQC) uncompensated flow (F), mass-flow compensation of gases or
vapors.
pressure (P),
temperature (T), and
specific gravity (G).
Equation D (EQD) uncompensated flow (F), volumetric-flow compensation of a gas
or vapor.
pressure (P),
temperature (T), and
molecular weight (MW).
Equation E (EQE) uncompensated flow (F), mass-flow compensation of steam.
pressure (P),
temperature (T),
steam quality factor (Q), and
steam compressibility (X).
If you need characterization or alarming on individual inputs to the FLOWCOMP block, provide the inputs
through a DATAACQ block.
If you want alarming for the compensated flow output, send the output to a DATAACQ block.
23.8.4 Output-FLOWCOMP block

You can configure the COMPTERM parameter as an output pin on the FLOWCOMP block for connection to
another block.
23.8.5 Equations-FLOWCOMP block

The FLOWCOMP block uses the following basic equation.
PV = CPV *CF1 / CF2 *F *COMPTERM
749
Where:
CPV = Overall scale factor for PV
CF1 = Compensation factor
CF2 = Compensation factor
F = Uncompensated flow input
COMPT = A calculated flow compensation term
ERM
• The PVCHAR parameter is the COMPTERM Characterization option. Default value is SQUAREROOT.
Valid options are SQUAREROOT and NONE.
• If COMPTERM is greater than COMPHILM then COMPTERM is clamped to COMPHILM.
• If COMPTERM is less than COMPLOLM then COMPTERM is clamped to COMPLOLM.
• The COMPTERM is calculated differently for each equation as noted in the following sections.
Equation A
Used for mass-flow or volumetric flow compensation of liquids.
• If PVCHAR = SQUAREROOT, then:
•
• Else: If PVCHAR = NONE, then:

•
See “REMCAS (Remote Cascade) Block” below.
23.8.6 Additional considerations for FLOWCOMP Equation A

Consider the following when converting uncompensated, standard volumetric-flow to compensated, standard
volumetric-flow.
• If the variation in density caused by fluid-composition changes is not significant, then:
– G = Gravity of the actual fluid at flowing conditions
– RG = Gravity at flowing conditions used in design basis
• If the variations in density caused by fluid-composition changes are significant, C1 and C2 of the
FLOWCOMP should be manipulated as follows:
– C1 is set to the Gravity at reference conditions used in the design basis.
– If the measured value of specific gravity at flow conditions is available, the actual specific gravity,
referenced to standard conditions, is calculated from that measurement by another function block (using
the flowing temperature and expansion formulas) this is pulled by the FLOWCOMP block into the C2
pin.
– If actual specific gravity is measured by a lab, a numeric block could be used to hold the value and can
be pulled by the FLOWCOMP block into the C2 pin. In this case, another function block may use the lab
value and flowing temperature to calculate specific gravity at flowing conditions and the result is used as
the G input.
• For these cases:
– G = Gravity of the actual fluid at flowing conditions
– RG = Gravity at flowing conditions used in design basis
– C1 = Gravity at reference conditions used in design basis
– C2 = Gravity of the actual fluid at reference conditions
Equation B
Used primarily for mass-flow compensation of gases and vapors.
•

•
Equation C
Used for mass-flow compensation of gases and vapors.
•

•
Equation C
Used typically for volumetric-flow compensation of gases and vapors.
•

•
Equation E
Used for mass-flow compensation of steam.
•

•
751
Symbol definitions
Where:
G = Specific gravity
MW = Molecular weight
P = Pressure (input)
T = Temperature (input)
Q = Steam quality (input)
X = Steam compressibility (input)
RG = Reference specific gravity (configured)
RP = Reference pressure (configured)
RT = Reference temperature (configured)
RQ = Reference steam quality (configured)
RX = Reference steam compressibility (configured)
RMW = Reference molecular weight (configured)
P0 = Zero pressure reference (configured)
T0 = Zero temperature reference (configured)
23.8.7 Error handling-FLOWCOMP block

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), an error message displaying that “All required Inputs Not Connected” appears while activating the
Control Module.
23.8.8 Alarm behavior-FLOWCOMP block

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
– Increment Cycle count
• Else, if after MAXCYCLE cycles or if MAXCYCLE equals 0, then:
– Trigger a BAD COMPTERM alarm
– Set COMPTERM to NaN, PVSTS to BAD and PV to 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.
MAXCYCLE can take three possible values::
• NaN - In this case:
– COMPTERM will freeze to its last good value
– COMPTERM will never go to bad
– PV status will be set to UNCERTAIN
• 0 - In this case:
– If the COMPTERM is BAD, BAD COMPTERM alarm is raised right away, PV status will
be set to UNCERTAIN.
• Greater than 0 - In this case
– COMPTERM will be frozen at its last good values till the MAXCYCLE cycles.
– After MAXCYCLE cycles, set COMPTERM to NaN, PVSTS to BAD and PV to NaN.
Cycle Is the number of cycles elapsed after freezing the COMPTERM.
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.
23.8.9 Alarm example-FLOWCOMP block

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.
If the G input to the FLOWCOMP block is connected to PV of the Analog Input Channel (AIC) block in a
C200/C200E Controller and. the PV of the AIC goes BAD, then the G input to the FLOWCOMP block will also
go bad leading to a BADCOMPTERM alarm after MAXCYCLE cycles.
23.8.10 Fail-Safe values-FLOWCOMP block

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
23.8.11 FLOWCOMP parameters

FLOWCOMP block.
753
23.9 GENLIN (General Linearization) Block

The GENLIN (General Linearization) block calculates an output value (PV) as a function of the input value
(P1) based on a separate function that can be represented by 2 to 13 user-defined coordinates. (You specify the
IN and OUT values of each coordinate to make a segment.) The input value (P1) is then compared with the
input range of each segment and the output is set at the intersection of the input with the appropriate segment.
The GENLIN block looks like this graphically:
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]):
•
• If P1 intersects the last segment (that is, P1 > IN[i] for i = NUMSEGS - 1)):
•
• If P1 intersects any other segment (that is, IN[i] < P1 < IN[i + 1] for i =1 to NUMSEGS -2):
•
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.
• The segment coordinate values (IN[i]) must be specified in ascending order, from smallest to largest value.
23.9.1 Function-GENLIN block

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.
23.9.2 Inputs
The GENLIN block requires one input value (P1):
• P1 must be brought from another function block.
• P1STS represents the status of P1.
23.9.3 Outputs-GENLIN block

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.
23.9.4 Error handling-GENLIN block

• 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).
23.9.5 GENLIN parameters

Refer to the Control Builder Components Reference for a complete list of the parameters used with the GENLIN
block.
755
23.10 LEADLAG Block

The LEADLAG block provides dynamic lead-lag compensation for changes in its input (P1). It subjects a
change in the input value (P1) to one lead compensation and two lag compensation factors.
There is a user configurable time constant for each compensation factor. You can suppress a compensation
factor by setting its corresponding time constant to zero (0).
The block looks like this graphically:
Each LEADLAG block supports the following user configurable attributes. The following table lists the given

• PV Format (PVFORMAT) - Lets you select the decimal format to be used to
display the PV 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.
information.
• Lead Time (min) (LEADTIME) - Lets you specify the lead time constant in
minutes. The default value is 0, which means the lead time compensation is
suppressed. .
• Lag 1 Time (min) (LAG1TIME) - Lets you specify the first order lag time
constant in minutes. The default value is 0, which means the first order lag time
compensation is suppressed.
• Lag 2 Time (min) (LAG2TIME) - Lets you specify the second order lag time
constant in minutes. The default value is 0, which means the second order lag
time compensation is suppressed.
• Overall Scale Factor (CPV) - Lets you specify the overall-scaling factor for the
PV output. The default value is 1.
• Overall Bias (DPV) - Lets you specify an overall bias for the PV output. The
default value is zero (0).
faceplate.
23.10.1 Function-LEADLAG block

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.
23.10.2 Input-LEADLAG block

The block requires one input. P1 must be brought from another block.
23.10.3 Output-LEADLAG block

The block produces an output value (PV), a status (PVSTS), and a status flag (PVSTSFL).
757
23.10.4 PV status-LEADLAG block

• Bad - which means that PV is NaN (Not a Number)
• 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.
23.10.5 Error handling-LEADLAG block

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.
23.10.6 Equation-LEADLAG block

The LEADLAG block applies the following equation.
PV = L-1 [CPV * (1 + LEADTIME * s) / {(1 +LAG1TIME * s) * (1 + LAG2TIME * s)} * P1(s)]

+DPV
Where:
CPV = Overall scale factor for PV
DPV = Overall bias for PV
L-1 Inverse of the LaPlace transform
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.)
LEADTIME = Lead time constant (If 0, no lead time.)
P1 = Input value to which lead and lag compensation is applied
PV = Output of this block
s = LaPlace operator notation only (not a parameter)
23.10.7 Time constant recommendations-LEADLAG block

The execution rate of the LEADLAG block should be greater than the lowest break-point period of the block as
follows.
• The first order lag time (LAG1TIME) should be greater than or equal to 2 * TS. Where TS is the sample
time in minutes.
• The second order lag time (LAG2TIME) should be greater than or equal to 2 * TS.
• The absolute lead time (|LEADTIME|) should be greater than or equal to 2 * TS. (Note that the absolute
value of lead time is used, since both positive and negative lead times can be specified.)
23.10.8 Restart condition-LEADLAG block

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.
23.10.9 LEADLAG parameters

LEADLAG block.
759
23.11 ROC (Rate of Change) Block

The Rate of Change (ROC) function block, available under the Auxiliary function block library, is a
computational block intended for use on the input side of function blocks for limiting the input variable to the
block (typically SP). This block is especially useful in case where it is desirable to prevent a random change in
the output sequence. In power plants, for instance, speed control of HT motors requires control without
exceeding the rate of change of current. The following is an illustration of an ROC function block:
Attention
The ROC block can only be used with C300, C200E, and ACE Controllers.
BADPV alarms.
• BADPVALM.TM
• BADPVALM.TMO
The Rate of Change block supports the following user configurable attributes. The following table lists the
with that tab.

between 1 to 32767. The default value is 10.
• Low Range in EUs - Lets you specify the low input range value in engineering
units that represents the 0 full scale PV input for the block. The default value is 0
(zero).
• High Range in EUs - Lets you specify the high input range value in engineering
units that represents 100% full scale PV input for the block. The default value is
100.
• Positive ROC Limit (EUs/min) - Lets you specify a maximum output rate of
change limit for the positive direction of the output in percent per minute. This
lets you prevent an excessive rate of change in the output allowing you to match
the slew rate of the control element to the control dynamics. We recommend that
you configure this value before you tune the loop, so tuning can accommodate
any slowdown in response time caused by this rate limiting. The default value is
Not a Number (NaN), which means no rate limiting is applied.
• Negative ROC Limit (EUs/min) - Lets you specify a maximum output rate of
change limit for the negative direction of the output in percent per minute. This
lets you prevent an excessive rate of change in the output allowing you to match
the slew rate of the control element to the control dynamics. We recommend that
you configure this value before you tune the loop, to enable tuning to
accommodate any slowdown in response time caused by this rate limiting. The
default value is Not a Number (NaN), which means no rate limiting is applied.
• Deadband Time (BADPVALM.TM) -
With R410, thisparameter is introduced to define the duration in seconds during
You can configure individual deadband time for BADPVALM. However, if you
are migrating from pre-R410 to later releases, refer to “Impact of migration on
alarm attributes”
• Off-delay Time (BADPVALM.TMO) - With R410, thisparameter is introduced
to define the duration in seconds during which an RTN reporting is suppressed
even though the alarm condition does not exist. The RTN is reported on the
Station only after this time expires and the alarm condition has returned to
Configuration Parameters Lets you select the available parameters that appear on the face of the function block
in the Project tab in Control Builder.
761

faceplate.
23.11.1 Function-ROC block

• 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.
• The use of an ROC block is not recommended in case the OP of a PID block is connected to the P1 of an ROC
block and the output is transmitted through PV to the SP of a secondary PID in cascade. In such a case, if the
secondary PID is back INITIALIZED, the INITREQ is not propagated to the Primary PID because the ROC block
is connected between them. The ROC block does not have back initialization capability.
• The ROC block is sensitive to noise. Connecting input filters such as LeadLag or DataAcq block to the ROC block
is highly recommended. The input filter helps in smoothening the signal by reducing/eliminating noise, if any.
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.
23.11.2 Configuration examples-ROC block

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
763
PVROCNEGLM = 60
PVEULO = 0
PVEUHI = 100
23.11.3 Inputs-ROC block

• P1 - Process Input 1.
• PVROCPOSLM - PV Rate of Change limit in the positive direction.
• PVROCNEGLM - PV Rate of Change limit in the negative direction.
23.11.4 Outputs-ROC block

• 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.
23.11.5 Error handling-ROC block

• 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.
• If P1 is set to NaN, then, PV is set to NaN and BADPVFL is set to TRUE.
• If negative limit is greater than the span in EUs/min or less than 0 %, then “LimitOrRangeCrossover” Error
is reported.
• If PVEULO has a value NaN, then “InvalidValue” Error is reported.
• If PVEULO is greater than PVEUHI, then “LimitOrRangeCrossover” Error is reported.
• If new PVEULO causes the positive/negative trip limits to go beyond the range of 0 - Span in EUs/min, then
“LimitOrRangeCrossover” error is reported.
• If PVEUHI is NaN, then “InvalidValue” error is reported.
• If PVEUHI is lesser than PVEULO, a “LimitOrRangeCrossover” error is reported.
• If new PVEUHI causes the positive/negative trip limits to go beyond the range of 0 - Span in EUs/min, then
“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.
23.11.6 ROC parameters

Refer to the Control Builder Components Reference for a complete list of the parameters used with the Rate of
Change block.
23.12 SIGNALSEL (Signal Selector) Block

The Signal Selector function block accepts as many as six input signals, and may be configured to do one of the
following on these inputs:
• Select the input with the minimum value.
• Select the input with the maximum value.
• Select the median input.
• Calculate the average of the inputs.
• Select an input based on the Multiplex value; i.e., act as a multiplexer.
R410For example, you can use the following parameters to configure the on-delay time, off-delay time,
deadband values, and deadband units for DEVALM parameter.
• DEVALM.TM
• DEVALM.TMO
• DEVALM.DB
• DEVALM.DBU
23.12.1 Function-SIGNALSEL block

This function block supports the following methods for selecting an input:
765
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.
MED Select the median input. Ignored inputs are excluded.
AVG Calculate the average of the inputs. Ignored inputs are excluded.
MUX Select an input based on the Multiplex value; i.e., act as a multiplexer. Inputs are not ignored.
23.12.2 Configuration parameters-SIGNALSEL block

The following table provides a summary of the SIGNALSEL specific parameters that you can configure
through the block's properties form in Control Builder.

Main • Name - Block (Tag) name of up to 16 characters long. Must be unique within
the CM block containing it.
characters to identify the variable values associated with this block. For
example, you could specify DEGF for temperature values in degrees
Fahrenheit. This name is used on any associated displays and generated
reports.
• Execution Order in CM (ORDERINCM) - Specifies the execution order of
the block in the CM relative to other blocks contained in this CM. Enter as a
number between 1 to 32767. The default value is 10. Refer to the Function
Block Execution Schedules section in the beginning of this document for
more information.
• PVEU Range High (PVEUHI) - Lets you specify the high input range value
in engineering units that represents 100% full scale PV input for the block.
• PVEU Range Low (PVEULO) - Lets you specify the low input range value
in engineering units that represents the 0 full scale PV input for the block.
The default value is 0 (zero).
• Positive ROC Limit (EUs/min) (PVROCPOSLM) - Lets you specify a
maximum output rate of change limit for the positive direction of the output
in percent per minute. This lets you prevent an excessive rate of change in the
output allowing you to match the slew rate of the control element to the
control dynamics. We recommend that you configure this value before you
tune the loop, so tuning can accommodate any slowdown in response time
caused by this rate limiting. The default value is Not a Number (NaN), which
means no rate limiting is applied.
• Negative ROC Limit (EUs/min) (PVROCNEGLM) - Lets you specify a
maximum output rate of change limit for the negative direction of the output
in percent per minute. This lets you prevent an excessive rate of change in the
output allowing you to match the slew rate of the control element to the
control dynamics. We recommend that you configure this value before you
tune the loop, to enable tuning to accommodate any slowdown in response
time caused by this rate limiting. The default value is Not a Number (NaN),
which means no rate limiting is applied.

Input • 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.
• Ignore Highest Inputs (IGNORHI) - Lets you select the number of highest
inputs to be ignored.
• Ignore Lowest Inputs (IGNORLO) - Lets you select the number of lowest
inputs to be ignored.
• Ignore Limit (IGNORLM) - Lets you set the maximum allowable range
between the lowest and highest input.
• 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 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.
needs to be added to or subtracted from trip point before reporting an RTN.
By specifying a deadband value, you can prevent nuisance alarms due to
noise at values near the trip point. The default value is 0. For a high alarm,
RTN is reported only when the OP value is less than trip point - deadband
value. For a low alarm, RTN is reported only when the OP value is more than
trip point + deadband value.
Prior to R410, once the deadband value was configured, this value was
loaded to the individual alarm parameters (for example, DEVALM.DB) when
the CM was loaded. If you configured the individual alarm parameters as
Monitoring Parameters for the block, you could change the individual alarm
value while monitoring the loaded block in CB.
With R410, deadband value can be individually configured for each alarm.
For example, you can configure DEVALM.DB as 5. However, if you are
migrating from pre-R410 to later releases, refer to “Impact of migration on
• Deadband Time (xxxxALM.TM) - Defines the duration in seconds during
which a process alarm reporting is suppressed. This helps in preventing
nuisance alarms from being reported repeatedly during process upset and
alarm, the alarm is reported on the Station only if the alarm condition
continues to exist even after this value expires. The default time is 0; that is
the alarm is reported as soon as the alarm condition occurs.
parameters (for example, DEVALM.TM) when the CM was loaded. If you
configured the individual alarm parameters as Monitoring parameters for the
block, you could change the individual alarm value while monitoring the
loaded block in CB.
With R410, deadband time can be individually configured for each alarm. For
example, you can configure DEVALM.TM as 5 seconds. However, if you are
parameters (for example, DEVALM.DBU) when the CM was loaded. If you
configured the individual alarm parameters as Monitoring parameters for the
767

block, you could change the individual alarm value while monitoring the
loaded block in CB.
With R410, deadband unit can be individually configured for each alarm. For
example, you can configure DEVALM.DBU as percent. However, if you are
which an RTN reporting is suppressed even though the alarm condition does
not exist. The RTN is reported on the Station only after this time expires and
the alarm condition has returned to normal. The default time is 0; that is RTN
is reported as soon as the alarm condition returns to normal. If a deadband
value is also configured, the RTN is reported only when the OP value is less
than trip point - deadband for the configured Off-delay time. However, if you
are migrating from pre-R410 to later releases, the alarm off-delay time will be
set as default value (0).
• Forced Select Permissive (FRCPERM) - Lets you allow the operator to force
select an input.
• Forced Select (FRCSEL) - Lets you override the selected input.
• Forced Request (FRCREQ)
Identification Lets you view information pertinent to the qualification and version control
system and enter block comments, if desired.
Block Pins Lets you select the available parameters that you want to expose as input/output
Configuration Parameters Lets you select the available parameters that appear on the face of the function
block in the Project tab in Control Builder.
Block Preferences Lets you change several block-viewing preferences including the color of the
block's faceplate.
23.12.3 Configuration examples-SIGNALSEL block
Example 1: Selection method is MED

A strategy configured for a SIGNALSEL block with four inputs configured to find the median value of the valid
inputs would function as follows:
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 the 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.
769
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, i.e.) 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.
Selection method is MUX

If the block is configured with Selection Method MUX, then NMIN, Ignore Inputs would not be applicable and
cannot be edited. CURPINPT would be equal to NUMPINPT. Also, bad inputs could be selected. Now the
block would function as follows:
If the block is configured with Selection Method = MUX and BOOLMUX= On, it would function as follows.
771
23.12.4 Input-SIGNALSEL block

• 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..
23.12.5 Ignore Inputs-SIGNALSEL block

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.
23.12.6 Ignore Limit Checking-SIGNALSEL block

Ignore Limit is the maximum allowable range between the lowest and highest input. Inputs that are outside this
range (IGNORLM) for more than a specified time(IGNORTM) are ignored.
The SIGNALSEL block performs ignore limit checking as follows:
• It ignores Bad inputs (NaN), and the highest and lowest inputs (defined by IGNORHI and IGNORLO).
• If there are no remaining inputs, ignore limit checking is not done for the block.
• It calculates a “center value” from the inputs that remain:
– If the number of remaining inputs is odd, the “center value” = the median input.
– If the remaining inputs is even, “center value” = the average of the middle two inputs.
• It calculates a high and low ignore limit from specified limit (IGNORLM):
– High ignore limit = “center value” + IGNORLM / 2
– Low ignore limit = “center value” - IGNORLM / 2
• It compares each of the remaining inputs with the high and low ignore limits.
• If an input is outside the ignore limits for more than IGNORTM (the ignore time) seconds, the function
block updates the appropriate parameters (the ignored input flags IGNORD, IGNORDFL[1…6] and the
current number of valid inputs CURPINPT). As a result, the input will be ignored in future processing (i.e.,
Input Selection).
• The center value, high and low ignore limits shall be computed every cycle of execution of the block.
• Inputs that have been ignored on exceeding ignore limits, shall become valid again when their value returns
back within the high and low 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.
23.12.7 Output-SIGNALSEL block

• 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]).
23.12.8 Selection Methods-SIGNALSEL block

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.
MED Select the median input. Ignored inputs are excluded.
773
Method Processing
AVG Calculate the average of the inputs. ignored inputs are excluded.
MUX Select an input based on the Multiplex value to act as a multiplexer. Inputs are not ignored.
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 to 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.
23.12.9 Force-Select-SIGNALSEL block

• 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.
23.12.10 Bumpless Input Switching-SIGNALSEL block

The function block may be configured to provide bumpless switching between inputs. If so configured, the
block will ramp to the new input value when any of the following occur:
• The selected input changes.
• The number of valid inputs changes.
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 would occur. Ramping can be disabled by setting ramp rate to NaN.
23.12.11 Deviation Alarming-SIGNALSEL block

• 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.
23.12.12 Deviation Alarm Deadband-SIGNALSEL block

• The SIGNALSEL block also has a deadband (DEVALM.DB) for the deviation alarm.
• The purpose of this parameter is to prevent recurring alarms and returns-to-normal due to noise.
• The deadband is applied only when the alarm return-to-normal state. Once inputs are alarmed, it must return
to a range of DEVALM.TP - DEVALM.DB, before it is considered “normal”.
Also, the alarm is triggered only when the deviation range (difference between the highest and lowest inputs)
exceeds DEVALM.TP for more than the specified time.
775
23.12.13 Deviation Alarm Deadband Units-SIGNALSEL block

• The SIGNALSEL block also has a parameter called deadband units (DEVALM.DBU) for the deviation
alarm.
• The purpose of this parameter is to specify whether the deadband given by the user is in engineering units or
in percentage of the trip point.
23.12.14 Error handling-SIGNALSEL block

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.
23.12.15 Restart or point activation-SIGNALSEL block

On a Warm restart, Cold restart or when this block is inactivated the following parameters are initialized
• PV is set to NaN.
• P(1) through P(6) values are set to NaN.
• PSTS(1) through PSTS(6) are set to BadValSts.
• CURPINPT is set to zero.
• DEVALM.FL and INALM alarming flags are set to OFF.
• 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.
23.12.16 Parameters for Checkpoint-SIGNALSEL block

The following parameters are checkpointed.
DEVALM.DB FRCREQ IGNORLO NMIN

DEVALM.TM FRCSEL IGNORTM PVRATE
DEVALM.TP IGNORHI MEDOPT SELIN
FRCPERM IGNORLM MUXSEL SELMETHOD
23.12.17 SIGNALSEL parameters

SIGNALSEL block.
777
23.13 TOTALIZER Block
23.13.1 Description
The TOTALIZER block periodically adds an input value (P1) to an accumulator value (PV). It looks like this
graphically:
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.
23.13.2 Function-TOTALIZER block

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.
23.13.3 Configuration example-TOTALIZER block

TOTALIZER block in a flow control loop for quick reference. The view in the following figure depicts a loaded
configuration in Monitoring mode.
Figure 18: Example of CB configuration using a TOTALIZER block in a flow control loop
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.
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.
779
Callout Description
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
Based on these configured Trip Point values, the corresponding accumulated deviation flag will turn ON at
the following accumulated values.
• ACCDEV.FL[1] turns ON at PV = 90
5 Be sure to configure the ORDERINCM parameters for the DATAACQ block and the AICHANNEL block
to be lower numbers than the ORDERINCM parameter for the TOTALIZER block, so the DATAACQ and
AICHANNEL blocks execute before the TOTALIZER block. This configuration avoids possible
TOTALIZER interruptions during a warm restart scenario.
23.13.4 Input-TOTALIZER block

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.
23.13.5 Outputs-TOTALIZER block

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]).
23.13.6 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 to the COMMAND parameter. Since COMMAND is a write-only parameter, its displayed value does
not reflect the last entered command.
Possible choices are:
– Start - requests the TOTALIZER to start the accumulation (change STATE to Running). The Totalizer
block must be reset using the reset pin (RESETFL) prior to counting.
– Stop - requests the TOTALIZER to stop the accumulation (change STATE to Stopped).
– Reset - requests the TOTALIZER to reset the accumulated value (PV) with a user-specified reset value
(RESETVAL). STATE will not change; if the accumulator is running, it continues from the reset value.
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 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.
– Operator - only the operator may store 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 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.
23.13.7 Accumulator target value-TOTALIZER block

Prior to starting the TOTALIZER, you may specify a target value for the accumulator (ACCTV). The
TOTALIZER block compares PV with ACCTV on each cycle and sets the target-value-reached flag
(ACCTVFL) to ON when the accumulation is complete (that is, when PV is greater than or equal to ACCTV).
23.13.8 Deviation trip points-TOTALIZER block

The TOTALIZER block provides trip points and flags to signal when the accumulated value is “getting close” to
the target value. You may specify as many as four trip points, and the TOTALIZER block sets a corresponding
flag when each trip point is reached. The flags are typically monitored by another function block that can
initiate some sort of control action (for example, changing a valve position from full open to trickle when a
TOTALIZER trip point is reached).
The trip point values (ACCDEV.TP[1-4]) are expressed as deviations from the target value. The TOTALIZER
block compares the actual deviation (ACCTV - PV) with each trip point, and sets a flag (ACCDEV.FL[1-4])
when the deviation is less than or equal to 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.
23.13.9 Equations-TOTALIZER block

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:
Equation Bad Input Handling Warm Restart Handling

A Use zero if input is bad. Continue after input turns valid
B Use last good value if input is bad. Continue after input turns valid
C Stop if the input is bad and set PV to Continue after input turns valid
NaN.
D Use zero if input is bad. Stop after a warm restart.
E Use last good value if input is bad. Stop after a warm restart.
781
Equation Bad Input Handling Warm Restart Handling

F Stop if the input is bad and set PV to Stop after a warm restart.
NaN.
The following table summarizes block actions associated with a given PVEQN handling option relative to the
accumulator state and the input status. .
If Accumulator is … And Option is … Then, block …

Running (STATE = RUNNING) and Use zero if input is bad Sets the input value (P1) to zero and sets
the input status (P1STS) is BAD PVSTS to Uncertain.
When the input status (P1STS) returns to
normal, PVSTS remains Uncertain until a Reset
command is received.
Running (STATE = RUNNING) and Use last good value if input is Sets the input value (P1) to its last good value
the input status (P1STS) is BAD bad and sets PVSTS to Uncertain
normal, PVSTS remains Uncertain until a Reset
Running (STATE = RUNNING) and Stop if the input is bad Sets the input value (P1) to NaN (Not a
the input status (P1STS) is BAD Number) and sets PVSTS to Bad.
normal, PVSTS remains Bad until the operator
restarts the accumulation.
To restart the accumulator, the operator must
estimate the accumulated value, issue a Reset
command to establish that value, and then issue
a Start command. The last accumulated value
before the status went bad is designated as
LASTGOOD.
Running (STATE = RUNNING) Continue after a warm restart Sets PVSTS to Uncertain and continues
accumulation from last value of PV.
PVSTS remains Uncertain until a Reset
Running (STATE = RUNNING) Stop after a warm restart Sets the accumulated value (PV) to NaN (Not a
Number), sets PVSTS to Bad, and stops the
accumulation. The operator must intervene to
restart the accumulator.
23.13.10 Accumulated value calculation-TOTALIZER block

For equations A through F, the accumulated value (PV) is calculated as follows:
PVI = PV(i-1) + C1\ • time_scale • (P(i-1) + [Pi - P(i-1)] / 2)
Where:
PVi = TOTALIZER block output from the current pass
PV(i-1) = accumulated value at the end of block's last processing pass
C1 = scale factor for P1; used to convert to different engineering units
Pi = input value from current pass
P(i-1) = input value from last pass
time_scale = (TS*60) if TIMEBASE = seconds

(TS) if TIMEBASE = minutes
(TS / 60) if TIMEBASE = hours
whe
re
TS =
TOT
ALI
ZER
bloc
k's
proc
essi
ng
inter
val,
in
min
utes
23.13.11 Error handling-TOTALIZER block

• 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.
23.13.12 Restart and activation-TOTALIZER block

When a TOTALIZER block is activated:
• PV is set to NaN (Not a Number).
• PVSTS is set to Bad.
• The accumulator is stopped (that is, STATE = Stopped).
23.13.13 TOTALIZER parameters

TOTALIZER block.
783
24 Data Acquisition Functions
Related topics
“DATAACQ (Data Acquisition) Block” on page 786
785
24 DATA ACQUISITION FUNCTIONS
24.1 DATAACQ (Data Acquisition) Block

The DATAACQ (Data Acquisition) block processes a specified process input value (P1) into a desired output
value (PV). It looks like this graphically.
time, deadband values, and deadband units for the PVHIALM parameter.
• PVHIALM.TM
• PVHIALM.TMO
• PVHIALM.DB
• PVHIALM.DBU
BADPVALM, ROCPOSALM, and ROCNEGALM alarms.
• BADPVALM.TM
• BADPVALM.TMO
• ROCPOSALM.TM
• ROCPOSALM.TMO
• ROCNEGALM.TM
• ROCNEGALM.TMO
Each DATAACQ block supports the following user configurable attributes. The following table lists the given

information.
• PV Source Option (PVSRCOPT) - Lets you select whether you want to limit the
PV source to AUTO only or allow other PV source selections. The default
selection is ONLYAUTO.
• PV Source (PVSOURCE) - Lets you select the source of the PV as SUB for a
user program, MAN for an operator, or AUTO for process input connection.
Only applicable with PV Source Option selection of ALL. The default selection
is AUTO.
• PV Format (PVFORMAT) - Lets you select the decimal format to be used to
display the PV 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.
• PV Character (PVCHAR) - Lets you select whether or not you want to apply
Linear or Square Root PV characterization conversion to the input (P1). The
default selection is NONE, which means no characterization conversion is
applied.
• PV Limits Hi (PVEXHILM) - Lets you specify a high limit value for the PV in
engineering units. If the PV value exceeds this limit, the block clamps the PV to
the limit value and sets the PV high limit flag (PVEXHIFL). The default value is
102.9.
• PV Limits Low (PVEXLOLM) - Lets you specify a low limit value for the PV in
engineering units. If the PV value falls below this limit, the block clamps the PV
to the limit value and sets the PV low limit flag (PVEXLOFL). The default value
is -2.9.
• Low Signal Cut Off (LOCUTOFF) - - Lets you specify the low signal cutoff
limit for the P1 input after filtering and clamping. When PVAUTO is below the
limit, the block sets the PVAUTO value to the PVEULO value. Only applicable
with PV character selection of Linear or Square Root. The default value is NaN
(Not-a-Number), which means there is no cutoff limit.
• Clamping Option (P1CLAMPOPT) - Lets you specify whether or not you want
P1 to be clamped within the PV high (PVEXHILM) and low (PVEXLOLM)
limits. The default setting is DISABLE, which means no clamping is applied.
• Lag Time (P1FILTTIME) - Lets you specify a first order filter time in minutes
for the P1 input. When time is non-zero (1 to 1440 minutes), 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. See Input Filtering in this section for more details. The
default value is 0.
787

Alarms • Alarm Limits - Identifies the types of alarms this block supports. Of course,
these alarms also interact with other block configuration values such as PVEU
Range Hi and PVEU Range Lo. The types are:
– PV High High (PVHHALM.FL
– PV High (PVHIALM.FL)
– PV Low (PVLOALM.FL)
– PV Low Low (PVLLALM.FL)
– Positive Rate of Change (ROCPOSALM.FL)
– Negative Rate of Change (ROCNEGALM.FL)
– Bad PV (BADPVALM.FL)
– High Significant Change (PVHISIGCHG.TP)
– Low Significant Change (PVLOSIGCHG.TP)
– PVHHALM.TP (PV High High Alarm Trip Point)
– PVHIALM.TP (PV High Alarm Trip Point
– PVLOALM.TP (PV Low Alarm Trip Point)
– PVLLALM.TP (PV Low Low Alarm Trip Point)
– ROCPOSALM.TP (Positive Rate of Change Alarm Trip Point)
– ROCNEGALM.TP (Negative Rate of Change Alarm Trip Point)
– PVHISIGCHG.TP (High Significant Change Alarm Trip Point)
– PVLOSIGCHG.TP TP (Low Significant Change Alarm Trip Point)
(PVHHALM.PR, PVHIALM.PR, PVLOALM.PR, PVLLALM.PR,
ROCPOSALM.PR, ROCNEGALM.PR, and BADPVALM.PR). The default
display.
Summary display.
(PVHHALM.SV, PVHIALM.SV, PVLOALM.SV, PVLLALM.SV,
ROCPOSALM.SV, ROCNEGALM.SV, and BADPVALM.SV) as a number
the individual alarm parameters (for example, PVHIALM.DB and
PVLOALM.DB) when the CM was loaded. If you configured the individual
For example, you can configure PVHIALM.DB as 5 and PVLOALM.DB as 3.
of migration on alarm attributes” on page 221.

• Filter Time (ALMTM/xxxxALM.TM) -
Defines the duration in seconds during which a process alarm reporting is
suppressed. This helps in preventing the nuisance alarms from being reported
repeatedly during the process upset and improves the efficiency of the operator.
Once you configure this value for an alarm, the alarm is reported on the Station
only if the alarm condition continues to exist even after this value expires. The
default time is 0; that is the alarm is reported as soon as the alarm condition
occurs.
parameters (for example, PVHIALM.TM and PVLOALM.TM) when the CM
With R410, the filter time can be individually configured for each alarm. If the
configured filter time is more than 9999 seconds, the values are clamped. For
example, you can configure PVHIALM.TM as 5 seconds and PVLOALM.TM
as 3 seconds. However, if you are migrating from pre-R410 to later releases,
refer to “Impact of migration on alarm attributes” on page 221.
• Deadband Units (ALMDBU/xxxx.ALMDBU) - Defines the unit for the
parameters (for example, PVHIALM.DBU and PVLOALM.DBU) when the CM
With R410, the deadband unit can be individually configured for each alarm. For
example, you can configure PVHIALM.DBU as percent and PVLOALM.DBU
as EU. However, if you are migrating from pre-R410 to later releases, refer to
“Impact of migration on alarm attributes” on page 221.
default value (0).
faceplate.
insertion configuration considerations for regulatory control blocks” on page 266 for
more information
789
24.1.1 Function-DATAACQ block
C200/C200E Controller and ACE Controller without CAB insertion points

The DATAACQ block is normally configured to fetch an analog input from an AI Channel function block. As
shown in the following figure, it performs the following major functions:
• Input Processing - fetches input data from another block through process connections, checks its validity,
and updates input parameters P1 and P1STS as appropriate.
• PV Characterization - converts input parameter P1 to Engineering Units, when the user configurable PV
Characterization option is configured as Linear or Square Root. The converted P1 value is stored in a read-
only parameter (P1EU).
• Filtering and Clamping - performs filtering and clamping on the read-only parameter P1EU and stores the
result in PVAUTO. There are user configurable parameters associated with both the filtering (P1FILTTIME)
and clamping (P1CLAMPOPT) functions.
• Low Signal Cut Off - Applies a user configurable low signal cut off limit to the PVAUTO value after
filtering and clamping.
• PV Source Selection - normally copies the filtered and clamped value of PVAUTO to the output PV, but also
allows for instances where the operator or user program can store to PV, if the user configurable PV Source
selection is configured for MAN or SUB, respectively.
• Alarm Processing - generates alarm flags when PV exceeds any of a number of user-specified alarm trip
points for longer than a designated time interval.
These functions are discussed in more detail in the following paragraphs.
Table 50: DATAACQ block major functions.
ACE Controller with CAB insertion points

In systems running R210 or greater, you can insert Control Algorithm Block (CAB) programs at the following
predefined locations in a DATAACQ block that is associated with a control strategy to be run in an ACE
Controller.
Insertion Type Description

PV_Alg Replace DATAACQ PV algorithm with a custom CAB PV algorithm.
Post_PVchar Insert CAB instance after PV characterization.
Post_Clampfilt Insert CAB instance after PV clamping and filtering.
Post_PVsrc Insert CAB instance after PV source selection.
Post_Alarmproc Insert CAB instance after alarm processing.
The following illustration shows where you can insert CAB programs in relation to the DATAACQ block's
major functions. This means that you can use CAB programs to enhance aspects of the block's execution but
still take advantage of the more complex system functions such as initialization, anti-reset windup, range-
checking and alarming integral to the native block.
791
Table 51: CAB insertion locations in DATAACQ block major functions
24.1.2 CAB Insertions for DATAACQ block parameters

In R210 system or greater, the access level/lock for the following DATAACQ block parameters is now
Continuous Control (CONTCONTROL). This provides write access for CAB programs to these parameters.
This means you can modify and/or enhance other built in DATAACQ features by inserting user written CAB
programs for one or more of these parameters. The CAB programs must be configured for an access level of
Continuous Control (CONTCONTROL).
P1 Process Input Value
P1STS Status of Process Input Value
P1EU Process Input Value in Engineering Units
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)
PVEXHIFL Process Variable (PV) High Limit Flag
PVEXLOFL Process Variable (PV) Low Limit Flag
PVSTS Process Variable (PV) Status
24.1.3 CAB insertion configuration considerations

• You can insert up to 10 CAB programs in DATAACQ block.
• You must insert CAB instances in the same Control Module that contains the DATAACQ block.
• 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.
• 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-DATAACQ block” on page 794
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.
24.1.4 Insertion type functional characteristics-DATAACQ block

The following table summarizes the functional characteristics for a given insertion type.

Process Variable Algorithm (PV_Alg) Provides the capability of performing a calculation on the
fetched input value. The user-written algorithm must store
the computed value into the process input value (P1). The
configured parameter references in the CAB instance
acquire inputs for the CAB program. The value placed in P1
goes through the rest of the processing namely PV
characterization, filtering, PV source selection and alarm
processing. The user-written CAB program stores the
calculated value in P1 and must also store the status into
parameter P1STS based on the value of P1. If the calculated
value is NaN, the status is set to BAD. If calculated value is
good, the status is set to Normal The CAB program should
also handle the scenario where the input recovers from a
BAD status. Note that the value of P1STS can never be set
to Manual or Uncertain, in a simple strategy.
Post PV Characterization (Post_PVchar) Provides the capability of implementing a custom filtering
function. The filtered value is stored in P1EU. You can also
implement custom clamping and cutoff functions in a
Post_PVchar insertion program. Another option is to use the
built-in filtering value under certain process conditions by
setting the parameter P1FILITINIT to TRUE (ON) in the
CAB program.
793

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 PV Source (Post_PVsrc) Provides the capability of implementing custom PV
calculations. The CAB program can also selectively enable
or disable alarms based on process conditions.
For example, if you need to disable the PV high alarm, the
trip point for PV high alarm (PVHIALM.TP) is set to NaN
in the insertion program and the PV high alarm will not be
processed in the alarm processing routine
Post Alarm Processing (Post_Alarmproc) Provides the capability of modifying the built-in alarm
processing.
For example, selected alarms can be disabled in the next
execution cycle by setting their trip points to NaN.
24.1.5 Pin connections to inserted CAB instances-DATAACQ block

Normally, inserted CAB instances do not have outside pin connections to their custom data parameters (CDPs).
Inserted CAB instances usually share data only with their calling block, which is the block that is using the
CAB as an insertion program. In this case, block connections are created between the calling block and the
inserted CAB blocks, during the load of insertion points configuration for parameter references. The parameter
references ensure that data flow occurs in the proper sequence with respect to the execution of the calling block
and the CAB program.
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).
24.1.6 CAB Insertion status and fail alarm-DATAACQ block

When the DATAACQ block calls out the CAB instance program, the CAB instance returns an execution status
as follows.
• If the program execution runs till completion, the status will read NORMAL.
• If the program does not run till completion, it returns a non-normal status.
• If the program terminates, it returns a termination status.
When any of the insertions return a non normal status, the insertion fail flag (INSFAILFL) in the DATAACQ
block is set to TRUE (ON). The flag is reset to FALSE (OFF), when all the insertions recover and return a
normal status.
24.1.7 Handling of insertion failure-DATAACQ block

If any insertion except Post_Alarmproc returns a non -normal status, the DATAACQ block takes the following
actions.
• PVAUTO is set to NaN
• IF PVSOURCE = AUTO, the PV status is set to bad and a BADPV alarm condition is set to TRUE
• P1FILTINIT is set to TRUE. This will reset the P1 value during filtering
• Insertion fail alarm condition is set to TRUE, if the status is not a termination
• The BADPV alarm, Insertion fail alarm and any other alarms detected in the current cycle are processed
If a Post_Alarmproc insertion fails and there are no other errors, the PV is left as is and the PV status is left in
Normal state.
24.1.8 CAB insertion configuration examples-DATAACQ block
Single CAB insertion

DATAACQ block with an insertion type from a single CAB instance.
Table 52: Configuration example using single CAB insertion.
Callout Description
1 The Control Module contains a DATAACQ block named daca.
2 The daca block is configured to include an insertion type PV_Alg from a CAB instance named
CAB_1A.
3 The CAB instance named CAB_1A is added to the Control Module containing the daca block.
795
Callout Description
4 During configuration, the ORDERINCM parameter for CAB_1A is changed to match the setting of
ORDERINCM for the daca block. Also, the insertion point parameter (INSMASTER) for CAB_1A is
turned On or set to True and shows the tag name for daca block on its configuration form.
5 Once the Control Module and its components is loaded to an ACE controller and activated, the daca
block controls the execution of the CAB_1A instance as required. If the CAB_1A instance runs
this case, the CAB_1A instance returns a NORMAL status.
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.
• If PVSOURCE is configured as AUTO, PV status is set to BAD and BADPV alarm condition is set to TRUE
• P1FILTINIT is set to TRUE. This will reset the filtered P1 value in the next cycle.
• INSFAILFl parameter is set to TRUE.
• BADPV alarm is generated.
Multiple CAB insertions

DATAACQ block with insertion types from four CAB instances.
Table 53: Configuration example using multiple CAB insertions
Callout Description
2 The daca block is configured to include an insertion type PV_Alg from a CAB instance named
CAB_1A, insertion type Post_PVchar from a CAB instance named CAB_2A, insertion type
Post_PVsrc from a CAB instance named CAB_3A, and insertion type Post_Alarmproc from a CAB
instance named CAB_4A
3 The CAB instances named CAB_1A, CAB_2A, CAB_3A, and CAB 4A are added to the Control
Module containing the daca block.
4 During configuration, the ORDERINCM parameters for CAB_1A, CAB_2A, CAB_3A, and
CAB_4A are changed to match the setting of ORDERINCM for the daca block. Also, the insertion
point parameters (INSMASTER) for all four CAB instances are turned On or set to True.
block controls the execution of all CAB instances as required. If all CAB instances run successively
with no failures, the cycle is repeated during every Control Module execution cycle. In this case, all
CAB instances return a NORMAL status.
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.
CAB_1A, CAB 2A, CAB_3A Failure Scenario
797
Callout Description
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.
• P1FILTINIT is set to TRUE
• The BADPV and any other alarms detected during the current cycle is processed
CAB_4A Failure Scenario
If CAB_4A returns a non normal status, the PV value is left as is.
Two CAB insertions of same type

DATAACQ block with the same insertion type from two CAB instances.
Table 54: Configuration example using two CAB insertions of the same type
Callout Description
2 The daca block is configured to include insertion type Post_PVsrc from CAB instances named
CAB_1A and CAB_2A
3 The CAB instances named CAB_1A and CAB_2A are added to the Control Module containing the
dacablock.
Callout Description
4 During configuration, the ORDERINCM parameters for CAB_1A and CAB_2A are changed to
match the setting of ORDERINCM for the daca block. Also, the insertion point parameters
(INSMASTER) for both CAB instances are turned On or set to True.
block controls the execution of both CAB instances as required. Since the CAB instances are both
inserted at Post_PVsrc, the instances will be executed in the order in which they were configured. For
example, if CAB instance CAB_1A was added to the CM before CAB_2A, CAB_1A is executed
first. If both CAB instances run successively with no failures, the cycle is repeated during every
Control Module execution cycle. In this case, both CAB instances return a NORMAL status.
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.
• P1FILTINIT is set to TRUE. This will reset the filtered P1 value in the next cycle.
• INSFAILFl parameter is set to TRUE.
• BADPV alarm is generated.
24.1.9 Input-DATAACQ block

The DATAACQ block requires one process input value - P1. P1 must be brought from another block.
24.1.10 Input ranges and limits-DATAACQ block

PVEUHI and PVEULO define the full range of P1 in engineering units.
• PVEUHI represents the 100% of full-scale value.
• PVEULO represents the 0% of full-scale value.
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.
24.1.11 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.
799
– 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.
24.1.12 PV Characterization-DATAACQ block

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.
P1EU (P1 /100)*(PVEUHI - PVEULO) + PVEULO

where:
P1 = Process input value from another block
P1EU = P1 value in Engineering Units
PVEUHI = User configured PV high range value in Engineering Units for 100% full
scale
PVEULO = User configured PV low range value in Engineering Units for 0% full scale
100 = Span for 0 to 100 input range
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,
converts 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):
P1EU SQRT (P1 /100) * (PVEUHI - PVEULO) + PVEULO
– For P1 input less than zero (0):
P1EU - (SQRT (-P1 /100)) * (PVEUHI - PVEULO) + PVEULO
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.
24.1.13 Input filtering-DATAACQ block

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:
FilteredP1 = FilteredP1LAST + (P1 - FilteredP1LAST)* Ts / (Ts + P1FILTTIME)
where:
FilteredP1LAST = previous filtered value
Ts = elapsed time in minutes
P1FILTTIME = filter lag time in minutes
• 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.
24.1.14 Input clamping-DATAACQ block

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)
– Appropriate “limit exceeded” flag is set (PVEXHIFL or PVEXLOFL)
• If P1CLAMPOPT = Disable and the filtered P1 is outside the limits, the block sets PVAUTO to Bad. If the
filtered input is outside the PV limits:
– P1 = Actual input value
– P1STS = Normal
– PVAUTO = NaN
– PVAUTOSTS = Bad
– Appropriate “limit exceeded” flag is set (PVEXHIFL or PVEXLOFL).
24.1.15 Low signal cut off-DATAACQ block

If you configure PV Characterization as LINEAR or SQUARE ROOT, you can configure a low cut off value to
be applied to PVAUTO after filtering and clamping.
If the low cut off value is not NaN (Not-a-Number) and PVAUTO is less than the user configured low cut off
value, PVAUTO is set to the PVEULO range value.
If the low cut off value is NaN, no cut off action is applied.
If you configure the PV Characterization as NONE, the low signal cut off function is not applicable.
24.1.16 Output-DATAACQ block

The DATAACQ block produces an output value (PV) and status (PVSTS) as well as a status flag (PVSTSFL).
801
24.1.17 PV source selection-DATAACQ block

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.
– applies no filtering on operator-entered values.
• SUB (Substitution) - indicates that a user program may enter the PV and -
– sets PVSTS to uncertain
– if the program attempts to store a value that exceeds the PV limits (PVEXHILM and PVEXLOLM), the
value is clamped to the appropriate limit and the “limit exceeded” flag (PVEXHIFL and PVEXLOFL) is
set.
– applies no filtering on program-entered values.
24.1.18 PV status-DATAACQ block

• Bad - which means that PV is NaN (Not-a-Number)
• 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.
24.1.19 Alarm processing-DATAACQ block

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.
PV High alarming is enabled by setting PVHIALM.TP to a value which is not IEENaN, and disables it by
setting PVHIALM.TP = NaN.
PVHIALM.TP must be <= PVHHALM.TP.
• PV High High trip point (PVHHALM.TP) - if PV exceeds this trip point for more than PVHHALM.TM
seconds, a PV High High alarm is generated and the PV High High alarm flag (PVHHALM.FL) is set.
PV High High alarming is enabled by setting PVHHALM.TP to a value which is not IEENaN, and disabled
by setting PVHHALM.TP = NaN.
PVHHALM.TP must be <= PVEUHI.
• PV Low trip point (PVLOALM.TP) - if PV falls below this trip point for more than PVLOALM.TM
seconds, a PV Low alarm is generated and the PV Low alarm flag (PVLOALM.FL) is set.
PV Low alarming is enabled by setting PVLOALM.TP to a value which is not IEENaN, and disabled by
setting PVLOALM.TP = NaN.
PVLOALM.TP must be >= PVLLALM.TP.
• PV Low Low trip point (PVLLALM.TP) - if PV falls below this trip point for more than PVLLALM.TM
seconds, a PV Low Low alarm is generated and the PV Low Low alarm flag (PVLLALM.FL) is set.
PV Low Low alarming is enabled by setting PVLLALM.TP to a value which is not IEENaN, and disabled
by setting PVLLALM.TP = NaN.
• Positive Rate-of-Change trip point (ROCPOSALM.TP) - The rate-of-change trip point is specified by the
user as EUs per minute, and the function block converts this to EUs per 4-second period. If PV changes in a
positive direction by more than this amount for two consecutive 4-second periods, the function block will
generate a Positive Rate-of-Change alarm and set the Positive Rate-of-Change alarm flag
(ROCPOSALM.FL).
Positive Rate-of-Change alarming is enabled by setting ROCPOSALM.TP >= 0, and disabled by setting
ROCPOSALM.TP = NaN.
Attention
• The rate-of-change trip point is specified in EUs per minute.
• ROCPOSALM.TP is expressed as a positive number in EUs per minute.
• Negative Rate-of-Change trip point (ROCNEGALM.TP) - The Rate-of-Change trip point is specified by the
user in EUs per minute, and the function block converts this to EUs per 4-second period. If PV changes in a
negative direction by more than this amount for two consecutive periods, the function block will generate a
Negative Rate-of-Change alarm and set a Negative Rate-of-Change alarm flag (ROCPOSALM.FL).
Negative Rate-of-Change alarming is enabled by setting ROCNEGALM.TP >=0, and disabled by setting
ROCNEGALM.TP = NaN.
Attention
• The rate-of-change trip point is specified in EUs per minute.
• ROCNEGALM.TP is expressed as a positive number 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.
If xxxALM.TM = 0, the function block will generate an alarm as soon as PV exceeds the trip point.
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.
This parameter does not apply to Rate-of-Change alarms (i.e., there is no ROCNEGALM.DBU or
ROCPOSALM.DBU parameter). For Rate-of-Change alarms, the deadband is always expressed in EUs/
minute.
• Alarm flag (PVHIALM.FL, PVHHALM.FL, ROCNEGALM.FL, etc.) - Indicates if the corresponding alarm
condition exists.
803
• Alarm priority (PVHIALM.PR, PVHHALM.PR, ROCNEGALM.FL, etc.) - Indicates the relative priority of
the alarm.
• Alarm severity (PVHIALM.SV, PVHHALM.SV, ROCNEGALM.SV, etc.) - Indicates the relative severity of
the alarm (from 0 to 15).
24.1.20 Additional Rate of Change Alarm considerations-DATAACQ block

If Control Module Period is greater than 2 seconds (possible in ACE only), then the ROC alarm works as
follows:
• The calculation of the ROC trip point should be twice the current Period.
– If Period is 10 seconds, the ROC Alarm is checked for two consecutive 20 second Periods. If PV exceeds
ROC trip point for two consecutive 20 second Periods, a ROC Alarm is generated. The ROC is generated
after 40 seconds or four executions.
– If Period is 1 minute, the ROC Alarm is checked for two consecutive 2 minute Periods. If PV exceeds
ROC trip point for two consecutive 2 minute Periods, a ROC Alarm is generated. The ROC is generated
after 4 minutes or four executions.
24.1.21 PV significant-change alarming-DATAACQ block

If PV is between the high and high-high alarm trip points and continues to rise, the following parameters may
be used to re-annunciate the high alarm:
• PV High Significant-Change Trip Point (PVHISIGCHG.TP) - re-annunciates the high alarm when PV is
between the PV high and high-high limits (PVHIALM.TP and PVHHALM.TP) and keeps rising.
For example, consider a temperature input with PVHIALM.TP = 800 degrees, PVHHALM.TP = 850
degrees and PVHISIGCHG.TP = 10 degrees. When the temperature rises to 800 degrees, the PV high alarm
is annunciated and, if the temperature continues to rise, the alarm is re-annunciated at 810 degrees, 820
degrees, and so on.
• PV High Significant-Change Count (PVHISIGCHG.CT) - which is a count of the number of times PV has
exceeded its high significant change trip point. Other blocks and user programs may monitor it.
When PV falls below the high alarm trip point (plus 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 re-annunciate the low alarm:
• PVLOSIGCHG.TP - the PV Low Significant-Change Trip Point.
• PVLOSIGCHG.CT - the PV Low Significant-Change Count.
24.1.22 Bad PV alarm-DATAACQ block

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.
24.1.23 DATAACQ parameters

DATAACQ block.
25 Pulse Input
Related topics
“Pulse Input Block” on page 806
“PITOTALIZER Block” on page 807
805
25 PULSE INPUT
25.1 Pulse Input Block

The Pulse Input Totalizer Block provides a flow totalization function to complement a Pulse Input Channel
(PICHANNEL) or Pulse Input Counter Fast Cutoff (PICFASTCUTOFF) block.
25 PULSE INPUT
25.2 PITOTALIZER Block

The PITOTALIZER block periodically adds the change of the input value (that is, the difference in P1) to an
accumulator value (PV). It looks like this graphically:
You specify a target value for the accumulator, and up to four trip points, which are “near” and “nearer to” the
target value. The PITOTALIZER block sets status flags to indicate when the accumulator value is near (and
nearer to) the user-specified target values. Accumulation proceeds even when the target value is exceeded. An
external operator or program command is required to stop the block from further accumulating.
25.2.1 Function-PITOTALIZER block

The PITOTALIZER 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.
25.2.2 Configuration example-PITOTALIZER block

In this example, the PITOTALIZER block is used to accumulate total flow in a flow control loop.
807
25 PULSE INPUT
Note the following:

• Use the PV parameter connection to carry data and status from the PICHANNEL and DATAACQ 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 required.
• When monitoring, you can use the COMMAND parameter on the PITOTALIZER block to issue Start, Stop
or RESET commands. 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.
• When the accumulated value (P1) reaches the accumulated target value (ACCTV), the accumulated target
value flag (ACCTVFL) turns on.
• In this example, the following values were configured for 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
Based on these configured trip point values, the corresponding accumulated deviation flag turns ON at the
following accumulated values:
ACCDEV.FL[1] turns on at P1 = 90
• The DATAACQ block generates alarm flags when PV exceeds any of a number of user-specified alarm trip
points for longer than the designated time interval.
25 PULSE INPUT
25.2.3 Input-PITOTALIZER block

The PITOTALIZER block requires one input (P1):
• P1 is the value to be accumulated - the input value (P1) must be an integer value.
• P1 must be brought from another block (such as, PICHANNEL.AVRAW or PICFASTCUTOFF.AVRAW)
25.2.4 Outputs-PITOTALIZER block

The PITOTALIZER 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]).
25.2.5 PITOTALIZER states

The PITOTALIZER 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 to the COMMAND parameter. Since COMMAND is a write-only parameter, its displayed value does
not reflect the last entered command.
– Start - requests the PITOTALIZER to start the accumulation (change STATE to Running).
– Stop - requests the PITOTALIZER to stop the accumulation (change STATE to Stopped).
– Reset - requests the PITOTALIZER to reset the accumulated value (PV) with a user-specified reset value
(RESETVAL). The STATE will not change; if the accumulator is running, it continues from the reset
value.
When the PITOTALIZER 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 PITOTALIZER without losing any “accumulation”.
• CMDATTR: Specifies who may store to COMMAND (that is, either the operator or a user program).
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.
– Operator - only the operator may store to COMMAND.
– Program - only a program 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 to COMMAND.
– Off-to-On transitions cause the PITOTALIZER 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 PITOTALIZER 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 PITOTALIZER to be reset.
809
25 PULSE INPUT
25.2.6 Accumulator target value-PITOTALIZER block

Prior to starting the PITOTALIZER, you may specify a target value for the accumulator (ACCTV). The
PITOTALIZER block compares PV with ACCTV on each cycle and sets the target-value-reached flag
(ACCTVFL) to ON when the accumulation is complete (that is, when PV is greater than or equal to ACCTV).
25.2.7 Deviation trip points-PITOTALIZER block

The PITOTALIZER block provides trip points and flags to signal when the accumulated value is “getting close”
to the target value. You may specify as many as four trip points, and the PITOTALIZER block sets a
corresponding flag when each trip point is reached. The flags are typically monitored by another function block
that can initiate some sort of control action (for example, changing a valve position from full open to trickle
when a PITOTALIZER trip point is reached).
The trip point values (ACCDEV.TP[1-4]) are expressed as deviations from the target value. The PITOTALIZER
block compares the actual deviation (ACCTV - PV) with each trip point, and sets a flag (ACCDEV.FL[1-4])
when the deviation is less than or equal to a trip point. For example, if the user sets ACCTV = 50 and
ACCDEV.TP[1] = 10, the PITOTALIZER block sets ACCDEV.FL[1] to ON when PV is greater than or equal to
40.
25.2.8 Near-Zero Cutoff-PITOTALIZER block

To prevent the accumulation of negative flow values, where the flow transmitter may not be precisely calibrated
near zero flow, the user can specify a cutoff value (in EU) with parameter CUTOFF.LM. When RATE is below
CUTOFF.LM, it is replaced by zero and PV will remain constant. This feature is disabled when CUTOFF.LM is
NaN or 0.
If P1STS goes bad while RATE is less than CUTOFF.LM, the RATE is set to 0 for Bad Input Handling.
When RATE becomes greater than CUTOFF.LM, the accumulation continues.
25.2.9 Bad Input Handling and Warm-Restart Options-PITOTALIZER block

A user can configure the Bad Input Options (PVEQN) parameter to specify how the PITOTALIZER should
handle the following combinations of bad inputs and warm restarts.
Use Zero Rate if Input is Bad

If accumulator is running and P1STS goes BAD, the RATE is replaced by zero and PVSTS will become
UNCERTAIN. The block will use the Analog Operation and the resulting PV will hold.
When P1STS becomes NORMAL, accumulation will continue. The PVSTS remains UNCERTAIN until a Reset
Use Last Calculated Rate Value if Input is Bad

If accumulator is running and P1STS goes BAD, accumulation continues under the assumption of constant flow.
The analog operation algorithm is used with the last good RATE value. The PV will continue accumulating and
PVSTS will be UNCERTAIN.
When P1STS becomes NORMAL, the Pulse Input algorithm will be used again as accumulation continues. The
PVSTS remains UNCERTAIN until a Reset command is received.
Set PVSTS Bad and Stop if Input is Bad

If accumulator is running and P1STS goes BAD, the PV becomes NaN and PVSTS goes BAD.
When P1STS becomes NORMAL, the PV remains NaN and PVSTS remains BAD until a Reset command is
received.
25 PULSE INPUT
Continue After Warm Restart

On warm restart when the accumulator is running, the first execution cycle is used to prime P1. Accumulation
continues in the following cycles. This means pulses that were counted while the CEE was IDLE will NOT be
accumulated by the PITOTALIZER. The PVSTS will be set to UNCERTAIN until a Reset command is
received.
Stop after Warm Restart

On warm restart when the accumulator is running, the PV remains NaN, PVSTS remains BAD and accumulator
is stopped. The operator must intervene to restart the accumulator.
25.2.10 Bad Input Options (PVEQN) Selection Summary

The following table summarizes the bad input and warm restart combinations for a given PVEQN selection.
PVEQN Bad Input Handling Warm Restart Handling

EQA Use zero rate if input is bad Continue after a warm restart
EQB Use last calculated rate value if input is bad Continue after a warm restart
EQC Stop if the input is bad Continue after a warm restart
EQD Use zero rate if input is bad Stop after a warm restart
EQE Use last calculated rate value if input is bad Stop after a warm restart
EQF Stop if the input is bad Stop after a warm restart
25.2.11 Control Module Activation-PITOTALIZER block

When the Pulse Input Totalizer's Control Module is activated, the PV value remains NaN, PVSTS remains
BAD, and the accumulator state is Stopped. The Operator must establish Normal operation.
25.2.12 Operating Algorithms-PITOTALIZER block
Pulse Input Operation

For equations A through F, when accumulator is running, the accumulated value (PV) is calculated as follows:
PVi = PV (i - 1) + C1/C2 * ( P1(i) - P1(i - 1) )
Where:
PVi = accumulated value in EU from the current pass
PV (i-1) = accumulated value in EU at the end of block's last processing pass for the function block
C1 = dimensionless scale factor for P1; used to convert to different Engineering Units
C2 = unit normalizer in Counts per Engineering Units
P1(i) = input value from current pass in Counts
P(i-1) = input value from last pass in Counts
Analog Operation
For all equations A through F, when the P1 Input goes bad and the accumulator is running, the accumulated
value (PV) is calculated as follows:
811
25 PULSE INPUT
PVi = PV (i - 1) + (RATE * TS)
Where:
PVi = accumulated value in EU from the current pass
PV (i-1) = accumulated value in EU at the end of block's last processing pass
RATE = P1's flow rate in EU / TIMEBASE
TS = Sample Time in TIMEBASE units, hence:
• TS = CM Execution Period in sec, if TIMEBASE is seconds
• TS = CM Execution Period in sec / (60sec/min), if TIMEBASE is minutes
• TS = CM Execution Period in sec / (3600sec/hr), if TIMEBASE is hours
Rate Calculation
The RATE parameter represents the calculated P1 Input Flow Rate in EU / TIMEBASE. During Pulse Input
operation, RATE is calculated every control execution cycle. During Analog Operation, RATE is used to
calculate PV when PVEQN is B or E.
RATEi = C1/C2 * ( P1(i) - P1(i - 1) ) / TS
Where:
RATEi = P1's flow rate in EU / TIMEBASE
C1 = dimensionless scale factor for P1; used to convert to different Engineering Units
C2 = unit normalizer in Counts per Engineering Units
P1(i) = input value from current pass in Counts
P(i-1) = input value from last processing pass in Counts
TS = sample Time in TIMEBASE units, hence:
• TS = CM Execution Period in sec, if TIMEBASE is seconds
• TS = CM Execution Period in sec / (60sec/min), if TIMEBASE is minutes
• TS = CM Execution Period in sec / (3600sec/hr), if TIMEBASE is hours
25.2.13 Pulse versus Analog Operation

Pulse Input Operation will always be used unless P1STS is BAD. The P1STS goes bad whenever downstream
path is broken either by loss of connection, inactivation, and so on. The Analog Operation will be used when
P1STS is bad and transitions between the two modes will be properly handled.
25.2.14 Error handling-PITOTALIZER block

• 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 PITOTALIZER 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).
25 PULSE INPUT
– The PITOTALIZER block is in warm restart and the “stop” option is configured (Equation D, E, or F).
• When PVSTS is Bad, the PITOTALIZER 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.
CAUTION
Be aware that there can be an unexpected large value of PV when the input value (P1) jumps from a higher value
to a lower value. The chances of this behavior are rare as the PITOTALIZER block is used with the PICHANNEL.
However, if this condition exists due to some reset mechanisms, you must stop the PITOTALIZER block prior to
the jump and restart it afterwards. If you do not perform this action, the PITOTALIZER calculates the P1
difference to be extremely large and may cause an unexpected behavior.
25.2.15 Restart and activation-PITOTALIZER block

When a PITOTALIZER block is activated:
• PV is set to NaN (Not a Number).
• PVSTS is set to Bad.
• The accumulator is stopped (that is, STATE = Stopped).
25.2.16 PITOTALIZER parameters

PITOTALIZER block.
813
25 PULSE INPUT
26 Device Control
Related topics
“DEVCTL (Device Control) Block” on page 816
815
26 DEVICE CONTROL
26.1 DEVCTL (Device Control) Block

The DEVCTL (Device Control) block is a multi-input, multi-output function that provides an interface to
discrete devices, such as motors, solenoid valves, and motor-operated valves. This block provides built-in
structures for handling interlocks and supports display of the interlock conditions in group, detail and graphic
displays. It looks like this graphically.
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
26 DEVICE CONTROL

information. This is the block's parameter.
output (OP), when the block's MODE is either MANual or AUTOmatic. The
default is OPERATOR.
attribute (MODEATTR) the block is to assume, when the Control to Normal
function is initiated through the Station display. When MODEATTR is
configured as Normal, it is actually set to the present value of
NORMMODEATTR, if NORMMODEATTR is not None. Selections are NONE,
• Enable PV Source Selection (PVSRCOPT) - Lets you enable or disable PV
source selection. Check box to enable PV source (PVSOURCE) selection
through the companion scroll window. Uncheck box to limit PVSOURCE to
only AUTO. The default is enabled or box checked. When PVSRCOPT is ALL
or enabled, you can select one of the following to be the source (PVSOURCE)
of the PV (GPV) value.
– SUB - Provided by an SCM.
– MAN - Operator stores value directly.
– AUTO - Derived from the parameter PVAUTO (GPVAUTO) representing
the assigned state of the actual inputs DI[1..4].
– TRACK - Derived directly for the commanded output state (OP). Use this
online when a limit switch has failed, or as a debug mode.
• Number Of Inputs (NUMDINPUTS) - Lets you specify the number of digital
inputs to be used with the block. The default is 2.
• Number of Outputs (NUMDOUTS) - Lets you specify the number of digital
outputs to be used with block. The default is 1.
• Number of States (NUMSTATES) - Lets you define the number of settable states
as two or three. The default is 2 states.
– State Names (STATETEXT[0..6] - Lets you specify a name of up to 12
characters to be used to identify the given state. The defaults are State1for
State 1 Name (STATETEXT[5]), State0 for State 0 Name (STATETEXT[4]),
State2 for State 2 Name (STATETEXT[6]), Inbet for In Between
(STATETEXT[1]), and Bad for Null (STATETEXT[0]), respectively. State 2
name is only applicable if number of states (NUMSTATES) is three.
Inputs • Number of Digital Inputs (NUMINPTS) - Same as entry on Main tab.
• Inputs 1, 2, 3, 4 (DI[1..4]) - Shows the input combinations to be associated with
a given state. A Check in the box for the input represents its ON condition and
no Check is for its OFF position. The default State is null (BAD). State 2
selections are only applicable if number of states (NUMSTATES) is three and a
name was configured through the Main tab.
817
26 DEVICE CONTROL

Output • Outputs1,2,3 (DO[1..3] or PO[1..3]) - Lets you specify the output combinations
to be associated with the given state. Check the box for the output to associate its
ON condition with the given state (State 1, State 0, State 2) or leave it unchecked
for its OFF position. The default is OFF or unchecked. State 2 selections are
only applicable if number of states (NUMSTATES) is three.
• Safe (SAFEOP) - Lets you select the state that defines the DEVCTL block in a
safe state. The default is S0 (State 0). State 2 (S2) selection is only applicable if
number of states (NUMSTATES) is three.
• Pulse Output (POCONNECTED[1..3]) - Lets you specify whether a given pulse
output is to be enabled (ON) or not (OFF). A Check equals ON. When enabled,
the corresponding output (PO[x]) pin will be exposed on the block. The default
is no pulse outputs configured. The selectable outputs depend upon the
configured number of outputs.
• Pulsewidth (PULSEWIDTH[1..3]) - Lets you specify the width of a given output
pulse as a value between 0.000 to 60 seconds. This is only configurable when the
corresponding output is configured as a pulse output (POCONNECTED[x] =
ON). The default value is 1 second for all configured pulse outputs.
• Momentary State (MOMSTATE) - Lets you specify a given state or states
operation as being momentary. See the Momentary State section for this block
for more information. The default is NONE. No state is momentary. Note that
Safe state ( SAFEOP ) cannot be configured as Momentary state. The Seal-In
Option and Momentary State are mutually exclusive. If Momentary state is not
None, Seal-In Option will not be configurable. If Seal-In is enabled, Momentary
state will not be configurable.
• Seal-In Option (SEALOPT) - Lets you specify whether the Seal-In Option is to
be enabled or disabled. See the Seal-In Option section for this block for
information about this option. The default is an unchecked box or disabled. To
enable the Seal-In Option, the Momentary state must be None. When the Seal-In
Option is enabled, the Momentary State selection becomes void.
• Enable Output Initialization (INITOPOPT) - Lets you specify if the Output
Initialization is to be enabled or disabled. If it is enabled, OP is set to SafeOP in
initialization, if there is no active interlock, and the device is not in Local
Manual condition. If disabled, INITOPOPT will not affect initialization.
• Enable Permissive and Override Interlock Bypassing (BYPPERM) - Lets you
specify if operators are permitted to bypass the Permissive and Override
Interlocks or not. The default is Disabled (unchecked) or OFF. An operator
cannot set or reset the BYPASS parameter.
• Bypass Permissive and Override Interlocks (BYPASS) - When BYPPERM is
ON, lets you change OP regardless of the state of the Override interlocks, if
BYPASS is set ON. This does not affect the Safety Override Interlock (SI).
When you reset the BYPASS parameter to OFF, any existing Override Interlocks
(OI[0..2]) take effect immediately. The default is OFF (unchecked). Operator
cannot bypass override interlocks to change OP.
26 DEVICE CONTROL

Maintenance • Enable Accumulation of Statistics (MAINTOPT) - Lets you specify if the
collection of Maintenance Statistics for the DEVCTL block is to be enabled or
not. When enabled or box checked, you can specify the maximum number of
transitions of PV to each state (MAXTRANS[0..2]) and the maximum number
of hours of PV accumulated in each state (MAXTIME[0..2]) for comparison
purposes only. The default is OFF or box unchecked. The maintenance statistics
are not collected.
If statistics are collected, you can configure the following parameters to appear
on the DEVCTL block during monitoring. An operator can only reset statistics
while the block is red tagged, but a user program or another FB can turn ON the
RESETFL parameter to reset statistics anytime.
– NUMTRANS[0..2] - Accumulated number of transitions of PV to each state,
since the last statistics reset.
– NUMSIOVRD - Accumulated number of safety interlock trips that result in
OP changing state, since the last statistics reset.
• STATETIME[0..2] - Accumulated time of PV in each state, since the last
statistics reset.
selections are:
– None
– ONESHOT
– SEMICONT
– CONTRTN
– CONT
• Abnormal State Options - Lets you specify the action the function block is to
take when the SCM goes into an abnormal state, a level 1 relationship exists, and
a previous OPREQ/GOPREQ command has been received.
The Starting State Option (STARTOPT) applies when the SCM state is
Checking, Idle, or Complete.
The Stop/Abort State Option (STOPOPT) applies when the SCM state is
Stopping or Stopped, Aborting or Aborted.
The Hold State Option (HOLDOPT) applies when the SCM state is Holding or
Hold.
You can choose the NONE or SAFEOP selection for any of the previous options.
If you select SAFEOP, the OPREQ is automatically set to the SAFEOP state and
OPTYPE to default. You should set STOPOPT and/or HOLDOPT to NONE, if
Stopping and/or Holding requires sequencing action. In this case, execute a
STOP and/or HOLD HANDLER as part of the SCM.
The Restart State Option (RESTARTOPT) applies when the SCM state is
Resume or Run. The NONE and LASTREQ are the only selections for the
Restart State Option.
819
26 DEVICE CONTROL

Alarms • PV Alarming - The following alarms are configurable to represent disagreements
between the commanded state (OP) and the feedback state (PV). These alarms
are disabled if there are no inputs or outputs.
– Command Disagree (CMDDISALM.FL): This alarm is generated when the
commanded output state (OP) changes and the feedback state (PV) does not
change to the same state within the specified feedback time. This alarm
returns to normal when the PV state becomes the same as the OP state. This
alarm does not apply for momentary commanded states.
– Command Fail (CMDFALALM.FL): This alarm checks to see if the PV state
changed from its original state to any other state within a specified feedback
time after the OP state is commanded. For slow responding devices, absence
of this alarm indicates that the device responded to the command, even if it
has not yet moved to its commanded position.
– Uncommanded Change (UNCMDALM.FL): This alarm is configured in
conjunction with the Command Disagree alarm function. This alarm is
generated, if an OP state has not been commanded and the PV state changes
for any reason except BADPV.
– Bad PV (BADPVALM.FL): This alarm is generated whenever PV is
detected in the Null state. The Null state can result from a BadPV condition
for an input provided by a source block, or because input combinations
represent a Null state as defined by the DIPVMAP[0..15] parameter.
• Command Disagree - Lets you configure the following parameters for this alarm.
– Time to State0 (or assigned State Name) (CMDDISALM.TM[0]): Lets you
set the feedback time for State 0 in range of 0 to 1000 seconds. A time of 0
disables the alarm. The default setting is 0.
– Time to State 1 (or assigned State Name) (CMDDISALM.TM[1]): Lets you
– Time to State 2 (or assigned State Name) (CMDDISALM.TM[2]): Lets you
disables the alarm. The default setting is 0. This can only be configured if the
number of states is 3.
– Priority (CMDDISALM.PR): Lets you select the priority level as NONE,
JOURNAL, LOW, HIGH, or URGENT. The default setting is LOW.
– Severity (CMDDISALM.SV): Lets you set the relative severity of the alarm
on a scale of 0 to 15. Where 15 is the most sever. The default setting is 0.
• Command Fail - Lets you configure the following parameters for the command
fail alarm.
– Time to State0 (or assigned State Name) (CMDFALALM.TM[0]): Lets you
disables the alarm. The default setting is 0. This value must be less than the
value set for CMDDISALM.TM[0].
– Time to State 1 (or assigned State Name) (CMDFALALM.TM[1]): Lets you
value set for CMDDISALM.TM[1].
– Time to State 2 (or assigned State Name) (CMDFALALM.TM[2]): Lets you
value set for CMDDISALM.TM[2]. This can only be configured if the
number of states is 3.
– Priority (CMDFALALM.PR): Lets you select the priority level as NONE,
– Severity (CMDFALALM.SV): Lets you set the relative severity of the alarm
on a scale of 0 to 15. Where 15 is the most sever. The default setting is 0.
26 DEVICE CONTROL

• Uncommanded Change - Lets you configure the following parameters for this
alarm.
– Priority (UNCMDALM.PR): Lets you select the priority level as NONE,
– Severity (UNCMDALM.SV): Lets you set the relative severity of the alarm
on a scale of 0 to 15. Where 15 is the most severe. The default setting is 0.
• Bad PV - Lets you configure the following parameters for this alarm.
– Priority (BADPVALM.PR): Lets you select the priority level as NONE,
– Severity (BADPVALM.SV): Lets you set the relative severity of the alarm
• Override Alarms - The following alarms are configurable to represent override
interlock conditions.
– Safety Override Interlock (SIALM.FL): This alarm may be generated when
the safety override interlock (SI) occurs, and has caused an OP state change.
– Override Interlock (OIALM[0..2].FL): This alarm may be generated when an
override interlock (OI[0..2]) occurs, and has caused an OP state change.
– Off Normal Condition (OFFNRMALM.FL): If an interlock bypass becomes
active when OPREQ is not Null, the OPREQ is transmitted to OP
immediately upon activation of the bypass parameter. If bypass is activated
after an interlock has been initiated, the OP and OFFNRMALM.FL will be
corrected within one scan.
• Override Alarms - Lets you configure the following parameters for the safety
override interlock alarm.
– Option (SIALM.OPT): Lets you specify whether the safety override
interlock alarm is enabled or not. The default setting is DISABLED.
– Priority (SIALM.PR): Lets you select the priority level as NONE,
– Severity (SIALM.SV: Lets you set the relative severity of the alarm on a
scale of 0 to 15. Where 15 is the most severe. The default setting is 0.
• State 0 Override Interlock Alarm - Lets you configure the following parameters
for this alarm.
– Option (OIALM[0].OPT): Lets you specify whether the State 0 override
– Priority (OIALM[0].PR): Lets you select the priority level as NONE,
– Severity (OIALM[0].SV): Lets you set the relative severity of the alarm on a
for this alarm.
for this alarm.
821
26 DEVICE CONTROL

• Off Normal Condition - Lets you configure the following parameters for this
alarm.
– Priority (OFFNRMALM.PR): Lets you select the priority level as NONE,
– Severity (OFFNRMALM.SV): Lets you set the relative severity of the alarm
faceplate.
26.1.1 Function-DEVCTL block

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” on page 280section for more information.
Attention
Refer to the Sequential Control Module User Guide for more information on the DEVCTL block's batch level 1 driver
interface function.
The following figures are a graphic representation of the DEVCTL block's major functions and associated
parameters.
26 DEVICE CONTROL
Table 55: DEVCTL block major functions and parameters - See Figure 43 also.
823
26 DEVICE CONTROL
Table 56: More DEVCTL block major functions and parameters.
In summary, the DEVCTL block provides these major features.

• Up to 4 inputs, 3 states, and 3 outputs.
• PV Source Selection, PV has 3 basic states plus in-between and faulty.
• Latched and pulsed outputs.
• Momentary states.
• Initialization, Local Manual and Redtagging.
• BADPV, Command Disagree, Uncommanded Change and Command Fail alarms.
• PV Change of state event.
• Permissive and Override Interlocks for each state.
• Interlock trip alarms.
• Seal In option.
• Maintenance statistics.
• The Safety Interlock enforces the defined safe state.
• Safe State explicitly configured. Cannot be momentary.
• Generic State parameters defined as consistent data types.
• Initialization has OPFINAL based configuration.
• Boolean Command option
• Batch level 1 driver option.
• OFF Normal Alarm associated with requested OP.
26 DEVICE CONTROL
26.1.2 Configuration examples-DEVCTL block

• 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.
Figure 19: Example of CB configuration using a DEVCTL block to provide two status outputs.
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.
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.
4 You can have the device commanded by another block or Sequential Control Module through the generic
output (GOP), which shows the state as S0 to S2.
The GOPSCADA parameter provides a link to Station detail displays and custom schematics to show the
state as STATE_0 to STATE_2.
825
26 DEVICE CONTROL
Callout Description
5 Use the BACKCALCIN/BACKCALOUT connection to carry secondary data from the DOC block to the
DEVCTL. (Note that the individual BACKCALCIN/BACKCALCOUT connections for each DEVCTL
output used are automatically built by Control Builder as implicit/hidden connections.)
The secondary data contains this information for DEVCTL blocks.
• Initialization request flag - requests continuous initialization. If this flag is set and this block is
configured to accept secondary initialization, this block goes to the initialized state and stays there until
the flag is reset.
• Initialization value - provides continuous and one shot initialization.
• 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.
Figure 20: Example of CB configuration using DEVCTL block to provide two on pulse outputs.
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.
2 You can use an appropriate interlock logic to activate the safety interlock function.
3 The DEVCTL block is in a CMDDISAGREE alarm state because its input states do not agree with the
input conditions consistent with the commanded state.
26 DEVICE CONTROL
Callout Description
4 You can command the device through the output (OP), which shows the state names you configured for the
block through Control Builder.
5 You can have the device commanded by another block or Sequential Control Module through the generic
output (GOP), which shows the state as S0 to S2.
The GOPSCADA parameter provides a link to Station detail displays and custom schematics to show the
state as STATE_0 to STATE_2.
6 For the DEVCTL block to provide pulse outputs, you must:
• Enable pulse outputs through the parameter Pulse Output 1, 2, 3 (check box checked), under Output tab
on the parameter configuration form, and configure the desired pulse width for the enabled pulse
outputs.
• Once the Pulse Output is configured, the PO[x] pin will be automatically exposed on the DEVCTL
block symbol. Wire PO[X] pin of DEVCTL block to ONPULSE pin on the corresponding
DOCHANNEL block.
7 For the DOCHANNEL block to handle pulse outputs, you must:
• configure the block to have visible ONPULSE input pin through the block configuration form. This pin
also displays the remaining pulse time upon a state change.
• double-click DOTYPE parameter on block and change selection to ONPULSE.
26.1.3 Inputs-DEVCTL block

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 NUMDINPUTS 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.
26.1.4 Outputs-DEVCTL block

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.
827
26 DEVICE CONTROL
• 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.
– The DOCHANNEL block determines the actual pulsewidth resolution and accuracy based on its
execution rate. It always rounds the configured pulsewidth value up consistent with its own execution
rate. For example, if the execution rate of the DOCHANNEL block is 125 milliseconds and the
configured PULSEWIDTH value is 450 milliseconds (.45 seconds), the actual pulse time output would
be 500 milliseconds, which is the next highest multiple of 125 milliseconds.
– A PULSEWIDTH value of 0 is a special case. If a 0 pulse is sent to ONPULSE or OFFPULSE, the
DOCHANNEL block immediately turns OFF any existing pulse.
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.
26.1.5 States-DEVCTL block

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.
26.1.6 State parameters and descriptors-DEVCTL block

The DEVCTL block includes these two sets of parameters for state associations.
• State Parameters
– PV
– PVAUTO
– OP
– OPFINAL
• Generic State Parameters
– GPV (generic version of PV)
– GPVAUTO (generic version of PVAUTO)
– GOP (generic version of OP)
26 DEVICE CONTROL
– GOPFINAL (generic version of OPFINAL)

The State Parameters are an enumeration with an assigned text name, which tracks the names assigned to
STATETEXT[0..6] parameter. An operator can use these parameters.
The Generic State Parameters are consistent data types, which can be compared with each other through the
enumeration GENSTAT_ENM. The generic state enumerations are:
• Null - Stands for Bad Value.
• 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 configuration. 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 would be 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.
• 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.
If STATETEXT is … Then, default name is… And, GENSTAT_ENM is…

STATETEXT[0] Bad* Null
STATETEXT[1] Inbet* Inbet
STATETEXT[2] Active Active
STATETEXT[3] Safe Safe
STATETEXT[4] State0* S0
*These names are configurable through the State Assignments tab.
26.1.7 Two-State motor input example-DEVCTL block

You can represent a simple two-state motor with one input (DI[1]). In this case, when the input is ON, the motor
is in the Run mode. When the input is OFF, the motor is stopped. The following table summarizes the input
state combinations as well as the configured state names and the related GENSTAT_ENM and
DIPVMAP[0..15]for reference.
DI[1] Input State Configured State Name Related DIPVMAP and GENSTAT
0 Stop S0
1 Run S1
(bad)* 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.
829
26 DEVICE CONTROL
26.1.8 Valve input example-DEVCTL block

You can represent a valve as a device with two digital inputs. One input could represent the contact at the Open
end of the valve travel, and the other could represent the contact at the Closed end of the valve travel. The
following table summarizes the input state combinations as well as the configured state names and the related
GENSTAT_ENM and DIPVMAP[0..15]for reference.
Input States Configured State Name Related DIPVMAP and

GENSTAT
DI[1] DI[2]
0 0 Moving Inbet
1 0 Open SO
0 1 Closed S1
1 1 Fault Null
(bad)* X Fault Null
X * Fault Null
26.1.9 Two-Input motor example-DEVCTL block

You are free to assign states to input combinations as desired. You can assign the same state to more than one
combination of input. In this example, the motor is considered to be in Run whenever the DI[2] input is ON (1).
The following table summarizes the input state combinations as well as the configured state names and the
related GENSTAT_ENM and DIPVMAP[0..15] for reference.

GENSTAT
DI[1] DI[2]
0 0 Fault Null
1 0 Stop S0
0 1 Run S1
1 1 Run S1
(bad)* X Fault Null
X (bad)* Fault Null
26.1.10 Reversible motor input example-DEVCTL block

You can use all three states to assign input combinations to represent a reversible motor. The following table
summarizes the input state combinations as well as the configured state names and the related GENSTAT_ENM
and DIPVMAP[0..15] for reference.
26 DEVICE CONTROL

GENSTAT
DI[1] DI[2]
0 0 Stop S0
1 0 Run S1
0 1 Reverse S2
1 1 Fault Null
(bad)* X Fault Null
X (bad)* Fault Null
26.1.11 Four-Input two-valve example-DEVCTL block

You can have up to four inputs with 16 possible state assignments. This can represent an application with two
valves that each have open and close contacts. In this case, DI[1] and DI[2] represent open and close states for
valve #1, and DI[3] and DI[4] represent open and close states for valve #2. The following table summarizes the
input state combinations as well as the configured state names and the related GENSTAT_ENM and
DIPVMAP[0..15] for reference.
Input States Configured State Related DIPVMAP and

Name GENSTAT
DI[1] DI[2] DI[3] DI[4]
0 0 0 0 Fault Null
1 0 0 0 Fault Null
0 1 0 0 Valve Moving Inbet
1 1 0 0 Fault Null
0 0 1 0 Valve Moving Inbet
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
X X X (bad)* Fault Null
X X (bad)* X Fault Null
X (bad)* X X Fault Null
(bad)* X X X Fault Null
831
26 DEVICE CONTROL
26.1.12 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.
26.1.13 Two-State motor with latched output example

You can command a latched two-state motor through a single output. In this example, if the commanded state is
S0 or Stop, the single output DO[1] is set to 0 (OFF). If the commanded state is S1 or Run, the single output
DO[1] is set to 1 (ON). There is no “bad” state for outputs. The following table summarizes the output state
combinations as well as the configured state names and the related GENSTAT_ENM for reference.
Configured State Name Related GENSTAT Output DO[1] State

Stop S0 0
Run S1 1
26.1.14 Valve Output Example-DEVCTL block

You can use two outputs to open and close a valve. Since there are more combinations of outputs than there are
states available, you must make unique output state assignments. For this example, when Close is commanded,
DO[1] only is set. When Open is commanded, DO[2] only is set. There is no way to command the other
possible combinations. The following table summarizes the output state combinations as well as the configured
state names and the related GENSTAT_ENM for reference.
Configured State Name Related GENSTAT Output States

DO[1] DO[2]
Close S0 1 0
Open S1 0 1
26.1.15 Three-State Motor output examples-DEVCTL block

You can use two outputs to provide different outputs for three states. Of course, the NUMSTATES parameter is
set to three. 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 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.
26 DEVICE CONTROL

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.

DO[1] DO[2] DO[3]
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.
26.1.16 Mode and mode attribute-DEVCTL block

• Mode (MODE) is fixed at MANual. The Normal Mode (NORMMODE) parameter is also fixed at MANual.
• Mode Attribute (MODEATTR) - determines where state commands to the DEVCTL block may originate -
that is, who may set the commanded output state (OP), as follows:
– OPERATOR = only the operator may command the output state.
– PROGRAM = only other function blocks (such as Logic blocks, SCM programs) may command the
output state by setting OPREQ.
– NORMAL = the setting specified by the Normal Mode Attribute (NORMMODEATTR) is assumed.
26.1.17 Safe output state-DEVCTL block

The Safe Output State (SAFEOP) parameter defines the default state for certain actions of the DEVCTL block,
such as the momentary output state and OP initialization. SAFEOP can be assigned to any of the settable states
of the block (that is, those states to which parameter OP may be assigned). The default for SAFEOP is State 0.
• When NUMSTATES = 2, then State 2 is illegal for SAFEOP.
• SAFEOP may not be assigned to a state, which is already configured as momentary.
• When OP or GOP is commanded to safe, the effective value of OP (GOP) is set equal to SAFEOP.
26.1.18 Momentary state-DEVCTL block

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).
833
26 DEVICE CONTROL
*Fixed Time is defined:

• For containing CM periods< 5 seconds. Momentary States are≈5 seconds for all possible CM periods.
• For periods> 5 seconds (ACE). Momentary states are at least one execution cycle, which can be up to 20 seconds on
ACE.
The following table summarizes the MOMSTATE parameter selections.
If Momentary State selection is … Then,

NONE No state is momentary.
STATE_0 State 0 is momentary and it must not be configured as the
safe output.
safe output.
STATE_0AND1 Both State 0 and State 1 are momentary and neither one
must be configured as the safe output. This can only be
selected if the number of states (NUMSTATES) is three.
safe output. This can only be selected if the number of
states (NUMSTATES) is three.
26.1.19 Local manual-DEVCTL block

The local manual (LOCALMAN) parameter is an input flag to support an interface to a local HAND/OFF/
AUTO (also called HAND/OF) switc 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.
26.1.20 Permissive interlocks-DEVCTL block

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.
26 DEVICE CONTROL
26.1.21 Safety Override Interlock-DEVCTL block

The Safety Override Interlock (SI) forces the commanded output state (OP) to the Safe Output State (emay
como a different state while SI is active
• SI may be connected to other blocks or may be directly set by an operator if the MODEATTR parameter is
set to Operator and the block is inactive.
• SI is defaulted to OFF, it must be set to ON to force OP to go to SAFEOP.
• When SI turns OFF, OP = SAFEOP is maintained until changed by:
– the operator
– a user program
– another Safety Override Interlock
26.1.22 Override Interlocks-DEVCTL block

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]
26.1.23 Configurable Override/Permissive Interlock Bypass-DEVCTL block

To grant an operator the ability to bypass the Permissive and Override Interlocks for a DEVCTL block, the
parameter BYPPERM must be set to ON. The operator can then set or reset the parameter BYPASS.
• When BYPASS is ON, OP can be changed regardless of the state of the Override 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 defaults to OFF and is read-only.
835
26 DEVICE CONTROL
26.1.24 Alarms-DEVCTL block

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 be used as a condition for exception handling.
The Off Normal condition is examined as follows:
If command disagree (CMDDISALM) is configured, the OFFNRMALM.FL is set only after the feedback time-
out has occurred. If an interlock or other attribute is active that would prevent OP from changing when a new
command is sent, the feedback time is ignored and the OFFNRMALM.FL will be active within one scan.
26 DEVICE CONTROL
If command disagree (CMDDISALM) is not configured, this means that there is no feedback timer. In this case,
the OFFNRMALM.FL is set after one scan time, to avoid race conditions between OP and PV.
• Off Normal Alarming with Bypass - If the interlock bypass (BYPASS) becomes active and the OPREQ is
not null, the OPREQ is transmitted to OP immediately upon the activation of the BYPASS parameter. If
BYPASS is activated after an interlock has initiated, the OP and the off normal alarm flag
(OFFNRMALM.FL) will be corrected within one scan.
• Override Interlock Alarms - When the alarm is enabled and the active interlock causes an OP state change,
the alarm will be generated.
• Safety Override Interlock Alarm - When the alarm is enabled and the active interlock causes an OP state
change, the alarm will be 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.
26.1.25 Seal-In option-DEVCTL block

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 .
26.1.26 Initialization Manual condition-DEVCTL block

Initialization Manual is a condition resulting from failure in the field devices connected to the output of the
Discrete Control FB. When this condition is active, the parameter INITMAN is set ON. Outputs may not be
commanded when INITMAN is TRUE.
• INITDOWN[1..3] - This is an input which may be connected to the DOC INITREQ output. When possible,
this connection will be made automatically by the system, without action required of the user.
• This is a structure containing the INITREQ status and the DOC.SO present value.
• INITCONNECTD[1..3] - This parameter is set by the FB Builder when the corresponding INITDOWN[] is
connected.
• INITMAN - This is a BOOLEAN value which is set TRUE whenever any of the INITDOWN[i].STATUS
are TRUE.
26.1.27 OP Initialization Option-DEVCTL block

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.
837
26 DEVICE CONTROL
26.1.28 Initialization Manual Condition with Safety Override Interlock, Override Interlocks, LocalMan,
and OP Initialization
The Safety Override Interlock and the Override Interlocks have an impact on how OP initialization works, as
described in the following.
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.
• If LEGACYINITOPT = DISABLE, OP is either back initialized from the outputs if a valid OP can be
constructed or OP is set to SafeOP.
• Otherwise, if OP Initialization is configured as SAFEOPOPT, OP is set to SafeOP;
• Otherwise (OP Initialization is configured as NORMALOPOPT), in cases where feedback is configured, the
stored OP value tracks the PV state if the PV state is settable ( State0, State1, or State2 );
• Otherwise, OP value is back-initialized from the output connections if
– there are no output types of ONPULSE/OFFPULSE, and
– if a valid OP value can be constructed from the values of the output connections.
Otherwise, OP is set to SAFEOP.
The following figure illustrates the return from initialization behavior.
26 DEVICE CONTROL
26.1.29 Initialization with Pulse Output-DEVCTL block

If Pulse Outputs are configured, the following rules should be followed in generating pulses when recovering
from initialization :
• When PV is good, OP and OpFinal are initialized to PV, no pulses should be generated.
• When PV is Bad, OP and OpFinal are initialized to SafeOp, pulses should be generated.
• When LEGACYINITOPT is enabled, no pulses should be generated for any selection of INITOPOPT.
The following table represents the state of the pulse and digital outputs with respect to INITOPOPT and
LEGACYINITOPT after recovering from initialization.
Output INITOPOPT PV State Changes to Output Pulses

Type
When When When When
LEGAC LEGACYINITOPT is LEGACYI LEGACYINIT
YINITO enabled NITOPT OPT is enabled
PT is is disabled
disabled
Pulse NORMALOPOPT Good PV PV No No
Bad SafeOp SafeOp Yes No
HOLDOPOPT N/A Back Init from No Change Yes, if state No
outputs changes to
SafeOp
SAFEOPOPT N/A SafeOp SafeOp Yes No
Digital NORMALOPOPT Good PV PV N/A N/A
839
26 DEVICE CONTROL
Output INITOPOPT PV State Changes to Output Pulses

Type
Bad Back Init from Back Init from N/A N/A
outputs outputs
HOLDOPOPT N/A Back Init from No Change N/A N/A
outputs
SAFEOPOPT N/A SafeOp SafeOp N/A N/A
For more information on the LEGACYINITOPT parameter, refer to the Control Builder Parameter Reference
guide.
26.1.30 Initialization Request Flags-DEVCTL block

The Device Control function block parameter INITREQ[0..2] provides an indication whether a command to a
certain state (corresponding to the parameter index 0..2) will be accepted and acted upon at the present time.
This parameter can be read prior to sending a command to the block to check if the device can respond as
desired. INITREQ[i] (i = 0, 1, or 2) = OFF indicates that the block can be commanded to statei, and INITREQ
[i] (i = 0, 1, or 2) = ON indicates that the block cannot be commanded to statei. Things like override interlocks,
permissive interlocks, etc. can cause a certain state to not be settable at a given point in time.
Tip
Note that the INITREQ is used differently in DevCtl block than in other blocks, such as DOC, AOC, or RegCtl.
26.1.31 OP and DO Initialization After Load-DEVCTL block

This function gives you an opportunity to configure the initialization values of digital outputs (DOs) to their
desired values. This feature is typically used for the strategy where the outputs of a Device Control function
block are connected to non-initializable blocks, such as logic blocks. The configuration is done through a new
parameter, INITOPAFTLD. The user will have to configure the initialization state for OP, and the value of OP
will be mapped to DOs, according to the configured map of OP-DO (OPDOMAP), after load. The options for
INITOPAFTLD can be any configured states (State0, State1, or State2 if 3-state is configured), or default. The
default option will initialize OP to State0, and all the DOs to 0 (OFF).
CAUTION
When the default option for parameter INITOPAFTLD is selected, there may be a mismatch between the OP value
and the DO states until a back-initialization or state change occurs. State0 may not correspond to all DOs of 0
(OFF).
26.1.32 Maintenance Statistics-DEVCTL block

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).
26 DEVICE CONTROL
• STATETIME [0. 2] - accumulated time of PV in each state (since the last statistics reset).
• NUMSIOVRD - accumulated number of safety interlock trips, which result in OP changing state (since the
last statistics reset).
The statistics are accumulated since the most recent reset. The operator only can reset the statistics while the
DEVCTL block is red-tagged, but a program (or other function block) can reset the statistics by storing ON to
RESET.FL anytime.
26.1.33 Output requests-DEVCTL block

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.
26.1.34 Output command-DEVCTL block

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.
Commanded output state change effective from next execution cycle

The OP parameter represents the Commanded Output State. The OP value can be modified at any time during
the block execution. When a new OP is commanded, the new OP will be accepted and stored in the block. The
new OP parameter value can be stored at any time during the block execution. However, the new OP parameter
value will be effective after validating the OP value conditions such as Permissive/Safety/Override interlocks,
841
26 DEVICE CONTROL
and output requests which happens in the subsequent execution of the block. In addition, the last OP remains
displayed in the block's faceplate. This is because the new OP value will be effective from the next execution
cycle.
26.1.35 Logic override OPREQ

You can use the clear OPREQ flag parameter (CLROPREQFL) through a passive connection to a Logic type
block to clear the OPREQ, if the MODEATTR is Program. When the CLROPREQFL changes from OFF to
ON, OPREQ is set to NULL and the OP remains unchanged.
26.1.36 DEVCTL parameters

DEVCTL block.
27 Logic Functions
Related topics
“Logic Function Blocks” on page 844
“Change Execute (CHGEXEC) Block” on page 861
“CHGEXEC Usage Considerations for Change Driven Execution” on page 862
“Change Driven Application Risk Factors” on page 863
“Blocks Qualified for Use with CHGEXEC Block” on page 864
“Experion Controller Platform Support for CHGEXEC” on page 867
“CHGEXEC Main Parameter Details” on page 868
“CHGEXEC Cascading Between Control Modules Example” on page 870
“CHGEXEC Cascading Within Control Module Example” on page 873
“Importance of Using Consistent Input Data” on page 874
“Periodic Auto Trigger Function of CHGEXEC” on page 876
“Execution Order Considerations for CHGEXEC within CM” on page 879
“CHGEXEC Behaviors for State Transitions” on page 880
“CHGEXEC Supports Checkpoint Function” on page 885
“Load Monitoring Parameters” on page 886
“Sample CHGEXEC TESTOPT Procedure” on page 887
“Examples and scenarios” on page 888
“Contact Monitoring (CONTACTMON) Block” on page 894
843
27 LOGIC FUNCTIONS
27.1 Logic Function Blocks

The Logic Functions Blocks can be combined with the Device Control Function Block to provide the basis for
integrated Logic control. The blocks provided fall into one of these basic functional categories.
• Bitwise Boolean functions
• Comparison functions
• Arithmetic functions
• Selection functions
• Bistable (flip-flop) functions
• Edge triggered functions
• Timed functions
• Voted functions
The following table provides a description and a brief explanation of the functional capabilities of the named
function block. In most cases, the name of the block is intuitive of its function.
Block Name/ Graphic Description Function

2003 2-out-of-3 Voting block outputs Sets the output (DISCREP) to ON
(DISCREP and MAJ) are determined if NOT all inputs agree for a
as follows: specified time duration (DELAY);
otherwise, it is set to OFF.
• DISCREP = OFF when all inputs
are equal.
= ON when all inputs are not
equal for time >= DELAY.
• MAJ = value held by the majority
of the inputs.
Starting in Experion R311.1, 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 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.
If Configured LOGICINITOPT Value Is And, Some IN Disagree … Then, DISCREP Value After State
… Transition Is …
PULSEEXPIRED OFF OFF
PULSEEXPIRED ON ON only if disagreement persists for
full DELAY interval.
PULSEREADY OFF OFF
PULSEREADY ON May go ON if disagreement persists for
less than full DELAY interval.
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.
AND Provides an up to 8-input AND Turns the digital output (OUT) ON
algorithm, meaning that it performs only when all inputs (IN[1], IN[2],
the Boolean operation of conjunction. …, IN[8]) are ON. Therefore:
Each input (IN[1], IN[2], …, IN[8])
• If all inputs are ON, then: OUT
has the capability of being optionally
= ON.
inverted, if required.
• If any input is OFF, then: OUT
= OFF.
27 LOGIC FUNCTIONS

CHECKBAD Provides bad input handling for Checks if input (IN) value equals
desired input. NaN.
• If IN = NaN
• Then, OUT = ON
• Else, OUT = OFF
CHECKBOOL Provides the ability to modify the Determines the action to be taken
OUTPUT based on programmable in the event of an invalid input. If
parameters where the OUTPUT will the value of INSTS[1..8] is
either track the INPUT, latch the kBadValSts, the value passed
OUTPUT, (ON or OFF), or latch the through the block, from IN[1..8] to
OUTPUT to a specific known good OUT[1..8], will be modified based
value for a specific time based on on the configuration of the
configuration parameters associated BADINACT[1..8] parameter.
with the block.
If BADINACT is configured as
See “CheckBool functionality” on OFF, then OUT[1..8] is set equal
page 888 under Examples and to OFF
Scenarios for Use Case examples of
the CheckBool block.
ON, then OUT[1..8] is set equal to
“ON”
HoldLast, then OUT[1..8] is set
equal to LASTIN[1..8]
CHGEXEC The Change Execution block helps in Refer to the “Change Execute
optimizing the performance of control (CHGEXEC) Block” on page 861
modules (CM) used exclusively for section following this table for
logic computation. more information about this
block's functions.
The CONTACTMON block can only be used with C300, C200E, and ACE Controllers.
845
27 LOGIC FUNCTIONS

CONTACTMON The Contact Monitoring block, Inputs:
available under the Logic library, is
• IN[1..2] - Input parameter
used for limit switches with NO and
corresponding to the NO and
NC Contact with the same activation
NC Contact of a micro Switch.
mechanism. In most cases, the limit
switch serves some critical Outputs:
applications. An alarm is generated
• PVFL - this gives the negated
when both digital inputs are ON or
XOR results of IN[1] and
OFF at the same time, indicating a
IN[2]
switch malfunction. The Contact
Monitoring block allows the user to • OUT1 - Tracks IN[1] when
generate an alarm whenever the state both inputs of COC are not ON
of both inputs is simultaneously ON • OUT2 - Tracks IN[2] when
or OFF based on the NORMAL state both inputs of COC are not ON
configuration.
Error Handling:
See Contact Monitoring
(CONTACTMON) block under • The block displays an error
Examples and Scenarios section for when an invalid index or
sample block function and execution. access lock is detected during
loading.
• SR parameters are not editable
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.
• The alarm flags are cleared
when the CM is inactivated or
CEE is made IDLE.
DELAY Provides the ability to delay the The OUT always follows the input
output (OUT) response to the given (IN) action by a sample cycle time.
input (IN) by a sample cycle time.
27 LOGIC FUNCTIONS

EQ Provides a 2-input Compare Equal Turns the digital output (OUT) ON
(with deadband range) function, only when the two inputs (IN[1]
meaning that it compares two inputs and IN[2]) are considered equal
for equality within a specified within a specified deadband range
deadband range. or, for single inputs, a designated
trip point parameter (TP) as
follows:
• If ((IN[1] - IN[2) <=
DEADBAND1), then: OUT =
ON.
• If ((IN[1] - IN[2]) >
OFF.
• Else OUT is not changed.
DEADBAND1 and DEADBAND2
must satisfy the following
constraint:: 0 <= DEADBAND1
<= DEADBAND2
If either input (IN[1] or IN[2]) is
NaN, the output (OUT) is set to
INBADOPT.
FTRIG Falling edged Trigger Block sets the Provides falling edged change
output (OUT) to ON following the detection, thereby turning the
ON-to-OFF transition of the input output ON if an ON-to-OFF
and stays ON until the next execution transition is detected.
cycle, at which time it returns to OFF.
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.
If Configured LOGICINITOPT Value Is And, Current IN Value Is … Then, OUT Value After State Transition
… Is …
PULSEEXPIRED AN OFF
Y
PULSEREADY AN May pulse depending on value of
Y current input and value of input at last
execution.
purposes only.
847
27 LOGIC FUNCTIONS

GE Provides a 1- or 2-input Compare Turns the digital output (OUT) ON
Greater Than or Equal (with only when one designated input
deadband) function, meaning it (IN[1]) is greater than or equal to a
checks to see if one designated input second input (IN[2]) or, for single
(IN[1]) is greater than or equal to inputs, a designated trip point
either a second input (IN[2]) or, for parameter (TP) as follows:
single inputs, a designated trip point
• If IN[1] >= IN[2], then: OUT =
parameter (TP).
ON.
• If IN[1] < (IN[2] -
DEADBAND), then: OUT =
OFF.
• If (IN[2] - DEADBAND) <
IN[1] < IN[2], then OUT is not
changed.
INBADOPT.
GT Provides a 1- or 2-input Compare Turns the digital output (OUT) ON
Greater Than (with deadband) only when one designated input
function, meaning that it checks to (IN[1]) is greater than a second
see if one designated input (IN[1]) is input (IN[2]) or, for single input, a
greater than either a second input designated trip point parameter
(IN[2]) or, for a single input, a (TP) as follows:
designated trip point parameter (TP).
• If IN[1] > IN[2], then: OUT =
ON.
• If IN[1] <= (IN[2] -
OFF.
• If (IN[2] - DEADBAND) <
IN[1] <= IN[2], then: OUT is
not changed.
INBADOPT.
LE Provides a 1- or 2-input Compare Turns the digital output (OUT) ON
Less Than or Equal (with deadband) only when one designated input
function, meaning it checks to see if (IN[1]) is less than or equal to a
one designated input (IN[1]) is less second input (IN[2]) or, for a
than or equal to either a second input single input, a designated trip point
(IN[2]) or, for a single input, a parameter (TP) as follows:
designated trip point parameter (TP).
• If IN[1] <= IN[2], then: OUT =
ON.
• If IN[1] > (IN[2] +
OFF.
• If IN[2] < IN[1] <= (IN[2] +
DEADBAND), then: OUT is
not changed.
INBADOPT.
27 LOGIC FUNCTIONS

LIMIT Provides a 3-input limit function, Provides an output that is
meaning that it provides an output maintained within a specified
that is maintained within a specified range as follows:
range as defined by user-specified
• MN ≤ OUT ≤MX
minimum and maximum values.
• If IN is not NaN, OUT = MIN
( MAX ( IN, MIN ), MAX )
• If IN = NaN, OUT = NaN
LT Provides a 1- or 2-input Compare Turns the digital output (OUT) ON
Less Than (with deadband) function, only when one designated input
meaning that it checks to see if one (IN[1]) is less than a second input
designated input (IN[1]) is less than (IN[2]) or, for a single input, a
either a second input (IN[2]) or, for a designated trip point parameter
single input, a designated trip point (TP) as follows:
parameter (TP).
• If IN[1] < IN[2], then: OUT =
ON.
• If IN[1] >= (IN[2] +
OFF.
• If IN[2] <= IN[1] < (IN[2] +
DEADBAND), then: OUT is
not changed.
INBADOPT.
MAX Provides an N-input MAX function, Used to isolate the highest value of
meaning that it provides an output multiple input values and use it as
that is the maximum value of N- a designated output value.
inputs.
MAXPULSE Provides a maximum time limit pulse Used to limit the output (OUT)
output (OUT) each time the input pulse to a maximum width.
(IN) transitions from OFF to ON. You
• If the input (IN) pulse time is
specify the maximum output pulse
less than or equal to the
width (PULSEWIDTH) in seconds
specified PULSEWIDTH time,
through configuration.
IN is assumed to equal one
output (OUT) pulse.
• If the IN pulse time is greater
than the specified
PULSEWIDTH time, OUT
pulse terminates at end of
specified PULSEWIDTH time.
849
27 LOGIC FUNCTIONS

MAXPULSE timing diagram:
the MAXPULSE block OUT responds as a result of block state transitions such as activate, warm start, cold start or RAM
configuration.
… Is …
PULSEEXPIRED ANY OFF
PULSEREADY ANY May pulse depending on value of
current input and value of input at last
execution.
purposes only.
MIN Provides an N-input MIN function, Used to isolate the lowest value of
meaning that it provides an output multiple input values and use it as
that is the minimum value of N- a designated output value.
inputs.
MINPULSE Provides a minimum time limit pulse Used to define the minimum
output (OUT) each time the input output (OUT) pulse width.
(IN) transitions from OFF to ON. You
specify the minimum output pulse
less than or equal to the
width (PULSEWIDTH) in seconds
specified PULSEWIDTH time,
through configuration.
output (OUT) pulse width
equals the specified time.
than the specified
PULSEWIDTH time, OUT
pulse width tracks IN pulse
time, so OUT pulse exceeds
specified time.
27 LOGIC FUNCTIONS

MINPULSE timing diagram:
the MINPULSE block OUT responds as a result of block state transitions such as activate, warm start, cold start or RAM
configuration.
… Is …
execution.
purposes only.
MUX Provides an up to 8-input Extensible Sets the actual output (OUT) to a
Multiplexer algorithm, meaning that particular input (IN[1], IN[2], …,
it selects 1 of “N” inputs depending IN[8]) depending on the value of a
on a separate input K. separate input K.
• OUT = INk+1
MUX-REAL Provides an up to 8-input Extensible Sets the actual output (OUT) to a

Multiplexer algorithm, meaning that particular input (IN[1], IN[2], …,
it selects 1 of “N” inputs depending IN[8]) depending on the value of a
on a separate input K. separate input K.
• OUT = INk+1
MVOTE Provides an output (MAJ) value that Sets the MAJ output equal to the
equals the value of the majority of the value of the majority of the inputs
inputs (IN[1..8]) and sets another (IN[1..8]).
output (DISCREP) to ON if not all
Sets the DISCREP output to ON, if
inputs agree for a specified time
not all inputs agree during the
(DELAY). You specify the time
specified time (DELAY). DELAY
(DELAY) in seconds through
is a unit integer with time unit in
configuration. You must also specify
seconds.
the number of inputs
(NUMOFINPUTS) through
configuration.
851
27 LOGIC FUNCTIONS

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.
If Configured LOGICINITOPT Value Is And, Some IN Disagree … Then, DISCREP Value After State
PULSEEXPIRED ON ON only if disagreement persists for
full DELAY interval.
PULSEREADY OFF OFF
PULSEREADY ON May go ON if disagreement persists for
less than full DELAY interval.
purposes only.
NAND Provides an up to 8-input NAND Turns the digital output (OUT)
algorithm, meaning that it performs OFF only when all inputs (IN[1],
an inverted AND function. Each input IN[2], …, IN[8]) are ON;
(IN[1], IN[2], …, IN[8]) has the therefore:
capability of being optionally
• If all inputs are ON, then: OUT
= OFF.
• If any input is OFF, then: OUT
= ON.
NE Provides a 1- or 2-input Compare Not Turns the digital output (OUT) ON
Equal (with deadband range) only when the two inputs (IN[1]
function, meaning that it checks to and IN[2]) are not considered
see if one designated input (IN[1]) is equal within a specified deadband
not equal to either a second input range or, for single inputs, a
(IN[2]) or, for a single input, a designated trip point parameter
designated trip point parameter (TP). (TP) as follows:
• If ((IN[1] - IN[2) <=
OFF.
• If ((IN[1] - IN[2]) >
ON.
• Else OUT is not changed.
DEADBAND1 and DEADBAND2
must satisfy the following
constraint:: 0 <= DEADBAND1
<= DEADBAND2 If either input
(IN[1] or IN[2]) is NaN, the output
(OUT) is set to INBADOPT.
27 LOGIC FUNCTIONS

nOON n-out-of-N voting block; outputs are Provides VOTED, ORED and
computed as follows: ALARM outputs in support of
logical functions.
• VOTED output is set to ON if at
least n inputs are ON, otherwise it
is set to OFF.
• ORED output is set to ON if any
input is ON, otherwise it is set to
OFF.
• ALARM output is a pulse output
- every time an input turns ON, a
fixed pulse (of the pulsewidth
specified by PULSEWIDTH
parameter) is generated, provided
the total number of inputs which
are ON is less than n.
the nooN block OUT responds as a result of block state transitions such as activate, warm start, cold start or RAM
configuration.
… Is …
execution.
purposes only.
NOR Provides an up to 8-input NOR Turns the digital output (OUT)
algorithm, meaning that it performs OFF if any one input (IN[1], IN[2],
an inverted OR function. Each input …, IN[8]) is ON; therefore:
(IN[1], IN[2], …, IN[8]) has the
• If all inputs are OFF, then:
OUT = ON.
• If any one input is ON, then:
OUT = OFF.
NOT Provides a NOT algorithm, meaning Reverses the state of a digital input
it performs an inversion function. (IN) such that the output (OUT) is
the complement of the single input;
therefore:
• OUT = opposite of IN
• If IN = ON, then: OUT = OFF.
• If IN = OFF, then OUT = ON.
OFFDELAY Delays the input signal supplied at the Used to delay the input by a
input (IN) when the input signal specified delay time after an
transitions from ON to OFF. ON/OFF device transitions from
the ON state to the OFF state.
• Delay time is specified by the
DELAYTIME parameter.
853
27 LOGIC FUNCTIONS

OFFDELAY timing diagram:
the OFFDELAY block OUT responds as a result of block state transitions such as activate, warm start, cold start or RAM
configuration.
… Is …
PULSEEXPIRED ON ON
PULSEREADY ANY May delay depending on value of
execution.
purposes only.
ONDELAY Delays the input signal supplied at the Used to delay the input by a
input (IN) when the input signal specified delay time after an
transitions from OFF to ON. ON/OFF device transitions from
the OFF state to the ON state.
• Delay time is specified by the
DELAYTIME parameter.
ONDELAY timing diagram:
27 LOGIC FUNCTIONS

the ONDELAY block OUT responds as a result of block state transitions such as activate, warm start, cold start or RAM
configuration.
If Configured LOGICINITOPT Value Is And, Current IN Value Is … Then, OUT Value After State
PULSEEXPIRED ON ON
PULSEREADY ANY May delay depending on value of
execution.
purposes only.
OR Provides an up to 8-input OR Turns the digital output (OUT) ON
algorithm, meaning that it performs if any one input (IN[1], IN[2], …,
the inclusive OR Boolean function. IN[8]) is ON; therefore:
Each input (IN[1], IN[2], …, IN[8])
• If all inputs are OFF, then:
has the capability of being optionally
OUT = OFF.
• If any one input is ON, then:
OUT = ON.
PULSE Provides a fixed pulse output (OUT) Used to define the fixed output
each time the input (IN) transitions (OUT) pulse width.
from OFF to ON. You specify the
fixed output pulse width
less than or equal to the fixed
(PULSEWIDTH) in seconds through
PULSEWIDTH time, output
configuration.
(OUT) pulse width equals the
fixed time.
than the fixed PULSEWIDTH
time, OUT pulse width is
restricted to the fixed time.
Another output pulse cannot be
generated until the preceding
pulse has completed.
PULSE timing diagram:
855
27 LOGIC FUNCTIONS

the PULSE block OUT responds as a result of block state transitions such as activate, warm start, cold start or RAM
configuration.
… Is …
PULSEEXPIRED ON ON
execution.
purposes only.
QOR Qualified OR - provides an (N + 1)- Turns the digital output (OUT) ON
input generic-qualified OR function, if a specified number (k) of total
meaning that the output (OUT) is digital inputs is ON.
turned ON if a certain number (k) of
total inputs (IN[n]) is ON. Each input
(IN[1], IN[2], …, IN[8]) has the
ROL Provides a 16-bit integer output Used to shift out bits in the output
(OUT) that is rotated to the left by the (OUT) by rotating the bits in the
number of bits (N) specified from the input (IN) left by the number of
16-bit integer input (IN). You specify bits (N) specified.
the number of bits through
• OUT = IN left rotated by N
configuration.
bits, circular.
ROL execution diagram:
ROR Provides a 16-bit integer output Used to shift out bits in the output
(OUT) that is rotated to the right by (OUT) by rotating the bits in the
the number of bits (N) specified from input (IN) right by the number of
the 16-bit integer input (IN). You bits (N) specified.
specify the number of bits through
• OUT = IN right rotated by N
configuration.
bits, circular.
ROR execution diagram:
RS Reset - provides a bistable Reset Specifies the output (Q) of the flip-
Dominant flip-flop as defined in the flop as a function of the input S
IEC DIS 1131-3 standard. (Set), the input R (Reset), and the
last state of Q.
27 LOGIC FUNCTIONS

RTRIG Rising-Trigger - sets the output Provides rising edge change
(OUT) to ON following the OFF-to- detection, thereby turning the
ON transition of the input (IN) and output ON if an OFF-to-ON
stays at ON until the next execution transition is detected.
cycle, at which time it returns to OFF.
the RTRIG block OUT responds as a result of block state transitions such as activate, warm start, cold start or RAM
configuration.
… Is …
execution.
purposes only.
SEL Provides a 3-input selector function, Sets the actual output (OUT) equal
meaning it selects 1 of 2 inputs (IN[1] to the value of 1 of 2 inputs (IN[1]
and IN[2]) depending on the separate or IN[2]), depending on the value
input G. of a separate input (G).
• If G = OFF, OUT = IN1
• If G = ON, OUT = IN2
SEL-REAL Provides a 3-input selector function, Sets the actual output (OUT) equal
meaning it selects 1 of 2 inputs (IN[1] to the value of 1 of 2 inputs (IN[1]
or IN[2]) depending on the separate or IN[2]), depending on the value
input (G). of a separate input (G).
• If G = OFF, OUT = IN1
• If G = ON, OUT = IN2
SHL Provides a 16-bit integer output Used to shift out bits in the output
(OUT) that is shifted to the left by the (OUT) by shifting the bits in the
number of bits (N) specified from the input (IN) left by the number of
16-bit integer input (IN). You specify bits (N) specified.
the number of bits (N) through
• OUT = IN left shifted by N
configuration.
bits, zero filled on right.
SHL execution diagram:
SHR Provides a 16-bit integer output Used to shift out bits in the output
(OUT) that is shifted to the right by (OUT) by shifting the bits in the
the number of bits (N) specified from input (IN) right by the number of
the 16-bit integer input (IN). You bits (N) specified.
specify the number of bits through
• OUT = IN right shifted by N
configuration.
bits, zero filled on left.
857
27 LOGIC FUNCTIONS

SHR execution diagram:
SR Provides a bistable Set Dominant Specifies the output (Q) of the flip-
flip-flop as defined in the IEC DIS flop as a function of the input S
1131-3 standard. (set), the input R (Reset), and the
last state of Q.
STARTSIGNAL Supports handling of restarts within Supports an enumeration-valued

Control Modules (CM). Can be used summary parameter named
within any CM to provide better RESTART. The normal value for
control over how the module the RESTART parameter is NONE.
initializes in response to events such Following a transition, it shows a
as Cold or Warm restart. value other than NONE until the
end of the first block execution.
Provides 7 read-only parameters that
The possible enumeration values
can be accessed to drive initialization
for RESTART are as follows:
actions. Each parameter has “pulse”
characteristics, so it normally holds a NONE(0)
value which indicates that no
CMLOAD (1)
initialization is required. When a
transition occurs appropriate CMACTIVE (3)
parameters acquire an informative CEECOLD (4)
value. This value lasts until the end of
the first block execution, which CEEWARM (5)
follows the transition. After first CEESWITCH (6)
execution, the parameter is reset to a
value which indicates that no restart The CEESWITCH value indicates
has occurred since the last execution. that the parent CM in a C200/
A STARTSIGNAL instance must C200E Controller is executing for
always be configured so that its the first time following a
ORDERINCM parameter places its redundancy switchover.
execution after that of any blocks Since it is possible for more than
which read its parameters as the one transition to occur between the
parameters are reset when the block time that a control module stops
executes following the transition. executing and the time that it
restarts, there is an implicit priority
built into the values other than
NONE of parameter RESTART.
This priority insures that the
strongest initialization signal is the
one which will be seen. The
priority is as follows.
1. CMLOAD
2. CMACTIVE
3. CEECOLD
4. CEEWARM
5. CEESWITCH
27 LOGIC FUNCTIONS

The RESTART parameter only
shows a value other than NONE
until the first execution. It can be
used to drive initializations within
the CM. But in many cases it will
be more convenient to use one of
the Boolean-valued parameters
described below.
STARTSIGNAL Boolean Parameters CMLOADFL This parameter holds True for the
first execution cycle following a
Note that there is no implied priority or
load of the parent CM.
mutual exclusivity among the flag parameters
described here. For example, if a CEE starts CMACTIVEFL This parameter holds True for the
in idle, has a control module loaded, is first execution cycle following
activated, and then CEE is warm started, the inactivation and then activation of
first execution of the CM parameters the parent CM.
CMLOADFL, CMACTIVEFL,
CEECOLDFL This parameter holds True for the
CEEWARMFL, AND ANYRESTARTFL
first execution cycle following cold
will be True. Parameters CEECOLDFL and
start of the CEE.
CEESWITCHFL will be False. Parameter
RESTART will have the value CMLOAD. CEEWARMFL This parameter holds True for the
first execution cycle following
warm start of the CEE.
CEESWITCHFL This parameter holds True for the
first execution cycle following
redundant switchover of the CEE
on a C200/C200E Controller.
ANYRESTARTFL This parameter holds True for the
first execution cycle, if any of the
preceding flag parameters are True.
This is the same as saying that the
parameter holds True whenever
parameter RESTART is not equal
to NONE.
TRIG The edge detect (change detect) • An Off to On or On to Off
function block. The input (IN) and transition of the IN sets the
output (OUT) types must be type OUT to On and it stays On
BOOLEAN. until the next execution cycle
when it returns to Off.
• The IN is assumed to start at
the Off stage when the function
block is first turned On.
the TRIG block OUT responds as a result of block state transitions such as activate, warm start, cold start or RAM
configuration.
… Is …
execution.
purposes only.
859
27 LOGIC FUNCTIONS

WATCHDOG Monitors other system functions or Used to monitor other system
remote devices and sets the output functions or remote devices.
(OUT) to ON if the monitored
• Monitored function or device
function or device fails to
must set IN parameter to ON
communicate.
within a specified time interval
Example: Applications like (DELAYTIME), otherwise it is
TotalPlant Batch uses the Watchdog assumed to have failed and
item to determine the communication output (OUT) is set to ON.
between TotalPlant Batch server • If output (OUT) is ON, it is
(TPB) and Experion controllers. reset to OFF as soon as IN is
Watchdog also provides a Watch dog set to ON.
protocol in Experion, which is simple
set/reset protocol. The application
such as TPB server sets the Watch
dog by writing one to the watchdog
item. The Experion controller
accessed through the data server is
referred as TPB Phase Data Interface
on Experion .It is expected to reset
the watchdog to zero when a non-zero
value is detected. Therefore, when
you reset the watch dog values, TPB
server can detect the presence of a
healthy controller. However, the
controller can detect the presence of a
healthy TPB server by periodic
setting of the watchdog.
If the controller determines that the
TPB server has not written to the
watchdog for a long period of time,
then it assumes that the TPB server is
no longer available and responds by
holding all active phases within. If
the TPB server detects that the
controller does not reset the
watchdog, it assumes that
communication to all tags defined in
the data server connection is not
reliable. Batches using any of these
tags is in response when the
communication problems occur.
XOR Provides an up to 8-input XOR Turns digital output (OUT):
algorithm, meaning it performs the
• OFF when even number of
exclusive OR function.
inputs (2, 4, 6, or 8) are ON.
OUT = IN[1] XOR IN[2] XOR IN[3] • ON when odd number of
… XOR IN[n] inputs(1, 3, 5, or 7) are ON.
Each input (IN[1], IN[2], …, IN[8]) This action adheres to the IEC DIS
has the capability of being optionally 1131-3 standard. But, this may not
inverted, if required. be the expected behavior for an
XOR with more than two inputs.
27.1.1 Parameters-Logic Functions Blocks

Refer to the Control Builder Components Reference for a complete list of the parameters used with the named
logic function block.
27 LOGIC FUNCTIONS
27.2 Change Execute (CHGEXEC) Block

The CHGEXEC block provides the following main features to help you design change driven logic strategies
within Control Modules (CMs).
• Supports up to 32 change detected Boolean inputs.
• Supports output of captured inputs to downstream blocks to prevent consumption of inconsistent data during
CM execution.
• Supports a cascade output that allows operation of multiple CHGEXEC instances to be coordinated.
• Supports a slow, periodic, background execution for convenience in strategy design.
• Supports engineer-only test options which allow strategy designers to force it to suspend background
execution or to execute continuously in the absence of input changes.
You can only use the CHGEXEC block with blocks that are qualified to run under change driven execution.
Most Experion Control 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.
Table 57: CHGEXEC block graphical representation in control drawing
861
27 LOGIC FUNCTIONS
27.3 CHGEXEC Usage Considerations for Change Driven Execution

The following table summarizes some things you need to consider before using CHGEXEC blocks in Control
Modules to create change driven execution strategies.
When you use CHGEXEC to Then, take this into consideration

Optimize Control Module performance CHGEXEC receives a set of Boolean inputs and identifies if and when they
when used exclusively for logic change. If any input has changed since the last execution cycle, the CM
computation. containing the CHGEXEC block 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 unexecuted for
that cycle to optimize performance.
Create Control Module logic strategies Using CHGEXEC to create CM logic strategies that execute most of their logic
to execute most of their logic by by exception, reduces the average processing power consumed by the strategy.
exception.
Be sure you are fully aware of the advantages, disadvantages and constraints of
designing control strategies that execute by exception. You are responsible for
identifying and resolving any design issues with your given strategy.
Vary the control module's processing When ordinary CMs are scheduled to run continuously, it is relatively easy to
load. 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.
Application engineers must make sure that no single CM/CHGEXEC logic
strategy uses too large a proportion of the processing budget for any given cycle,
when executing with input changes. Engineers are responsible for insuring that
the overall controller execution is stable and without overruns for all conditions
of input changes which impact change driven execution. It might be necessary
for engineers to leave some or all CEE execution cycles more lightly loaded
than they would under other conditions.
Another design concern is the kinds of basic blocks that can run within a CM
with a CHGEXEC block. Since most CEE blocks are intended to run
continuously, their design depends on a parent that runs at its configured period
without fail. These blocks will malfunction, if they do not run every period.
You can use a subset of CEE blocks in a change driven execution environment
because they do not need to run continuously. See the following section for a list
of these blocks and do not use other blocks for change driven execution.
27 LOGIC FUNCTIONS
27.4 Change Driven Application Risk Factors

The characteristics of change driven control strategies present a greater design risk than continuous applications.
Application engineers must keep the following risk factors in mind and take greater care in designing such
strategies.
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.
Risk Factor What does it mean

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.
Variability of Execution Load Execution load of a change-driven strategy varies tremendously depending on
whether or not an input change has occurred. The statistical rate of input
changes impacts the average CPU consumed by the controller. Bursts of input
changes impact the peak CPU consumed by the controller. The risk of overruns
is greater, since It is more difficult to assess the total controller load when
change driven strategies are used.
Multiple CHGEXEC blocks in same Most change driven configurations only work with single CHGEXEC defined
Control Module 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.
To benefit from the use of a CHGEXEC block, the rate of input change must be
substantially slower than the CM's rate of execution. If the logic configuration is
large, then the addition of the CHGEXEC will add only a small percentage to
the CM processing time. If the logic configuration is small, then the addition of
the CHGEXEC could increase the CM processing time by 20 percent or more.
Application engineers must carefully judge whether the use of a CHGEXEC
block is beneficial to the application.
863
27 LOGIC FUNCTIONS
27.5 Blocks Qualified for Use with CHGEXEC Block

The following table identifies blocks in a given Control Builder Library that are qualified or not qualified for
use within a Control Module containing a CHGEXEC block.
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.
CAUTION
Neither Control Builder nor the CEE prevent application engineers from 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.
Block Type Qualified For Comment

Use With
CHGEXEC
DEVCTL Library
DEVCTL No DEVCTL is a large block that integrates substantial functionality. It has been
designed to run within a continuously executing CM and will not function
properly in a change-driven CM. DEVCTL design incorporates change driven
execution internally so its CPU load is comparatively light.
LOGIC Library
2OO3 Yes
AND Yes
CHECKBAD Yes
CHECKBOOL No Design of the CHECKBOOL block is not tolerant of change-driven execution.
It can only function properly within a continuously executing CM.
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
27 LOGIC FUNCTIONS

Use With
CHGEXEC
MAXPULSE Yes Blocks whose operation involves timing (MAXPULSE, MINPULSE,
OFFDELAY, ONDELAY, NOON, PUSH, PULSE, TIMER, WATCHDOG)
use a special technique to prevent the accumulation of timing errors across
sporadic cycles of change driven execution. However, they can only change
output state when they execute. When used with the CHGEXEC block, the
granularity of their time response is limited by the auto-trigger period. Output
reaction can occur from 1 to 2 seconds after the timeout has expired. Be aware
that timing blocks whose execution is gated by an instance of CHGEXEC will
not work at all when
TESTOPT = NOAUTOTRIG.
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
865
27 LOGIC FUNCTIONS

Use With
CHGEXEC
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.
Block TIMER is designed so that it behaves differently depending on the
value of its configuration parameter, TIMEBASE. When TIMEBASE =
SECONDS or TIMEBASE = MINUTES the block works as a clock-based
timing object. The timing operation is correct under normal execution and
under change driven execution to within the error of the auto-trigger period.
However, when TIMEBASE = CYCLES the TIMER block operates as a
counter rather than a timer. It counts the number of times it has executed since
its state changed to RUNNING. Under normal, periodic execution this is
equivalent to timing with a time base of execution periods. Under change
driven execution it is not equivalent to any rigorous timing operation. Under
change driven execution a TIMEBASE of CYCLES may be used to count
executions but not to do timing.
TYPECONVERT Yes
27 LOGIC FUNCTIONS
27.6 Experion Controller Platform Support for CHGEXEC

The following table lists the Experion Controller/CEE Platforms that support the CHGEXEC block.
Tip
You can test CM strategies employing CHGEXEC blocks either on simulation platforms or controller platforms. As
with any CM, the CMs with CHGEXEC blocks do not need to be modified in any way when moved between
controllers and simulators.
Controller Simulator CEE Base Cycle CHGEXEC Supported

ACE Soft Controller SIM-ACE Simulator 0.5 seconds Yes
C300 Embedded Controller SIM-C300 Simulator 50 milliseconds Yes
C200E Embedded Controller SIM-C200E Simulator 50 milliseconds Yes
C200 Embedded Controller -------- 5 milliseconds No1
1 A C200/C200E Controller does not support the CHGEXEC block. The following occurs when an application engineer
attempts to use a CM containing a CHGEXEC instance with any of these platforms.
• When the CM is loaded to the CEE the load fails.
• The returned error message is “Component block type reference error”, error number 101.2013.
1 The C200 Controller does not support the CHGEXEC block. When an application engineer attempts to load a CM
containing a CHGEXEC instance to the CEEC200, the load fails. The message "Component block type reference error"
(error number 101.2013) appears.
867
27 LOGIC FUNCTIONS
27.7 CHGEXEC Main Parameter Details

The following table identifies the main configuration parameters associated with a CHGEXEC block and
defines their function.
If Parameter Is . . . Then, Its Function Is . . .

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.
DATA[ ] is also used as an output. This allows input values to by captured and frozen within
the CHGEXEC so that subsequent logic is guaranteed to see the same values as those which
triggered change driven execution. See the Consistent Data Usage section for more
information.
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.
RIGGER An output parameter of type Boolean which can be used to create cascades of CHGEXEC
blocks, either within a single CM or across multiple CMs. TRIGGER can be connected to
one of the DATA[ ] inputs of a downstream CHGEXEC to force it to allow the parent CM to
run to completion even if none of its other inputs have changed.
TRIGGER changes from Off to On or from On to Off in all cycles where the owning
CHGEXEC allows the parent CM to run to completion. This is true even in cases such as
auto-trigger (discussed below) where the inputs may not have changed state.
Whenever the parent CM of a CHGEXEC is activated, TRIGGER emits a transition on the
first cycle of execution and another transition on the second cycle of execution. This insures
that a downstream, cascaded CHGEXEC instance will execute by the second cycle,
regardless of what values it holds in LASTDATA[ ].
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.
EXITOPT A configuration parameter of type enumeration which can optionally be used to cascade
CHGEXECs within a single CM. Possible values are EXITONEQU (“Exit On Equal”) and
CONTONEQU (“Continue On Equal”).
• CHGEXEC behavior when EXITOPT is configured as EXITONEQU is as follows.
– If all DATA[ i] are equal to their corresponding LASTDATA[ i], then TRIGGER is
left unchanged and CHGEXEC forces the parent CM to exit immediately. If any
DATA[ i] are not equal to their corresponding LASTDATA[ i], then TRIGGER is
changed and CHGEXEC allows the parent CM to keep executing.
– EXITOPT == EXITONEQU corresponds to the majority use case for CHGEXEC and
is the default configuration.
• CHGEXEC behavior when EXITOPT is configured as CONTONEQU is as follows.
– If all DATA[ i] are equal to their corresponding LASTDATA[ i], then TRIGGER is
left unchanged and CHGEXEC allows the parent CM to keep executing. If any
DATA[ i] are not equal to their corresponding LASTDATA[ i], then TRIGGER is
changed and CHGEXEC allows the parent CM to keep executing. EXITOPT ==
CONTONEQU is used on rare occasions where more than 32 inputs need to be
monitored. In this case two CHGEXECs would be placed within the same CM with
each CM using different configurations of EXITOPT. See the section for more
information.
NUMDATA A configuration parameter which controls how many elements of the DATA[ ] array are
scanned each time CHGEXEC executes. All elements at index greater than NUMDATA are
ignored. NUMDATA ranges from 1 to 32
27 LOGIC FUNCTIONS
If Parameter Is . . . Then, Its Function Is . . .

AUTOPERIOD A configuration parameter which controls the period of background processing within a
CHGEXEC. When inputs are static for an extended interval CHGEXEC auto-triggers so that
the parent CM may run to completion. The auto-trigger happens at the end of the
AUTOPERIOD interval if and only if no inputs have changed during that interval.
AUTOPERIOD is an enumeration with a default value of “1sec”. It's range of supported
values are: 500mS, 1sec, and 2sec.
AUTOPHASE A configuration parameter which controls the phasing of periodic auto-trigger processing
within a CHGEXEC. AUTOPHASE prevents large numbers of CHGEXEC instances from
synchronizing in such a fashion that their periodic processing occurs on the same CEE cycle.
AUTOPHASE may be explicitly assigned by the application engineer, but this happens
rarely. Usually engineers prefer to leave AUTOPHASE at its default of -1. This causes the
CHGEXEC to assign a random phase value within the allowed range at time of block load.
Once assigned, the value of AUTOPHASE is preserved across RRR and across checkpoint
save/restore. This causes load impact from CHGEXEC background processing to be held
constant across CEE processing cycles when a controller restart occurs.
TESTOPT A parameter which can optionally be used by application engineers when testing CHGEXEC
strategies using one of the following values.
• NOTEST, EXECALL, and NOAUTOTRIG
TESTOPT defaults to NOTEST. In this configuration CHGEXEC behaves as normal with no
deviations from prescribed behavior.
When TESTOPT = EXECALL, CHGEXEC allows its parent CM to run to completion on
every execution period, regardless of whether inputs have changed or any other conditions.
This option can be used to test the level of loading that occurs when change driven execution
happens.
When TESTOPT = NOAUTOTRIG, CHGEXEC executes as normal except that there is no
auto-trigger processing. In this case the CM executes only in response to input changes (or
system state changes) regardless of the value of AUTOPERIOD. This option can be used to
verify that change triggering works as expected, with no possibility of defects masked by
background periodic execution.
When CHGEXEC is commissioned for on process control, TESTOPT must have the value
NOTEST. Application engineers must be sure not to leave TESTOPT at EXECALL or
NOAUTOTRIG after testing is complete.
869
27 LOGIC FUNCTIONS
27.8 CHGEXEC Cascading Between Control Modules Example

While most change driven logic strategies will use a single CM, you can use CHGEXECS blocks within
different Control Modules. This is like a cascaded CHGEXEC where the TRIGGER parameter in the
CHGEXEC in the first CM triggers the CHGEXEC in the second CM, as shown in the figures below.
Figure 21: Control Modules With Cascaded CHGEXEC Instances
27.8.1 Graphical Examples of Cascaded CHGEXEC control charts

The following figures show the sample control charts for implementing cascaded CHGEXEC blocks between
the two Control Modules shown in the figure above.
Figure 22: Primary Control Module in Cascaded CHGEXEC (CM_CHGEXEC_PRI)
27 LOGIC FUNCTIONS
Table 58: Secondary Control Module in Cascaded CHGEXEC (CM_CHEXEC_SEC)
27.8.2 Cascaded CHGEXEC functional considerations

The following table summarizes some functional considerations associated with implementing a cascaded
CHGEXEC application.
Consideration Description
Coordinated Logic A CHGEXEC cascade crossing CM boundaries would probably involve coordinated logic,
which had been partitioned across modules. Such strategies would typically execute with the
same PERIOD and PHASE values. This is shown in the Control Module figures above.
Block Execution Order Order of block execution must be deliberately assigned for any CM strategy, but especially
for CHGEXEC strategies. Often the CHGEXEC will run 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 Execution When a change-driven logic strategy is split across CMs, execution order of the CMs must
Order 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.
TRIGGER with Multiple In cascaded CHGEXEC strategies, multiple secondaries can follow a single primary with all
Secondaries consuming the primary's TRIGGER output. In this case, each of the secondary CHGEXEC's
would be triggered to run to completion by a change in the primary's TRIGGER parameter.
Secondary Control Module Be careful when building CHGEXEC cascades across CMs. In some strategies, it may save
Output Connections time to have the secondary CM connect to 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
871
27 LOGIC FUNCTIONS
Consideration Description
Cascades that Cross CEE Be careful when using CHGEXEC cascades that cross CEE boundaries. In general, if a
Boundaries 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 should explicitly pass
all output data from the primary through the CHGEXEC.
27 LOGIC FUNCTIONS
27.9 CHGEXEC Cascading Within Control Module Example

You can cascade CHGEXEC blocks within a single Control Module. This would be the exception and the only
reason would be to support a logic strategy requiring more than 32 change driven inputs, as shown in the figure
below.
Attention
The following figure shows the leading CHGEXEC with only two data elements, which is inaccurate. A second
CHGEXEC would be introduced to support additional inputs only after those of the first had been exhausted.
Figure 23: Cascaded CHGEXEC Within Single Control Module
27.9.1 EXITOPT considerations for cascaded CHGEXEC in single CM

As shown in the figure above, EXITOPT is assigned different values in the leading and following CHGEXEC
blocks. On the leading CHGEXEC(A) it is set to CONTONEQU. This allows the following CHGEXEC(B) to
do its own change detection regardless of whether the first has seen input changes. On the following
CHGEXEC(B), the EXITOPT is set to EXITONEQU as usual. The following CHGEXEC(B) is the one which
decides whether or not to exit the CM. The leading CHGEXEC(A) never exits.
If multiple CHGEXEC blocks are placed within the same CM, the only configuration which will work is the
one shown in the figure above. More specifically, the following requirements must be met whenever two
CHGEXEC blocks are placed within the same CM.
• The leading CHGEXEC must have EXITOPT = CONTONEQU.
• The following CHGEXEC must receive the TRIGGER output of the leading CHGEXEC as an input.
873
27 LOGIC FUNCTIONS
27.10 Importance of Using Consistent Input Data

If a CHGEXEC block controls the execution of Logic blocks that also use the data monitored by the
CHGEXEC, the Logic blocks must pull this data from the CHGEXEC itself for the following reasons.
• The CM connections are quite flexible. They allow data flow to be configured through both wired
connections or parameter connections. They allow parameters to be fetched from within the same CM, from
different CMs in the same CEE, from CMs in a different CEE or from IO modules outside the CEE.
• If a CM is designed so that two different connectors reference the same output parameter, CEE
implementation does not guarantee that these connections will return the same data value when the CM
executes. For non-local data in particular, such as certain kinds of IO data, each connector can spawn a
different fetch request. Though not likely, it is possible for the referenced parameter to change state between
the servicing of two different fetch requests. This would cause two different values of the same parameter to
be used during CM execution.
• This design issue exists regardless of whether a CHGEXEC is used in the design of a logic strategy. If On /
Off data is consumed more than once within the strategy best practice is to pull that data into local storage
and have the multiple consumers pull from common storage. But failure to follow this practice is less critical
if the CM executes continuously. Any anomalous result will be transient and corrected by the time of next
execution.
27.10.1 Wrong input data example

In CM strategies which use CHGEXEC the consequences of inconsistent data are more critical. For example,
suppose that a DI PV is used by a logic gate. The PV would be connected to one of the DATA[ i] inputs of the
CHGEXEC for change monitoring. The PV might also be connected directly to the input of the logic gate, as
shown in the following figure.
Now suppose that the CHGEXEC sees a change in the digital PV and allows the logic gate to execute. In such a
case there is no guarantee that the logic gate will see the same value of PV that was seen by the CHGEXEC. It
might even see the old value that held before PV had changed. Such a condition could lead to unpredictable
results and would constitute a defect in the CM design. It might be hard to debug such a defect. Occurrence
would depend on timing coincidence and might happen rarely.
Figure 24: Wrong Use Of CHGEXEC: Downstream Logic Pulls Change Data Directly
27 LOGIC FUNCTIONS
27.10.2 Correct input data example

Based on the previous example, the proper configuration would be one which pulled the corresponding
CHGEXEC output instead of directly pulling the DI PV, as shown in the following figure.
Based on these considerations, CMs using CHGEXEC must always be designed so that the CHGEXEC and
subsequent logic use the same image of fetched parameter data. The most natural way to accomplish this is to
have the elements of DATA[ ] exposed as both inputs and outputs on the CHGEXEC instance. The input
DATA[ ] will typically connect to parameters outside the CM or to I/O within the CM. The output DATA[ ] will
be referenced by downstream logic within the CM.
Figure 25: Correct Use Of CHGEXEC: Downstream Logic Pulls From CHGEXEC Output
875
27 LOGIC FUNCTIONS
27.11 Periodic Auto Trigger Function of CHGEXEC

In addition to its main activity of gating change-driven execution, the CHGEXEC block also supports a periodic
auto trigger activity. Auto trigger puts an upper limit on how much time can pass before the parent CM is
allowed to run to completion.
The period of auto-trigger is configured with parameter AUTOPERIOD. Precisely what this means is described
below. Note that for specificity in the description we assume that EXITOPT has the value which corresponds to
the majority use case (EXITOPT set to EXITONEQU ).
• At the end of every time interval of length AUTOPERIOD, CHGEXEC checks whether an execution has
occurred within the preceding interval for any reason (for example, input change or state change). If so, and
if no inputs have changed since the last cycle, CHGEXEC postpones the auto-trigger for another
AUTOPERIOD and causes the parent CM to exit. If not, CHGEXEC allows the parent CM to run to
completion notwithstanding the absence of input change or state change.
• When TESTOPT == EXECALL, there is no auto-trigger processing since the CM executes to completion
once every cycle.
27.11.1 Auto Trigger application support

The CHGEXEC blocks support of auto-trigger meets the following two needs in applications scenarios.
Application Need Auto Trigger Support

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” on
page 864 can be used within change driven strategies as long as a time out
response on the order of seconds is sufficiently fast.
27.11.2 ATUOPERIOD sets period for Auto Trigger

When inputs aren't changing at all, CMs are allowed to run to completion exactly once every AUTOPERIOD.
When no inputs are changing this is the amount of time that passes between executions. However, when inputs
do change they can have the effect of postponing the next auto-trigger.. The largest period of time that can pass
before an auto-trigger fires is as follows.
• 2 * AUTOPERIOD - Control Module PERIOD
The CHGEXEC block's auto-trigger activity is specifically designed to disallow multiple executions within a
single AUTOPERIOD interval. Doing otherwise would cause undesirable behavior in CHGEXEC cascades. It
would cause downstream CMs to have an effective auto-trigger period of N times AUTOPERIOD where N is
the depth of the cascade.
27 LOGIC FUNCTIONS
27.11.3 TRIGGER output and Auto Trigger execution

The behavior of the TRIGGER output with respect to auto trigger execution can be a source of confusion. The
following rule applies regardless of the value of the EXITOPT parameter.
• TRIGGER toggles whenever the parent CM is allowed to run to completion, regardless of whether the grant
of execution arises from change of inputs, expiration of the auto-trigger period or state transition.
27.11.4 Relationship between Auto Trigger and AUTOPHASE for synchronization prevention
The CHGEXEC block is designed to prevent large numbers of change driven strategies from synchronizing so
that their auto triggers occur on the same processing cycle. Such synchronization could lead to processing
overruns. It works by assigning a fixed auto-trigger phase to each instance as a random number. This spreads
out the auto-trigger executions across the available CEE cycles. The key configuration considerations are as
follows.
• The auto-trigger phase can be read from parameter AUTOPHASE and can also be assigned through that
parameter if desired. Normally, AUTOPHASE is left at its default of -1 when a CHGEXEC block is first
configured. This causes CHGEXEC to assign a random value within the allowed range when the instance is
loaded. If AUTOPHASE is not -1 upon load its value is accepted and left unchanged.
• If application engineer feel that the current value of AUTOPHASE is undesirable they may assign a new
value. To do this, they can choose a value between the limits of 0 and M - 1, where M is the maximum
allowed AUTOPERIOD divided by the controller base cycle. Or, they may simply assign the value of -1
again. This causes a new, probably different, random value to be assigned to AUTOPHASE.
• The value of AUTOPHASE is preserved across RAM Retention Restart and across checkpoint save /
restore. This means that the processing load from periodic auto-trigger which is seen by each cycle will not
change when the CEE restarts. Note, however, that AUTOPHASE is not preserved across CM reload unless
the application engineer takes deliberate action. If AUTOPHASE has been left at -1 within the CB project
configuration then reloading will cause a new AUTOPHASE value to be assigned. To avoid this, the
application engineer should do Control Builder Upload and Update on the parent CM after AUTOPHASE
been assigned.
27.11.5 AUTOPERIOD configuration restrictions

When the AUTOPERIOD value of a CHGEXEC instance is configured it must be consistent with the PERIOD
configuration of the parent Control Module. What is meant by “consistent” in this case is the following.
• CHGEXEC.AUTPERIOD greater than CM.PERIOD
• CHGEXEC.AUTOPERIOD / CM.PERIOD = a whole number
This consistency requirement has the effect of disallowing certain combinations of CHGEXEC.AUTPERIOD
and CM.PERIOD. Allowed and disallowed configurations are shown in the following table where period values
have units of seconds.
Control Module CHGEXEC AUTOPERIOD Platform

Period
0.50 1.00 2.00
0.05 Supported Supported Supported C200/C200E, C300
0.10 Supported Supported Supported C200/C200E, C300
0.20 Not Supported Supported Supported C200/C200E, C300
0.50 Not Supported Not Supported Supported C200/C200E, C300, ACE
1.00 Not Supported Not Supported Supported C200/C200E, C300, ACE
877
27 LOGIC FUNCTIONS
Control Module CHGEXEC AUTOPERIOD Platform

Period
Greater Than or Not Supported Not Supported Not Supported C200/C200E, C300, ACE
Equal 2.00
• If a CHGEXEC and CM are configured with inconsistent AUTOPERIOD and PERIOD values in Control
Builder Project side and then loaded, the inconsistency is detected when the CM is activated after load. Error
status “Configuration Mismatch” is returned and the CM is not allowed to activate.
• If AUTOPERIOD is changed on a running CHGEXEC then any inconsistency is detected at the time of
parameter store resulting in return of error status “Configuration Mismatch” and rejection of the
AUTOPERIOD value.
27 LOGIC FUNCTIONS
27.12 Execution Order Considerations for CHGEXEC within CM

When using CHGEXEC within a CM, the application engineer has the option to divide execution flow into two
segments.
• Execution Segment 1: Blocks ordered to execute ahead of the CHGEXEC.
• Execution Segment 2: Blocks ordered to execute after the CHGEXEC.
Normally CHGEXEC would be the first or one of the first blocks to execute within a change driven CM. In this
case, Execution Segment 1 would be completely empty or nearly empty. However, if appropriate, the
application engineer could place substantial block content ahead of the CHGEXEC instance. In this case, only
the blocks following the CHGEXEC would execute on a change driven basis.
Any blocks which are ordered to execute ahead of the CHGEXEC are not subject to the restrictions which apply
to change driven execution. This means that unqualified blocks can be placed within a CM that hosts a
CHGEXEC as long as they are ordered to execute ahead of any CHGEXEC. Application engineers should
exercise caution, if they choose to apply this technique so that no mistakes are made with block ordering.
879
27 LOGIC FUNCTIONS
27.13 CHGEXEC Behaviors for State Transitions

The CHGEXEC block implements defined behaviors across all transitions that effect its parent CM or its parent
CEE. These are described in the following table.
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.
• The TRIGGER toggles whenever the parent CM is allowed to run to completion. Consequently, it toggles at least
once whenever a state change occurs.
State Transition CHGEXEC Parameter Behavior

DATA[ ] LASTDATA[ ] TRIGGER
Load of Parent CM Off Off Off CM and children do not
execute until CEESTATE
goes to Run and
EXECSTATE goes to Active.
Activation of Unchanged until Unchanged until set Changes state on first On first cycle CM and
Parent CM inputs are pulled on equal to DATA[ ] on cycle of execution. children start executing.
first cycle of first cycle of Changes state again on CHGEXEC overrides change
See Note 1
execution. execution. second cycle of detection to allow CM to run
execution. to completion regardless of
whether or not DATA[ ] has
See Note 4
changed.
Inactivation of Unchanged Unchanged Unchanged CM and all children stop
Parent CM executing.
CEE Execution Unchanged until Unchanged until set Changes state on first On first cycle CM and
Start inputs are pulled on equal to DATA[ ] on cycle of execution. children start executing.
first cycle of first cycle of CHGEXEC overrides change
See Note 2 See Note 4
execution. execution. detection to allow CM to run
See Note 5 to completion regardless of
whether or not DATA[ ] has
changed.
CEE Execution Unchanged Unchanged Unchanged CM and all children stop
Stop executing.
Redundancy Role Unchanged until Unchanged until set Unchanged unless CM and children run to
Change inputs are pulled on equal to DATA[ ] on DATA[ ] has changed completion or exit early
first cycle of first cycle of since last execution based on normal operation of
See Note 3
execution. execution. before role change. CHGEXEC. CHGEXEC
does not override change
detection.
27 LOGIC FUNCTIONS

Note:
1. Activation of
Parent CM
consists of the
following
transition.
• EXECSTA
TE changes
from
Inactive to
Active on
parent CM
when
CEESTAT
E is Run.
2. CEE Execution
Start can be
any of the
following
transitions.
• Cold
Restart
changes
CEESTAT
E from Idle
to Run
when
EXECSTA
TE of
parent CM
is Active.
• Warm
Restart
changes
CEESTAT
E from Idle
to Run
when
EXECSTA
TE of
parent CM
is Active.
• RAM
Retention
Restart
when
CEESTAT
E is Run
and
EXECSTA
TE of
parent CM
is Active.
3. CEE Execution
Start can be
any of the
881
27 LOGIC FUNCTIONS

following
transitions.
• Cold
Restart
changes
CEESTAT
E from Idle
to Run
when
EXECSTA
TE of
parent CM
is Active.
• Warm
Restart
changes
CEESTAT
E from Idle
to Run
when
EXECSTA
TE of
parent CM
is Active.
• RAM
Retention
Restart
when
CEESTAT
E is Run
and
EXECSTA
TE 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
27 LOGIC FUNCTIONS

(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
883
27 LOGIC FUNCTIONS

more overruns
will occur
within a
properly
balanced CEE
configuration.
CEE will not
report any
alarms as a
result of startup
transition
overruns.
27 LOGIC FUNCTIONS
27.14 CHGEXEC Supports Checkpoint Function

Checkpoint save of a CHGEXEC block persists all configuration data. The following parameters are read upon
checkpoint save and recovered upon checkpoint restore.
• EXITOPT
• NUMDATA
• AUTOPERIOD
• AUTOPHASE
• TESTOPT
Dynamic data of a CHGEXEC block is not persisted as a result of checkpoint save. Upon checkpoint restore the
following parameters take the same values they do following configuration load (Off for Booleans and 0 for
Integers).
• DATA[ ]
• LASTDATA[ ]
• TRIGGER
• CHGINDEX
885
27 LOGIC FUNCTIONS
27.15 Load Monitoring Parameters

As part of strategy development, application engineers can monitor CPU usage parameters to gauge processing
load. Relevant instrumentation parameters include the following.
• CPUCYCLEAVG (CEE block)
• CPUCYCLEMAX (CEE block)
• CPUFREEAVG (CEE block or Platform block)
• CPUFREEMIN (CEE block or Platform block)
• CRCYCLEORN (CEE block)
• LSCYCLEORN (CEE block)
• STATSRESET (CEE block)
The CPUCYCLEAVG, CPUCYCLEMAX, CRCYCLEORN and LSCYCLEORN are array parameters which
cover each cycle plus one additional element. The last element (index 40 in the case of C300) gives an average
across all cycles.
Three statistics which are particularly useful are the following.
• CRCYCLEORN[40]
• CPUCYCLEAVG[40]
• CPUCYCLEMAX[40]
In applications where logic is running at the fastest period, these three numbers alone give a good summary of
load effects. Application engineers can monitor these parameters during development to get a good sense of
strategy performance
27 LOGIC FUNCTIONS
27.16 Sample CHGEXEC TESTOPT Procedure

During performance assessment, application engineers can use the configuration TESTOPT = EXECALL to
compare a CM's processing load with and without input changes. There is no required methodology for doing
this. The following table offers a sample procedure.
Stage Description
1 Implement the CHGEXEC CM as well as any cascaded CMs whose implementation is closely coupled.
2 Make sure all CMs of interest are loaded and active.
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.
6 Start with TESTOPT = NOTEST as per default CHGEXEC configuration.
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.
8 Let 3 minutes pass after setting STATSRESET in order for averages to equilibrate.
9 Verify that CRCYCLEORN[40] is zero. If it is not zero, verify that it is not changing. Any overruns during the
course of the test would invalidate the results.
10 Record the value of CPUCYCLEAVG[CYCLE].
11 Set TESTOPT to EXECALL.
12 Set STATSRESET to ON. Let 3 minutes pass for averages to equilibrate.
13 Verify that CRCYCLEORN[40] has not changed.
14 Record the value of CPUCYCLEAVG[CYCLE].
15 Subtract the first value of CPUCYCLEAVG[CYCLE] from the second. This difference gives the value, in % of
cycle execution, of the processing load of the CMs under test with and without input changes.
16 Set TESETOPT back to NOTEST.
887
27 LOGIC FUNCTIONS
27.17 Examples and scenarios
Related topics
“CheckBool functionality” on page 888
“CheckBool scenario 1” on page 890
27.17.1 CheckBool functionality

The CHECKBOOL block evaluates its input connections and passes these input values through to its associated
outputs. You should use the CHECKBOOL block as a front end to any critical Boolean function block which
requires their inputs be deterministic. Its primary function is to interconnect Control Modules to preserve data
integrity. You can do this by placing a CHECKBOOL block on each end of a Control Module to Control
Module link and then connecting the blocks. The following illustrations show a simple control strategy
configuration using CHECKBOOL blocks to link the Source Module to the Receive Module in both Project and
Monitoring modes.
Table 59: Sample CHECKBOOL Strategy linking Control Modules in Project Mode
27 LOGIC FUNCTIONS
Table 60: Viewing Sample CHECKBOOL Strategy Linking Control Modules in Monitoring Mode
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.
889
27 LOGIC FUNCTIONS
27.17.2 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.

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.
27 LOGIC FUNCTIONS

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.
891
27 LOGIC FUNCTIONS

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.
27 LOGIC FUNCTIONS
893
27 LOGIC FUNCTIONS
27.18 Contact Monitoring (CONTACTMON) Block
27.18.1 Function-CONTACTMON block

Enables alarm generation whenever the state of both inputs is same or different based on the NORMAL state
configuration.
With R410, the following parameters are introduced to configure the on-delay time and off-delay time for bad
PV alarm. The parameters are:
• On-Delay Time (BADPVALM.TM) - With R410, this parameter is introduced to define the duration in
seconds during which a process alarm reporting is suppressed. This helps in preventing the nuisance alarms
from being reported repeatedly during the process upset and improves the efficiency of the operator. Once
you configure this value for an alarm, the alarm is reported on the Station only if the alarm condition
continues to exist even after this value expires. The default time is 0; that is the alarm is reported as soon as
You can configure individual deadband time for BADPVALM. However, if you are migrating from pre-
R410 to later releases, refer to “Impact of migration on alarm attributes” on page 221.
• Off-Delay Time (BADPVALM.TMO) - With R410, this parameter is introduced to define the duration in
seconds during which an RTN reporting is suppressed even though the alarm condition does not exist. The
RTN is reported on the Station only after this time expires and the alarm condition has returned to normal.
The default time is 0; that is RTN is reported as soon as the alarm condition returns to normal. However, if
you are migrating from pre-R410 to later releases, the alarm off-delay time will be set as default value (0).
27.18.2 Predecessor Block-CONTACTMON 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.
27.18.3 Execution-CONTACTMON block

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:
IN[0] IN[1] PVFL OUT1 OUT2

ON ON ON OFF OFF
27 LOGIC FUNCTIONS
IN[0] IN[1] PVFL OUT1 OUT2

ON OFF OFF ON OFF
OFF ON OFF OFF ON
OFF OFF 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:
PVFL STATE0 STATE1 NORMAL Alarm Generated

ON OFF ON State0 Yes
OFF ON OFF State0 No
OFF ON OFF State1 Yes
ON OFF ON State1 No
X X X None No
895
27 LOGIC FUNCTIONS
28 Math Functions
Related topics
“Math Function Blocks” on page 898
897
28 MATH FUNCTIONS
28.1 Math Function Blocks

The Math Function Blocks add a library of blocks similar to the Logic blocks. These blocks are self describing
and expression-less basic blocks that are always contained within a Control Module. The Control Module must
be given a system-wide unique name (tag name), while the Math blocks only need to be given a name that is
unique within the scope of the containing Control Module.
The Math blocks do not have an Execution State (EXECSTATE) and Execution Period (PERIOD) of their own.
They will always follow the EXECSTATE and PERIOD of the Control Module that contains them.
Unless noted otherwise bad values will propagate according to the following IEEE rules:
• If a NaN input is encountered when calculating, the result (and the output) shall be NaN.
• Disconnected inputs have a default value of zero (with the exception of multiply where the input(s) default is
one).
• Infinity values will be considered according to IEEE 754 floating point computation rules. For instance,
+INF - (+INF) = NaN, so any sum including positive infinity and negative infinity values will result in a
NaN output value.
28.1.1 Available Math blocks and size

The following table lists the Math blocks that are available in Library by name, function and approximate size.
Block Library Function Approximate Size in Bytes

Name
ABS Absolute value 50
ADD Sum of n arguments 110
DIV Division 60
EXP e to the power of x 50
LN Natural logarithm of a number (log to the base of e) 50
LOG Base 10 logarithm of a number 50
MOD (x MOD y) 60
MUL Product of n arguments 110
NEG -(x) 50
POW (x^y) 60
ROUND Rounded up to nearest integer value 50
SQRT square root 50
SUB Subtraction 60
TRUNC Round down to nearest integer value 50
ROLLAVG Rolling average 120
This does not include the
auxiliary memory buffer
that is based on the
number of samples
configured by the
function block user.
28 MATH FUNCTIONS
28.1.2 Math blocks functional description

The following table provides a description and a brief explanation of the functional capabilities of the named
function block. In most cases, the name of the block is intuitive of its function.
Block Name/ Description Function

Graphic
ABS Provides the absolute value function. At runtime, the output (OUT)
becomes the absolute value of the
user connected input (IN[1]).
ADD Provides the addition function. Sums the value of the number of
inputs (IN[1..8]) configured by the
user as the output (OUT).
DIV Provides the divide function. At runtime, the output (OUT)

becomes the quotient of input 1
(IN[1]) divided by input 2 (IN[2]).
EXP Provides the exponent function. At runtime, the output (OUT)

becomes the exponent of the user
connected input (IN[1]).
LN Provides the natural logarithm At runtime, the output (OUT)

function. becomes the natural logarithm of
the user connected input (IN[1], log
to the base of e).
LOG Provides the logarithm function. At runtime, the output (OUT)

becomes the base 10 logarithm of
the user connected input (IN[1]).
899
28 MATH FUNCTIONS

Graphic
MOD Provides the modulo function. At runtime, the user connected
inputs (IN[1], IN[2]) are truncated
to integer and the output (OUT)
becomes the Remainder of IN[1]
divided by IN[2].
MUL Provides the multiply function. At runtime, the output (OUT)

becomes the Product of the user
connected inputs (IN[1..8]).
NEG Provides the negative function. At runtime, the output (OUT)

becomes the negative (-) equivalent
of the user connected input (IN[1]).
POW Provides the raise to power function. At runtime, the output (OUT)
becomes the user connected input 1
(IN[1]) raised to the power the user
connected input 2 (IN[2]).
ROUND Provides the round up function. At runtime, the output (OUT)

becomes the user connected input
(IN[1]) rounded up to the nearest
integer value.
SQRT Provides the square root function. At runtime, the output (OUT)
becomes the square root of the user
connected input (IN[1]).
SUB Provides the subtract function. At runtime, the output (OUT)

becomes the user connected input 1
(IN[1]) minus the user connected
input 2 (IN[2]).
28 MATH FUNCTIONS

Graphic
TRUNC Provides the truncate function. At runtime, the output (OUT)
becomes the user connected input
(IN[1]) rounded down to the
nearest integer value.
ROLLAVG Provides the rolling average function. At runtime, the output (OUT)
becomes the quotient of sum of all
good samples (IN) divided by
number of good samples.
28.1.3 Rolling Average block-CONTACTMON block

Rolling averages are used for monitoring, control, and calculations. Sometimes government regulations require
rolling average calculations. Rolling averages are used in many control and database applications.
Attention
Rolling Average Function blocks can be loaded and operated only in a C200E, C300, or ACE.
The Rolling Average algorithm is based on the following:

1. Collect input samples at a specified frequency (some multiple of CM Period). If you do not set the frequency
as a multiple of CM Period, you can load the Rolling Average function block successfully but cannot
initialize the average calculation.
2. Save the samples in a buffer.
3. Calculate the average of the samples that are collected.
While calculating the rolling average, only good samples are included in the calculation and all bad samples are
excluded from the calculation. The rolling average is calculated at each Rolling Average function block
execution as long as there is at least one good sample. The block also displays the quality of the rolling average
value by counting the number of good samples and bad samples.
A NaN, disconnected input, or an infinity value is considered as a bad input. Also, no alarms are notified
whenever the block receives a bad input.
The maximum number of samples that can be collected is 3800 based on the CM Period. The number of
samples that can be collected is controlled by the frequency of sample collection and the size of the sample
collection buffer. These functions are accomplished by the following parameters.
• ROLLFREQ - Defines how frequently the samples must be collected. It is a numeric value and a multiple of
the associated CM Period. For example, if the CM Period is 5 secs, ROLLFREQ value can be a multiple of
5 (5, 10, 15, 20, and so on).
• ROLLFRBASE - Unit of time that is associated with the frequency of sample collection. This could be
seconds, minutes, or hours.
– For example if ROLLFREQ is “5”, and ROLLFRBASE is “Seconds” then samples are collected every 5
seconds.
• ROLLBUF - Defines how long the samples must be collected.
901
28 MATH FUNCTIONS
• ROLLBFBASE - Defines the unit of time for the collection buffer (ROLLBUF).
– For example, if ROLLBUF is “20” and ROLLBFBASE is “Seconds” then samples are collected upto 20
seconds. After 20 seconds, new samples overwrite the old samples.
Example of calculating rolling average

Consider the following values for calculating the rolling average.
• CM Period =5 Secs
• ROLLFREQ =5
• ROLLFRBASE = Sec
• ROLLBUF = 20
• ROLLBFBASE = Sec
The number of samples collected = 4
If the input values = 4, 6, NaN, 8, then
OUT = (4+6+8)/3=6
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.
The 3800 can be updated as “(ROLLBUF * ROLLBFBASE)/(ROLLFREQ * ROLLFRBASE.
Initialization of the Rolling Average function block

The Rolling Average function block is activated only after the user configurations are performed and the CM
containing the block is loaded to the associated CEE.
The Rolling Average output (OUT) is initialized to NaN on startup or restart. The OUT value changes to a non-
NaN when a first valid input is processed. The initial value of the ROLLAVGOK and ROLLAVGBAD
parameters is “0”. These initial values are also stored internally during the following:
• CM EXECSTATE transitions from INACTIVE to ACTIVE.
• CEE transitions from IDLE to RUN.
• The rolling average restart (ROLLAVGRST) parameter value is “ON.”
Rolling Average Runtime Errors

No point process alarms are generated from the Rolling Average function block processing. The following are
the scenarios during which the rolling Average result (OUT) remains a bad value (NaN).
• A bad input is counted as a bad sample and is not included in rolling average calculation. The OUT remains
a NaN until one good sample is collected.
• The CM is activated without correcting the errors that occurred while loading the block. When this happens,
ROLLAVGSZ and ROLLMULTIPLE parameter values remain at “0.” However, the Control Module's
remaining functions are unaffected.
• The CM Period is changed to a value that is illegal for the block to execute. For example, if you change the
CM Period from 1 sec to 2 secs while you have specified the frequency of sample collection as 1 sec. You
can change the CM Period only when the CM is inactive or the controller is idle. When this happens, the
ROLLAVGSZ parameter value remains unchanged and the ROLLMULTIPLE 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.
28 MATH FUNCTIONS
Errors resulting from invalid parameter combinations

Even though invalid parameter combinations result in successful point load completion of the block, rolling
average calculation does not initialize until the errors are rectified. The following are the possible invalid
parameter combinations:
• The ACE Control Module's NOPERIOD and SCALEPERIOD parameter values are NaN. This is considered
as an illegal combination for the Rolling Average function block.
• The number of samples in the sample buffer exceeds its limits (greater than 3800).
• The frequency of sample collection (ROLLFREQ) is lesser than 1 or greater than 3800.
• The size of the collection buffer (ROLLBUF) is not legal for collection frequency or not a multiple of
frequency. For example, if frequency = 2 seconds and buffer size = 61 seconds, this is considered as illegal
(since sample collection occurs every 2 seconds and cannot occur at the 61st second).
• The frequency of sample collection (ROLLFREQ) is greater than the buffer size. For example, if frequency
= 10 minutes and buffer size = 5 minutes, this is considered illegal (since sample collection occurs every 10
minutes, the buffer size must be greater than the frequency).
• The frequency of sample collection (ROLLFREQ) is less than the CM Period. For example, if frequency = 1
minutes and CM Period = 2 minutes, this is considered illegal.
• The frequency of sample collection (ROLLFREQ) is not a multiple of the CM Period. For example, if
frequency = 41 minutes and CM Period = 20 minutes, this is considered as illegal.
An error also occurs if the memory available in CEE is insufficient for the rolling average sample buffer.
Memory size for the block

The estimated memory size for the Rolling Average function block is as follows:
• 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.
Validations of the memory size

• The CEE calculates and verifies the memory associated with the block to be within the range (1 to 3800).
• Also, the CEE validates that the size of the collection buffer is within the limits (0 to 3800) based on the CM
Period and the frequency of the sample collection.
Redundancy support for the block

In the event of a controller switchover, the block continues its operations with the existing sample buffer. The
controller switchover does not restart the rolling average calculations. To support this function, the sample
buffer is included in the Dynamic State Data (DSD) for the block. A single DSD must not exceed 32K
(maximum size). This includes the maximum possible size of the buffer, other DSD items, and inherited data.
Checkpoint Save and restoration

Only configuration values are saved during Checkpoint Save and restored on start-up. The internal sample
buffer is not maintained in the Checkpoint.
903
28 MATH FUNCTIONS
Scenarios during which the block does not execute

The Rolling Average function block does note execute in the following scenarios:
• CM Period is “None” and SCALEPERIOD parameter is “NaN.”
• CM BPS parameter is stored as a result of a process special execution and CM Period is a value other than
“None.”
29 Power Generation Functions
Related topics
“POWERGEN Function Blocks” on page 906
“GRPCAPRBK (Group Capability and Runback) Block” on page 907
“HTMOTOR (HT Motor Drive Control) Block” on page 913
“LEVELCOMP (Drum Level Computation) Block” on page 941
“LTMOTOR (LT Motor Drive Control) Block” on page 946
“MAINIBV (IBV Logic) Block” on page 968
“SOLENOID (Solenoid Valve Drive Control) Block” on page 974
“VALVEDAMPER (Valve/Damper Drive Control) Block” on page 995
905
29 POWER GENERATION FUNCTIONS
29.1 POWERGEN Function Blocks

Power Generation function blocks provide a variety of configurable functions for supporting control strategies
designed for power plant applications
associated POWERGEN function block. Functional descriptions for each block are given in the following
subsections.
Attention
The following blocks can only be used with C300 Controllers. They are not supported for use with C200/C200E
Controllers.

Support Coordinated Master Control “GRPCAPRBK (Group Used to define associated equipment capability
scheme Capability and Runback) including alarms and ROC limit output.
Block” on page 907
Support HT motor drive control “HTMOTOR (HT Motor Used to define inputs and interlocks for conventional
requirements Drive Control) Block” on HTMOTOR drive.
page 913
Support drum level computation “LEVELCOMP (Drum Used to compute drum level from measured
Level Computation) differential pressure and other field specific constants.
Support LT motor drive control “LTMOTOR (LT Motor Used to define inputs and interlocks for conventional
requirements Drive Control) Block” on LTMOTOR drive.
page 946
Provide Integral Bypass Valve (IBV) “MAINIBV (IBV Logic) Used to define configurable timing logic for the main
logic Block” on page 968 valve.
Support solenoid valve drive control “SOLENOID (Solenoid Used to define inputs and interlocks for conventional
requirements Valve Drive Control) solenoid valve drive control.
Support valve/damper control “VALVEDAMPER Used to define configurable operation requirements for
requirements (Valve/Damper Drive valve/damper control.
Control) Block” on
page 995
29.2 GRPCAPRBK (Group Capability and Runback) Block

A Coordinated Master Control (CMC) scheme includes a unit load demand scheme. The unit load demand
scheme is part of the CMC scheme that receives the load demand from the load dispatcher and checks the
demand signal against the allowable operating limits for the unit and the minimum required load. During online
operation, the demand can be Runback in the event of loss of auxiliary equipment such as losing one forced
draft fan, which limits the load carrying capability of the unit. A maximum rate of change is imposed on the
load demand to ensure that the unit load increase or decrease is executed within the limits that are safe for the
operation for the Boiler-Turbine-Generator unit. The demand, after having been processed in this manner, is
used as the load demand signal in the CMC scheme.
All the auxiliary equipments like ID Fan, FD Fan, PA Fan, Primary/Secondary Air Pre Heaters, BCW Pump,
Turbine, CEP Pump, CW Pump, Mills, and so on are monitored continuously and unit capability because of the
individual equipment are compared with the Load SP and the minimum is selected as the SP to the Unit
Capability ramp generator. When an equipment trips, the SP to the Unit capability ramp generator comes down
correspondingly. The output of the Ramp Generator is brought down by Runback action. The runback rate
depends upon the equipment that has tripped.
The Group Capability and Runback block, available under the Powergen function block library 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.
907

Main • Name: Block (Tag) name of up to 16 characters long. Must be unique within the
• Execution Order in CM (ORDERINCM): Specifies the execution order of the
between 1 and 32767. The default value is 10.
• Description (DESC): Block descriptor of up to 132 characters long.
• Engineering Units (EUDESC): Lets you specify a text string of up to 16
characters to identify the variable values associated with this block.
• Number of Equipments (NUMBEROFEQP) -The number of equipment in the
group for which the Group Capability and Rate of change of load set point for
Group is calculated.
• Capability Output Options -Lets you choose the Capability Output value in case
of bad input status. The user can choose either user provided Safe value or hold
the last output value.
• Display Configuration -Lets you specify the number of GRPCAPRBK blocks in
the CM for which a common display is required. Default Value as 1.Display uses
this parameter from the block which has name GRPCAPRBKA. This parameter
is ignored for the block which does not have name GRPCAPRBKA.
• Alarms -Lets you specify the priority and severity for following alarms.
– Runback Active (RUNBKACTALM.PR/SV): This alarm is generated when
the Capability Output value is less than the Load set point input. This alarm
returns to normal when the Capability Output value is equal or greater than
the Load set point input.
– Safe Output triggered (SAFEOPALM.PR/SV: This alarm is generated when
the Inputs (All DI or LOADSP) status is bad. This alarm returns to
NORMAL when Input statuses are not bad.
• ROC Limit Output (ROCLM) - Lets you choose the ROC Limit Output
(ROCLM) value in case of bad input status. The user can choose either user
provided Safe value or hold the last output value. This group has Runback ROC
limit parameter that allows you to configure the ROC limit output in Runback
state.
• Equipment Capability Values - Lets you configure the ON state and OFF state
Capability values of individual equipment. The ON state Capability value is
always greater than OFF state capability value of equipment.
faceplate.
29.2.1 Function-GRPCAPRBK block

• 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
909
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).
29.2.2 Configuration examples-GRPCAPRBK block

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.
29.2.3 Inputs-GRPCAPRBK block

• LOADSP - Load Set point
• DI[1..10]
29.2.4 Outputs-GRPCAPRBK block

• OUTCAP - Output capability
• RUNBKACTFL - Runback control flag
• ROCLM - Current ROC Limit
• SAFEOPTRIGFL- Safe output triggered
29.2.5 Error handling-GRPCAPRBK block

• 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.
911
• 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 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.
• RUNBKACTFL and RUNBKACTALM.FL parameters essentially provide the same functionality of raising the
Run back active alarm flag in a Group Capability block. Either of the two parameters may be used to achieve the
functionality.
29.2.6 GRPCAPRBK parameters

Refer to the Control Builder Components Reference for parameter details for the Group Capability and Runback
Function block.
29.3 HTMOTOR (HT Motor Drive Control) Block

A Drive Control is achieved through Device Control Blocks (DEVCTL) in Experion. The existing Device
control block is designed for all types of drives like LT, HT, and valves. It has configurable states, number of
inputs, number of outputs, and hosts PV and OP alarms. You have to configure them before using the block.
There is a single permissive and interlock inputs for each state. Therefore all the switchgear related inputs and
Process inputs have to hover around this one single input pin by employing OR or AND blocks for
multiplexing. The HT Motor Control FB (HTMOTOR), available under the POWERGEN library, is derived
from the Device Control block in Experion (DEVCTL) customized to meet the HT Motor Drive control
requirements found in power plants. The HT Motor Control FB accepts inputs and interlocks pertaining to a
conventional HTMOTOR drive and its switchgear and is capable of controlling the drive through outputs
governed by predetermined logic.
The HT Motor Control function block is graphically represented as follows:
The following diagram illustrates the START logic flow for an HT Motor block.
913
The following diagram illustrates the STOP logic flow for an HT Motor block.
915
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
with that tab

selection is ALL.
user program, MAN for an operator, or AUTO for process input connection,
TRACK for tracking OP. Only applicable with PV Source Option selection of
ALL. The default selection is AUTO.
selection is OPERATOR. MODEATTR identifies who can store values to the
output (OP), when the block's MODE is either MAN or AUTO.
OPERATOR, PROGRAM. The default selection is NONE.
Output • 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, RUN and
STOP. Both digital outputs are set to OFF in DEFAULT mode.
• OP Initialization Option (INITOPOPT) - Lets you specify the state to which OP
is set when INITMAN transitions from ON to OFF. Selections are
NORMALOPT, HOLDOPT and SAFEOPOPT.
• 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 STOP but OP is not altered.
• Pulse Output (PORUNCONNECTED and POSTOPCONNECTED) - Lets you
specify whether a given pulse output is to be enabled (ON) or not (OFF). A
Check equals ON and enables configuring the pulse width and PO Pins. The
default is no pulse outputs configured.
• Bypass Permit (BYPPERM) - Lets you specify if operators are permitted to
bypass the Permissive and Override Interlocks or not. The default is Disabled
(unchecked) or OFF. An operator cannot set or reset the BYPASS parameter.
• Perm. and Intlock. Bypass (BYPASS) - When BYPPERM is ON, lets you
change OP regardless of the state of the Override interlocks, if BYPASS is set
ON. This does not affect the Safety Override Interlock (SI). When you reset the
BYPASS parameter to OFF, any existing Override Interlocks (OI[0..2]) take
effect immediately.
• BYPASS when BKT (BKTBYPASS) - Lets you change OP regardless of the
state of the Override interlocks, if BKTBYPASS is set to ON. BKTBYPASS is
set to ON only when BKT is ON. This does not affect the Safety Override
Interlock (SI). When you reset the BKTBYPASS parameter to OFF, any existing
Override Interlocks (OI[0..1]) take effect immediately. The default is OFF
(unchecked). Operator cannot bypass override interlocks to change OP.
917

Maintenance • Track Number of PV transitions/State (TRKNUMTRANS) - When enabled or
box checked, you can track the number of transitions of PV to each state
(NUMTRANS[0 -1]. The default is OFF or box unchecked and NUMTRANS[0
-1] in maintenance statistics is not collected.
• Track Number of SI Overrides (TRKSIOVRD) - When enabled or box checked,
you can track the number of SI overrides. The default is OFF or box unchecked
and the NUMSIOVRD in maintenance statistics are not collected.
• Maint. stats. reset flag (RESETFL) - An operator, a user program or another FB
can turn ON the RESETFL parameter to reset statistics anytime.
• No. of safety ovr. trips (NUMSIOVRD)- Accumulated number of safety
interlock trips that result in OP changing state, after the last statistics reset.
• No. of all PV transitions (NUMALLTRANS) - Accumulated number of
transitions of PV to each state, after the last statistics reset.
• Track State Time (TRKSTATETIME) - When enabled or box checked, you can
track the amount of time the drive is in different states.
– RUNTIME - Accumulated time the drive spends in the RUN state.
– STOPTIME - Accumulated time the drive spends in the STOP state.
– TRIPTIME - Accumulated time the drive spends in the STOP state because
of a trip.
SCM • SCM Mode Tracking Opt (MODETRACK) - Lets you select the desired Mode
Tracking function for the SCM associated with this block's Control Module. It
defines how the FB sets the state of the MODEATTR based upon the MODE of
the SCM. The default selection is ONESHOT. The selections are NONE,
ONESHOT, SEMICONT, CONTRTN, and CONT.
take when the SCM is in an abnormal state.
– The Starting State Option (STARTOPT) applies when the SCM state is
Checking, Idle, or Complete. The options are NONE, SAFEOP. The default
selection is NONE.
– The Stop/Abort State Option (STOPOPT) applies when the SCM state is
Stopping or Stopped, Aborting or Aborted. The options are NONE,
SAFEOP. The default selection is NONE.
– The Hold State Option (HOLDOPT) applies when the SCM state is Holding
or Hold. The options are NONE, SAFEOP. The default selection is NONE.
– The Restart State Option (RESTARTOPT) applies when the SCM state is
Restart State option. The default selection is NONE.

Alarms The following alarms are configurable to represent disagreements between the
commanded state (OP) and the feedback state (PV).
• Command Disagree (CMDDISALM.FL): This alarm is generated when the
change to the same state within the specified feedback time. This alarm returns
to NORMAL when the PV state becomes the same as the OP state.
• Command Fail (CMDFALALM.FL): This alarm checks to see if the PV state
changed from its original state to any other state within a specified feedback time
after the OP state is commanded. For slow responding devices, absence of this
alarm indicates that the device responded to the command, even if it has not yet
moved to its commanded position.
• Uncommanded Change (UNCMDALM.FL): This alarm is configured in
generated, if an OP state has not been commanded and the PV state changes for
any reason except BADPV.
• Bad PV (BADPVALM.FL): This alarm is generated whenever PV is detected in
the Null state. The Null state can result from a BadPV condition for an input
provided by a source block, or because input combinations represent a Null state.
Command Disagree - Lets you configure the following parameters for this alarm.
• Time to STOP (or assigned State Name) (CMDDISALM.TM[0]): Lets you set
the feedback time for STOP in range of 0 to 1000 seconds. A time of 0 disables
the alarm. The default setting is 0.
• Time to RUN (or assigned State Name) (CMDDISALM.TM[1]): Lets you set
the feedback time for RUN in range of 0 to 1000 seconds. A time of 0 disables
• Priority (CMDDISALM.PR): Lets you select the priority level as NONE,
• Severity (CMDDISALM.SV): Lets you set the relative severity of the alarm on a
scale of 0 to 15. Where 15 is the most sever. The default setting is 0.
Command Fail - Lets you configure the following parameters for the command fail
alarm.
• Time to STOP (or assigned State Name) (CMDFALALM.TM[0]): Lets you set
the feedback time for STOP in range of 0 to 1000 seconds. A time of 0 disables
the alarm. The default setting is 0. This value must be less than the value set for
CMDDISALM.TM[0].
• Time to RUN (or assigned State Name) (CMDFALALM.TM[1]): Lets you set
the feedback time for RUN in range of 0 to 1000 seconds. A time of 0 disables
CMDDISALM.TM[1].
• Priority (CMDFALALM.PR): Lets you select the priority level as NONE,
• Severity (CMDFALALM.SV): Lets you set the relative severity of the alarm on
a scale of 0 to 15. Where 15 is the most sever. The default setting is 0.
Uncommanded Change - Lets you configure the following parameters for this
alarm.
• Priority (UNCMDALM.PR): Lets you select the priority level as NONE,
• Severity (UNCMDALM.SV): Lets you set the relative severity of the alarm on a
Bad PV - Lets you configure the following parameters for this alarm.
• Priority (BADPVALM.PR): Lets you select the priority level as NONE,
919

• Severity (BADPVALM.SV): Lets you set the relative severity of the alarm on a
Safety Override Alarms - Lets you configure the following parameters for the
safety override interlock alarm.
• Safety Override Interlock (SIALM.FL): This alarm is generated when the safety
override interlock (SI) causes an OP state change.
• Option (SIALM.OPT): Lets you specify whether the safety override interlock
alarm is enabled or not. The default setting is DISABLED.
• Priority (SIALM.PR): Lets you select the priority level as NONE, JOURNAL,
LOW, HIGH, or URGENT. The default setting is LOW.
• Severity (SIALM.SV: Lets you set the relative severity of the alarm on a scale of
0 to 15. Where 15 is the most severe. The default setting is 0.
Override Alarms - The following alarms are configurable to represent override
interlock conditions
STOP Override Interlock Alarm - Lets you configure the following parameters for
this alarm.
• Option (OIALM[0].OPT): Lets you specify whether the STOP override interlock
• Priority (OIALM[0].PR): Lets you select the priority level as NONE,
• Severity (OIALM[0].SV): Lets you set the relative severity of the alarm on a
• Override Interlock (OIALM[0..1].FL): This alarm is generated when an override
interlock (OI[0..1]) occurs and causes an OP state change.
RUN Override Interlock Alarm - Lets you configure the following parameters for
this alarm.
• Option (OIALM[1].OPT): Lets you specify whether the RUN override interlock
Equipment safety alarm- Lets you configure parameters for the following alarms.
Motor trip alarm: Lets you configure the following parameters for this alarm
• Option (MOTORTRIPALM.OPT): Lets you specify whether the motor trip is
enabled or not. The default setting is ENABLE.
• Priority (MOTORTRIPALM.PR): Lets you select the priority level as NONE,
• Severity (MOTORTRIPALM.SV): Lets you set the relative severity of the motor
trip alarm on a scale of 0 to 15. Where 15 is the most severe. The default setting
is 0.
Lockout Relay Reset alarm: Lets you configure the following parameters for this
alarm.
• Option (LRRALM.OPT): Lets you specify whether the lockout relay reset alarm
is enabled or not. The default setting is ENABLE.
• Priority (LRRALM.PR): Lets you select the priority level as NONE, JOURNAL,
• Severity (LRRALM.SV): Lets you set the relative severity of the lockout relay
reset alarm on a scale of 0 to 15. Where 15 is the most severe. The default setting
is 0.

Winding Temperature Trip alarm: Lets you configure the following parameters
for this alarm.
• Option (WDGTEMPALM.OPT): Lets you specify whether the winding
temperature trip alarm is enabled or not. The default setting is ENABLE.
• Priority (WDGTEMPALM.PR): Lets you select the priority level as NONE,
• Severity (WDGTEMPALM.SV): Lets you set the relative severity of the
winding temperature trip alarm on a scale of 0 to 15. Where 15 is the most
severe. The default setting is 0.
Bearing Temperature Trip alarm: Lets you configure the following parameters for
this alarm.
• Option (BRNGTEMPALM.OPT): Lets you specify whether the bearing
temperature trip alarm is enabled or not. The default setting is ENABLE.
• Priority (BRNGTEMPALM.PR): Lets you select the priority level as NONE,
• Severity (BRNGTEMPALM.SV): Lets you set the relative severity of the
bearing temperature trip alarm on a scale of 0 to 15. Where 15 is the most
severe. The default setting is 0.
Vibration Trip alarm: Lets you configure the following parameters for this alarm.
• Option (VIBRALM.OPT): Lets you specify whether the vibration trip alarm is
• Priority (VIBRALM.PR): Lets you select the priority level as NONE,
• Severity (VIBRALM.SV): Lets you set the relative severity of the vibration trip
alarm on a scale of 0 to 15. Where 15 is the most severe. The default setting is 0.
Off Normal Condition - Lets you configure the following parameters for this alarm
• Off Normal Condition (OFFNRMALM.FL): If an interlock bypass becomes
active when OPREQ is not Null, the OPREQ is transmitted to OP immediately
upon activation of the bypass parameter. If bypass is activated after an interlock
has been initiated, the OP and OFFNRMALM.FL is corrected within one scan.
• Priority (OFFNRMALM.PR): Lets you select the priority level as NONE,
• Severity (OFFNRMALM.SV): Lets you set the relative severity of the alarm on
a scale of 0 to 15. Where 15 is the most severe. The default setting is 0.
faceplate.
29.3.1 Function-HTMOTOR block

• The HT Motor Control block has two inputs, two states, and two outputs.
921
• Provides PV Source Selection; PV has 2 basic states such as RUN and STOP plus 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.
• Provides predefined Safe State.
• Provides generic state parameters defined as consistent data types.
• Provides initialization with OPFINAL based configuration.
• Provides Boolean command option.
• Provides Batch level 1 driver option.
• Provides OFF Normal alarm associated with requested OP.
• Provides First out detection mechanism to detect the input that acted first to cause the motor to trip.
• Provides maintenance statistics: Running and stopped hours for the motor are calculated similar to the
STATIME parameter of Device Control block. The trip time is recognized by motor state at STOP and
presence of corresponding OI or SI parameter or MTT or WDGTEMPTRIP or VIBRTRIP or
BRNGTEMPTRIP.
• Provides Bypass permissive interlock and protection interlock when the breaker is in test position (BKT =
ON). However, this does not bypass SI interlocks and Switchgear protection.
You can red tag a HTMOTOR block. Refer to the “Configuration examples-PID Block” on page 383section for
more information.
Predecessor and Successor Block

The HT Motor Drive Control block takes inputs from DI channels or from the program. All the inputs are two
state inputs and can be connected to any block with a digital output. The output of the block can be connected to
DO or further connected to subsequent logic, if necessary.
29.3.2 Configuration examples-HTMOTOR block
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:
923
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 DI channel block to the HT Motor
block.
In case of an auto standby configuration, the HT motor block can be commanded by Auto Start, Auto Stop
provided the Remote switch is 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 HT Motor
block.
In case of a local mode configuration, the HT motor block can be commanded by Local Start, Local Stop
provided the Remote switch is OFF, the local switch is ON and MODEATTR is in PROGRAM.
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.
Use the PV parameter connection to carry equipment trip inputs (bearing temperature, winding
temperature) from the DI channel block to the HT Motor.
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.
925
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
HT Motor block.
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 PVFL parameter connection to carry safety, override and permissive inputs (SI, OI[0], PI[1]) from
the DICHANNEL block to the HT Motor.
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.
927
929
Callout Description
HT Motor block.
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 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.
Use the PV parameter connection to carry equipment trip inputs (bearing temperature, winding
temperature) from the DICHANNEL block to the HT Motor.
3 Use the PV parameter connection to carry Remote switch
Input, UCP REL, UCP START, UCP STOP from the DI channel block to the HT Motor block.
In case of an UCP configuration, the HT motor block can be commanded by UCP Start, UCP Stop
provided the Remote switch is ON, the UCP REL is ON and MODEATTR is in PROGRAM.
29.3.3 Inputs-HTMOTOR block

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 via 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.
29.3.4 Outputs-HTMOTOR block

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 to any other block parameter or to a field
• An output to any connection except to a DOCHANNEL block is a Boolean output only.
• The DOCHANNEL (DOC) block can connect three different inputs to a drive control block (output).
However, only one of these inputs can be connected for any 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.
• The internal PO*CONNECTED parameter is set to ON when the respective PO* is configured as a block
pin and connected to a DOC.ONPULSE or DOC.OFFPULSE input. This lets the drive control block know
what output is used.
• You can configure an individual PULSEWIDTH for each PO*. The setting range is between 0.000 and 60
seconds with a resolution of 1 millisecond.
• The DOCHANNEL block determines the actual pulsewidth resolution and accuracy based on its execution
rate. It always rounds-off the configured pulsewidth value up consistent with its own execution rate. For
example, if the execution rate of the DOCHANNEL block is 125 milliseconds and the configured
PULSEWIDTH value is 450 milliseconds (.45 seconds), the actual pulse time output is 500 milliseconds,
which is the next highest multiple of 125 milliseconds.
• A PULSEWIDTH value of 0 is a special case. If a 0 pulse is sent to ONPULSE or OFFPULSE, the
The output parameters are: MTTACTED, WDGTEMPTRIPACTED, VIBRTRIPACTED,
BRNGTEMPTRIPACTED, LOCALSTOPACTED, UCPSTOPACTED, SEQSTOPACTED, OIACTED,
CMDRUN, CMDSTOP, OP, PV, CONSSTARTRDY, PORUN, POSTOP, NUMTRANS[0,1],
NUMALLTRANS, NUMSIOVRD, TRIPTIME, STOPTIME, RUNTIME.
29.3.5 Error handling-HTMOTOR block

• 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.
• 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 accept a value between 0 and 96000.
• TRKTRIPTIME, TRKRUNTIME, TRKSTOPTIME requires Engineer Access lock.
• For the HT Motor FB, if both feedback status is ON and OFF, a fault status is flagged and output generation
is not processed.
931
29.3.6 States-HTMOTOR block

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.
29.3.7 State parameters and descriptors-HTMOTOR block

The block includes these two sets of parameters for state associations.
• State parameters
• PV
• PVAUTO
• OP
• OPFINAL
• Generic State parameters
• GPV (generic version of PV)
• GPVAUTO (generic version of PVAUTO)
• GOP (generic version of OP)
• GOPFINAL (generic version of OPFINAL)
The State parameters are an enumeration with an assigned text name, which tracks the names assigned to
The Generic State parameters are consistent data types, which can be compared with each other through the
enumeration GENSTAT_ENM. The generic state enumerations are as follows:
• NULL - Stands for Bad Value.
• 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).
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.
If STATETEXT is? Then, the default name is And, GENSTAT_ENM is

STATETEXT[0] Bad Null
STATETEXT[1] Inbet Inbet

STATETEXT[3] Safe(STOP) Safe
STATETEXT[4] STOP S0
STATETEXT[5] RUN S1
STATETEXT[6] NOCOMMAND S2
29.3.8 Mode and mode attribute-HTMOTOR block

• Mode Attribute (MODEATTR) - determines where state commands to the HT Motor block can originate -
that is, who can set the commanded output state (OP), as follows:
– OPERATOR = only the operator can command the output state.
– PROGRAM = only other function blocks (such as Logic blocks, SCM programs) can command the
• MODEATTR can be changed from PROG to OPER and vice versa through other FB via
MODEATTRCHGFL.
29.3.9 Safe output state-HTMOTOR block

The Safe Output State (SAFEOP) parameter defines the default state for certain actions of the HT Motor block,
such as OP initialization. In case of HT Motor, the safe Output State (SAFEOP) is predefined as STOP State.
• When OP or GOP is commanded to SAFE, the effective value of OP (GOP) is set equal to SAFEOP.
29.3.10 Command dependency on switches and Mode attribute-HTMOTOR block
HT MOTOR Local\Remote Switch ModeAttribute

LocalStart LOCAL
UCPStart REMOTE
AutoStart REMOTE PROG
SeqStart REMOTE PROG
ConsoleStart REMOTE OPER
LocalStop LOCAL
UCPStop
AutoStop REMOTE PROG
SeqStop REMOTE PROG
ConsoleStop OPER
Ignore
Check
933
29.3.11 Local manual-HTMOTOR block

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.
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.
29.3.12 Permissive interlocks-HTMOTOR block

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.
ON.
29.3.13 Safety Override Interlock-HTMOTOR block

The Safety Override Interlock (SI) forces the commanded output state (OP) to the Safe Output State (STOP)
when active. OP cannot be commanded to a different state when SI is active.
• SI may be connected to other blocks or may be directly set by an operator if the MODEATTR parameter is
• SI is defaulted to OFF, it must be set to ON to force OP to go to STOP.
• When SI turns OFF, OP = STOP is maintained until changed by:
– the operator
– a user program
29.3.14 Override Interlocks-HTMOTOR block

• Override Interlocks may be connected to other block outputs or may be directly set by an operator if
• 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].
29.3.15 Configurable Override/Permissive Interlock Bypass-HTMOTOR block

To grant an operator the ability to bypass the Permissive and Override Interlocks for a HT Motor block, the
• BKTBYPASS bypasses OI and PIs when BKT is ON. It is independent of BYPERM.
29.3.16 Alarms-HTMOTOR block

Output State (OP) and the Current Active State (PV). A Safety Override Interlock alarm is also available. Each
• Command Fail alarm - generated when the Current Active State (PV) fails to change from an original value
HT Motor block configuration form. The value of OP just commanded determines which
The alarm function is automatically disabled, if there are no inputs or no outputs.
Attention
• The CMDFALALM.TM[0..1] cannot be configured if CMDDISALM.TM[0..1] has not been configured.
• The CMDFALALM.TM[0..1] setting must be less than the CMDDISALM.TM[0..1] setting for the same
state[0..1].
• 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
– 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].
935

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 (setting of the output state and related alarm
notification) always occurs regardless of the effect of the other alarm.
29.3.17 Seal-in option-HTMOTOR block

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
Attention
To configure Seal-in option, ensure that the CM is inactive and CMDDISALM.TM [0..1] is configured.
29.3.18 FIRSTUP functionality-HTMOTOR block

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.
29.3.19 Initialization Manual condition-HTMOTOR block

Discrete Control FB. When this condition is active, the parameter INITMAN is set ON. Outputs cannot be
• INITDOWN[1..2] - This is an input which can be connected to the DOC INITREQ output. When possible,
this connection is made automatically by the system, without any user action.
• This is a structure containing the INITREQ status and the DOC.SO current value.
connected.
• INITMAN - This is a BOOLEAN value which is set TRUE whenever any of the INITDOWN[i].STATUS is
TRUE.
29.3.20 OP initialization option-HTMOTOR block

• 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 = HOLDOPOPT, initialization is not performed. OP remains at the last value.
29.3.21 Initialization Manual condition with Safety Override Interlock, Override Interlocks, LocalMan,
and OP initialization-HTMOTOR block
The Safety Override Interlock and the Override Interlocks have an impact on how OP initialization works.
When the INITMAN parameter transitions from ON to OFF, the HT Motor FB provides an output value OP as
follows:
• If the Safety Interlock is active, the OP is set to STOP
• If any of the Override Interlocks are active and not bypassed, the OP is set to the highest priority Override
Interlock
• If LocalMan is ON, OP tracks PV provided PV is in a settable state (STOP, RUN). If PV is in an unsettable
state (BAD) or PV does not exist, OP is set to STOP
• If OP Initialization is configured as HOLDOPOPT, OP remains on the last value
• If OP Initialization is configured as SAFEOPOPT, OP is set to STOP
• If OP Initialization is configured as NORMALOPOPT, in cases where feedback is configured, the stored OP
value tracks the PV state if the PV state is settable (START, STOP)
• OP value is back-initialized from the output connections if
Otherwise, OP is set to STO
29.3.22 Initialization with pulse output-HTMOTOR block

If pulse outputs are configured, the following rules apply in generating pulses when recovering from
initialization:
• When PV is good, OP and OPFinal are initialized to PV, no pulse is generated.
• When PV is Bad, OP and OPFinal are initialized to STOP, pulse is generated.
29.3.23 Initialization request flags-HTMOTOR block

The HT Motor function block parameter INITREQ[0..1] provides an indication whether a command to a certain
state (corresponding to the parameter index 0..1) is accepted and acted upon at the current time. This parameter
can be read prior to sending a command to the block to check if the device can respond as required. INITREQ[i]
(i = 0 or 1) = OFF indicates that the block can be commanded to statei, and INITREQ [i] (i = 0, or 1) = ON
indicates that the block cannot be commanded to statei. Override interlocks and permissive interlocks cause a
certain state to be non-settable at a given point in time.
937
29.3.24 OP and DO initialization after load-HTMOTOR block

The initialization values of digital outputs (DOs) can be configured to their desired values. This feature is
typically used in strategies where the output of a HT Motor FB is connected to non-initializable blocks, such as
logic blocks. The configuration is done through INITOPAFTLD. Configure the initialization state for OP, and
the value of OP is mapped to DOs, according to the configured map of OP-DO (OPDOMAP), after load. The
options for INITOPAFTLD can be any configured states (STOP, RUN), or default. The default option initializes
OP to STOP.
29.3.25 Maintenance statistics-HTMOTOR block

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.
• NUMALLTRANS - Number of all PV transitions. This can be enabled provided TRKNUMTRANS is
enabled.
• RUNTIME, STOPTIME, TRIPTIME - Accumulated number of hours, the HT 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 HT MOTOR
block anytime irrespective of Redtagging, unlike the DEVCTL block.
29.3.26 Output requests-HTMOTOR block

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
means the OPREQ continues to attempt stores even if attributes, such as interlocks, become active and block
to OP.
29.3.27 Output command-HTMOTOR block

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).
• Similarly, the HT Motor block can be commanded through LOCAL START/STOP, UCP START/STOP
provided the following conditions are met:
1. Both LOCAL and UCP commands ignore MODEATTR.

2. LOCAL START/STOP depends on the LOCAL SWITCH which should be ON.
3. UCP STOP ignores the LOCAL/REMOTE SWITCH condition.
4. UCP START depends on REMOTE SWITCH which should be ON.
• Similarly, the HT Motor block can be commanded through Console START/STOP provided the following
conditions are met:
1. MODEATTR should be OPER
2. Console STOP ignores LOCAL REMOTE SWITCH condition.
3. Console START depends on REMOTE SWITCH which should be ON.
If an SCM commands the HT Motor block by sending a Null type of request to GOP and there are active
OPCMDs such as AUTO START/STOP, UCP START/STOP, LOCAL START/STOP (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). Only an SCM can gain control, only when all OPCMD elements are OFF.
The HT Motor can also be commanded by SCM through SEQ START/STOP when SCM option is FIXED and
MODEATTR is PROGRAM.
Attention
• UCP START/STOP, SEQ START/STOP, LOCAL START/STOP work on OFF to ON transitions. So, there is no
priority for them.
• AUTO START/STOP work on priority as per SAFEOP which is STOP since they are latched.
• LOCAL START/STOP, UCP START/STOP commands change the MODEATTR to Operator.
• AUTO START/STOP, SEQ START/STOP, UCP START, CONSOLE START depends on REMOTESWITCH
which should be ON.
• AUTO START/STOP, SEQ START/STOP is not allowed when BYPASS is ON. However, AUTO START/STOP,
SEQ START/STOP is allowed when BKTBYPASS is ON.
• UCP STOP and CONSOLE STOP ignore the switches for its operation.
• FIRSTUPACTED is set when the motor encounters an abnormal condition. FIRSTUPACTED is not reset
automatically when the motor is brought back to its NORMAL state. It is essential to reset FIRSTUPACTED
before starting the motor.
• Restarting the motor is possible without resetting FIRSTUPACTED. An Auto reset of the FIRSTUPACTED on
restarting the motor can be achieved though Engineering solution.
• CONSSTARTRDY indicates that the motor can be started from the Console. It checks for all the interlocks and
permissives required for starting the motor from the console. However, once the motor is running,
CONSSTARTRDY is of no consequence.
• Since BKT and BKS are complimentary inputs, the HT motor can be commanded only when either one of them is
ON.
29.3.28 Logic override OPREQ-HTMOTOR block

The clear OPREQ flag parameter (CLROPREQFL) can be used through a passive connection to a Logic type
29.3.29 Monitoring HT Motor Current

The HT Motor current can be monitored by configuring a DACA block in the CM containing the HT Motor
block, which takes the current signal from the field. This current can be monitored from the Detailed Display of
HT Motor from the Station under Maintenance tab. The alarm features for current monitoring can also be
configured in the DACA block.
939
29.3.30 HTMOTOR parameters

Refer to the Control Builder Components Reference for a complete list of the parameters used with the Drive
Control block.
29.4 LEVELCOMP (Drum Level Computation) Block

The Drum Level Computation block (LEVELCOMP), available under the POWERGEN library, computes the
drum level from the measured DP and other field specific constants. In a power plant, the drum level is
measured indirectly in terms of differential pressure (DP), and the level is computed based on the measured DP.
DP to Level computation techniques is employed in level measurements like boiler drum, de-aerator, and HP
heaters, where the process fluid is at high pressure and temperature. The level component is measured in terms
of DP across the measuring setup. It is assumed that the vessel remains in a saturated state of the process fluid.
The pressure inside the container is measured and the density of Steam and Water are computed based on this
measured pressure. The Drum Level Computation function block is graphically represented as follows:
The equation for computing drum level is:

h = ( H (ρRef - ρS ) - DP ) / (ρW - ρS )
The variables in the equation stand for:
• h: Drum level to be measured
• H: Length of stand pipe.
• DP: Differential pressure of the drum
• ρRef: Density of water in wet leg (This computation uses the Water Leg temperature)
• ρS: Density of steam
• ρW: Density of water
The Drum Level Computation block supports bad PV alarm.
The Drum Level Computation 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.
941

• Process Value Hi Range (PVEUHI) - Lets you specify the high input range value
in engineering units that represents 100% full scale PV input for the block. The
• Process Value Lo Range (PVEULO) - Lets you specify the low input range value
in engineering units that represents the 0 full scale PV input for the block. The
default value is -300.
• Wet Leg Temperature (WETLEGTEMP) - Lets you enter the wet leg
temperature. Wet leg refers to the liquid filled low side impulse line in a
differential pressure level measuring system. You can enter a range of 0 to 70
DEGC (or 32 to 158 Deg F). The default value is 45 Deg F.
• DP Slope (DPSLOPE) - Defines the slope to be applied to DP parameter. Default
value =1.
• DP Bias (DPBIAS) - Defines the bias to be applied to the DP parameter. Default
value = 0.
• Pressure Slope (PRSLOPE) - Defines the slope component of Modified Drum
Pressure. Default value = 0.
• Pressure Bias (PRBIAS) - Defines the bias component of Modified Drum
Pressure. Default value =1
• Bad PV Alarm Priority (BADPVALM.PR) - Lets you set the desired priority
level individually for each alarm type assuming that the PV value is bad. The
default value is LOW.
• Bad PV Alarm Severity (BADPVALM.SV) - Lets you assign a relative severity
individually for each alarm type, as a number between 0 and 15, with 15 being
the most severe, assuming that the PV value is bad. This determines the alarm
• DP Engineering Unit Selection - Lets you select the DP Engineering Unit
– Pressure Engineering Unit Selection (DPENGUNIT) - Lets you select the
Absolute Pressure Engineering Unit
– Engineering Unit Selection for Temperature (PRENGUNIT) - Lets you
select the Engineering Unit Selection for Temperature
– Temperature Engineering Unit Selection - Allows the user to configure the
temperature's engineering unit.
• PV Engineering Unit Selection (PVENGUNIT) - Allows the user to configure
the Pressure Signal's Engineering Unit.

faceplate.
29.4.1 Function-LEVELCOMP block

• 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
• Block 1: Channel Block

The channel blocks bring in analog channels such as DP and pressure to the Drum level Computation.
• Block 2: DACA Block
This block is required as the transmitter selection block does not have alarm capability.
• Block 3: Transmitter Selection Block
The signals involved - Pressure and DP, employs dual/triple redundant configuration. Therefore this block
supports “median value selection.”
• Block 4: Drum level computation block
This block eventually computes the drum level.
• Block5: DACA
This block is optional for exclusive alarms and ranging.
943
Successor Block
The output of the Drum Level Computation block has a direct connectivity to a DACA block.
Drum Level Computation

The Drum level is computed in two steps with two inputs - DP and drum pressure. The drum pressure is used to
find the density of steam and water. This is achieved by employing a polynomial that provides the density of
steam and water at a given pressure. The computed density and DP input is then used in the equation to
calculate the Drum level PV.
29.4.2 Inputs-LEVELCOMP block

• DP - Differential Pressure of the drum
• PRESSURE - Pressure input parameter.
29.4.3 Outputs-LEVELCOMP block

• PV - Drum level.
• PVP - Drum level in %
• DENSTEAM - Density of steam in drum
• DENWATER - Density of water in drum
• DENWATERREF - Density of WETLEG water
29.4.4 Error handling-LEVELCOMP block

• 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 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.
29.4.5 LEVELCOMP parameters

Refer to the Control Builder Components Reference for a complete list of the parameters used with the Drum
Level Computation block.
945
29.5 LTMOTOR (LT Motor Drive Control) Block

control block is designed for all types of drives like LT, HT, and valves. It has configurable states, number of
inputs, number of outputs, and hosts PV and OP alarms. You have to configure them before using the block.
There is a single permissive and interlock inputs for each state. Therefore all the switchgear related inputs 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 (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
with that Tab.

• PV Source selection (PVSRCOPT) - Lets you select the source of the PV as
SUB for a user program, MAN for an operator, or AUTO for process input
connection, TRACK for tracking OP. Only applicable with PV Source Option
selection of ALL. The default selection is AUTO.
Output • 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, STOP and
RUN. Both digital outputs are set to OFF in DEFAULT mode.
• OP Initialization Option (INITOPOPT)- Lets you specify the state to which OP
NORMALOPT, HOLDOPT and SAFEOPOPT. By default, the option is
NORMALOPT.
DISABLE and ENABLE. If ENABLE, the field output destinations are set to
SAFEOP but OP is not altered.
• Pulse Output (POSTOPCONNECTED and PORUNCONNECTED) - Lets you
Check equals ON. When enabled, the corresponding output (PORUN and
POSTOP) pin is exposed on the block. The default is no pulse outputs
configured. The selectable outputs depend upon the configured number of
outputs.
effect immediately.
947

box checked, you can track the number of transitions of PV to each state
(NUMTRANS[0 -1]. The default is OFF or box unchecked and NUMTRANS[0
-1] in maintenance statistics are not collected.
you can track the number of SI overrides. The default is OFF or box unchecked
and the NUMSIOVRD in maintenance statistics are not collected.
• Maint. stats. reset flag (RESETFL) - An operator, a user program or another FB
can turn ON the RESETFL parameter to reset statistics anytime.
• No. of safety ovr. Trips (NUMSIOVRD) - Accumulated number of safety
• (Total number of statet transitions (NUMTRANS) - The accumulated number of
transitions to the reference state since the last reset of Maintenance Statistics.
• Track State Time (TRKSTATETIME) - When enabled or box checked, you can
track the amount of time the drive is in different states. The default is OFF or
box unchecked.
– RUNTIME - Accumulated time the drive spends in the RUN state.
– STOPTIME - Accumulated time the drive spends in the STOP state.
– TRIPTIME - Accumulated time the drive spends in the STOP state because
of a trip.
• Abnormal State Options - Lets you specify the action the function block should
selection is NONE.

Alarms The following alarms are configurable to represent disagreements between the
commanded state (OP) and the feedback state (PV).
to NORMAL when the PV state becomes the same as the OP state.
• Bad PV (BADPVALM.FL): This alarm is generated whenever PV is detected in
the Null state. The Null state can result from a BadPV condition for an input
provided by a source block, or because input combinations represent a Null state.
• Safety Override Interlock (SIALM.FL): This alarm can be generated when the
safety override interlock (SI) occurs, and has caused an OP state change.
• Override Interlock (OIALM[0..1].FL): This alarm can be generated when an
override interlock (OI[0..1]) occurs, and has caused an OP state change.
• Time to STOP (CMDDISALM.TM[0]): Lets you set the Command disagree
feedback time for STOP in range of 0 to 1000 seconds. A time of 0 disables the
alarm. The default setting is 0.
• Time to RUN (CMDDISALM.TM[1]): Lets you set the Command disagree
feedback time for RUN in range of 0 to 1000 seconds. A time of 0 disables the
alarm. The default setting is 0.
• Priority (CMDDISALM.PR): Lets you select the priority level of the Command
disagree alarm as NONE, JOURNAL, LOW, HIGH, or URGENT. The default
setting is LOW.
• Severity (CMDDISALM.SV): Lets you set the relative severity of the Command
disagree alarm on a scale of 0 to 15. Where 15 is the most sever. The default
setting is 0.
alarm.
• Time to STOP (CMDFALALM.TM[0]): Lets you set the Command Fail
feedback time for STOP in range of 0 to 1000 seconds. A time of 0 disables the
alarm. The default setting is 0. This value must be less than the value set for
CMDDISALM.TM[0].
• Time to RUN (CMDFALALM.TM[1]): Lets you set the Command Fail
feedback time for RUN in range of 0 to 1000 seconds. A time of 0 disables the
alarm. The default setting is 0. This value must be less than the value set for
CMDDISALM.TM[1].
• Priority (CMDFALALM.PR): Lets you select the priority level of the Command
Fail alarm as NONE, JOURNAL, LOW, HIGH, or URGENT. The default setting
is LOW.
• Severity (CMDFALALM.SV): Lets you set the relative severity of the
Command Fail alarm on a scale of 0 to 15. Where 15 is the most sever. The
default setting is 0.
949

alarm.
• Priority (UNCMDALM.PR): Lets you select the priority level of the
Uncommanded Change alarm as NONE, JOURNAL, LOW, HIGH, or
URGENT. The default setting is LOW.
• Severity (UNCMDALM.SV): Lets you set the relative severity of the
Uncommanded Change alarm on a scale of 0 to 15. Where 15 is the most severe.
Safety Override Alarms - The following alarms are configurable to represent
override interlock conditions.
• Severity (SIALM.SV): Lets you set the relative severity of the alarm on a scale
of 0 to 15. Where 15 is the most severe. The default setting is 0.
Override Alarms - Lets you configure the following parameters for the override
interlock alarm.
STOP Override Interlock Alarm - Lets you configure the following parameters for
this alarm.
• Option (OIALM[0].OPT): Lets you specify whether the STOP override interlock
RUN Override Interlock Alarm - Lets you configure the following parameters for
this alarm.
• Option (OIALM[1].OPT): Lets you specify whether the RUN override interlock
Equipment safety alarm- Lets you configure the following parameters for this
alarm.
• Option (MOTORTRIPALM.OPT): Lets you specify whether the motor trip is
• Priority (MOTORTRIPALM.PR): Lets you select the priority level as NONE,
• Severity (MOTORTRIPALM.SV): Lets you set the relative severity of the moto
trip alarm on a scale of 0 to 15. Where 15 is the most severe. The default setting
is 0.
Off Normal Condition - Lets you configure the following parameters for this alarm

a scale of 0 to 15. Where 15 is the most severe. The default setting is 0..
faceplate.
29.5.1 Function-LTMOTOR block

• 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 BADPV, Command Disagree, Equipment Safety, Uncommanded Change, Command Fail, and
interlock trip alarms.
• Provides PV Change of state event.
• 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.
• Provides Initialization with OPFINAL based configuration.
• Provides Boolean Command option.
• Provides batch level 1 driver option.
• Provides OFF Normal Alarm associated with requested OP.
• Provides maintenance statistics: Running and stopped hours for the motor is calculated and stored in
RUNTIME, STOPTIME parameters. The Trip time is recognized by motor state at STOP and presence of
corresponding OI or SI parameter and stored in TRIPTIME parameter.
You can red tag a LTMOTOR block. Refer to the “About Red Tagging”section for more information.
Predecessor and successor block

The LT Motor Drive Control block can take inputs from DI channels or from the program. All inputs are two
state inputs and can be connected to any block with a digital output. The output of the block can be connected to
951
29.5.2 Configuration examples-LTMOTOR block
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.
953
Callout Description
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.
2 Use the PV parameter connection to carry Remote switch input from the DI channel block to the LT Motor
block.
In case of an auto standby configuration, the LT motor block can be commanded by Auto Start, Auto Stop
provided the Remote switch is 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 LT Motor
block.
In case of a local mode configuration, the LT motor block can be commanded by Local Start, Local Stop
provided the Remote switch is OFF, the local switch is ON and MODEATTR is in PROGRAM.
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.
955
Callout Description
LT Motor block.
Callout Description
the DICHANNEL block to the LT Motor.
Scenario 3
The following scenario depicts the implementation of an LT Motor block in a Control Strategy with UCP Start/
Stop logic and MCC Inputs.
957
Callout Description
LT Motor block.
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, UCP REL, UCP START, UCP STOP from
the DI channel block to the LT Motor block.
In case of a UCP configuration, the LT motor block can be commanded by UCP Start, UCP Stop provided
the Remote switch is ON, Local switch is OFF, UCP REL is ON and MODEATTR is in PROGRAM.
29.5.3 Inputs-LTMOTOR block

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
29.5.4 Outputs-LTMOTOR block

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
• 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.
• The internal PO*CONNECTED parameter is set to ON when the respective PO* is configured as a block
pin and connected to a DOC.ONPULSE or DOC.OFFPULSE input. This lets the drive control block know
what output is used.
• Each PO* can be configured with an individual PULSEWIDTH. The setting range is between 0.000 and 60
seconds with a resolution of 1 millisecond.
• The DOCHANNEL block determines the actual pulsewidth resolution and accuracy based on its execution
rate. It always rounds the configured pulsewidth value up consistent with its own execution rate. For
example, if the execution rate of the DOCHANNEL block is 125 milliseconds and the configured
PULSEWIDTH value is 450 milliseconds (.45 seconds), the actual pulse time output is 500 milliseconds,
which is the next highest multiple of 125 milliseconds.
• A PULSEWIDTH value of 0 is a special case. If a 0 pulse is sent to ONPULSE or OFFPULSE, the
959
The output parameters are: MTTACTED, LOCALSTOPACTED, UCPSTOPACTED, SEQSTOPACTED,

OIACTED, CMDRUN, CMDSTOP, OP, PV, CONSSTARTRDY, PORUN, POSTOP, NUMTRANS[0,1],
NUMALLTRANS, NUMSIOVRD, TRIPTIME, STOPTIME, RUNTIME.
29.5.5 Error handling-LTMOTOR block

• 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.
29.5.6 States-LTMOTOR block

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.
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.
29.5.7 State parameters and descriptors-LTMOTOR block

The block includes the following set of parameters for state associations.
• PV
• PVAUTO
• OP
• OPFINAL
• 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.
designated SAFEOP.
• S0 -Represents settable output State 0 (STOP).
• S1 - Represents settable output State 1 (RUN).
states enumeration.

STATETEXT[3] Safe(STOP) Safe
STATETEXT[4] STOP S0
STATETEXT[5] RUN S1
29.5.8 Mode and mode attribute-LTMOTOR block

• Mode Attribute (MODEATTR) - determines where state commands to the LT Motor block can originate,
that is, who can set the commanded output state (OP), as follows:
MODEATTRCHGFL.
29.5.9 Safe output state-LTMOTOR block

The Safe Output State (SAFEOP) parameter defines the default state for certain actions of the LT Motor block,
such as OP initialization. In case of the LT Motor the safe Output State (SAFEOP) is predefined as STOP State.
29.5.10 Command dependency on switches and mode attribute-LTMOTOR block
LT MOTOR Local\Remote Switch ModeAttribute

LocalStart LOCAL
UCPStart REMOTE
AutoStart REMOTE PROG
961
LT MOTOR Local\Remote Switch ModeAttribute

SeqStart REMOTE PROG
ConsoleStart REMOTE OPER
LocalStop LOCAL
UCPStop
AutoStop REMOTE PROG
SeqStop REMOTE PROG
ConsoleStop OPER
Ignore
Check
29.5.11 Local manual-LTMOTOR block

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
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.
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.
29.5.12 Permissive interlocks-LTMOTOR block

PI[0..1]are Permissive Interlocks which are inputs that can be connected to an external function block to
LT Motor block to a specific state. Permissive Interlocks themselves never cause OP to change.
ON.
29.5.13 Safety Override Interlock-LTMOTOR block

The Safety Override Interlock (SI) forces the commanded output state (OP) to the Safe Output State (STOP)
• SI can be connected to other blocks or can be directly set by an operator if the MODEATTR parameter is set
to Operator and the block is inactive.
• SI is defaulted to OFF, it must be set to ON to force OP to go to STOP.
• When SI turns OFF, OP = STOP is maintained until changed by:
– the operator
– a user program
29.5.14 Override Interlocks-LTMOTOR block

• Override Interlocks can be connected to other block outputs or can be directly set by an operator if
determined by the state assigned to predefined SAFEOP that is STOP and the priority is SI, OI[0], OI[1].
29.5.15 Configurable Override/Permissive Interlock Bypass-LTMOTOR block

To grant an operator the ability to bypass the Permissive and Override Interlocks for a LT Motor block, the
29.5.16 Alarms-LTMOTOR block

An available set of PV state alarms can be configured to represent disagreements between the Commanded
• Command Fail alarm - generated when the Current Active State (PV) fails to change from an original value
LT Motor block configuration form. The value of OP just commanded determines which
963
Attention
state[0..1].
• 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
– 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
• 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.
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
notification) always occurs regardless of effects of the other alarm.
29.5.17 Seal-in option-LTMOTOR block

enabled, when the condition is detected, field output destinations are set to the Safe Output State (STOP), but
Attention
29.5.18 Initialization Manual condition-LTMOTOR block

• INITDOWN[1..2] - This is an input which may be connected to the DOC INITREQ output. When possible,
connected.
are TRUE.
29.5.19 OP initialization option-LTMOTOR block

Initialization.
29.5.20 Initialization Manual condition with Safety Override Interlock, Override Interlocks, LocalMan,
and OP initialization-LTMOTOR block
When the INITMAN parameter transitions from ON to OFF, the LT Motor FB provides an output value OP as
follows:
• If the Safety Interlock is active, the OP is set to STOP;
• If any of the Override Interlocks are active and not bypassed, the OP is set to the highest priority Override
Interlock;
• If LocalMan is ON, OP tracks PV, if PV is in a settable state (STOP, RUN). If PV is in an unsettable state
(BAD), or PV does not exist, OP is set to STOP;
• If OP Initialization is configured as HOLDOPOPT, OP remains on the last value;
• If OP Initialization is configured as SAFEOPOPT, OP is set to STOP;
• If OP Initialization is configured as NORMALOPOPT, in cases where feedback is configured, the stored OP
value tracks the PV state if the PV state is settable ( STOP, RUN)
• OP value is back-initialized from the output connections if
Otherwise, OP is set to STOP.
29.5.21 Initialization with pulse output-LTMOTOR block

If Pulse Outputs are configured, the following rules apply in generating pulses when recovering from
initialization:
• When PV is good, OP and OPFinal are initialized to PV, no pulse is generated.
• When PV is Bad, OP and OPFinal are initialized to STOP, pulse is generated.
29.5.22 Initialization request flags-LTMOTOR block

The LT Motor function block parameter INITREQ[0..1] provides an indication whether a command to a certain
state (corresponding to the parameter index 0..1) is accepted and acted upon at the current time. This parameter
can be read prior to sending a command to the block to check if the device can respond as required. INITREQ[i]
(i = 0 or 1) = OFF indicates that the block can be commanded to statei, and INITREQ [i] (i = 0, or 1) = ON
965
indicates that the block cannot be commanded to statei. Override interlocks and permissive interlocks cause a
certain state to be non-settable at a given point in time.
29.5.23 OP and DO initialization after load-LTMOTOR block

typically used in strategies where the output of a LT Motor FB is connected to non-initializable blocks, such as
logic blocks. The configuration is done through INITOPAFTLD. The user has to configure the initialization
state for OP, and the value of OP is mapped to DOs, according to the configured map of OP-DO (OPDOMAP),
after load. The options for INITOPAFTLD can be any configured states (STOP, RUN), or default. The default
option initializes OP to STOP.
29.5.24 Maintenance statistics-LTMOTOR block

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:
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
The statistics are accumulated after the most recent reset. The operator can reset the statistics of LT MOTOR
29.5.25 Output requests-LTMOTOR block

Whenever an external FB attempts to change the commanded state OP, the LT MOTOR block uses the OP
to OP.
29.5.26 Output command-LTMOTOR block

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).
• Similarly, you can command the LT Motor block through LOCAL START/STOP, UCP START/STOP
– Both LOCAL and UCP commands ignore MODEATTR
– LOCAL START/STOP depends on the LOCAL SWITCH which should be ON.
– UCP STOP ignores the LOCAL/REMOTE SWITCH condition.
– UCP START depends on REMOTE SWITCH which should be ON.
• Similarly, you can command the LT Motor block through Console START/STOP provided the following
conditions are met:
– MODEATTR should be OPER
– Console STOP ignores LOCAL REMOTE SWITCH condition.
– Console START depends on REMOTE SWITCH which should be ON.
If an SCM commands the LT Motor block by sending a Null type of request to GOP and there are active
OPCMDs such as AUTO START/STOP, UCP START/STOP, LOCAL START/STOP. (this is possible when
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 LT Motor can also be commanded by SCM through SEQ START/STOP when SCM option is FIXED and
MODEATTR is PROGRAM.
Attention
• UCP START/STOP, SEQ START/STOP, LOCAL START/STOP work on OFF to ON transitions. So, there is no
priority for them.
• AUTO START/STOP work on priority as per SAFEOP which is STOP since they are latched.
• LOCAL START/STOP, UCP START/STOP commands change the MODEATTR to Operator.
• AUTO START/STOP, SEQ START/STOP, UCP START, CONSOLE START depends on REMOTESWITCH
which should be ON.
• AUTO START/STOP, SEQ START/STOP is not allowed when BYPASS is ON.
• UCP STOP and CONSOLE STOP ignore switches for its operation.
• CONSSTARTRDY indicates that the motor can be started from the Console. It checks for all the interlocks and
permissives required for starting the motor from the console. However, once the motor is running,
CONSSTARTRDY is of no consequence.

29.5.28 LTMOTOR parameters

Control block.
967
29.6 MAINIBV (IBV Logic) Block

Some high pressure valves require an Integral Bypass Valve to ease the main valve operation by equalizing the
pressure across its ports. Every time an open command is issued; it first initiates the IBV to open. Once the IBV
is fully open, an open command is released to the Main Valve after a configured time delay. Subsequent to the
opening transition (closed to not closed) of the main valve, the IBV valve is closed.
Some applications use additional digital input from a DP switch across the main valve. In these applications, the
main valve OPEN command is released only when the DP switch acts and open feedback of the IBV reaches the
block.
The Main - IBV Logic function block (MAINIBV), available under the POWERGEN library has a user
configurable DELAY parameter for providing the time delay before releasing an open command to the main
valve from the moment the IBV open feedback is sensed by the block. The feedback can be open limit switch of
IBV or the action of DP switch across the valve indicating the flow of the actual process fluid across the main
valve. The bypass valve in not kept in an OPEN condition if the main valve OPEN command fails. A user
configurable timer is provided to close the IBV in such eventualities. The IBV Logic function block is
graphically represented as follows:
The Main - IBV Logic block supports the following user configurable attributes. The following table lists the
with that tab.

• Main Valve Open CMD Delay (DELAY) - Enables you to specify the time delay
before an open command to Main valve is issued from the moment the IBV open
command is sensed by the block
• Open CMD Time Out (IBVVLVFDBKTO) - Expiry of this timer (in seconds)
indicates that desired feedback has not come and the open command operation is
aborted.
• Close CMD Time Out (MAINVLVFDBKTO) - Expiry of this timer (in seconds)
indicates that desired feedback has not come and the open command operation is
aborted.
• Open Seq Fail Alarm Priority (OPENSEQALM.PR) - Indicates the relative
priority of the alarm.
• Open Seq Fail Alm Severity (OPENSEQALM.SV) - Indicates the relative
severity of the alarm (from 0 to 15).
• Close Seq Fail Alm Priority (CLOSESEQALM.PR) - Indicates the relative
priority of the alarm.
• Close Seq Fail Alm Severity (CLOSESEQALM.SV) - Indicates the relative
severity of the alarm (from 0 to 15).
• BAD PV Alarm Priority (BADPVALM.PR) - Lets you set the desired priority
• BAD PV Alarm Severity (BADPVALM.SV) - Lets you assign a relative severity
faceplate.
969
29.6.1 Function-MAINIBV block

• 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.
29.6.2 Inputs-MAINIBV block

• 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.
29.6.3 Outputs-MAINIBV block

• OPENIBV\CLOSEIBV - Open/Close command to IBV drive control.
• OPENMAIN\CLOSEMAIN - Open/Close command to Main Valve drive control.
29.6.4 Control logic-MAINIBV block

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
Path (1): Activation
Path (2): OPEN Command Detected in IDLE status
Path (3): Processing in Open Sequence
Path (4): Open Sequence success
Path (5): Open Sequence failure
Path (6): CLOSE Command detected in Open Sequence
Path (7): CLOSE Command Detected in IDLE status Detected in IDLE status
Path (8): Processing in Close Sequence
Path (9): Close Sequence success
Path (10): Close Sequence failure
Attention
• SCM writes directly to OPENSEQ and CLOSESEQ from SCM Expressions.
• SCM can write directly to OP/GOP of Valve damper/drive/Dev Ctrl from SCM Expressions (which is always
connected in the downstream of MAINIBV.)
• Operator can take control of Valve Damper/ Drive/ Dev ctl by changing mode attribute to operator whenever
required for bypassing the MAINIBV.
29.6.5 Open sequence logic-MAINIBV block

The Open sequence logic is illustrated by the following flow-chart:
971
29.6.6 Close sequence logic-MAINIBV block

The Close sequence logic is illustrated in the following flow-chart:
Attention
• The OPEN IBV command is withdrawn as soon as the OPEN IBV feedback is received. To issue OPEN
command, the CLOSEMAIN feedback should be ON.
• An Interlock error is displayed if the open cmd is issued when CLOSEMAINFEEDBACK is OFF.
• If feedback is received when the MAIN valve is OPEN, a CLOSEIBV command is issued and IBVOPENFDBK is
rejected leading to alarm generation and the FB goes to IDLE status.
• The block generates OPENCMD and CLOSECMD alarms based on open sequence fail and close sequence fail
respectively. An additional Event is generated that indicates the exact cause of the alarm (IBV feedback time out/
Main feedback time out.)
29.6.7 Error handling-MAINIBV block

• 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.
29.6.8 MAINIBV parameters

Refer to the Control Builder Components Reference for a complete list of the parameters used with the Main-
IBV Logic block.
973
29.7 SOLENOID (Solenoid Valve Drive Control) Block

Control block is designed for all types of drives like LT, HT, and valves. It has configurable states, number of
inputs, number of outputs, and hosts PV and OP alarms. The states have to be configured before using the
block. There is a single permissive and interlock input for each state. Therefore all the switchgear related inputs
and Process inputs have to hover around this one single input pin by employing OR or AND blocks for
multiplexing.
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.

• PV Source selection (PVSRCOPT) - Lets you select the source of the PV as
SUB for a user program, MAN for an operator, or AUTO for process input
connection, TRACK for tracking OP. Only applicable with PV Source Option
selection of ALL. The default selection is AUTO.
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 to 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.
DISABLED and ENABLED. If ENABLED, the field output destinations are set
to SAFEOP but OP is not altered.
SEALOPT can be enabled only when CMDDISALM.TM[0..1] is configured.
effect immediately.
975

box checked, you can track the maximum number of transitions of PV to each
state (NUMTRANS[0 -1]) for comparison purposes only. The default is OFF or
box unchecked and NUMTRANS[0 -1] in maintenance statistics is not collected.
you can track the maximum number of SI overrides to each state for comparison
purposes only. The default is OFF or box unchecked and the NUMSIOVRD in
maintenance statistics are not collected.
• Maint. stats. reset flag (RESETFL) - An operator can only reset statistics while
the block is red tagged, but a user program or another FB can turn ON the
• No. of safety ovr. trips (NUMSIOVRD))- Accumulated number of safety
• Number of State transitions (NUMTRANS) - Total number of state transitions.
• No. of all PV transitions (NUMALLTRANS)- Accumulated number of
• (RESETFL) - Lets you reset all maintenance statistics to their default values.
• Abnormal State Options - Lets you specify the action the function block should
selection is NONE.
• The Restart State Option (RESTARTOPT) applies when the SCM state is

Alarms PV Alarming - The following alarms are configurable to represent disagreements
between the commanded state (OP) and the feedback state (PV). These alarms are
disabled if there are no inputs or outputs.
to NORMAL when the PV state becomes the same as the OP state. This alarm
does not apply for momentary commanded states.
Bad PV (BADPVALM.FL): This alarm is generated whenever PV is detected in the
Null state. The Null state can result from a BadPV condition for an input provided
by a source block, or because input combinations represent a Null state. Lets you
configure the following parameters for this alarm.
• Time to CLOSE (or assigned State Name) (CMDDISALM.TM[0]): Lets you set
the feedback time for CLOSE in range of 0 to 1000 seconds. A time of 0
• Time to OPEN (or assigned State Name) (CMDDISALM.TM[1]): Lets you set
the feedback time for OPEN in range of 0 to 1000 seconds. A time of 0 disables
• Priority (CMDDISALM.PR): Lets you select the priority level as NONE,
• Severity (CMDDISALM.SV): Lets you set the relative severity of the alarm on a
scale of 0 to 15. Where 15 is the most sever. The default setting is 0.
alarm.
• Time to Close (or assigned State Name) (CMDFALALM.TM[0]): Lets you set
the feedback time for Close in range of 0 to 1000 seconds. A time of 0 disables
CMDDISALM.TM[0].
• Time to Open (or assigned State Name) (CMDFALALM.TM[1]): Lets you set
the feedback time for Open in range of 0 to 1000 seconds. A time of 0 disables
CMDDISALM.TM[1].
• Priority (CMDFALALM.PR): Lets you select the priority level as NONE,
• Severity (CMDFALALM.SV): Lets you set the relative severity of the alarm on
a scale of 0 to 15. Where 15 is the most sever. The default setting is 0.
977

alarm.
• Priority (UNCMDALM.PR): Lets you select the priority level as NONE,
• Severity (UNCMDALM.SV): Lets you set the relative severity of the alarm on a
• Override Interlock (OIALM[0..1].FL): This alarm is generated when an override
interlock (OI[0..1]) occurs, causing an OP state change.
Safety Override Alarms - Lets you configure the following parameters for the
safety override interlock alarm
• Safety Override Interlock (SIALM.FL): This alarm is generated when the safety
override interlock (SI) occurs, and causes an OP state change.
• Severity (SIALM.SV: Lets you set the relative severity of the alarm on a scale of
0 to 15. Where 15 is the most severe. The default setting is 0.
Close Override Interlock Alarm - Lets you configure the following parameters for
this alarm.
• Option (OIALM[0].OPT): Lets you specify whether the Close override interlock
Open Override Interlock Alarm - Lets you configure the following parameters for
this alarm.
• Option (OIALM[1].OPT): Lets you specify whether the Close override interlock
Off Normal Condition - Lets you configure the following parameters for this alarm.

faceplate.
29.7.1 Function-SOLENOID block

• 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 BADPV, Command Disagree, SafetyInterlock , Uncommanded Change and Command Fail,
Override Interlock alarms.
• Allows PV change of state event.
• Provides Interlock trip alarms.
• Provides a Seal In option.
• Provides an explicitly configured safe state.
• Provides Initialization with OPFINAL based configuration.
• Provides Boolean command option
• Provides batch level 1 driver option.
• Provides OFF Normal alarm associated with requested OP.
You can red tag a SOLENOID block. Refer to the “About Red Tagging” section for more information.

The Solenoid Valve Control block takes inputs from DI channels or from the PROGRAM. All the inputs are two
state inputs and are connected to any block with a digital output. The output of the block can be connected to a
29.7.2 Configuration examples-SOLENOID block
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.
979
981
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.
In case of an auto standby configuration, the Solenoid Valve block can be commanded by Auto Open, Auto
Close provided the Remote switch is 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 Solenoid
Valve block.
In case of a local mode configuration, the Solenoid Valve block can be commanded by Local Open, Local
Close provided the Remote switch is OFF, the local switch is ON and MODEATTR is in PROGRAM.
Scenario 2:
Safety, Override and permissive inputs and MCC inputs.
983
Callout Description
Valve block.
In the Solenoid Valve block, the MCC inputs (LTO, LTC) provide the feedback if the valve is open or
close.
the DICHANNEL block to the Solenoid Valve block.
Scenario 3:
UCP Open/Close logic and MCC inputs.
985
Callout Description
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, UCP REL, UCP Open, UCP Close from
the DI channel block to the Solenoid Valve block.
In case of a UCP configuration, the Valve/Damper block can be commanded by UCP Open, UCP Close
provided the Remote switch is ON, Local switch is OFF, UCP REL is ON and MODEATTR is in
PROGRAM.
29.7.3 Inputs-SOLENOID block

The inputs which are physically wired to the system and brought to this block via 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
29.7.4 Outputs-SOLENOID block

The output parameters are: CMPOPEN, OP, PV, NUMTRANS[0,1], NUMSIOVRD
29.7.5 Error handling-SOLENOID block

• 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.
29.7.6 States-SOLENOID block

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.
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.
29.7.7 State parameters and descriptors-SOLENOID block

• PV
• PVAUTO
• OP
• OPFINAL
STATETEXT[0..6] parameter for use by an operator.
• Active - Refers to momentary state settings for a two-state device. It is defined as not SAFEOP of Close and
Open and illegal for 3 state configurations. For example, if SAFEOP is designated as Close (S0), Open (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.
987
designated SAFEOP.
• S0 -Represents settable output State 0 (CLOSE).
• S1 - Represents settable output State 1 (OPEN).
• S2 - Represents settable output State 2 .
The following table lists the default Solenoid name for a given STATETEXT[0..6] and shows the corresponding
generic states enumeration.
If STATETEXT is? Then, the default Solenoid name is And, GENSTAT_ENM is

STATETEXT[3] Safe(OPEN/CLOSE) Safe
STATETEXT[4] CLOSE S0
STATETEXT[5] OPEN S1
29.7.8 Mode and mode attribute-SOLENOID block

• Mode Attribute (MODEATTR) - determines where state commands to the Solenoid Valve block can
originate - that is, who can set the commanded output state (OP), as follows:
MODEATTRCHGFL.
29.7.9 Safe output state-SOLENOID block

The Safe Output State (SAFEOP) parameter defines the default Solenoid valve state for certain actions of the
Solenoid Valve block, such as OP initialization. The safe Output State (SAFEOP) is configurable as OPEN/
CLOSE State.
29.7.10 Command dependency on switches and mode attribute-SOLENOID block
Solenoid Local\Remote Switch ModeAttribute

LocalOpen LOCAL
UCPOpen
AutoOpen REMOTE PROG
SeqOpen REMOTE PROG
ConsoleOpen OPER
Solenoid Local\Remote Switch ModeAttribute

LocalClose LOCAL
UCPClose
AutoClose REMOTE PROG
SeqClose REMOTE PROG
ConsoleClose OPER
Ignore
Check
Based on Safe OP configuration
If Safe OP = OPEN then UCPOpen and Console Open will ignore switches.
If Safe OP = CLOSE then UCPClose and ConsoleClose will ignore switches.
29.7.11 Local manual-SOLENOID block

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
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.
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.
29.7.12 Permissive interlocks-SOLENOID block

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.
989
29.7.13 Safety Override Interlock-SOLENOID block

The Safety Override Interlock (SI) forces the commanded output state (OP) to the Safe Output State (SAFEOP)
• SI may be connected to other blocks or can be directly set by an operator if the MODEATTR parameter is
• SI is OFF by default in case of Solenoid, it must be set to ON to force OP to go to SAFEOP.
• When SI turns OFF, OP = SAFEOP is maintained until changed by:
– the operator
– a user program
29.7.14 Override Interlocks-SOLENOID block

• 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.
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].
29.7.15 Configurable Override/Permissive Interlock Bypass-SOLENOID block

To grant an operator the ability to bypass the Permissive and Override Interlocks for a Solenoid Valve block, the
• When BYPASS is ON, OP can be changed regardless of the state of the Override and Permissive Interlocks.
• When BYPPERM is OFF, BYPASS is OFF by default in case of Solenoid and is read-only.
29.7.16 Alarms-SOLENOID block

• 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

Attention
state[0..1].
• 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.
– The feedback time (CMDDISALM.TM[0..1) for each state can be configured through the Alarms tab on
Solenoid Valve block configuration form. The value of OP just commanded determines which
• Uncommanded Change alarm - It 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.
state.
• Override Interlock alarms - When the alarm is enabled and the active override interlock causes an OP state
• Safety Override Interlock alarm - When the alarm is enabled and the active safety interlock causes an OP
state change, an alarm is generated.
29.7.17 Seal-in option-SOLENOID block

enabled, when the condition is detected, field output destinations are set to the Safe Output State (SafeOP), but
Attention
991
29.7.18 Initialization Manual condition-SOLENOID block

• INITDOWN[1..2] - This is an input which can be connected to the DOC INITREQ output. When possible,
connected.
are TRUE.
29.7.19 OP initialization option-SOLENOID block

NORMALOPT, SAFEOPOPT or HOLDOPOPT. The default value for Solenoid is NORMALOPT.
Initialization.
and OP Initialization-SOLENOID block
OP as follows:
• If the Safety Interlock is active, the OP is set to SAFEOP;
Override Interlock;
• Otherwise, if LocalMan is ON, OP tracks PV, if PV is in a settable state (OPEN/CLOSE). If PV is in an
unsettable state (BAD), or PV does not exist, OP is set to SafeOP;
• Otherwise, if OP Initialization is configured as HOLDOPOPT, OP remains on the last value;
• Otherwise, if OP Initialization is configured as SAFEOPOPT, OP is set to SafeOP;
stored OP value tracks the PV state if the PV state is settable ( CLOSE, OPEN);
• Otherwise, OP value is back-initialized from the output connections
• If a valid OP value can be constructed from the values of the output connections.
Otherwise, OP is set to SAFEOP.
29.7.21 Initialization request flags-SOLENOID block

The Solenoid Valve function block parameter INITREQ[0..1] provides an indication whether a command to a
certain state (corresponding to the parameter index 0..1) is accepted and acted upon at the current time. This
parameter can be read prior to sending a command to the block to check if the device can respond as required.
INITREQ[i] (i = 0 or 1) = OFF indicates that the block can be commanded to statei, and INITREQ [i] (i = 0, or
1) = ON indicates that the block cannot be commanded to statei. Override interlocks and permissive interlocks
cause a certain state to be non-settable at a given point in time.
29.7.22 OP and DO initialization after load-SOLENOID block

typically used in strategies where the output of a Solenoid Valve FB is connected to non-initializable blocks,
such as logic blocks. The configuration is done through the parameter, INITOPAFTLD. The user has to
configure the initialization state for OP, and the value of OP is mapped to DOs, according to the configured map
of OP-DO (OPDOMAP), after load. The options for INITOPAFTLD can be any configured states (CLOSE,
OPEN), or default. The default option initializes OP to CLOSE, and all the DOs to 0 (OFF).
29.7.23 Maintenance statistics-SOLENOID block

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.
• 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
The statistics are accumulated after the most recent reset. The operator can reset the statistics of Solenoid Valve
Control block anytime irrespective of redtagging,
29.7.24 Output requests-SOLENOID block

Whenever an external FB attempts to change the commanded state OP, the Solenoid Valve block uses the OP
active. OPREQ acts like a repeated attempt to store to OP. The OPREQ is always active unless it is NULL. This
to OP.
29.7.25 Output command-SOLENOID block

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).
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:
993
– 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:
– 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
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.
• AUTO OPEN/CLOSE works on priority as per SAFEOP which is CLOSE since they are latched.
• LOCAL OPEN/CLOSE, UCP OPEN/CLOSE commands change the MODEATTR to Operator.
• AUTO OPEN/CLOSE, SEQ OPEN/CLOSE depends on REMOTESWITCH which should be ON.
• AUTO OPEN/CLOSE, SEQ OPEN/CLOSE is not allowed when BYPASS is ON.
• UCP OPEN/CLOSE and CONSOLE OPEN/CLOSE depends on SAFEOP configuration. If SAFEOP is open,
UCP OPEN, CONSOLE OPEN ignores switches and UCP CLOSE, CONSOLE CLOSE depends on
REMOTESWITCH. If SAFEOP is CLOSE, UCP CLOSE, CONSOLE CLOSE ignore switches and UCP OPEN,
CONSOLE OPEN depend on REMOTESWITCH.
• CONSOPENRDY indicates that the valve can be opened from the Console. It checks for all the permissives and
interlocks required to open the valve from the console. However, once the valve is open, CONSOPENRDY is of
no consequence.

29.7.27 SOLENOID parameters

Control block.
29.8 VALVEDAMPER (Valve/Damper Drive Control) Block

A Drive Control is currently achieved through Device Control Blocks (DEVCTL) in Experion. The existing
Device Control block is designed for all types of drives like LT/ HT Motor, and valves. It has configurable
states, number of inputs, number of outputs, and hosts PV and OP alarms. You have to configure them before
using the block. There is a single permissive and interlock input for each state. Therefore all the switchgear
related inputs and process inputs have to hover around this one single input pin by employing OR or AND
blocks for multiplexing.
The Valve/Damper control function block is graphically represented as follows.
The Valve/Damper control block (VALVEDAMPER), available under the POWERGEN library 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.
995

• Enable PV Source Selection (PVSRCOPT) - Lets you select the source of the
PV as SUB for a user program, MAN for an operator, or AUTO for process
input connection, TRACK for tracking OP. Only applicable with PV Source
Option selection of ALL. The default selection is AUTO.
Output • Init OP After Load (INITOPAFTLD) - Initialization values for OP and
CmdOpen\CmdClose after load. The selections are DEFAULT, NOCOMMAND,
OPEN, CLOSE.
• OP Initialization Option (INITOPOPT) - Lets you specify the state to which OP
NORMALOPT, HOLDOPT and SAFEOPOPT. . By default, the option is
NORMALOPT.
DISABLE and ENABLE. If ENABLE, the field output destinations are set to
SAFEOP but OP is not altered.
• Pulse Output (POCLOSECONNECTED, PORUNCONNECTED) - Lets you
Check equals ON. When enabled, the corresponding output (POCLOSE,
POOPEN) pin is exposed on the block. The default is no pulse outputs
configured. The selectable outputs depend upon the configured number of
outputs.
effect immediately.
• Torque Switch used for Tight-shutoff (TSENABLED) - When ON, the Close
Command cutoff is governed by TSC.
• Use Torque Switch for Protection (TSFORPROT) - When ON, the TSO and
TSC signals are used as protection for Open and Close commands respectively.

box checked, you can track the maximum number of transitions of PV to each
state (NUMTRANS[0 -2]) for comparison purposes only. The default is OFF or
box unchecked and NUMTRANS[0 -2] in maintenance statistics is not collected
you can track the maximum number of SI overrides to each state for comparison
purposes only. The default is OFF or box unchecked and the NUMSIOVRD in
maintenance statistics are not collected.
• Maint. stats. reset flag (RESETFL) - An operator can only reset statistics while
the block is red tagged, but a user program or another FB can turn ON the
• No. of safety ovr. trips (NUMSIOVRD)- Accumulated number of safety
• Number of Transitions (NUMTRANS[0 -2]) - Accumulated time of PV in each
state, after the last statistics reset.
• Track Open Feedback Time (TRKOPENFEEDBKTIME) - When ON, the time
taken to receive Open feedback after the Open command is issued is recorded.
• Track Close Feedback Time (TRKCLOSEFEEDBKTIME) - When ON, the time
taken to receive Close feedback after the Close command is issued is recorded.
• Open Feedback Time (OPENFEEDBKTIME) - The time taken in seconds to
receive Open feedback after the Open command is issued.
• Close Feedback Time (CLOSEFEEDBKTIME) - The time taken to receive
Close feedback after the Close command is issued.
selection is NONE.
997

Alarms PV Alarming - The following alarms are configurable to represent disagreements
between the commanded state (OP) and the feedback state (PV). These alarms are
disabled if there are no inputs or outputs.
• Command Disagree (CMDDISALM.FL) - This alarm is generated when the
to NORMAL when the PV state becomes the same as the OP state. This alarm
does not apply for momentary commanded states.
• Command Fail (CMDFALALM.FL) - This alarm checks to see if the PV state
• Bad PV (BADPVALM.FL): This alarm is generated whenever both feedbacks
are ON.
• Safety Override Interlock (SIALM.FL) - This alarm may be generated when the
safety override interlock (SI) occurs, and has caused an OP state change.
• Override Interlock (OIALM[0..2].FL) - This alarm is generated when an
override interlock (OI[0..2]) occurs, and causes an OP state change.
Off Normal Condition (OFFNRMALM.FL) - If an interlock bypass becomes
active when OPREQ is not Null, the OPREQ is transmitted to OP immediately upon
activation of the bypass parameter. If bypass is activated after an interlock has been
initiated, the OP and OFFNRMALM.FL is corrected within one scan
• Time to OPEN (or assigned State Name) (CMDDISALM.TM[1]) - Lets you set
the feedback time for State 1 in range of 0 to 1000 seconds. A time of 0 disables
• Time to CLOSE (or assigned State Name) (CMDDISALM.TM[2]) - Lets you set
the feedback time for State 2 in range of 0 to 1000 seconds. A time of 0 disables
the alarm. The default setting is 0. This can only be configured if the number of
states is 3.
disagree alarm as NONE, JOURNAL, LOW, HIGH, or URGENT. The default
setting is LOW.
Command disagree alarm on a scale of 0 to 15. Where 15 is the most severe. The
alarm.
• Time to State OPEN (CMDFALALM.TM [1]) - Lets you set the feedback time
for State 1 in range of 0 to 1000 seconds. A time of 0 disables the alarm. The
default setting is 0. This value must be less than the value set for
CMDDISALM.TM [1].
• Time to State CLOSE (CMDFALALM.TM[2]) - Lets you set the feedback time
for State 2 in range of 0 to 1000 seconds. A time of 0 disables the alarm. The
default setting is 0. This value must be less than the value set for
CMDDISALM.TM[2]. This can only be configured if the number of states is 3.

Fail alarm as NONE, JOURNAL, LOW, HIGH, or URGENT. The default setting
is LOW.
Command Fail alarm on a scale of 0 to 15. Where 15 is the most sever. The
alarm.
• Priority (UNCMDALM.PR) - Lets you select the priority level as NONE,
• Severity (UNCMDALM.SV) - Lets you set the relative severity of the alarm on
• Priority (BADPVALM.PR) - Lets you select the priority level as NONE,
• Severity (BADPVALM.SV) - Lets you set the relative severity of the alarm on a
Override Alarms - Lets you configure the following parameters for the safety
override interlock alarm.
• Option (SIALM.OPT) - Lets you specify whether the safety override interlock
• Priority (SIALM.PR) - Lets you select the priority level as NONE, JOURNAL,
• Severity (SIALM.SV): Lets you set the relative severity of the alarm on a scale
of 0 to 15. Where 15 is the most severe. The default setting is 0.
NOCOMMAND Override Interlock Alarm - Lets you configure the following
parameters for this alarm.
• Option (OIALM[0].OPT): Lets you specify whether the NOCOMMAND
override interlock alarm is enabled or not. The default setting is DISABLED.
OPEN Override Interlock Alarm - Lets you configure the following parameters
for this alarm.
• Option (OIALM[1].OPT): Lets you specify whether the OPEN override
CLOSE Override Interlock Alarm - Lets you configure the following parameters
for this alarm.
• Option (OIALM[2].OPT): Lets you specify whether the CLOSE override
999

Off Normal Condition - Lets you configure the following parameters for this alarm.
Torque Switch Open Alarm - Lets you configure the following parameters for this
alarm.
• Option (TSOALM.OPT): Lets you specify whether the OPEN override interlock
• Priority (TSOALM.PR): Lets you select the priority level as NONE, JOURNAL,
• Severity (TSOALM.SV): Lets you set the relative severity of the alarm on a
Torque Switch Close Alarm - Lets you configure the following parameters for this
alarm.
• Option (TSCALM.OPT): Lets you specify whether the OPEN override interlock
• Priority (TSCALM.PR): Lets you select the priority level as NONE, JOURNAL,
• Severity (TSCALM.SV): Lets you set the relative severity of the alarm on a
Equipment safety alarm - Lets you configure the following alarms:
• Motor Trip alarm: Lets you configure the following parameters for the alarm.
– Option (MOTORTRIPALM.OPT): Lets you specify whether the motor trip
– Priority (MOTORTRIPALM.PR): Lets you select the priority level as
NONE, JOURNAL, LOW, HIGH, or URGENT. The default setting is LOW.
– Severity (MOTORTRIPALM.SV): Lets you set the relative severity of the
motor trip alarm on a scale of 0 to 15. Where 15 is the most severe. The
• Winding Temperature Switch alarm: Lets you configure the following
parameters for the alarm.
– Option (WTSALM.OPT): Lets you specify whether the winding temperature
switch alarm is enabled or not. The default setting is ENABLED.
– Priority (WTSALM.PR): Lets you select the priority level as NONE,
– Severity (WTSALM.SV): Lets you set the relative severity of the winding
temperature switch alarm on a scale of 0 to 15. Where 15 is the most severe.
faceplate.

29.8.1 Function-VALVEDAMPER block

• 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 BADPV, Command Disagree, SafetyInterlock, Uncommanded Change and Command Fail,
Override Interlock alarms.
• Provides PV change of state event.
• Provides interlock trip alarms.
• Provides a seal-in option.
• Provides a Safety Interlock that enforces the defined safe state.
• Predefines Safe State as NoCommand.
• 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 the “About Red Tagging” section for more information.

The Valve/Damper Drive Control block accepts inputs from DI channels or from the PROGRAM. All inputs are
two state inputs and can be connected to any block with a digital output. The output of the block can be
connected to DO or further connected to subsequent logic, if necessary.
29.8.2 Configuration examples-VALVEDAMPER block
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.
1001
1003
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.
In case of an auto standby configuration, the Valve/Damper block can be commanded by Auto Open, Auto
Close provided the Remote switch is 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.
In case of a local mode configuration, the Valve/Damper block can be commanded by Local Open, Local
Close provided the Remote switch is OFF, the local switch is ON and MODEATTR is in PROGRAM.
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.
1005
Callout Description
Damper block.
open or close.
Valve/Damper block.
the DICHANNEL block to the Valve/Damper block.
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.
1007
Callout Description
Damper block.
open or close.
Valve/Damper block.
2 Use the PV parameter connection to carry Remote switch input, UCP REL, UCP Open, UCP Close from
the DI channel block to the Valve/Damper block.
In case of a UCP configuration, the Valve/Damper block can be commanded by UCP Open, UCP Close
provided the Remote switch is ON, Local switch is OFF, UCP REL is ON and MODEATTR is in
PROGRAM.
29.8.3 Inputs-VALVEDAMPER block

The inputs which are physically wired to the system and brought to the block via 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.
29.8.4 Outputs-VALVEDAMPER block

The output parameters are: POOPEN, POCLOSE, CMDOPEN, CMDCLOSE, OP, PV, NUMTRANS[0,1,2],
NUMALLTRANS, NUMSIOVRD, OPENFEEDBKTIME, CLOSEFEEDBKTIME
29.8.5 Limit Switches-VALVEDAMPER block

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.
• 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 not withdrawn provided TSForProt is OFF.
• If TSC feedback is received before the LTC feedback, it is an indication of an abnormality and a TSC alarm
is raised and CLOSE command is not withdrawn provided TSForProt is OFF and TSEnabled is OFF.
• If TSForProt is OFF and TSO acted, the OPEN command is not withdrawn.
• When TSForProt is ON and TSC is also ON, you cannot issue CLOSE command.
• If TSEnabled is OFF, the LTC feedback is used to withdraw the CLOSE command.
• If TSEnabled is ON, the TSC feedback in place of the LTC feedback is used to withdraw the CLOSE
command.
• If TSC feedback is received before the LTC feedback, it is an indication of an abnormality and a TSC alarm
is raised and CLOSE command is withdrawn provided TSEnabled or TSForProt is ON.
• A CLOSE command cannot be issued if LTC is ON and TSEnabled is OFF.
• A CLOSE command cannot also be issued if TSC and TSEnabled are ON.
• If TSEnabled or TSForProt are ON and TSC is ON, you cannot issue a CLOSE command.
• If OI(1) transitions from OFF to ON when TSO or LTO is ON, the store will be rejected as per LTO OR
(TSO AND TSCPROT).
• If LTO or TSO acts while OI(1) is ON or PI(0) OFF, command withdrawal is affected. After command
withdrawal is effected, if OI(2) transitions from OFF to ON, the OP state does not change since SAFEOP is
configured as S0 (NOCOMMAND). OP can be commanded to close if OI(1) is OFF.
29.8.6 Error handling-VALVEDAMPER block

• 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). oth ON is flagged and output is not
generated.
1009
29.8.7 States-VALVEDAMPER block

A “stat” 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.
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.
29.8.8 State parameters and descriptors-VALVEDAMPER block

• PV
• PVAUTO
• OP
• OPFINAL
• Generic state parameters
STATETEXT[0..6] parameter for an operator's use.
The generic state parameters are consistent data types, which can be compared with each other through the
• Active - Refers to momentary state settings for a two-state device.
• Safe - Stands for SAFEOP which is NOCOMMAND. 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 (NOCOMMAND).
• S1 - Represents settable output State 1 (OPEN).
• S2 - Represents settable output State 2 (CLOSE)
state enumeration.


STATETEXT[3] Safe(NOCOMMAND) Safe
STATETEXT[5] OPEN S1
STATETEXT[6] CLOSE S2
29.8.9 Mode and mode attribute-VALVEDAMPER block

• Mode Attribute (MODEATTR) - determines where state commands to the Valve/Damper block originate,
that is, which access level can set the commanded output state (OP), as follows:
MODEATTRCHGFL.
29.8.10 Safe output state-VALVEDAMPER block

The Safe Output State (SAFEOP) parameter defines the default Valve/Damper state for certain actions of the
Valve/Damper block, such as OP initialization. In case of a Valve/Damper, the safe Output State (SAFEOP) is
predefined as NOCOMMAND.
• When OP or GOP is commanded to SAFE, the effective value of OP (GOP) is set equal to SAFEOP which
is NOCOMMAND.
29.8.11 Command dependency on switches and Mode attribute-VALVEDAMPER block
ValveDamper Local\Remote Switch ModeAttribute

LocalOpen LOCAL
UCPOpen REMOTE
AutoOpen REMOTE PROG
SeqOpen REMOTE PROG
ConsoleOpen REMOTE OPER
LocalClose LOCAL
UCPClose REMOTE
AutoClose REMOTE PROG
SeqClose REMOTE PROG
ConsoleClose REMOTE OPER
Ignore
Check
1011
29.8.12 Local manual-VALVEDAMPER block

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.
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.
29.8.13 Permissive interlocks-VALVEDAMPER block

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.
29.8.14 Safety Override Interlock-VALVEDAMPER block

The Safety Override Interlock (SI) forces the commanded output state (OP) to the Safe Output State
(NOCOMMAND) when active. OP cannot be commanded to a different state when SI is active.
• When MODEATTR is set to OPER and the block is inactive, the SI can be connected to other blocks or can
be directly set by an operator.
• SI is OFF by default in case of Valve/Damper; it must be set to ON to force OP to go to SAFEOP which is
NOCOMMAND.
• When SI turns OFF, OP = NOCOMMAND is maintained until it is changed by an operator, a user program,
or another Safety Override Interlock.
29.8.15 Override Interlocks-VALVEDAMPER block

OI[0..2] are Override Interlocks which, when active, force the commanded output (OP) to its respective state
• 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.
determined by the state assigned to a predefined SAFEOP that is NOCOMMAND and the priority is SI,
OI[0], OI[1], OI[2].
29.8.16 Configurable Override/Permissive Interlock Bypass-VALVEDAMPER block

To grant an operator the ability to bypass the Permissive and Override Interlocks for a Valve/Damper block, the
• When BYPASS is ON, OP can be changed regardless of the state of the Override and Permissive Interlocks.
• When BYPPERM is OFF, BYPASS is OFF by default in case of Valve/Damper and is read-only.
29.8.17 Alarms-VALVEDAMPER block

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
– 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
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.
• 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
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
state[1..2].
• 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.
state.
1013
• Override Interlock alarms - When the alarm is enabled and the active override interlock causes an OP state
• 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
29.8.18 Seal-in option-VALVEDAMPER block

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.
29.8.19 Initialization Manual condition-VALVEDAMPER block

• INITDOWN[1..2] - This is an input which is connected to the DOC INITREQ output. When possible, this
connection is made automatically by the system, without any user action.
connected.
• INITMAN - This is a BOOLEAN value which is set TRUE whenever any of the INITDOWN[i].STATUS is
TRUE.
29.8.20 OP initialization option-VALVEDAMPER block

NORMALOPT, SAFEOPOPT or HOLDOPOPT. The default value for Valve/Damper is NORMALOPT.
Initialization.
• INITOPOPT = SAFEOPOPT, OP is set to NOCOMMAND
and OP Initialization-VALVEDAMPER block
OP as follows:
• If the Safety Interlock is active, the OP is set to NOCOMMAND;
Override Interlock;
• Otherwise, if LocalMan is ON, OP tracks PV, if PV is in a settable state (OPEN/CLOSE). If PV is in an
unsettable state (BAD), or PV does not exist, OP is set to SafeOP;
• Otherwise, if OP Initialization is configured as HOLDOPOPT, OP remains on the last value;
• Otherwise, if OP Initialization is configured as SAFEOPOPT, OP is set to NOCOMMAND;
stored OP value tracks the PV state if the PV state is settable ( State0, State1);
• Otherwise, OP value is back-initialized from the output connections
• If a valid OP value can be constructed from the values of the output connections.
Otherwise, OP is set to NOCOMMAND.
29.8.22 Initialization request flags-VALVEDAMPER block

The Valve/Damper function block parameter INITREQ[0..1] provides an indication whether a command to a
certain state (corresponding to the parameter index 0..1) is accepted and acted upon at the current time. This
parameter can be read prior to sending a command to the block to check if the device can respond as required.
INITREQ[i] (i = 0 or 1) = OFF indicates that the block can be commanded to statei, and INITREQ [i] (i = 0, or
1) = ON indicates that the block cannot be commanded to statei. Override interlocks and permissive interlocks
cause a certain state to be non-settable at a given point in time.
29.8.23 OP and DO initialization after load-VALVEDAMPER block

typically used in strategies where the output of a Valve/Damper FB is connected to non-initializable blocks,
such as logic blocks. The configuration is done through the parameter, INITOPAFTLD. The user has to
configure the initialization state for OP, and the value of OP is mapped to DOs, according to the configured map
of OP-DO (OPDOMAP), after load. The options for INITOPAFTLD can be any configured states (CLOSE,
OPEN, NOCOMMAND), or default. The default option initializes OP to NOCOMMAND, and all the DOs to 0
(OFF).
29.8.24 Maintenance statistics-VALVEDAMPER block

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.
• NUMTRANS[0..2] - Number of transitions of PV to each state. This can be enabled provided
enabled.
• NUMSIOVRD - accumulated number of safety interlock trips, which results in OP changing state (after the
• 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.
1015
The statistics are accumulated after the most recent reset. The operator can reset the statistics of Valve/Damper
29.8.25 Output requests-VALVEDAMPER block

Whenever an external FB attempts to change the commanded state OP, the Valve/Damper block uses the OP
to OP.
29.8.26 Output command-VALVEDAMPER block

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).
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
– 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:
– 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.
• AUTO OPEN/CLOSE work on priority as per SAFEOP which is NOCOMMAND since they are latched.
• LOCAL OPEN/CLOSE, UCP OPEN/CLOSE commands change the MODEATTR to Operator.
• AUTO OPEN/CLOSE, SEQ OPEN/CLOSE, UCP OPEN/CLOSE, CONSOLE OPEN/CLOSE depends on
REMOTESWITCH which should be ON.
• AUTO OPEN/CLOSE, SEQ OPEN/CLOSE is not allowed when BYPASS is ON.
• The Valve/Damper block does not support inching operation. However, to achieve the inching operation, after
issuing an OPEN command to the valve/damper, issue a NO COMMAND and reissue the OPEN command again
until desired. It can also be achieved through logic by using the AUTONOCOMMAND pin. Similarly, issue a
CLOSE command to the valve/damper, then issue a NO COMMAND and reissue the CLOSE command again
until desired.
• If MODEATTR is PROGRAM, UCP and LOCAL operations change the MODEATTR of the Valve to OPER. If
the MODEATTR is already in OPER, UCP and LOCAL operations requests are accepted.
• CONSOPENRDY indicates that the valve can be opened from the Console. It checks for all the permissives and
interlocks required to open the valve from the console. However, once the valve is open, CONSOPENRDY is of
no consequence.
29.8.27 Logic override OPREQ-VALVEDAMPER block

29.8.28 VALVEDAMPER parameters

Control block.
1017
30 Thermodynamic Utility Functions
Thermodynamic utility function blocks provide a variety of configurable functions for computing the
thermodynamic quantities of water and steam. The following table presents the functions performed through the
configuration of the associated thermodynamic utility function block.

“Steam Property Block Compute the thermodynamic Used for computing enthalpy, entropy, specific
(STEAMPROP)” on page 1020 quantities of water and steam. volume, pressure, and temperature of a
thermodynamic system.
The following topics describe about thermodynamic utility function blocks.
Related topics
“Steam Property Block (STEAMPROP)” on page 1020
1019
30 THERMODYNAMIC UTILITY FUNCTIONS
30.1 Steam Property Block (STEAMPROP)

In steam generators and utilities, thermodynamic efficiency is calculated to optimize/maximize the efficiency of
the plant operation. To calculate the thermodynamic efficiency, you need the thermodynamic properties of
steam/water such as entropy, enthalpy, specific volume, and density for a given pressure, temperature and the
state of matter. The STEAMPROP function block accepts temperature/pressure as inputs from measurement and
provides entropy/enthalpy, and so on, as outputs. These values can be used for efficiency calculation and
optimal operation. reduction in efficiency can additionally indicate the health degradation of the thermodynamic
system or plant equipment. This block supports the following units of measuring system.
• SI in kJ/kg degree K
• Metric in kcal/kg degree C
• English in Btu/lb degree F
You can use any one of them while configuring the inputs as applicable. The detailed display of this block
includes graphical representation of steam tables. For more information about the graphical representation of the
STEAMPROP block, refer to the STEAMPROP block detail displays topic in the Control Building User's
Guide.
The STEAMPROP block can be used in the following platforms.
• C300 Controller
• ACE Controller
• SIM-C300
Attention
In this platform, the STEAMPROP block is useful for any process simulation and is best for optimizing the
process operation.
• SIM-ACE
The following figure is a graphical representation of the STEAMPROP block.
Figure 26: STEAMPROP block
Typical usage of STEAMPROP block

The following illustration depicts the typical usage of the STEAMPROP block in the industry for calculating
the mechanical efficiency of a Steam Turbine.
Figure 27: STEAMPROP block usage in the industry
The mechanical efficiency can be calculated using the following formula.
where,
Shaft Power = Measured Generator Output Power in KW
Inlet Steam Mass Flow Rate = Measured from the Inlet Steam Mass Flow Transmitter in field (in Tons/Hour)
Inlet Specific Enthalpy [Hin] = Output calculated by Steam Property Block-A configured for Superheated
Steam
Outlet Specific Enthalpy [Hexh] = Output calculated by Steam Property Block-B configured for Saturated
Steam
Note
Steam Quality can be measured using any steam quality measuring device (for example, Throttling Calorimeter) or
it can be entered manually.
30.1.1 Function
Steam Property function block computes the thermodynamic quantities of water and steam. The thermodynamic
quantities of water and steam can be one of the following:
• Enthalpy (H)
• Entropy (S)
• Pressure (P)
• Temperature (T)
• Specific volume (V)
This function block supports one of the following selections.

• Water
1021
• Steam
– Saturated
– Superheated
This function block uses the equations quoted in Industrial Formulation 1997 (IF-97) released by the
International Association for the Properties of Water and Steam (IAPWS). For more information about
Industrial Formulation 1997 (IF-97), refer to the http://www.iapws.org/.
It uses rigorous thermodynamic equations to compute the required output. For example, in case of water, if the
pressure and the temperature are the inputs to the block, then the following outputs can be computed.
• Enthalpy (H)
• Entropy (S)
• Specific volume (V)
30.1.2 Inputs/Outputs - STEAMPROP block
Inputs
The STEAMPROP block accepts the following inputs.
• Pressure (P)
• Temperature (T)
• Entropy (S)
• Steam quality/dryness fraction (X)
Note
For more information about the range of the inputs, refer to the respective parameters documented in the Control
Builder Parameter Reference.
Outputs
The output of the STEAMPROP block can be fetched through a wired connection or read directly by a program.
The STEAMPROP block output can be one of the following:
• Pressure (P)
• Temperature (T)
• Entropy (S)
• Enthalpy (H)
• Specific Volume (V)
Supported inputs/outputs configuration

The inputs/outputs of the STEAMPROP block varies based on the configuration of the STEAM_WATER and
STEAMTYPE parameters. The following table helps you to identify the supported inputs and outputs based on
the configuration of the STEAM_WATER and STEAMTYPE parameters.
Table 61: Supported STEAMPROP block inputs/outputs configuration
STEAM_WATER and STEAMTYPE configuration Supported inputs Supported outputs

STEAM_WATER = WATER • Pressure (P) • Specific Volume (V)
• Temperature (T) • Enthalpy (H)
• Entropy (S)
STEAM_WATER = "STEAM" and STEAMTYPE = "Saturated" • Temperature (T) • Pressure (P)
• Pressure (P) • Temperature (T)
• Pressure (P) • Enthalpy (H)

• Entropy (S) • Specific Volume (V)
• Temperature (T)
• Pressure (P) • Specific Volume (V)
• Steam Quality (X) • Enthalpy (H)
• Entropy (S)
• Temperature (T) • Specific Volume (V)
• Steam Quality (X) • Enthalpy (H)
• Entropy (S)
STEAM_WATER = "STEAM" and STEAMTYPE = "Superheated" • Pressure (P) • Specific Volume (V)
• Temperature (T) • Enthalpy (H)
• Entropy (S)
• Pressure (P) • Enthalpy (H)
• Entropy (S) • Specific Volume (V)
• Temperature (T)
30.1.3 Configuration parameters - STEAMPROP block

The following table provides a summary of the STEAMPROP specific parameters that you can configure
Engineer to enter or modify values for these parameters.
Note
The table does not include descriptions of the common parameters such as block name and description.
Table 62: Configurable parameters of STEAMPROP block

Steam Or Water STEAM_WATER Used for configuring the input (water or steam) for computing
thermodynamic quantities. By default, this parameter is
configured as "Steam."
Steam Type STEAMTYPE Used for configuring the steam type for computing
thermodynamic quantities. By default, this parameter is
configured as "Saturated" if the preceding parameter is
configured as "Steam."
Engineering Unit System ENGUNITSYSTEM Used for configuring the engineering unit system for water or
steam. By default, this parameter is configured as "SI."
Pressure (P) PRESSUREIO Used for configuring the pressure as input or output as
applicable. By default, this parameter is configured as "Not
Configured."
Temperature (T) TEMPERATUREIO Used for configuring the temperature as input or output as
applicable. By default, this parameter is configured as "Not
Configured."
Specific Volume (V) SPECIFICVOLUMEIO Used for configuring the specific volume as output. By default,
this parameter is configured as "Not Configured."
Enthalpy (H) ENTHALPYIO Used for configuring the enthalpy as output. By default, this
parameter is configured as "Not Configured."
Entropy (S) ENTROPYIO Used for configuring the entropy as input or output as applicable.
By default, this parameter is configured as "Not Configured."
1023

Steam Quality (X) STEAMQUALITYIO Used for configuring the steam quality as input. By default, this
parameter is configured as "Not Configured."
30.1.4 Configuration example - STEAMPROP block

You have to configure the STEAMPROP block based on the required thermodynamic quantity computation. For
example, if you want to compute the thermodynamic quantities of water then you must configure the
STEAM_WATER parameter as "Water."
Subsequently, you have to configure the input parameter as Pressure and Temperature and the output parameter
as Specific Volume (V), Enthalpy (H), and Entropy (S).
Suppose if you want to compute the thermodynamic quantities of steam then you must configure the
STEAM_WATER parameter as "Steam." Next, you must configure the STEAMTYPE parameter as "Saturated"
or "Superheated."
Attention
By default, STEAMTYPE parameter is set as "Saturated."
Finally, you have to configure the input/output parameters as mentioned in the “Inputs/Outputs - STEAMPROP
block” on page 1022.
Computing the thermodynamic quantities of water

The following is an example illustration for computing the thermodynamic quantities of water.
Figure 28: STEAMPROP block configured for measuring thermodynamic quantities of water
In this example, STEAMPROP block is configured as follows:

1. STEAM_WATER parameter is set as "Water."
2. Engineering Unit System (ENGUNITSYSTEM) parameter is set as "ENGLISH."
3. Pressure is set as "Input."
4. Temperature is set as "Input."
5. Enthalpy is set as "Output."
6. Specific Volume is set as "Output."
In addition, the STEAMPROP block is configured to accept the pressure and the temperature inputs using the
NUMERIC blocks.
Computing the thermodynamic quantities of steam (saturated)

The following is an example illustration for computing the thermodynamic quantities of steam (saturated).
Figure 29: STEAMPROP block configured for measuring thermodynamic quantities of steam (saturated)

1. STEAM_WATER parameter is set as "Steam."
2. Steam Type (STEAMTYPE) parameter is set as "Saturated."
3. Engineering Unit System (ENGUNITSYSTEM) parameter is set as "SI."
5. Entropy is set as "Input."
In addition, the STEAMPROP block is configured to accept the pressure and the entropy inputs using the
NUMERIC blocks.
Computing the thermodynamic quantities of steam (superheated)

The following is an example illustration for computing the thermodynamic quantities of steam (superheated).
Figure 30: STEAMPROP block configured for measuring thermodynamic quantities of steam (superheated)

1. STEAM_WATER parameter is set as "Steam."
2. Steam Type (STEAMTYPE) parameter is set as "Superheated."
3. Engineering Unit System (ENGUNITSYSTEM) parameter is set as "METRIC."
5. Entropy is set as "Input."
1025

In addition, the STEAMPROP block is configured to accept the pressure and the entropy inputs using the
NUMERIC blocks.
30.1.5 Typical configuration of STEAMPROP block

The following illustration depicts the typical configuration of the STEAMPROP block for calculating the
mechanical efficiency of a Steam Turbine.
Figure 31: Typical configuration of the STEAMPROP block
The following inputs of the Steam Turbine are provided to the AUXCALC to calculated the mechanical
efficiency.
• Superheated inlet steam flow
• Inlet steam temperature
• Exhaust steam pressure
• Exhaust steam quality
This typical configuration has been created using the typical usage explained in the “Steam Property Block
(STEAMPROP)” on page 1020.
In this example, two STEAMPROP blocks, six NUMERIC blocks, and one AUXCALC blocks are used to
calculate the mechanical efficiency of a Steam Turbine. The following table explains the configuration of each
block.
Block type Configuration

Sup_pressure (NUMERIC) Provides the pressure as an input to the Superheated
(STEAMPROP) block.
Sup_Temp (NUMERIC) Provides the temperature as an input to the Superheated
(STEAMPROP) block.
Sat_pressure (NUMERIC) Provides the pressure as an input to the Saturated
(STEAMPROP) block.
Steam_quality (NUMERIC) Provides the steam quality (dryness of the steam) as an input
to the Saturated (STEAMPROP) block.
Gen_Output_KW (NUMERIC) Provides the shaft power as an input to the AUXCALC
block.
In_steam_flow (NUMERIC) Provides the steam flow rate as an input to the AUXCALC
block.
Superheated (STEAMPROP) Accepts pressure and temperature as inputs and calculates
the Enthalpy (H).
Saturated (STEAMPROP) Accepts pressure and steam quality (dryness of steam) as
inputs and calculates the Enthalpy (H).
AUXCALCA (AUXCALC) Accepts the Enthalpy (H) from the STEAMPROP
(Superheated and Saturated) blocks, the shaft power in Kilo
Watts from the NUMERIC block (Gen_Output_KW), and
the inlet flow rate from the NUMERIC block
(In_steam_flow) and then calculates the efficiency.
For more information about the supported input/output configuration of the STEAMPROP block, refer to the
“Inputs/Outputs - STEAMPROP block” on page 1022.
30.1.6 Error handling - STEAMPROP block

The Control Module containing the STEAMPROP block cannot change the EXECSTATE status to ACTIVE, if
the following condition is satisfied:
• When the STEAM_WATER and STEAMTYPE parameters are configured appropriately, the input and
output parameters of the STEAMPROP block are either not configured or set as "Not Configured" in the
configuration form.
• The INPUTERROR parameter is set to “ON” when the input is out of range.
For detailed information about the supported input/output configuration of the STEAMPROP block, refer to the
“Inputs/Outputs - STEAMPROP block” on page 1022.
30.1.7 STEAMPROP block parameters

STEAMPROP block.
1027
31 I/O Reference blocks
Before the I/O Reference blocks were added to the Library, a tight coupling between the CM and the Input/
Output channels of the PM I/O channels, Series C I/O module existed. Hence, you had to validate the software
changes when the hardware was available. In addition, the CM had to be deleted from the Monitoring view if
there were any modifications made to the I/O channel.
I/O Reference blocks are available as basic function blocks and they provide a mechanism to the CM for
referencing the Input/Output channel of the supported I/O families or parameter values of any block. The
references can be made to the PM I/O channels, Series C I/O channels, or parameter values of any block. The
Reference blocks in strategies eliminate the dependency between the strategies and IOMs.
When the REF block references an I/O channel, it mirrors the I/O channel block behavior and provide access to
the values of the channel blocks. When the REF block references to a parameter, it works as parameter
connector and provides access to the parameter values of any block through the CM name. The Reference block
supports configuration and monitoring, and it is not loaded and executed with the CM.
Whenever a reference is made in the Reference blocks, you can navigate to the referenced value by clicking the
hyper-link available in the faceplate of the Reference block.
Benefits of the Reference blocks

The following are the benefits of the Reference blocks.
• The Reference block does not have to be re-configured or re-tested when the channel assignment is changed.
• The control strategies can be tested without building dummy I/O modules.
• Parameter connectors can be modified through Bulk Edit without having to open each chart and modify the
parameter connectors.
• A single typical can be created to reference a calculated value, a PM I/O channel block or a Series C I/O
channel block. Bulk build/edit tools can be used to specify the referenced type and reference of a strategy
created from the typical.
• A reference value of a referenced block may be modified without deleting the CM from the Monitoring
view.
• When CM is deleted from the Monitoring view, the output channels hold the last good value and do not go
to fail-safe state.
• HART may be enabled for an I/O channel by performing “Load While Active” for the channels. As a result
of this, the channel state is not affected. The operation is independent of the CM and has no impact to the
CM.
• Load of a strategy does not affect the state of a channel.
Types of Reference blocks

There are four types of Reference blocks listed under the IOREFERENCES library. The types of Reference
blocks are:
1. AIREF (Analog Input Reference) block
2. AOREF (Analog Output Reference) block
3. DIREF (Digital Input Reference) block
1029
31 I/O REFERENCE BLOCKS
4. DOREF (Digital Output Reference) block

The following table lists the various functions that can be performed through the configuration of the associated
I/O reference function block.
Block Used for .... Block description

“AIREF (AI Reference block)” on Referencing an AI channel block or an Acts as an interface between the analog
page 1036 analog parameter value. input channels or the pulse input channels
and the Control Module or between the
parameters and the Control Module.
“AOREF (AO Reference block)” on Referencing an AO channel block or Acts as an interface between the analog
page 1038 an analog parameter value. output channels and the Control Module or
between the parameters and the Control
Module.
“DIREF (DI Reference block)” on Referencing a DI channel block or a Acts as an interface block between the
page 1040 digital parameter value. digital input channels and the Control
Module or between the parameters and the
Control Module.
“DOREF (DO Reference block)” on Referencing a DO channel block or a Acts as an interface block between the
page 1042 digital parameter value. digital output channels and the Control
Module to generates status output (0 or 1),
pulsed output (ON or OFF) for specified
pulse time based on origin of input and
parameters. Acts as a parameter connector
between the parameters and the Control
Module.
Related topics
“Configuration of Reference block” on page 1031
“Behavior of Reference blocks when REFTYPE is configured as PARAMETER” on page 1034
“AIREF (AI Reference block)” on page 1036
“AOREF (AO Reference block)” on page 1038
“DIREF (DI Reference block)” on page 1040
“DOREF (DO Reference block)” on page 1042
“Copying Reference blocks” on page 1044
“Bulk Build of CM containing Reference blocks” on page 1045
“Navigating from Reference block faceplate to parameters or I/O channels” on page 1046
“UDT behavior of Reference blocks” on page 1047
“Limitations of Reference blocks” on page 1048
31.1 Configuration of Reference block

There are three parameters of the Reference blocks that must be configured for defining the references to the I/O
channels or parameter values of any block. The following table summarizes the 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 Engineer and above to enter or modify values for these parameters. The table does not include descriptions of
the common parameters such as block name and description.

Reference Type REFTYPE Used for configuring the type of interface. If the
REFTYPE is configured as SERIES_C_IO or PM I/O,
then the type of interface is between the CM and IOMs.
If the REFTYPE is configured as PARAMETER, then
type of interface is similar to a parameter connector. By
default, this parameter is set to SERIES_C_IO.
The reference type can be one of the following:
• NONE
• SERIES_C_IO
• PMIO
• PARAMETER
Reference REF Used for specifying the actual reference. Based on the
REFTYPE configuration, the reference can be a channel
or a parameter.
Channel Type CHANTYPE Used for providing a list of valid channel types that can
be referenced when REFTYPE is configured as
SERIES_C_IO or PMIO. This parameter is disabled
when the REFTYPE is set as PARAMETER or NONE.
The guidelines for configuring the Reference blocks are listed as follows:
• If the REFTYPE is set to SERIES_C_IO, then the Reference block references a Series C I/O channel.
• If the REFTYPE is set to PMIO, then the Reference block references a PM I/O channel.
• If the REFTYPE is set to PARAMETER, then the Reference block references a parameter and works as a
parameter connector.
• If the REFTYPE is NONE, then the Reference block is identical to any other basic block and does not have
any special configuration consideration.
When you set the REFTYPE as PARAMETER, you can use only PUSH parameters for the OP/SO parameter of
AOREF/DOREF blocks.
The REF parameter is used for selecting the parameter to be referenced in the Reference block. When the
Reference block is configured with a parameter, it behaves like a regular parameter connector.
The REF parameter displayed on the faceplate can only display the 24 characters of the REF value. Hence, if
the selected/referenced parameter value is more than 24 characters, then the REF value is truncated and right-
justified with an ellipsis on the left side.
Attention
The parameter originating from the Reference block cannot be used as value for the REF parameter of another
Reference block. An error message is displayed when the REF value is set as parameter originating from the
Reference block. For more information about the error message, see Control Builder Error Code Reference.
Mapping between PM I/O channel types and IOREFERENCES block types

The Reference block types map to the following PM I/O channel types and the UDTs derived from them.
1031
Table 63: Mapping between Reference blocks and PM I/O I/O channel types
Reference Blocks PM I/O I/O channel types

AIREF • PMIO:AICHANNEL
• PMIO:HAICHANNEL
AOREF • PMIO:AOCHANNEL
• PMIO:HAOCHANNEL
DIREF PMIO:DICHANNEL
DOREF PMIO:DOCHANNEL
Mapping between Series C I/O channel types and IOREFERENCES block types
The Reference block types map to the following Series C I/O channel types and the UDTs derived from them.
Table 64: Mapping between Reference blocks and Series C I/O channel types
Reference Blocks Series C I/O channel types

AIREF • SERIES_C_IO:AICHANNEL
• SERIES_C_IO:PICHANNEL
AOREF SERIES_C_IO:AOCHANNEL
DIREF SERIES_C_IO:DICHANNEL
DOREF SERIES_C_IO:DOCHANNEL
The behavior of the Reference block varies based on the configuration of the REFTYPE parameter. The various
behavior of the Reference blocks are explained in the following sections.
When the REFTYPE parameter is configured as “NONE”

When the REFTYPE parameter is configured as “NONE,” the following parameter behaviors apply.
• Channel Type (CHANTYPE) and Reference (REF) parameters are not available for any configuration.
• Icon on the block’s faceplate is blank as there is no parameter or a channel being referenced.
Attention
Reference blocks with REFTYPE configured as NONE cannot be loaded to the Monitoring view.
When the REFTYPE parameter is configured as “SERIES_C_IO” or “PMIO”

When the Reference Type (REFTYPE) parameter is set as SERIES_C_IO or PMIO, the REF parameter can
reference any channel block. In addition, you can select/type the CHANTYPE parameter using the point picker.
Note
The CHANTYPE parameter is set automatically when the REF parameter is selected.
The following figure is an example Main tab of the AIREF block where the REFTYPE is set as
“SERIES_C_IO.”
Figure 32: Main tab of the AIREF block
When the CHANTYPE parameter is set, the parameters of the channel type are exposed as parameters of the
Reference block. This provides access to channel parameters, using the Reference block name (for example,
CM.AIREF.BADPVFL). The parameters of the channel may be exposed as faceplate parameters or pins on the
Reference block; hence, they are displayed in the following tabs.
• Block Pins
• Configuration Parameters
• Monitoring Parameters
The following figure displays the Block Pins, Configuration Parameters, and Monitoring Parameters tabs
of the AIREF block where the project parameters from the reference AI channel is automatically added.
Figure 33: Parameters visible in the tabs when REFTYPE is “SERIES_C_IO” or “PMIO”
1033
31.2 Behavior of Reference blocks when REFTYPE is configured as

PARAMETER
When the REFTYPE parameter is configured as “PARAMETER,” the Reference block behaves as a parameter
connector and the parameter connector icon appears on the Reference block’s faceplate. The CHANTYPE
parameter is disabled when the parameter connection is configured in the REF parameter. General parameter
connector validation rules are applicable when REF parameter references a parameter value.
Attention
If you refer a parameter from a DSA server, then the parameter value is not displayed in the Reference block’s block
pin even though it reads the parameter value.
REF value cannot refer to user-projected parameters with Reference blocks as origin.
You can select the parameter to be referenced using one of the following formats using the point picker option.
• Point.Parameter
• Point.Block.Parameter
• @Substituteblockname.Parameter
• @Substitute Parameter
The following are the examples formats.
• CM.REGCTL.SP
• BIC_02.PIDA.PV
• AICHANNEL_01.PV
• @HT_LVL1.PV
• @HT_LVL1
If the input-type Reference blocks (AIREF and DIREF) are configured to reference the parameters, then there
are no restrictions in the configuration.
Guidelines for entering REF parameter value when REFTYPE is “PARAMETER” for output reference blocks
If the output-type Reference blocks (AOREF and DOREF) are configured to reference the parameters, then you
must adhere to the following guidelines.
• For the AO/DO Reference blocks, only push connections are allowed for OP/SO parameter.
• For the AO/DO Reference blocks, REF value can be modified only after deleting the existing connection.
The following figure displays the Block Pins, Configuration Parameters, and Monitoring Parameters tabs
of the AIREF block where the AIREF behaves as a parameter connector.
Attention
These tabs display the same parameters when REFTYPE is set as “None” or “PARAMETER”.
Figure 34: Parameters visible in the tabs when REFTYPE is “PARAMETER”
1035
31.3 AIREF (AI Reference block)

The AIREF (AI Reference) block allows you to
• associate a configured analog input channel or a pulse input channel in a Control Module, or
• reference a parameter value of any block.
You can expose all the input/output pins of the AI channel/PI channel block as inputs and as outputs,
respectively, in the AIREF block.
The graphical representation of AIREF block is follows:
31.3.1 Function-AIREF block

The PV parameter represents a value of its reference (REF). The AIREF block makes the PV available for
connections to other blocks. The origin of PV is listed in the following table based on the REFTYPE parameter
configuration.
Table 65: Origin of the Input/output value for input Reference blocks
If REFTYPE is configured as ... Then, the PV origin is...

PMIO or SERIES_C_IO PV value of the channel.
PARAMETER values that are accessible in the Control Builder. The values can be
• Point.Parameters, or
31.3.2 Configuration example-AIREF block

The following figure is an example of the AIREF block configuration when REFTYPE is set as “PMIO.”
Figure 35: Configuration of AIREF block
The following figure is an example of the AIREF block configuration when REFTYPE is set as
“PARAMETER.”
Figure 36: Configuration of AIREF block when REFTYPE is PARAMETER
1037
31.4 AOREF (AO Reference block)

The AOREF (AO Reference) block allows you to
• associate a configured analog output channel in a Control Module, or
You can expose all the input/output pins of the AO channel block as inputs and as outputs, respectively, in the
AOREF block.
The graphical representation of AOREF block is follows:
31.4.1 Function-AOREF
The OP parameter represents a value of its reference (REF). The AOREF block makes the OP available for
connections to other blocks. The AOREF block cannot accept the OP values from different controllers. The
origin of OP is listed in the following table based on the REFTYPE parameter configuration.
Table 66: Origin of the Input/output value for output Reference blocks
If REFTYPE is configured as ... Then, the OP origin is...

PMIO or SERIES_C_IO OP value of the channel.
31.4.2 Configuration example-AOREF block

The following figure is an example of the AOREF block configuration when REFTYPE is set as “PMIO.”
Figure 37: Configuration of AOREF block
The following figure is an example of the AOREF block configuration when REFTYPE is set as
“PARAMETER.”
Figure 38: Configuration of AOREF block when REFTYPE is PARAMETER
1039
31.5 DIREF (DI Reference block)

The DIREF (DI Reference) block allows you to
• associate a configured digital input channel in a Control Module, or
You can expose all the input/output pins of the DI channel block as inputs and as outputs, respectively, in the
DIREF block.
The graphical representation of DIREF block is as follows:
Attention
If a DI channel of a Universal Input/Output (UIO) module is configured for pulse counting, then you must use the
DIREF block for referencing the UIO-DI channel.
31.5.1 Function-DIREF
The PV parameter represents a value of its reference (REF). The DIREF block makes the PV available for
connections to other blocks. The origin of PV is listed in the following table based on the REFTYPE parameter
configuration.
Table 67: Origin of the Input/output value for input Reference blocks
If REFTYPE is configured as ... Then, the PV origin is...

PMIO or SERIES_C_IO PV value of the channel.
31.5.2 Configuration example-DIREF block

The following figure is an example of the DIREF block configuration when REFTYPE is set as
“SERIES_C_IO.”
Figure 39: Configuration of DIREF block When REFTYPE is SERIES_C_IO
The following figure is an example of the DIREF block configuration when REFTYPE is set as
“PARAMETER.”
Figure 40: Configuration of DIREF block When REFTYPE is PARAMETER
1041
31.6 DOREF (DO Reference block)

The DOREF (DO Reference) block allows you to
• associate a configured digital output channel in a Control Module, or
You can expose all the input/output pins of the DOREF block as inputs and as outputs, respectively, in the
DOREF block.
The graphical representation of DOREF block is follows:
31.6.1 Function-DOREF
The SO parameter represents a value of its reference (REF). The DOREF block makes the SO available for
connections to other blocks. The DOREF block cannot accept the SO values from different controllers. The
origin of SO is listed in the following table based on the REFTYPE parameter configuration.
Table 68: Origin of the Input/output value for output Reference blocks
If REFTYPE is configured as ... Then, the SO origin is...

PMIO or SERIES_C_IO SO value of the channel.
Attention
The SO values are accepted only from the PUSH blocks or PUSH connections.
31.6.2 Configuration example-DOREF block

The following figure is an example of the DOREF block configuration when REFTYPE is set as
“SERIES_C_IO.”
Figure 41: Configuration of DOREF block when REFTYPE is SERIES_C_IO
The following figure is an example of the DOREF block configuration when REFTYPE is set as
“PARAMETER.”
Figure 42: Configuration of DOREF block When REFTYPE is PARAMETER
1043
31.7 Copying Reference blocks

The Reference blocks can be copied similar to the other basic blocks within a CM. When a Reference block is
copied, the values of the REFTYPE and CHANTYPE parameters are retained in the block that is copied. After
that, you can resolve the value of the REF parameter.
While copying the Reference block, if the REF parameter is not set and the REFTYPE is not “NONE,” then you
must resolve/configure the empty REF with a valid reference when the block is pasted.
To copy a Reference block

1 Open any Control Module that contains the Reference blocks.
The Control Module chart view opens.
2 Right-click the Reference blocks and then click Copy.
The selected Reference block is copied.
3 Paste the copied Reference block in the same chart.
The Name New Function Blocks dialog box opens.
4 Accept the default name of the Reference block or type a new name in the Destination column.
5 Click Next.
The Resolve Indeterminate or Substitute Connections dialog box.
6 Click the point picker in the After column, and then select the value that appears for the Reference (REF)
parameter.
If the copied block’s Reference (REF) value is not set, the Reference (REF) parameter is not listed in the
list of items to be resolved.
If the Reference (REF) parameter value is already set in the copying Reference block, the After column is
not set as empty.
7 Click Finish.
The copied Reference block is created in the CM chart.
The result of copying the Reference blocks varies based on the After column status in the Resolve
Indeterminate or Substitute Connections dialog box.
31.8 Bulk Build of CM containing Reference blocks

When you bulk build a CM containing Reference blocks, you have to select only the following parameters.
• REFTYPE
• REF
• CHANTYPE
Before modifying the REF parameter in the Bulk Build spreadsheet, ensure that the corresponding channel is
not used in any CM and it is a non-spare channel.
1045
31.9 Navigating from Reference block faceplate to parameters or I/O

channels
When a Reference Block is configured with a valid reference (a channel or a parameter), you can quickly
navigate to the referred channel or the parameter using the hyper-link available in the faceplate. The Reference
(REF) parameter is used for navigating between the Reference blocks and the referenced channel or the
parameter.
When the REF parameter refers a “Parameter value”

When the REF parameter refers to a parameter, the navigation functionality is identical to the Parameter
Connectors when performing a CTRL+Left Mouse button click on the REF parameter in Control Builder chart
or the Station.
In the Project view, if you double-click the Reference block faceplate, then it always opens the Reference
block’s configuration form.
In the Project view, if you double-click the REF parameter, then the Request Value Change dialog box opens.
You can only specify or modify the value from the Project view.
When the REF parameter refers a “Channel”

In the Project view, if you double-click the Reference Block faceplate then it always opens the Reference
block’s configuration form. However, the channel configuration form opens in the Monitoring view when you
double-click the Reference block. This is because, once the channel is loaded, the Reference blocks mirror the
channel.
In the Project/Monitoring view, if you double-click the REF parameter, then the Request Value Change dialog
box opens. You can only specify or modify the value from the Project view. However, you cannot change the
REF value in the Monitoring view.
31.10 UDT behavior of Reference blocks

User defined templates (UDT) of Reference blocks are also created using the “Make Template” option. You can
create the UDT using the Reference blocks with the desired REFTYPE value and then configure the Reference
blocks in the CM.
Configuration of Reference blocks in a UDT for I/O channels

To configure the Reference blocks when the REFTYPE is set as “SERIES_C_IO” or “PMIO,” you must adhere
to the following guidelines.
• The value of Channel Type (CHANTYPE) and Reference (REF) parameters cannot be set in the UDT.
• The REFTYPE, CHANTYPE, and the REF parameters cannot be made as template defining in UDTs.
Configuration of Reference blocks in a UDT for parameter values

To configure the Reference blocks when the REFTYPE is set as “PARAMETER,” you must adhere to the
following guidelines.
• The value of REF parameter can be set only to a substitute name if the REFTYPE is set as “PARAMETER”
in a UDT. You can set the REF parameter in one of the following formats.
– @Substituteblockname.Parameter
– @Substitute Parameter
• The value of CHANTYPE parameters cannot be set in the UDT.
• The REFTYPE, CHANTYPE, and the REF parameters cannot be made as template defining in UDTs.
Propagation of REFTYPE, CHANTYPE, and REF parameters from parent UDTs

• The value of REFTYPE, CHANTYPE, and the REF parameters does not propagate to sub-templates and
instances even if the “Use Conditional Propagation From Templates” check box is selected in the “System
Preferences ”dialog.
• Newly created sub-templates and instances obtain the values of REFTYPE, CHANTYPE and REF
parameters as set in the parent UDT. Any modification made to these parameters in the parent UDT does not
propagate thereafter.
To set the values for these parameters in all instances and sub-templates of the parent UDT, use the “Bulk
Edit Parameters” work flow available in the “Bulk Configuration Tools.”
For more information about the “Bulk Edit Parameters” work flow, see Bulk Configuration Tools Help.
1047
31.11 Limitations of Reference blocks

Following are some of the limitations of the Reference blocks.
• Reference blocks are supported in ACE only when the REFTYPE is set as “PARAMETER.”
• Reference blocks are supported only for PM I/O and Series C I/O families. However, in Series C family,
Reference blocks are not supported for Speed Protection Module (SPM) and Servo Valve Positioner Module
(SVPM).
Reference blocks are not supported in C300-20ms Controller.
• Reference blocks are not supported in C200/C200E Controller.
32 Utility Functions
Related topics
“Utility Function Blocks” on page 1050
“ALMWINDOW (Alarm Window -Alarm Annunciator) Block” on page 1052
“ANNPANEL (Annunciator Panel) Block” on page 1058
“DIGACQ (Digital Acquisition) Block” on page 1062
“EXECTIMER Block” on page 1067
“FIRSTOUT (First Out Detection) Block” on page 1072
“FLAG Block” on page 1077
“FLAGARRAY Block” on page 1079
“MESSAGE Block” on page 1080
“NUMERIC Block” on page 1083
“NUMERICARRAY Block” on page 1084
“PUSH Block” on page 1085
“TEXTARRAY Block” on page 1087
“TEXTCOMMENT (Text Comment) Block” on page 1088
“TIMER Block” on page 1089
“TYPECONVERT Block” on page 1091
1049
32 UTILITY FUNCTIONS
32.1 Utility Function Blocks

Utility function blocks provide a variety of configurable functions for storing and alarming selected control
data.
associated Utility function block. Functional descriptions for each block are given in the following subsections.
Attention
The ALMWINDOW, ANNPANEL, DIGACQ, and FIRSTOUT block can only be used with C300, C200E, and ACE
Controllers.

Support alarm annunciator “ALMWINDOW (Alarm Used to define configurable alarm inputs and
indication Window -Alarm annunciator outputs.
Annunciator) Block” on
page 1052
Support alarm annunciator “ANNPANEL Used in conjunction with the ALMWINDOW block to
indication (Annunciator Panel) provide configurable annunciator panel operation.
Provide better use of computing and “DIGACQ (Digital Used to define PV source for associated DI channel
memory resources Acquisition) Block” on input with PV alarm capability.
page 1062
Measure execution time of CEE “EXECTIMER Block” on Used to measure the execution timing of CEE Blocks
blocks page 1067 by creating two instances.
Provides first out logic identification “FIRSTOUT (First Out Used to define configurable inputs to be scanned for
for digital input transition Detection) Block” on first out function with alarm capability.
page 1072
Store a single two-state value “FLAG Block” on Used to define two separate states (for example,
page 1077 Running/Stopped, Off/On) to indicate the status of a
particular input.
Store multiple two-state values “FLAGARRAY Block” on Used to define two separate states (Off/On) to indicate
page 1079 status of a particular input.
Provide client triggered messages “MESSAGE Block” on Used to define up to 16 information only or
page 1080 confirmation type messages that can be triggered by a
client of the block.
Store a floating point value “NUMERIC Block” on Used to store up to 8 bytes of a floating point value
page 1083 within defined upper and lower limits for use in a
control strategy.
Store multiple floating point values “NUMERICARRAY Used to store up to 200 floating point values for use in
Block” on page 1084 a control strategy.
Push the value of various data types. “PUSH Block” on Used to push the value of different data types to the
page 1085 output destination.
Store multiple text strings “TEXTARRAY Block” on Used to store up to 120 text strings for use in a control
page 1087 strategy.
Add comments into the strategies/ “TEXTCOMMENT (Text Used to add comments into the strategies/templates.
templates Comment) Block” on
page 1088
Time process events or create known “TIMER Block” on Used to keep track of elapsed time during a process
delays. page 1089 and provides indication when elapsed time reaches
predefined limit.

Provide data type conversions “TYPECONVERT Block” Used to convert one data type to another for connecting
on page 1091 parameters of different data types.
1051
32.2 ALMWINDOW (Alarm Window -Alarm Annunciator) Block

The Alarm Annunciator - Alarm Window function block (ALMWINDOW), available under the Utility function
block library, is used to implement the annunciation sequence for alarm groups connected to window
annunciators. The alarm annunciator is implemented as two blocks, one encapsulating the function of individual
alarm group, and one to control the lamp test, acknowledge, and reset functions.
The following is an illustration of an ALARM WINDOW FB:
With R410, the following parameters are introduced for configuring the on-delay time and off-delay time for the
Off-Normal alarms.
• OFFNRMALM.TM
• OFFNRMALM.TMO
Each Alarm Window block supports the following user configurable attributes. The following table lists the
with that tab.

• Number Of Inputs (NUMIN) - Lets you specify the number of digital inputs to
be used with the block. The default is 4.
• Alarm Sequence - Allows the user to select among the three alarm sequences
which are supported by the ALMWINDOW block. The three sequences are:
Ringback, AutoReset and ManualReset
• Off Normal Alarm Priority (OFFNRMALM.PR) - Indicates the relative priority
of the alarm.
• Off Normal Alarm Severity (OFFNRMALM.SV) - Indicates the relative severity
of the alarm (from 0 to 15).
• Deadband Time (OFFNRMALM.TM) -
You can configure individual deadband time for OFFNRMALM. However, if
you are migrating from pre-R410 to later releases, refer to “Impact of migration
on alarm attributes” on page 221.
• Off-delay Time (OFFNRMALM.TMO) - With R410, this parameter is
introduced to define the duration in seconds during which an RTN reporting is
suppressed even though the alarm condition has returned to normal. The RTN is
reported on the Station only after this time expires and the alarm condition has
returned to normal. The default time is 0; that is RTN is reported as soon as the
alarm condition returns to normal. However, if you are migrating from pre-R410
to later releases, the alarm off-delay time will be set as default value (0).
faceplate.
32.2.1 Function-ALMWINDOW block

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).
1053

The Alarm windows blocks take inputs from DI channels or DIGACQ or from the program
(ALMIN[1..16]inputs). The Alarm windows output FLSHSTAT is connected to FLSHSTAT[*] input of the
annunciator panel block.
32.2.2 Inputs-ALMWINDOW block

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.
32.2.3 Outputs-ALMWINDOW block

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.
32.2.4 Alarms-ALMWINDOW block
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
Lamp State Events

AckAlarm NewAlarm RtnAlarm RstAlarm
Lamp State Events

LampOff LampState = FastFlash No Action DoNothing No Action
FastFlash No Action LampState = LampState = No Action
LampSteady SlowFlash
LampSteady LampState = FastFlash No Action LampState = No Action
SlowFlash
SlowFlash LampState = FastFlash No Action LampState = if(All alarms have rtn)
LampSteady then {LampState =
LampOff} else
{LampState =
LampSteady}
Manual reset sequence

The following is an illustration of the Alarm window state machine Manual Reset:
Following is the state transition table of the Alarm window state machine Manual Reset:
LampState Events
NewAlarm AckAlarm RtnAlarm RstAlarm
LampOff LampState = FastFlash NoAction NoAction NoAction
FastFlash NoAction LampState = NoAction NoAction
LampSteady
LampSteady LampState = FastFlash NoAction NoAction If(All Alms RTN)
{LampState =
LampOff}
1055
Automatic Reset Sequence:

The following is an illustration of the Alarm window state machine Automatic Reset:
Following is the state transition table of the Alarm window state machine Automatic Reset:
LampState Events
NewAlarm AckAlarm RtnAlarm RstAlarm
LampOff LampState = FastFlash No Action No Action No Action
FastFlash No Action If(All Alarms RTN) No Action No Action
{LampState =
LampOff}
Else
{LampState =
LampSteady}
LampSteady LampState = FastFlash No Action LampState = LampOff No Action
32.2.5 Error handling-ALMWINDOW block

• 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, error “Invalid Value” is displayed.
• The parameter NUMIN cannot be changed from Monitoring side.
• Access level check is done at the time of loading the block as well during a parameter write.
• An error is generated if we try to write the block description after the alarm window is connected to alarm
panel.
32.2.6 ALMWINDOW parameters

Refer to the Control Builder Components Reference for a complete list of the parameters used with the Alarm
Annunciator-Alarm Window block.
1057
32.3 ANNPANEL (Annunciator Panel) Block

The Alarm Annunciator - Annunciator Panel function block (ANNPANEL), available under the Utility function
block library, is used to implement the annunciation sequence for alarm groups connected to window
annunciators. A single window can use over 40 individual function blocks per function group.
The alarm annunciator is implemented as two blocks, one encapsulating the function of individual alarm group,
and one to control the lamp test, acknowledge, and reset functions.
The following is an illustration of the Alarm Annunciator Panel FB:
Each Annunciator Panel block supports the following user configurable attributes. The following table lists the
with that tab.

• Number Of Inputs (NUMANNWIN) - Lets you specify the number of alarm
window blocks that can be connected to the block. The default is 16.
• Fast Flash Factor (FSTFLSHSPD) - This parameter allows to configure the
flashing rate of LAMPOUT parameter when the input FLSHSTAT parameter is
in the FASTFLASH state. It can be configured as twice the rate of Slow flash
speed (2xSlowFlash) or 4 times the rate of Slow Flash speed(4xSlowFlash)
• Slow Flash Speed ( SLWFLSHSPD in blinks per Min) - Allows to specify the
rate of flashing the LAMPOUT parameter when the input FLSHSTAT parameter
is in SLOWFLASH state.
• Alarm Window Text (ALMWINTXT) - This text specified in this parameter
appears on the detail display pages for the Alarm panel.
Lets you select the available
parameters that you want to expose
as input/output pins on the function
block graphic in Control Builder.
faceplate.
32.3.1 Function-ANNPANEL block

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.

The annunciator Panel block outputs LAMP OUT 1 to LAMP OUT 16 and the Outhorn1 and Outhorn 2 is
connected to digital output channels. The input LAMP TEST is from digital input channel blocks or DIGACQ
block.
32.3.2 Configuration Example-ANNPANEL block

Attention
Be sure 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.
1059
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.
32.3.3 Inputs-ANNPANEL block

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.
32.3.4 Outputs-ANNPANEL block

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.
32.3.5 Error Handling-ANNPANEL block

• 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.
32.3.6 ANNPANEL parameters

Refer to the Control Builder Components Reference for a complete list of the parameters used with the Alarm
Annunciator - Alarm Panel block.
1061
32.4 DIGACQ (Digital Acquisition) Block

The Digital Acquisition function block, available under “Utility” in the function block library, uses a
combination of a DICHANNEL and SEL/FLAG when PVSOURCE is defined by the operator. The Digital
Acquisition block receives input from DI Channel block and allows the user to define the PVSOURCE. This
block is independent of the Channel type feeding the block. The following is a graphical representation of the
Digital Acquisition function block.
Off-Normal and Bad PV alarms.
• OFFNRMALM.TM
• OFFNRMALM.TMO
• BADPVALM.TM
• BADPVALM.TMO
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 in the CM relative to other blocks contained in the CM. Enter a number
characters to identify the variable values associated with the block.
• Normal State - Defines the Normal State of the block, as selected by the user.
• Actual State - Indicates the current state of the block as in PV
selection is ONLYAUTO.
user program, MAN for an operator, or AUTO for process input connection.
Only applicable with PV Source Option selection of ALL. The default selection
is AUTO.
• Text for each state (STATETEXT) - Lets you select the text for each state.
• Display Configuration (DABLOCKSINCM) - Indicates the number of blocks
that will be displayed in system detail display.

Alarms • Off Normal Alarm Priority (OFFNRMALM.PR) - Indicates the relative priority
of the alarm.
• Off Normal Alarm Severity (OFFNRMALM.SV) - Indicates the relative severity
• Bad PV Alarm Priority (BADPVALM.PR) - Lets you set the desired priority
• Bad PV Alarm Severity (BADPVALM.SV) - Lets you assign a relative severity
• Deadband Time (xxxxALM.TM) -
reported as soon as the alarm condition occurs. You can configure individual
deadband time for OFFNRMALM. However, if you are migrating from pre-
R410 to later releases, refer to “Impact of migration on alarm attributes” on
page 221.
• Off-delay Time (xxxxALM.TMO) - With R410, this parameter is introduced to
define the duration in seconds during which an RTN reporting is suppressed
even though the alarm condition does not exist. The RTN is reported on the
Station only after this time expires and the alarm condition has returned to
faceplate.
32.4.1 Function-DIGACQ block

• 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).
1063
Predecessor block
• A predecessor block is not required if PVSOURCE is set to MAN.
• If PVSOURCE is set to AUTO, any block with a digital output can be a predecessor.
• If the PVSOURCE is set to AUTO, or if the PVSRCOPT is set to 0 (ONLY AUTO), then a DICHANNEL
block can be a predecessor.
32.4.2 Configuration Scenario-DIGACQ block

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:
32.4.3 Inputs-DIGACQ block

• IN - Input parameter
32.4.4 Outputs-DIGACQ block

• 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
Only Auto AUTO Value of PVAUTOFL
ALL AUTO Value of PVAUTOFL
ALL MAN Value of PVFL
ALL SUB Value of PVFL
• 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.
1065
32.4.5 Error handling-DIGACQ block

• 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.
32.4.6 DIGACQ parameters

Refer to the Control Builder Components Reference for a complete list of the parameters used with the Digital
Acquisition block.
32.5 EXECTIMER Block

The EXECTIMER function block, available in the Utility function block library, is used to measure execution
timing of other CEE blocks. EXECTIMER is used to measure the timing of individual basic blocks or groups of
basic blocks within a Control Module.
The EXECTIMER block supports the following user configurable attributes. The following table lists the given
that tab.

Main • Execution Order in CM (ORDERINCM): Specifies the execution order of the block in
the CM relative to other blocks contained in the CM. Enter a number between 0 and
65535. The default value is 10.
• Averaging Interval (TAU): TAU establishes the time interval over which rolling
averages are computed. Units are seconds.
• Enable Timing (ENABLE): In most cases where EXECTIMER is applied, parameter
ENABLE is not used. On rare occasions, an application engineer may find it convenient
to leave instances of EXECTIMER in place permanently as part of the configuration.
When this is done, ENABLE maybe set to On to minimize CPU consumed when
measurements are not actually being taken. When EXECTIMER configurations are
disabled, ENABLE must be set to Off at both the “begin time interval” instance and the
“end time interval” instance.
• Interrupt Reject Factor (REJFACTOR): When REJFACTOR is non-NaN, new values of
DTIME are rejected from the statistical computations unless the following criterion is
met.
DTIME <= REJFACTOR * DTIMEMIN
If the application engineer chooses to use REJFACTOR, the value of MAXMINRATIO
can be used to judge an appropriate value.
• Offset (DTAOFFSET): Subtractive offset applied to DTIMEAVG in computing
DTIMEAVGCOMP.
Value is computed as follows.
DTIMEAVGCOMP = (DTIMEAVG - DTAOFFSET) * DTASCALE / DTANORM.
• Normalization (DTANORM): Denominator applied to DTIMEAVG in computing
DTIMEAVGCOMP.
• Scale Factor (DTASCALE): Numerator applied to DTIMEAVG in computing
DTIMEAVGCOMP.
1067

• Free Running Time Input (TIMEIN): Time value at the “end time” EXECTIMER
instance read by connection from partner “begin time” EXECTIMER instance. Units
are undefined in the application view.
Assume that there are two EXECTIMER instances: one capturing the beginning of a
time interval (BEGTIME) and the other capturing the end of a time interval
(ENDTIME). In such a scenario, TIMEOUT is used by making a connection from
output BEGTIME.TIMEOUT to input ENDTIME.TIMEIN. TIMEOUT is a specialized
parameter which may only be used in this fashion. Other uses will lead to block
malfunction or unpredictable results. Connections between TIMEOUT and TIMEIN
may not cross CEE boundaries.
• Delta Time (DTIME): Always displays NaN on the EXECTIMER instance used to
establish the beginning of the time interval. Displays non-NaN on the EXECTIMER
instance used to establish the end of the time interval if the following holds true:
– TIMEIN parameter of block instance is connected.
– TIMEIN parameter of block instance is receiving a good value.
– Block instance is enabled.
– Block instance is executing.
DTIME captures the difference between the current time read by the end instance and the
time value received through the parameter TIMEIN.
• Free Running Time Output (TIMEOUT): Time value supplied from high precision,
internal, free running clock. Units are undefined in the application view.
Assume that there are two EXECTIMER instances: one capturing the beginning of a
time interval (BEGTIME) and the other capturing the end of a time interval
(ENDTIME). In such a scenario, TIMEOUT is used by making a connection from
output BEGTIME.TIMEOUT to input ENDTIME.TIMEIN. TIMEOUT is a specialized
parameter which may only be used in this fashion. Other uses will lead to block
malfunction or unpredictable results. Connections between TIMEOUT and TIMEIN
may not cross CEE boundaries.
• Minimum (DTIMEMIN): Minimum value of DTIME since RESET was last set to On.
• Average (DTIMEAVG): Rolling time average of instantaneous DTIME values.
The time interval of the rolling average is established by parameter TAU. The
averaging is reset by writing On to parameter RESET.
• Maximum (DTIMEMAX): Maximum value of DTIME since RESET was last set to
On.
• Max to Min Ratio (MAXMINRATIO): Ratio of the value of parameter DTIMEMAX to
the value of parameter DTIMEMIN.
In cases where an application engineer wants to set parameter REJFACTOR to a value
other than NaN, MAXMINRATIO can be used to judge what would be an appropriate
value. If MAXMINRATIO is large, it typically means the measurement is capturing
interrupt execution or higher priority task execution unrelated to the block or blocks
under test.
• Standard Deviation (DTIMESTD): DTIMESTD is the square root of the time variance
in the DTIME values. It presents a rolling estimate of the standard deviation of the
DTIME values in the same way that DTIMEAVG presents the rolling average of the
DTIME values. The time interval over which the estimate is constructed is established
by parameter TAU. The averaging is reinitialized whenever parameter RESET is set to
On.
• Standard Deviation%: (DTIMESTDPRC): The value of DTIMESTD as percent of
DTIMEAVG.
DTIMESTDPRC is computed as follows.
DTIMESTDPRC = 100.0 * DTIMESTD / DTIMEAVG

• Compensated Average (DTIMEAVGCOMP): Value of DTIMEAVG after application of
negative offset and scale factors.
DTIMEAVGCOMP and its associated configuration parameters can optionally be used
for tasks such as the following:
– Subtract out the small timing overhead not associated with the block or module
under measurement.
– Attempt to compensate for other factors by scaling up or down a measurement.
Identification Lets you view information pertinent to the qualification and version control system and
enter block comments, if desired.
32.5.1 Function-EXECTIMER block

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
• C300-20ms
• C200E
• SIMC200E
• ACE
• SIMACE
Attention
EXECTIMER is not supported on the C200 platform.
32.5.2 Input-EXECTIMER block

The input parameter is ENDTIME.TIMEIN. There is no input for the BEGTIME instance that serves to mark
the beginning of a time interval.
1069
32.5.3 Output-EXECTIMER block

The output parameter is BEGTIME.TIMEOUT. There is no output for the ENDTIME instance that serves to
mark the end of a time interval.
32.5.4 EXECTIMER Parameters

EXECTIMER function block.
32.5.5 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.
32.5.6 Limitations-EXECTIMER block

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 C200/C200E or 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. This means that 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 gateway or 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.
1071
32.6 FIRSTOUT (First Out Detection) Block

The First Out function block, available under the Utility library, enables the identification of the digital input
signal that was first to transition from its NORMAL state among a set of digital inputs connected to an
equipment or device. Usually, this block is associated with critical equipment. An equipment's or a drive's
protection interlocks and stop commands are connected as input to the First Out block. When an input signal
transitions from its configured NORMAL state, the output flag of the First Out logic is raised. In addition, the
input responsible for the First Out flag is recorded. All the logic processing happens at runtime processing of the
new block. The recording is locked until a reset is applied to the block. The following is an illustration of the
First Out Detection function block:
The First Out Detection block supports the following user configurable attributes. The following table lists the
with that tab.

• Number Of Inputs (NUMDINPUTS) - Lets you specify the number of digital
inputs to be used with the block. The default is 8.
Alarm • First Out Alarm Priority (FIRSTOUTALM.PR) - Indicates the relative priority of
the alarm. The default selection is LOW.
• First Out Alarm Severity (FIRSTOUTALM.SV) - Indicates the relative severity
Transition Monitoring Lets you configure the transition monitoring status of the block.

faceplate.
32.6.1 Function-FIRSTOUT block

• 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 do this, the
following I/O pin connections are required:
• IN[1] - IN[8] Inputs
• RESET Input
• FIRSTOUTACTED Output
Therefore, these parameters are exposed via block pins in the default state. The following parameters are
exposed in the FB panel in monitoring view.
• NUMDINPUTS
• INPUTACTED[1] - INPUTACTED[8]
• FIRSTOUTINPUT
NUMDINPUTS
FIRSTOUT FB uses NUMDINPUTS parameter which obtains the value from the Main configuration form. The
range of NUMDINPUTS is 1-24. If user configured NUMDINPUTS data in the Main configuration form is
invalid, an error message is displayed during configuration and download.
1073
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.
You can view the configured normal state of input at the faceplate of the function block without opening the
configuration page. The hollow diamond symbol indicates that the input pin on the faceplate is configured with
the normal input state as “True.”
In the Monitoring view, the hollow symbol is indicated in the color configured under the Pins and Wires tab of
the System preferences.
Attention
To view the hollow diamond symbol for inputs, which are configured with normal input state as “True,” you must
ensure to select the Show Normal Input State with Hollow Diamond checkbox in the System preferences dialog
box.
The following figure illustrates the hollow diamond symbol for the inputs with normal input state configured as
“True.”
Predecessor and Successor Blocks

The First Out block is used for two state devices in a main Drive CM. The First Out block can be connected to
DEVCTL (two/three states) or any other set of DIs. The output can be used for debugging or can be sent to the
annunciation panel. Its inputs are a set of digital inputs (equipment's or a drives protection interlocks and stop
command) connected to the equipment or device.
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 will continue to monitor upto 64,534 cycles and capture the list of inputs that became
ABNORMAL in each cycle.
Scenario 1 - One Input Transition

If input 5 transitions from NORMAL state, the First Out logic detects input 5 and sets INPUTACTED[5] as ON
and FIRSTOUTINPUT to “Input 5”.
Scenario 2 - Multiple Input Transitioned

In a scenario where more than one input transitions in a single cycle, say 2 and 8, from the NORMAL state, the
FIRSTOUTACTED flag is set. This leads to INPUTACTED [2] and INPUTACTED [8] to turn ON. The
FIRSTOUTINPUT takes the value of “Multiple”.
1075
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.
Parameter Name Reset Value

INPUTACTED[*] OFF
FIRSTOUTINPUT None
FIRSTUPACTED OFF
32.6.2 Inputs-FIRSTOUT block

• IN [1..24] - Boolean inputs whose transitions are monitored.
• RESET - Reset the First Out recordings.
The block supports 24 inputs, of which eight inputs are exposed by default. The remaining inputs (9…24) can
be exposed during configuration using the configurable parameter NUMDINPUTS.
The NORMAL[1..24] parameter indicates the NORMAL state (ON\OFF) of the connected inputs. If First Out
logic is active, and if any of the inputs transition from the configured state to another state, the First Out logic
detects and records this transition and raises the corresponding INPUTACTED[*] flag and FIRSTUPACTED
flag. The recorded detail is RESET upon a raising edge trigger at RESET pin.
The FIRSTOUTINPUT captures the index of the first input pin that transitioned, causing the First Out action. In
the case of multiple inputs transitioning, FISTOUTINPUT reports as “multiple.”
32.6.3 Outputs-FIRSTOUT block

• 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.
32.6.4 Error handling-FIRSTOUT block

• 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.
32.6.5 First out detection FB parameters

Refer to the Control Builder Components Reference for a complete list of the parameters used with the First Out
Detection block.
32.7 FLAG Block

The FLAG function block provides storage for a single 2-state value. The value can be accessed as a simple
Boolean (Off or On) using the PVFL parameter, or as one of two user-configured State values (for example,
Running and Stopped) through the PV parameter. It looks like this graphically.
With R410, the following parameters are introduced for configuring the on-delay time and off-delay time for the
Off-Normal alarms.
• OFFNRMALM.TM
• OFFNRMALM.TMO
32.7.1 Function-FLAG block

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).
– an Off-Normal Alarm whereby one of the flag's states is configured as the normal state; whenever the
flag changes state, the Off-Normal Alarm is generated.
– an off-normal alert whereby one of the flag's states is configured as the normal state; whenever the flag
modifies state, the off-normal alert is generated.
– an Off-Normal On-Delay Time - With R410, this parameter is introduced to define the duration in
seconds during which a process alarm reporting is suppressed. This helps in preventing the nuisance
alarms from being reported repeatedly during the process upset and improves the efficiency of the
operator. Once you configure this value for an alarm, the alarm is reported on the Station only if the
alarm condition continues to exist even after this value expires. The default time is 0; that is the alarm is
reported as soon as the alarm condition occurs. You can configure individual deadband time for
OFFNRMALM. However, if you are migrating from pre-R410 to later releases, refer to “Impact of
migration on alarm attributes” on page 221.
– an Off-Normal On-Delay Time - With R410, this parameter is introduced to define the duration in
seconds during which an RTN reporting is suppressed even though the alarm condition does not exist.
The RTN is reported on the Station only after this time expires and the alarm condition has returned to
normal. The default time is 0; that is RTN is reported as soon as the alarm condition returns to normal.
However, if you are migrating from pre-R410 to later releases, the alarm off-delay time will be set as
default value (0).
1077
Support for Alerts

With R410, the FLAG block is enhanced such that you can configure the FLAG blocks for generation of alerts.
An alert is an off-normal condition of the FLAG block and does not have a priority or a severity.
To accomplish this, a new parameter Alert Enable Option (ALTENBOPT) is introduced in the FLAG block.
The ALTENBOPT parameter can be used to enable the block to generate an off-normal alarm or an off-normal
alert whenever the flag's state differs from the configured normal state. An alert is generated whenever the flag's
state differs from the configured normal state and the ALTENBOPT parameter is enabled.
Attention
• A FLAG block cannot be configured to generate an alarm and an alert simultaneously. The selection between an
alarm and an alert is based on the ALTENBOPT parameter.
• When an alert is generated, the FLAG block's borders appear in red in the Monitoring view.
• In a CM, alarms are prioritized over alerts. However, the alerts and the alarms can be acknowledged
simultaneously from the station.
For more information about configuring alerts, refer to the Server and Client Configuration Guide. For more
information about acknowledging alerts, refer to the Operator's Guide.
32.7.2 Input/Output-FLAG block

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.
32.7.3 FLAG parameters

Refer to the Control Builder Components Reference for a complete list of the parameters used with the FLAG
function block.
32.8 FLAGARRAY Block

The FLAGARRAY function block provides storage for up to 1000 2-state values. The value can be accessed as
a simple Boolean (Off or On) using the PVFL[n] parameter. Where “n” is the number of the flag. It looks like
this graphically:
32.8.1 Function-FLAGARRAY block

• 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).
32.8.2 Input/Output-FLAGARRAY block

The block has up to 1000 output flags(PVFL[n]). But, all block pin parameters are available to be exposed and
32.8.3 FLAGARRAY parameters

FLAGARRAY function block.
1079
32.9 MESSAGE Block

The MESSAGE block provides up to 16 user configurable messages (MESSAGE[n]) that can be triggered by a
client of the block. Where “n” is the number of the message. A client can be the output from a Step block in a
Sequential Control Chart module (SCM).
You can also configure each message type (MSGTYPE[n]) to be either:
• Information,
• Confirmable,
• Single Signature, or
• Double Signature.
Attention
You must have the Electronic Signature system license to use the Single Signature and Double Signature message
types.
32.9.1 Function-MESSAGE block

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.
For single signature type (SINGLESIGNATURE) messages, the client trigger pulses the corresponding
SENDFL[n] to send the MESSAGE[n] to the Server. Once a user acknowledges the message twice to confirm it
through the Message Summary display in Station, a Single Signature user interface appears for the user to
record an electronic signature. The MEANINGPRI[n] parameter provides an indication for the meaning of the
primary signature. Once the message is acknowledged and signature is obtained, the Message Summary Display
sends a confirmation to the MESSAGE block that turns on the CONFIRMED[n] parameter to show that the
message has been confirmed.
For double signature type (DOUBLESIGNATURE) messages, the client trigger pulses the corresponding
SENDFL[n] to send the MESSAGE[n] to the Server. Once a user acknowledges the message twice to confirm it
through the Message Summary Display in Station, a Single Signature and Double Signature user interface
appear for the user to record the required electronic signatures. The MEANINGPRI[n] and MEANINGSEC[n]
parameters provide indications for the meaning of the primary and secondary signatures, respectively. Once the
message is acknowledged and signatures are obtained, the Message Summary Display sends a confirmation to
the MESSAGE block that turns on the CONFIRMED[n] parameter to show that the message has been
confirmed. In addition, the MINLVLSECSIG[n] parameter lets users define the minimum security level
required for a secondary signature.
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. This means that 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.
Confirming a message
The confirming a message action varies based on whether you have Integrated Keyboard (IKB) in your system
or not.
If you have an IKB in your system, perform one of the following steps from the Message Summary display in
Station to confirm a message.
• Select the message and press MSG CONFM on the IKB.
• Select the message and click Confirm Message on the menu bar.
• Right-click the message and select Confirm.
If you do not have an IKB in your system, perform one of the following steps from the Message Summary
display in Station to confirm a message.
• Acknowledge the message twice.
• Select the message and click Confirm Message on the menu bar.
• Right-click the message and select Confirm.
In both scenarios, these actions set the CONFIRMED[n] parameter is set to ON (true). However, an operator
must still acknowledge the message from the Message Summary display if the CONFIRM[n] parameter is set
from the Monitoring view or from a logic connection in the control strategy.
32.9.2 Configuration and Operation Considerations-MESSAGE block

Some general considerations for configuring and operating MESSAGE blocks are listed here for reference.
• Each message has a maximum length of 132 characters.
• A new message cannot be sent when the message is awaiting/blocked on a confirmation (CONFIRMED[n]
parameter).
• You cannot configure the message type (MSGTYPE[n]) or minimum level secondary signature
(MINLVLSECSIG[n] when the message is awaiting/blocked on a confirmation (CONFIRMED[n]
parameter).
• You cannot configure a message (MESSAGE[n], meaning primary signature (MEANINGPRI[n] or
meaning secondary signature (MEANINGSEC[n] through the Monitoring tab. You must configure messages
through the Project tab and then load them to the Controller.
• When you acknowledge an Information message, it is removed from the Message Summary display.
Confirmation type messages are confirmed by a second acknowledgement and then removed from the
display.
32.9.3 Input/Output-MESSAGE block

The block has up to 16 inputs (SENDFL[0..15]) and 16 outputs (CONFIRMED[0..15]), depending on the
message types configured.
1081
32.9.4 MESSAGE parameters

MESSAGE function block.
32.10 NUMERIC Block

The NUMERIC block provides storage for a floating-point value which is accessible through the PV
configuration parameter. It looks like this graphically.
32.10.1 Function-NUMERIC block

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).
32.10.2 Input/Output-NUMERIC block

The block has one output (PV). But, all block pin parameters are available to be exposed and connected to using
Control Builder graphical connections.
32.10.3 NUMERIC parameters

NUMERIC function block.
1083
32.11 NUMERICARRAY Block

The NUMERICARRAY block provides storage for up to 200 floating point values which are accessible through
this graphically:
32.11.1 Function-NUMERICARRAY block

The NUMERICARRAY block outputs (PV[n]) can be used as source parameters to provide predefined analog
Number).
• 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.
32.11.2 Input/Output-NUMERICARRAY block

The block has up to 200 outputs (PV[n]), depending on the number of numeric values (NNUMERIC)
32.11.3 NUMERICARRAY parameters

NUMERICARRAY function block.
32.12 PUSH Block
The PUSH function block is used to push the value of different data types to the output destination.
32.12.1 Function-PUSH block

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.
32.12.2 Execution Status-PUSH block

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 i.e. when fetching of inputs as well as the conversion was done without any error or
clamping.
• CLAMPWARNING - Function completed, but with some limitation (e.g. 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
Following are the conditions for Clampwarning:
• When the value exceeds the defined maximum limit for parameters.
• When the value exceeds the maximum limit for the enumeration output values.
32.12.3 Store Status-PUSH block

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 i.e. 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
1085
• 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.
32.12.4 PUSH parameters

Refer to the Control Builder Components Reference for a complete list of the parameters used with the PUSH
function block.
32.13 TEXTARRAY Block

The TEXTARRAY block provides storage for up to 120 text strings which are accessible through the
32.13.1 Function-TEXTARRAY block

The TEXTARRAY block outputs (STR[n]) can be used to provide predefined text strings to other function
blocks.
• 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).
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]
120 8 [1. .120]
32.13.2 Input/Output-TEXTARRAY block

The block has up 120 output strings (STR[n]), depending on the number of string values (NSTRING)
32.13.3 TEXTARRAY parameters

TEXTARRAY function block.
1087
32.14 TEXTCOMMENT (Text Comment) Block

The Text Comment block is introduced with R410. It is available in the Utility function block library and can be
used only to add comments into strategies/templates. This block does not contain any logic and hence does not
participate in control execution. In addition, the Text Comment block does not contain any pin connections.
32.14.1 Benefits of using Text Comment block

Prior to R410, to add comments into strategies, OLE objects had to be embedded in the strategies. This
procedure had the following disadvantages:
• The time consumed to configure strategies with comments was high. For example, if you had to Bulk Build
around 2000 strategies with comments, you had to open each strategy individually and edit comments.
• More number of clicks (approximately 8) was required to insert a comment into a strategy.
With the introduction of the Text Comment block, adding comments is easy and it is less time consuming. The
following are the advantages of using the Text Comment block.
• The comments introduced using Text Comment block appears in the Bulk Build output file. Therefore, you
can edit the comments in the Bulk Build output file without opening the strategies individually. This in turn
reduces the time consumed in configuring strategies with comments.
• The number of clicks required to insert a comment into a strategy is considerably reduced (approximately
from 8 to 4). This in turn reduces the time consumed to configure strategies with comments.
Features of Text Comment block
The following list summarizes the features of the Text Comment block.
• Can be used in the container modules such as CM, SCM, RCM, and UCM. This block can also be used in
CMs assigned to FF links.
• Loaded only to the ERDB and not the controller database as it does not contain any logic and does not
participate in any control execution.
• No restriction on the number of Text Comment blocks that can be introduced in a strategy.
• Maximum number of characters in the comments is limited to 1000.
• Special characters (!, @, #, $, %, ^, &, *, _, +, >, <, /, \, ], [, {, }, ~, `) are not allowed in the comments.
• After a strategy is loaded, a Text Comment block can be introduced into the strategy or existing comments
can be modified. In addition, the block can be loaded while active without inactivating the strategy or setting
CEE to IDLE. For more information on active loading, refer to the About Editing/Loading parameters while
active section in the Control Building User's Guide.
• Comments can be bulk built. Also, Text Comment block parameters can be bulk edited.
• Can be imported/exported like any other function block.
• User templates can be created using the Text Comment block.
• The comments font, color, size, and style can be modified.
• Since this block does not have logic, the block parameters do not appear in the Point Picker dialog box.
32.14.2 TEXTCOMMENT parameters

TEXTCOMMENT function block.
32.15 TIMER Block

The TIMER block provides the capability to time process events or create known delays. It looks like this
graphically.
32.15.1 Function-TIMER block

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).
32.15.2 Input/Output-TIMER block

The block has one status output (SO). But, all parameters are available to be exposed and connected to using
Control Builder graphical connections.
32.15.3 Commands-TIMER block

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 will happen 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
1089
given (through COMMAND), the Stop command is executed and all lower priority command flags are
automatically turned OFF
32.15.4 TIMER parameters

Refer to the Control Builder Components Reference for a complete list of the parameters used with the TIMER
function block.
32.16 TYPECONVERT Block

The TYPECONVERT block provides the ability to convert one data type to another for connecting parameters
of different data types. It supports data type conversions for all combinations among the following major data
types.
• Boolean
• Integer (unsigned/signed 8/16/32-bit integers)
• Real (32-bit and 64-bit IEEE floating point numbers)
• Enumeration
32.16.1 Function-TYPECONVERT block

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.
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 will fail, 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 will fetch the
GPV Enumeration when it runs, and will convert 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 will be 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.
• 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.
1091
• 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]).
32.16.2 Execution status-TYPECONVERT block

The block's execution status (EXECSTS) parameter monitors how successful the block is in fetching the input
and can have the following values.
• OK - The fetching of inputs as well as the conversion was completed without any error or clamping.
• CLAMPWARNING - The function completed, but with some limitation. 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 due to larger input provided than the output chosen for conversion, EXECSTS will
be CLAMPWARNING.
The ClampWarning is issued only when the input needs to be clamped to match the output type configured
for conversion. For example, if the input is configured as UINT16 and is configured to convert into UINT8
(output), then the value will be clamped to UINT8 ranges.
• BadInput - The input connection exists but the data fetched is NaN (bad value). This is applicable only for
float input types.
• InBlkMissing - The block has detected an input connection that does not exist.
Attention
The TYPECONVERT block does not use BADINPUT EXECSTS when the block is in Inactive or in IDLE state.
32.16.3 Input/Output-TYPECONVERT block

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.
32.16.4 TYPECONVERT parameters

TYPECONVERT function block.
33 Sequential Control
Related topics
“SCM (Sequential Control Module) Block” on page 1094
1093
33 SEQUENTIAL CONTROL
33.1 SCM (Sequential Control Module) Block

Refer to the Sequential Control User's Guide for all information pertaining to the Sequential Control function in
an Experion system.
34 Notices
Trademarks
Experion®, PlantScape®, SafeBrowse®, TotalPlant®, and TDC 3000® are registered trademarks of Honeywell
International, Inc.
OneWireless™ is a trademark of Honeywell International, Inc.
Other trademarks
Microsoft and SQL Server are either registered trademarks or trademarks of Microsoft Corporation in the
United States and/or other countries.
Trademarks that appear in this document are used only to the benefit of the trademark owner, with no intention
of trademark infringement.
Third-party licenses
This product may contain or be derived from materials, including software, of third parties. The third party
materials may be subject to licenses, notices, restrictions and obligations imposed by the licensor. The licenses,
notices, restrictions and obligations, if any, may be found in the materials accompanying the product, in the
documents or files accompanying such third party materials, in a file named third_party_licenses on the media
containing the product, or at http://www.honeywell.com/ps/thirdpartylicenses.
Documentation feedback
You can find the most up-to-date documents on the Honeywell Process Solutions support website at:
http://www.honeywellprocess.com/support
If you have comments about Honeywell Process Solutions documentation, send your feedback to:
[email protected]
Use this email address to provide feedback, or to report errors and omissions in the documentation. For
immediate help with a technical problem, contact your local Honeywell Process Solutions Customer Contact
Center (CCC) or Honeywell Technical Assistance Center (TAC).
How to report a security vulnerability

For the purpose of submission, a security vulnerability is defined as a software defect or weakness that can be
exploited to reduce the operational or security capabilities of the software.
Honeywell investigates all reports of security vulnerabilities affecting Honeywell products and services.
To report a potential security vulnerability against any Honeywell product, please follow the instructions at:
https://honeywell.com/pages/vulnerabilityreporting.aspx
Submit the requested information to Honeywell using one of the following methods:
• Send an email to [email protected].
or
1095
34 NOTICES
• Contact your local Honeywell Process Solutions Customer Contact Center (CCC) or Honeywell Technical
Assistance Center (TAC) listed in the “Support” section of this document.
Support
For support, contact your local Honeywell Process Solutions Customer Contact Center (CCC). To find your
local CCC visit the website, https://www.honeywellprocess.com/en-US/contact-us/customer-support-contacts/
Pages/default.aspx.
Training classes
Honeywell holds technical training classes about Experion PKS. These classes are taught by experts in the field
of process control systems. For more information about these classes, contact your Honeywell representative, or
see http://www.automationcollege.com.

Control Builder Components Theory: Experion PKS

Uploaded by

Copyright:

Available Formats

Control Builder Components Theory: Experion PKS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Control Builder Components Theory: Experion PKS

Uploaded by

Copyright:

Available Formats

Experion PKS

Control Builder Components Theory

1 About This Document .......................................................................................................................... 27

2.5.3 Load error messages .......................................................................................................................... 63

7.4.8 Cascades through UCNIF: UCNOUT/EUCNOUT ......................................................................... 152

17.2.1 Smart Transmitter support ............................................................................................................. 237

19.2.1 Safety Interlock processing ............................................................................................................ 278

19.6.1 Function-FANOUT block .............................................................................................................. 337

19.8.10 Output ranges and limits-PID Block ............................................................................................ 389

19.10.13 PID equations for PIDER block ................................................................................................ 453

19.13.8 Set Point Ramping-POSPROP block ........................................................................................... 508

19.17.11 Timeout monitoring-RATIOBIAS block ................................................................................... 552

19.20.1 Function-REEOUT block ............................................................................................................ 605

19.23.13 Input switching-SWITCH block ................................................................................................ 659

23 Auxiliary Function Blocks ............................................................................................................... 705

23.6.11 ENHAUXCALC parameters ....................................................................................................... 736

23.12.8 Selection Methods-SIGNALSEL block ...................................................................................... 773

25.2.2 Configuration example-PITOTALIZER block .............................................................................. 807

27 Logic Functions ................................................................................................................................ 843

29.3.1 Function-HTMOTOR block .......................................................................................................... 921

29.5.18 Initialization Manual condition-LTMOTOR block ..................................................................... 964

29.8.5 Limit Switches-VALVEDAMPER block .................................................................................... 1009

31.11 Limitations of Reference blocks ............................................................................................................... 1048

32.11 NUMERICARRAY Block ........................................................................................................................ 1084

2.1 Control Builder Underlying Concepts

2.1.1 In the beginning or the Single-Loop Controller Reference

Figure 1: Generic single-loop controller functions.

A brief description of each of these functions is given in the following table.

2.1.2 Experion architecture - partitioned functionality

Figure 2: Simplified overview of Experion architecture.

2.1.3 Blocks for building process control operations

Block Type Description Name of example block in Control

Figure 3: Typical linking of Function Blocks through Control Builder.

2.1.4 Naming convention- independent versus dependent

2.1.5 Full or expanded tag name

2.1.6 Parameter names

2.1.7 Naming restrictions and conventions

2.1.8 Parameter data types

2.1.9 Data flow -- active versus passive

2.1.10 Active and passive connectors

2.1.11 Cascade loop connections

Figure 6: Sample PID cascade loop configuration

2.1.12 Data pull or push

2.2 Control Capacity and Performance

2.2.1 Control network capacity

Topic Network Media and Limits

Topic Network Media and Limits

2.2.2 C200/C200E configuration options

Module Slot Width 2 slots

2.2.3 C200/C200E Redundancy

2.2.4 C200/C200E communication performance

Overall Data Access Performance 5 ms CEE 50 ms CEE

Overall Data Access Performance 5 ms CEE 50 ms CEE

Overall Data Access Performance 5 ms CEE 50 ms CEE

2.2.5 C200E Whole Array Transfer Performance

Overall Controller Whole Array Transfer Performance 50 ms CEE

2.2.6 C200/C200E processing resources

Minimum Reserved CPU to be Maintained During 20%

2.2.7 C200/C200E Memory Resources and Block Configuration