Control Builder Components Theory EPDOC XX16 en 501C

EXPERION PKS
RELEASE 501
Control Builder Components Theory

EPDOC-XX16-en-501C
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-
Contents 3
Chapter 1 - About This Document 38
1.1 Revision History 38
Chapter 2 - Control Builder Components 39
2.1 Control Builder Underlying Concepts 39
2.1.1 In the beginning or the Single-Loop Controller Reference 40
2.1.2 Experion architecture - partitioned functionality 41
2.1.3 Blocks for building process control operations 42
2.1.4 Naming convention- independent versus dependent 43
2.1.5 Full or expanded tag name 44
2.1.6 Parameter names 45
2.1.7 Naming restrictions and conventions 46
2.1.8 Parameter data types 47

2.1.9 Data flow -- active versus passive 47
2.1.10 Active and passive connectors 47
2.1.11 Cascade loop connections 48
2.1.12 Data pull or push 49
2.2 Control Capacity and Performance 49

2.2.1 Control network capacity 49
2.2.2 C200/C200E configuration options 51

2.2.3 C200/C200E Redundancy 52
2.2.4 C200/C200E communication performance 53
2.2.5 C200E Whole Array Transfer Performance 55
2.2.6 C200/C200E processing resources 56
2.2.7 C200/C200E Memory Resources and Block Configuration 56
2.2.8 C300 configuration options 57
2.2.9 C300 Redundancy 58
2.2.10 C300 communication performance 59
2.2.11 C300 processing resources 61
2.2.12 C300 Memory Resources 61
2.2.13 ACE configuration options 62
2.2.14 ACE communication performance 62
2.2.15 ACE processing resources 64
2.2.16 ACE Memory Resources 64
2.3 I/O Capacity and Performance 65

2.3.1 C200/C200E IO capacity 65
2.3.2 C300 IO capacity 67
-3-
2.3.3 IO Unit load factors 68
2.4 Function Block Execution Schedules 70

2.4.1 Schedule consideration differences 70
2.4.2 Control Module and Sequential Control Module FBs schedule 70
2.4.3 CM Component Function Block scheduling 73
2.4.4 IOM FB schedule 76
2.4.5 CPM, ACE, and CEE FBs schedule 76
2.4.6 Cycle overruns 76
2.5 Block Configuration Load Considerations 77

2.5.1 Data categories 77
2.5.2 Container and self-standing blocks load versus states 78
2.5.3 Load error messages 79
2.5.4 RAM Retention Start Up (RRSU) 79
2.6 Memory Usage for CEE on C200/C200E, C300 or ACE 79

2.6.1 C200/C200ECEE Processing and Memory Models 80
2.6.2 C300 CEE Processing and Memory Models 83
2.6.3 ACE CEE Processing and Memory Models 87
2.7 CPU Utilization for CEE on CPM 89

2.7.1 CPU load categories 89
2.7.2 CPU utilization limits and estimates 90
2.8 CEE Standard Control Blocks 90

2.9 Control Component Library (CCL) Blocks 95
Chapter 3 - Control Module Independence 97
3.1 Module Independence for Flexible Modification 97
3.2 CM Independence and Hypothetical Controller Comparison 97
3.2.1 Hypothetical controller structure 97
3.2.2 Coupling effects in hypothetical controller 98
3.3 CEE Architecture 100

3.3.1 CEE controller structure 100
3.3.2 Program and Data Partitioning 101
3.3.3 Native program and custom program partitioning 102
3.3.4 Regulated Base Cycle 102
3.3.5 Coupling effects in CEE-based controller 102
3.4 Validation of Control Module Independence 105

3.5 Resource Coupling Across Different Platforms 106
Chapter 4 - Relative References 108
-4-
4.1 About Relative References 108
4.2 Relative References structure rules 108
4.2.1 How relative reference matching function works 109
4.3 Display options for relative references 110

4.3.1 How short name display option works 111
4.4 Control Builder functions supporting relative references 112

4.5 Control Builder blocks supporting expressions 112
4.6 Example of TRANSITION block using relative references 112
4.6.1 A container reference from a chart 113
4.6.2 A reference to a parameter on the same block from a form 113
4.6.3 A reference to a parameter on a different block in the same CM 113
4.6.4 Expression display interaction 114
4.7 Example of parameter connector using relative references 114

4.7.1 A reference to a parameter on a different block in the same CM 114
4.7.2 Parameter connector display interaction 115
4.8 Example of other parameters using relative references 115

4.8.1 A reference to a parameter on a basic block of the CM 116
4.8.2 Other parameters display interaction 116
4.9 Bulk Builder and Bulk Editor support 116

Chapter 5 - Peer-to-Peer Functionality 117
5.1 Basic Peer-to-Peer Design Concepts 117
5.1.1 Data flow models 118
5.1.2 Peer environments and subscription periods 119
5.1.3 Software Architecture for CPM/CEE 119
5.1.4 A word about ACE/CEE architecture 120
5.1.5 Peer-to-peer communication between CEE and non-CEE points 121
5.1.6 Peer-to-peer communication between ACE/C300 and EHPM points 121
5.1.7 Guidelines for configuring peer-to-peer communication between CEE and
non-CEE points 122
5.1.8 Renaming non-CEE point/data type change consideration in configuration 125
5.1.9 Designing control strategy for failsafe control 126
5.1.10 Runtime peer-to-peer behavior between CEE and non-CEE point 129
5.1.11 Runtime peer-to-peer behavior between CEE and Experion Server points 130
5.2 Initiator Rate - Calculation 131

5.2.1 Configuration without peer environment table 131
5.2.2 Configuration with peer environment table 131
-5-
5.3 Implications for Control Builder Configuration 134
5.3.1 Multiple CPMs and ACEs 134
5.3.2 CEE execution and subscription rates 135
5.3.3 Function block support 135
5.3.4 Peer-to-peer connections and DEF and REF blocks 136
5.3.5 Peer-to-peer configuration example 136
5.3.6 Peer-to-peer configuration guidelines 139
5.3.7 Example to illustrate peer-to-peer configuration for non-CEE points 139
Chapter 6 - Time Support in Experion System 141

6.1 Date and Time Synchronization 141
6.2 C300 and Series C Fieldbus Interface Module Time
Synchronization 141
6.2.1 BOOTP Mechanism and Multiple Clusters 142
6.3 Time Configuration Considerations 142

6.3.1 Time Data Types in Control Execution Environment (CEE) Blocks 143
6.3.2 Time Data Types in User Algorithms and Displays 143
6.3.3 C200/C200E, Application Control Environment (ACE) Time Parameters 144
6.3.4 Custom Algorithm Block (CAB) on ACE Time Functions 145
6.4 Examples of Time Usage in CAB and SCM 146

6.4.1 Example - Custom Algorithm Block (CAB) writes Time CDP 146
6.4.2 Example - Custom Algorithm Block (CAB) reads Time CDP 146
6.4.3 6.4.3 Example - Sequence Control Module (SCM) waits for a specified Time 147
6.4.4 Example - Sequence Control Module (SCM) records Time of process
command 147
Chapter 7 - Cold and Warm Restart Functionality 148

7.1 Overview 148
7.1.1 CEE Initial Startup 148
7.1.2 CEE Restarts 148
7.1.3 CEE Restart Behaviors 149
7.2 Planning 149

7.2.1 Invariant or Variant Restart Behaviors 149
7.2.2 Blocks with Invariant Restart Behavior 150
7.2.3 Blocks with Variant Restart Behavior 152
7.3 Configuration of Restart Behaviors 153

7.3.1 CEE Block 154
7.3.2 Control Module (CM) 154
7.3.3 Control Module Function Blocks 154
-6-
7.3.4 Logic Blocks 155
7.3.5 Sequential Control Module (SCM) 156
7.3.6 Summary Of SCM Restart Behavior 159
7.3.7 Supporting SCM Functionalities 159
7.3.8 SCM Blocks 161
7.4 Warm and Cold Restart Behaviors of Cascades 161

7.4.1 Definitions 161
7.4.2 Regulatory Cascades 162
7.4.3 CEE to CEE Cascades 163
7.4.4 CEE to Legacy Cascade when Node hosting Primary is restarted 165
7.4.5 CEE to EHPM FTE Cascade 166
7.4.6 CEE to Legacy Cascade when Node hosting Secondary is restarted 166
7.4.7 RegCtl Cascades when Node hosting the Primary is restarted 166
7.4.8 Cascades through UCNIF: UCNOUT/EUCNOUT 167
7.5 Operations 168

7.5.1 CEE Function Block 168
7.5.2 ACE Function Block 169
7.5.3 CPM Function Block 169
Chapter 8 - External OPC Server Support 170

8.1 OPC Data Access 170
8.1.1 OPC Server function block 170
8.1.2 OPC client/server data flow 171
8.2 OPC Data References 171

8.2.1 OPC Data Name Syntax 171
8.2.2 Parameter connectors only 172
8.2.3 OPC references in expressions 172
8.2.4 OPC references in SCM Alias table 173
8.2.5 Validation of OPC references 173
8.3 OPC Data Type Conversions 173

8.3.1 Gets conversions 174
8.3.2 General data conversion considerations 174
8.3.3 Stores conversions 177
8.4 ACE interface to TPS system as OPC server 177

Chapter 9 - System Namespace Workaround 179
9.1 Inter-Cluster Communication 179
9.2 Using the Inter Cluster Gateway for Communication
between Experion Clusters 179
-7-
9.2.1 Inter Cluster Gateway configuration guidelines 180
9.2.2 When to use Inter Cluster Gateway 180
9.2.3 Reviewing Inter Cluster Gateway characteristics 181
9.2.4 Inter Cluster Gateway connectivity 182
9.3 Remote EEOUT (REEOUT) Function Block 183

9.3.1 Functional description-REEOUT 183
Chapter 10 - Controller Redundancy Functionality 184

10.1 Basic Redundancy Design Concepts 184
10.1.1 Switchover and Secondary readiness 185
10.1.2 Failure conditions and switchover 185
10.1.3 Role of the Redundancy Module 187
10.2 Implications for Control Builder Functions 188

10.2.1 Redundant C200/C200E CPM configuration 188
10.2.2 RM configuration 188

10.2.3 RM monitoring 189
10.2.4 RM/RCP dialog box 189
10.2.5 Main tab 190
10.2.6 Summary tab 190
10.2.7 RM Profiles tab 192
10.2.8 Configuration tab 194
10.2.9 Synchronization tab 195

10.2.10 Chassis Profiles tab 198
10.2.11 Display tab 199
10.2.12 Server History tab 200
10.2.13 Server Displays tab 201
10.2.14 Auto-Synchronization events 203
Chapter 11 - Control Mode Shed on Loss of I/O Functionality 204

11.1 Basic Control Mode Shed Design Concepts 204
11.1.1 How it works 204
11.2 Option to specify a time delay for the REGCTL blocks to

shed the mode 205
11.2.1 Enabling the option of specifying time delay for REGCTL blocks to shed the
mode 206
11.2.2 Description of values for Bad Output Connection Option 207
11.2.3 Considerations for setting the BADOCOPT value 209
11.2.4 Applicability of BADOCOPT parameter for FANOUT blocks 209
11.2.5 Simulation support for the BADOCOPT parameter 209
11.2.6 Impact of BADOCOPT parameter on regulatory control functionalities 209
-8-
11.2.7 Effects of BADOCOPT value on delay timer in various scenarios 210
11.2.8 Auxiliary memory usage for the parameters 210
11.2.9 Detail Displays 211
11.3 Implications for Operation 212

11.3.1 Resetting mode after I/O communications are restored. 212
11.3.2 Allowing Redundancy synchronization with lost I/O communications 212
11.4 Remote Cascade function between Controllers 213

Chapter 12 - Enhancements to MODE behavior of the regulatory control
blocks 214
12.1 About the MODESTARTMAN parameter 214
12.1.1 When MODESTARTMAN is enabled 215
12.1.2 When MODESTARTMAN is disabled 216
12.2 MODESTARTMAN 217

Chapter 13 - Control Builder Export and Import Functionality 218
13.1 Basic Export/Import Design Concepts 218
13.1.1 Export functionality 218
13.1.2 Import functionality 219
Chapter 14 - SCM and CM Chart Visualization Functionality 220

14.1 Basic Chart Visualization Design Concepts 220
14.1.1 How SCM chart visualization works 220
14.2 Some SCM and CM Chart Operation Considerations 223

14.2.1 Detail display interaction notes 223
Chapter 15 - Enhancements to reporting of alarms in Station 224

15.1 Various configurable alarm attributes 224
15.2 Blocks and applicable alarms 225
15.2.1 Guidelines for configuring on-delay time for BADCTL alarm 227
15.2.2 Example to illustrate the alarm behavior based on alarm attributes 228
15.2.3 Impact of alarm priority change on alarm behavior 229
15.2.4 Impact of migration on alarm attributes 229
15.2.5 Impact of OUTIND parameter on alarm attributes 230
Chapter 16 - I/O Link Interface 231

16.1 I/O Functions 231
16.2 A word about Point form 231
16.3 IOP validation 232
-9-
16.4 I/O Link Cable Status and Statistics 232
16.4.1 Periodic swap functionality 232
16.4.2 Periodic swap transition diagram 233
16.4.3 Enabling periodic channel swap 233
16.4.4 Viewing cable status and statistics 234
Chapter 17 - Process Manager Input/Output Functionality 235

17.1 High and Low Level Analog Input Points 235
17.1.1 Function of high and low level analog input points 236
17.1.2 PV Characterization 238
17.1.3 Linear Conversions 239
17.1.4 Square root conversion 239
17.1.5 Thermal conversion 240
17.2 Smart Transmitter Interface Point 241

17.2.1 Smart Transmitter support 241
17.2.2 Multivariable transmitter support 242
17.2.3 Transmitter parameters and database access 242
17.2.4 STI parameter comparisons 243
17.2.5 Transmitter communication mode 243
17.2.6 STI IOP commands 244
17.2.7 Point states 244
17.2.8 STI IOP functions 246

17.2.9 STI PV characterization 246
17.2.10 STI linear conversion 248
17.2.11 STI square root conversion 248
17.2.12 STI thermal conversion 248
17.2.13 STI PV range checking and filtering 248
17.3 Analog Output Point 249

17.3.1 AO functions 249
17.3.2 AO direct/reverse output 250
17.3.3 AO output characterization 251
17.3.4 AO calibration compensation 251
17.4 Digital Input Point 251

17.4.1 DI functions 252
17.4.2 DI status point 253
17.4.3 DI PV source selection 253
17.4.4 DI off-normal alarming 254
17.4.5 Alarm delay 254
- 10 -
17.4.6 Event reporting 255
17.4.7 DI latched input point 255
17.4.8 DI sequence of events point 255
17.4.9 SOE definitions 256
17.4.10 SOE resolution considerations 256
17.4.11 DI SOE configuration considerations 257
17.5 Digital Output Point 258

17.5.1 DO functions 259
17.5.2 Pulse Width Modulated (PWM) Output Type 260
17.5.3 Status Output Type 260
17.5.4 Initialization request flag 260
Chapter 18 - Component Categories and Types 262

18.1 About categories 262
18.2 Function block types and data organization 262
Chapter 19 - Regulatory Control 264
19.1 Regulatory Control Blocks 264
19.1.1 Common regulatory control functions for C200/C200E and ACE
controllers without insertion points 267
19.1.2 Common regulatory control functions for ACE controllers with insertion
points 268
19.1.3 CAB insertion configuration considerations for regulatory control blocks 270
19.1.4 Insertion type functional characteristics for regulatory control blocks 270
19.1.5 Functional requirements for Custom CAB algorithm for regulatory control
block 271
19.1.6 CAB insertions for Regulatory Control block parameters 272
19.1.7 Pin connections to inserted CAB instances 273
19.1.8 Insertion status and fail alarm for regulatory control blocks 274
19.1.9 Handling of insertion failure on regulatory control block 274
19.1.10 CAB insertion on regulatory control block configuration examples 274
19.1.11 Tuning Conversions from Interactive to Non-Interactive PID 280
19.2 Clamping the output amperage to comply with the NAMUR

NE 43 standard 281
19.2.1 Device needs and the standard 281
19.2.2 Configuration 281
19.3 About Safety Interlock Function 285

19.3.1 Safety Interlock processing 285
19.3.2 Safety Interlock processing considerations 286
19.3.3 Safety Interlock Alarming 287
- 11 -
19.4 About Red Tagging 287
19.4.1 Function of Red Tagging 288
19.4.2 Before red tagging a point 288
19.5 AUTOMAN (Auto Manual) Block 288

19.5.1 Function-AUTOMAN 296
19.5.2 Configuration example-AUTOMAN 297
19.5.3 Inputs-AUTOMAN 298
19.5.4 Output-AUTOMAN 298
19.5.5 Initializable inputs and outputs for AUTOMAN 299
19.5.6 Output ranges of AUTOMAN 299
19.5.7 Output bias-AUTOMAN 300
19.5.8 Output Indication function for AUTOMAN 301
19.5.9 Mode Handling-AUTOMAN 303
19.5.10 Timeout Monitoring-AUTOMAN 303
19.5.11 Control Initialization-AUTOMAN 304

19.5.12 Secondary initialization option-AUTOMAN 305
19.5.13 Override feedback processing-AUTOMAN 305
19.5.14 Windup processing-AUTOMAN 305
19.5.15 Anti-Reset Windup Status-AUTOMAN 307
19.5.16 AUTOMAN parameters 308
19.6 ENHREGCALC (Enhanced Regulatory Control Calculator)

Block 308
19.6.1 Function-ENHREGCALC 318
19.6.2 Configuration example-ENHREGCALC 319
19.6.3 Operating modes and mode handling for ENHREGCALC 319
19.6.4 Inputs-ENHREGCALC 319
19.6.5 Initializable input-ENHREGCALC 320
19.6.6 SP limit checking-ENHREGCALC 320
19.6.7 SP target value processing-ENHREGCALC 320
19.6.8 Initializable outputs-ENHREGCALC 322
19.6.9 Output ranges and limits-ENHREGCALC 323
19.6.10 Assignable outputs-ENHREGCALC 323
19.6.11 Output assignment rules-ENHREGCALC 324
19.6.12 Control initialization-ENHREGCALC 325
19.6.13 Output bias-ENHREGCALC 325
19.6.14 Output Indication Function-ENHREGCALC 327
19.6.15 Timeout monitoring-ENHREGCALC 330
19.6.16 Timeout processing-ENHREGCALC 330
- 12 -
19.6.17 Mode shedding on timeout-ENHREGCALC 330
19.6.18 Override feedback processing-ENHREGCALC 330
19.6.19 Windup handling-ENHREGCALC 332
19.6.20 Windup processing-ENHREGCALC 332
19.6.21 Anti-Reset Windup Status-ENHREGCALC 334
19.6.22 Expressions 335
19.6.23 Parameters in Expressions 337
19.6.24 Guidelines for Writing Expressions 337
19.6.25 Enable/Disable switch example expression 339
19.6.26 String data support in expressions 339
19.6.27 Time support in expressions 339
19.6.28 Restart or point activation 341
19.6.29 ENHREGCALC parameters 341
19.7 FANOUT Block 341

19.7.1 Function-FANOUT block 349
19.7.2 Configuration example-FANOUT block 349
19.7.3 Inputs-FANOUT block 349
19.7.4 Outputs-FANOUT block 350
19.7.5 Initializable inputs and outputs for FANOUT block 350
19.7.6 Output ranges for FANOUT block 350
19.7.7 Output bias-FANOUT block 351
19.7.8 Mode handling-FANOUT block 352

19.7.9 Timeout monitoring-FANOUT block 353
19.7.10 Control initialization-FANOUT block 353
19.7.11 Secondary initialization option-FANOUT block 355
19.7.12 Override feedback processing-FANOUT block 355
19.7.13 BACKCALC processing 355
19.7.14 Output Indication Function 355
19.7.15 Windup processing in FANOUT block 358
19.7.16 Windup processing in Regulatory blocks 359
19.7.17 Anti-Reset Windup Status 360
19.7.18 FANOUT parameters 361
19.8 OVRDSEL (Override Selector) Block 362

19.8.1 Function-OVRDSEL block 369
19.8.2 Configuration example-OVRDSEL block 371
19.8.3 Configuration considerations-OVRDSEL block 372
19.8.4 Inputs-OVRDSEL block 373
19.8.5 Input ranges for OVRDSEL block 373
- 13 -
19.8.6 Input descriptors-OVRDSEL block 373
19.8.7 Initializable outputs-OVRDSEL block 374
19.8.8 Output ranges and limits for OVRDSEL block 374
19.8.9 Output Indication Function-OVRDSEL block 375
19.8.10 Mode handling-OVRDSEL block 377
19.8.11 Timeout monitoring-OVRDSEL block 377
19.8.12 Timeout processing-OVRDSEL block 377
19.8.13 Bypass processing-OVRDSEL block 378
19.8.14 Bad input option 378
19.8.15 OVRDSEL Equations 378
19.8.16 Input switching 379
19.8.17 Output bias-OVRDSEL 379
19.8.18 Bad CV processing 379
19.8.19 Control initialization-OVRDSEL 379
19.8.20 Restart or function block activation 380

19.8.21 Override feedback propagation 380
19.8.22 Recommendations on configuring override strategies 380
19.8.23 Windup processing 381
19.8.25 OVRDSEL parameters 383
19.9 PID Block 384

19.9.1 Function-PID Block 395
19.9.2 Functional scenario-PID Block 397
19.9.3 Configuration examples-PID Block 398
19.9.4 Operating modes and mode handling-PID Block 400
19.9.5 Required inputs-PID Block 400
19.9.6 Input ranges and limits-PID Block 400
19.9.7 Initializable outputs-PID Block 401
19.9.8 Control initialization-PID Block 401
19.9.9 Output bias-PID Block 402
19.9.10 Output ranges and limits-PID Block 403
19.9.11 Direct or reverse control-PID Block 404
19.9.12 Set Point Ramping-PID Block 404
19.9.13 PV tracking-PID Block 407
19.9.14 PID equations 408
19.9.15 Gain options-PID block 410
19.9.16 Tuning Constant Change Considerations 411
19.9.17 Timeout monitoring-PID block 411
- 14 -
19.9.18 Timeout processing-PID block 411
19.9.19 Output Indication Function-PID block 412
19.9.20 Windup handling-PID block 415
19.9.23 Override feedback processing-PID block 418
19.9.24 PID parameters 419
19.10 PID-PL (Profit Loop PKS) Block 419

19.10.1 Benefits 420
19.10.2 Graphic presentation 421
19.10.3 Modes 421
19.10.4 Configurable attributes 422
19.10.5 Function-PID-PL 431
19.10.6 Configuration examples-PID-PL 439
19.10.7 Operating modes and mode handling-PID-PL 442

19.10.8 Required inputs-PID-PL 443
19.10.9 Input ranges and limits-PID-PL 443
19.10.10 Initializable outputs-PID-PL 443
19.10.11 Control initialization-PID-PL 444
19.10.12 Output bias-PID-PL 444
19.10.13 Output ranges and limits-PID-PL 444
19.10.14 Direct or reverse control-PID-PL 444

19.10.15 Set Point Ramping-PID-PL 444
19.10.16 Range Control Ramping-PID-PL 444
19.10.17 PV tracking-PID-PL 445
19.10.18 PV Bad Value Handling 446
19.10.19 PV Calibration 446
19.10.20 Asynchronous PV Inputs 446
19.10.21 Control Equations-PID-PL block 447
19.10.22 Output Indication Function 447
19.10.24 Timeout monitoring 451
19.10.25 Windup handling-PID-PL block 451
19.10.28 Override feedback processing-PID-PL block 454
19.10.29 PID-PL parameters 454
19.11 PIDER (PID with External Reset Feedback) Block 455
- 15 -
19.11.1 Configuration example-PIDER block 456
19.11.2 Function 467
19.11.3 Operating modes and mode handling-PIDER block 468
19.11.4 Required inputs-PIDER block 468
19.11.5 Input ranges and limits-PIDER block 468
19.11.6 Initializable outputs-PIDER block 469
19.11.7 Control initialization-PIDER block 469
19.11.8 Output bias-PIDER block 470
19.11.9 Output ranges and limits-PIDER block 471
19.11.10 Direct or reverse control-PIDER block 471
19.11.11 Set Point Ramping-PIDER block 472
19.11.12 PV tracking 474
19.11.13 PID equations for PIDER block 475
19.11.14 PIDER equation variations 476
19.11.15 Gain options 477

19.11.16 Output Indication Function- PIDER block 479
19.11.18 Timeout monitoring 480
19.11.19 Timeout processing 481
19.11.20 Windup handling 481

19.11.23 Override feedback processing-PIDER block 484
19.11.24 Error handling for RFB and TRFB inputs 484
19.11.25 Restart or point activation 484
19.11.26 PIDER parameters 484
19.12 PIDFF (PID with Feedforward) Block 485

19.12.1 Function-PIDFF block 497
19.12.2 Functional scenario-PIDFF block 497
19.12.3 Operating modes and mode handling-PIDFF block 498
19.12.4 Required inputs-PIDFF block 499
19.12.5 Input ranges and limits-PIDFF block 499
19.12.6 Initializable outputs-PIDFF block 499
19.12.7 Control initialization-PIDFF block 500
19.12.8 Output bias-PIDFF block 500
19.12.9 Output ranges and limits-PIDFF block 502
19.12.10 Direct or reverse control for PIDFF block 502
19.12.11 Set Point Ramping-PIDFF block 502
- 16 -
19.12.12 PV tracking-PIDFF block 505
19.12.13 Feedforward add or multiply action and equations-PIDFF block 506
19.12.14 Feedforward value status-PIDFF block 507
19.12.15 PID equations-PIDFF block 508
19.12.16 Gain options-PIDFF block 509
19.12.17 Output Indication Function-PIDFF block 510
19.12.18 Tuning Constant Change Considerations-PIDFF block 513
19.12.19 Timeout monitoring-PIDFF block 514
19.12.20 Timeout processing-PIDFF block 514
19.12.21 Windup handling-PIDFF block 514
19.12.22 Windup processing-PIDFF block 515
19.12.23 Anti-Reset Windup Status-PIDFF block 516
19.12.24 Bypassing feedforward control action-PIDFF block 517
19.12.25 Override feedback processing-PIDFF block 517
19.12.26 PIDFF parameters 518
19.13 LEGACYGAP Option in R300 518

19.13.1 Legacy gap gain option 519
19.13.2 Equation-LEGACYGAP 519
19.13.3 Configuration-LEGACYGAP 520
19.13.4 Migration-LEGACYGAP 520
19.14 POSPROP (Position Proportional) Block 521

19.14.1 Function-POSPROP block 528
19.14.2 Operating modes and mode handling-POSPROP block 529
19.14.3 Required inputs-POSPROP block 529
19.14.4 Input ranges and limits-POSPROP block 530
19.14.5 Output-POSPROP block 530
19.14.6 Initializable inputs and outputs-POSPROP block 530
19.14.7 Output ranges-POSPROP block 531
19.14.8 Set Point Ramping-POSPROP block 531
19.14.9 Timeout monitoring-POSPROP block 534
19.14.10 Timeout processing-POSPROP block 535
19.14.11 Equations-POSPROP block 535
19.14.12 Control Initialization-POSPROP block 536
19.14.13 Secondary initialization option-POSPROP block 536
19.14.14 Override feedback processing for POSPROP block 536
19.14.15 Raise/Lower limit switches of POSPROP block 536
19.14.16 Bad control processing-POSPROP block 537
19.14.17 Windup processing-POSPROP block 537
- 17 -
19.14.18 Anti-Reset Windup Status-POSPROP block 539
19.14.19 POSPROP parameters 540
19.15 PULSECOUNT Block 540

19.15.1 Function-PULSECOUNT block 541
19.15.2 Required inputs-PULSECOUNT block 542
19.15.3 Output-PULSECOUNT block 542
19.15.4 Initializable inputs and outputs-PULSECOUNT block 543
19.15.5 PULSECOUNT parameters 543
19.16 PULSELENGTH Block 543

19.16.1 Function-PULSELENGTH block 544
19.16.2 Required inputs-PULSELENGTH block 545
19.16.3 Output-PULSELENGTH block 545
19.16.4 Initializable inputs and outputs-PULSELENGTH block 546
19.16.5 PULSELENGTH parameters 546
19.17 RAMPSOAK Block 546

19.17.1 Function-RAMPSOAK block 555
19.17.2 Required inputs-RAMPSOAK block 557
19.17.3 Input ranges and limits-RAMPSOAK block 557
19.17.4 Initializable outputs-RAMPSOAK block 557
19.17.5 Output ranges and limits-RAMPSOAK block 557
19.17.6 Mode handling-RAMPSOAK block 558
19.17.7 Hold command-RAMPSOAK block 558

19.17.8 CEE idle or Control Module inactivate command-RAMPSOAK block 558
19.17.9 Profile statistics-RAMPSOAK block 559
19.17.10 Guaranteed ramp rate-RAMPSOAK block 559
19.17.11 Guaranteed soak time-RAMPSOAK block 559
19.17.12 Event timer functions-RAMPSOAK block 560
19.17.13 Control initialization-RAMPSOAK block 560
19.17.14 Override feedback processing-RAMPSOAK block 560
19.17.15 Output Indication Function-RAMPSOAK block 560
19.17.16 Windup processing-RAMPSOAK block 561
19.17.17 Anti-Reset Windup Status-RAMPSOAK block 563
19.17.18 RAMPSOAK parameters 564
19.18 RATIOBIAS Block 564

19.18.1 Function-RATIOBIAS block 571
19.18.2 Configuration example-RATIOBIAS block 572
19.18.3 Operating modes and mode handling-RATIOBIAS block 573
19.18.4 Required inputs-RATIOBIAS block 573
- 18 -
19.18.5 Input ranges and limits-RATIOBIAS block 573
19.18.6 Initializable outputs-RATIOBIAS block 574
19.18.7 Output ranges and limits-RATIOBIAS block 574
19.18.8 Control initialization-RATIOBIAS block 575
19.18.9 Ratio bias option-RATIOBIAS block 575
19.18.10 Output bias-RATIOBIAS block 576
19.18.11 Timeout monitoring-RATIOBIAS block 578
19.18.12 Timeout processing-RATIOBIAS block 578
19.18.13 Override feedback processing 579
19.18.14 Output Indication Function-RATIOBIAS block 579
19.18.15 Windup handling-RATIOBIAS block 582
19.18.16 Windup processing-RATIOBIAS block 582
19.18.17 Anti-Reset Windup Status-RATIOBIAS block 584
19.18.18 RATIOBIAS parameters 585
19.19 RATIOCTL (Ratio Control) Block 585

19.19.1 Function-RATIOCTL block 594
19.19.2 Configuration example-RATIOCTL block 594
19.19.3 Operating modes and mode handling-RATIOCTL block 595
19.19.4 Required inputs-RATIOCTL block 596
19.19.5 Input ranges and limits-RATIOCTL block 596
19.19.6 Initializable outputs-RATIOCTL block 596
19.19.7 Output ranges and limits-RATIOCTL block 597

19.19.8 Control initialization-RATIOCTL block 598
19.19.9 Equations-RATIOCTL block 598
19.19.10 Output bias-RATIOCTL block 600
19.19.11 Timeout monitoring-RATIOCTL block 601
19.19.12 Timeout processing-RATIOCTL block 601
19.19.13 Override feedback processing-RATIOCTL block 602
19.19.14 Output Indication Function-RATIOCTL block 603
19.19.15 Windup handling-RATIOCTL block 605
19.19.16 Windup processing-RATIOCTL block 606
19.19.17 Anti-Reset Windup Status-RATIOCTL block 608
19.19.18 Restart or point activation-RATIOCTL block 609
19.19.19 Error handling-RATIOCTL block 609
19.19.20 RATIOCTL parameters 609
19.20 REGCALC (Regulatory Control Calculator) Block 610

19.20.1 Function-REGCALC block 619
19.20.2 Operating modes and mode handling-REGCALC block 620
- 19 -
19.20.3 Inputs-REGCALC block 620
19.20.4 Input ranges and limits-REGCALC block 620
19.20.5 Initializable outputs-REGCALC block 620
19.20.6 Output ranges and limits-REGCALC block 621
19.20.7 Assignable outputs-REGCALC block 621
19.20.8 Output assignment rules-REGCALC block 622
19.20.9 Control initialization-REGCALC block 623
19.20.10 Output bias-REGCALC block 623
19.20.11 Timeout monitoring-REGCALC block 625
19.20.12 Timeout processing-REGCALC block 625
19.20.13 Override feedback processing-REGCALC block 626
19.20.14 Output Indication Function-REGCALC block 627
19.20.15 Windup handling-REGCALC block 629
19.20.16 Windup processing-REGCALC block 629
19.20.17 Anti-Reset Windup Status-REGCALC block 631

19.20.18 Expressions-REGCALC block 632
19.20.19 Parameters in Expressions-REGCALC block 634
19.20.20 Guidelines for Writing Expressions-REGCALC block 634
19.20.21 String data support in expressions-REGCALC block 636
19.20.22 Time support in expressions-REGCALC block 636
19.20.23 REGCALC parameters 638
19.21 REEOUT (Remote EEOUT) Block 638

19.21.1 Function-REEOUT block 639
19.21.2 Configuration Example-REEOUT block 639
19.21.3 Inputs-REEOUT block 640
19.21.4 Outputs-REEOUT block 640
19.21.5 Push of SP to secondary cluster's regulatory FBs-REEOUT block 640
19.21.6 REEOUT parameters 640
19.22 REGSUMMER (Regulatory Summer) Block 640

19.22.1 Equation-REGSUMMER block 648
19.22.2 Function-REGSUMMER block 648
19.22.3 Configuration example-REGSUMMER block 649
19.22.4 Inputs-REGSUMMER block 649
19.22.5 Outputs-REGSUMMER block 649
19.22.6 Initializable inputs and outputs-REGSUMMER block 650
19.22.7 Output Ranges-REGSUMMER block 650
19.22.8 Output bias-REGSUMMER block 650
19.22.9 Mode handling-REGSUMMER block 651
- 20 -
19.22.10 Control initialization-REGSUMMER block 651
19.22.11 Override feedback processing-REGSUMMER block 652
19.22.12 Output Indication Function-REGSUMMER block 653
19.22.13 Windup processing-REGSUMMER block 655
19.22.14 REGSUMMER parameters 657
19.23 REMCAS (Remote Cascade) Block 658

19.23.1 Function-REMCAS block 666
19.23.2 Configuration example-REMCAS block 666
19.23.3 Inputs-REMCAS block 669
19.23.4 Input ranges and limits-REMCAS block 669
19.23.5 Input descriptors-REMCAS block 669
19.23.6 Outputs-REMCAS block 669
19.23.7 Output ranges and limits-REMCAS block 670
19.23.8 Output Indication Function-REMCAS block 670
19.23.9 Mode handling-REMCAS block 673

19.23.10 Timeout monitoring-REMCAS block 673
19.23.11 Timeout processing-REMCAS block 674
19.23.12 Input switching-REMCAS block 674
19.23.13 Equations-REMCAS block 675
19.23.14 Output bias-REMCAS block 675
19.23.15 Control Initialization-REMCAS block 676
19.23.16 Override feedback processing-REMCAS block 677

19.23.17 Windup processing-REMCAS block 677
19.23.18 Anti-Reset Windup Status-REMCAS block 679
19.23.19 REMCAS parameters 680
19.24 SWITCH Block 680

19.24.1 Function-SWITCH block 688
19.24.2 Inputs-SWITCH block 690
19.24.3 Input ranges and limits-SWITCH block 690
19.24.4 Input descriptors-SWITCH block 690
19.24.5 Initializable Outputs-SWITCH block 690
19.24.6 Output ranges and limits-SWITCH block 691
19.24.7 Mode handling-SWITCH block 691
19.24.8 Timeout monitoring-SWITCH block 691
19.24.9 Timeout processing-SWITCH block 692
19.24.10 Equations-SWITCH block 692
19.24.11 Bad input handling-SWITCH block 693
19.24.12 Bypass processing-SWITCH block 694
- 21 -
19.24.13 Input switching-SWITCH block 694
19.24.14 Output bias-SWITCH block 694
19.24.15 Error handling-SWITCH block 696
19.24.16 Control initialization-SWITCH block 696
19.24.17 Override feedback processing-SWITCH block 696
19.24.18 Output Indication Function-SWITCH block 697
19.24.19 Windup processing-SWITCH block 699
19.24.20 Anti-Reset Windup Status-SWITCH block 701
19.24.21 SWITCH parameters 701
Chapter 20 - UCN Interface 702

20.1 Universal Control Network (UCN) Interface Block Library 702
20.2 UCNOUT/EUCNOUT block 703
20.2.1 About remote cascade - UCNOUT/EUCNOUT block 704
20.2.2 Configuration form overview 706
20.2.3 Input/Output - UCNOUT/EUCNOUT block 707

20.2.4 Configuration example - UCNOUT/EUCNOUT block 707
20.2.5 UCNOUT/EUCNOUT parameters 709
Chapter 21 - Hiway Interface 710

21.1 Hiway Interface (HIWAYIF) Block Library 710
21.2 HIWAYOUT Block 710
21.2.1 About remote cascade-HIWAYOUT Block 711
21.2.2 Configuration form overview-HIWAYOUT Block 712
21.2.3 Input/Output-HIWAYOUT Block 712
21.2.4 Configuration example-HIWAYOUT Block 713
21.2.5 Load and Execution-HIWAYOUT Block 714
21.2.6 HIWAYOUT parameters 715
Chapter 22 - Exchange Functions 716

22.1 Exchange Function Blocks 716
22.2 REQFLAGARRAY Block 717
22.2.1 Function-REQFLAGARRAY Block 721
22.2.2 Input/Output-REQFLAGARRAY Block 721
22.2.3 REQFLAGARRAY parameters 721
22.3 REQNUMARRAY Block 721

22.3.1 Function-REQNUMARRAY Block 725
22.3.2 Input/Output-REQNUMARRAY Block 725
22.3.3 REQNUMARRAY parameters 725
- 22 -
22.4 REQTEXTARRAY Block 725
22.4.1 Function-REQTEXTARRAY Block 729
22.4.2 Input/Output-REQTEXTARRAY Block 729
22.4.3 REQTEXTARRAY parameters 729
22.5 RSPFLAGARRAY Block 729

22.5.1 Function-RSPFLAGARRAY Block 730
22.5.2 Input/Output-RSPFLAGARRAY Block 730
22.5.3 RSPFLAGARRAY parameters 731
22.6 RSPNUMARRAY Block 731

22.6.1 Function-RSPNUMARRAY Block 732
22.6.2 Input/Output-RSPNUMARRAY Block 732
22.6.3 RSPNUMARRAY parameters 732
22.7 RSPTEXTARRAY Block 732

22.7.1 Function-RSPTEXTARRAY Block 733
22.7.2 Input/Output-RSPTEXTARRAY Block 734
22.7.3 RSPTEXTARRAY parameters 734
Chapter 23 - Auxiliary Function Blocks 735

23.1 Common auxiliary block functions 737
23.2 AUXCALC (Auxiliary Calculation) Block 737
23.2.1 Function-AUXCALC block 738
23.2.2 Configuration example-AUXCALC block 739

23.2.3 Input-AUXCALC block 739
23.2.4 Output-AUXCALC block 739
23.2.5 Expressions-AUXCALC block 740
23.2.6 Parameters in Expressions-AUXCALC block 740
23.2.7 Guidelines for Writing Expressions-AUXCALC block 740
23.2.8 Assignable Outputs-AUXCALC block 741
23.2.9 AUXCALC parameters 742
23.3 AUXSUMMER (Auxiliary Summer) Block 742

23.3.1 Function-AUXSUMMER block 742
23.3.2 Configuration parameters-AUXSUMMER block 743
23.3.3 Configuration example-AUXSUMMER block 745
23.3.4 Input-AUXSUMMER block 745
23.3.5 Output-AUXSUMMER block 745
23.3.6 Error handling-AUXSUMMER block 746
23.3.7 Restart or point activation-AUXSUMMER block 746
23.3.8 AUXSUMMER parameters 746
- 23 -
23.4 CTUD (COUNTER UP/DOWN) Block 747
23.4.1 Function-CTUD block 748
23.4.2 Inputs-CTUD block 748
23.4.3 Outputs-CTUD block 750
23.4.4 Edge or Level trigger mechanism-CTUD block 750
23.4.5 Supported algorithms-CTUD block 752
23.4.6 Counter overflow and underflow conditions-CTUD block 753
23.4.7 Effects of restart or point activation on CTUD 755
23.4.8 Effects of Import or Export on CTUD 755
23.4.9 Effects of Checkpoint operations CTUD 755
23.4.10 Parameter error handling-CTUD block 756
23.4.11 CTUD parameters 757
23.5 DEADTIME Block 757

23.5.1 Function-DEADTIME block 759
23.5.2 Input-DEADTIME block 759

23.5.3 Output-DEADTIME block 759
23.5.4 PV status-DEADTIME block 759
23.5.5 Error handling-DEADTIME block 759
23.5.6 Delay type-DEADTIME block 760
23.5.7 Delay table-DEADTIME block 760
23.5.8 Restart condition-DEADTIME block 761
23.5.9 DEADTIME parameters 761
23.6 ENHAUXCALC (Enhanced Auxiliary Calculation) Block 761

23.6.1 Function-ENHAUXCALC block 762
23.6.2 Configuration parameters-ENHAUXCALC block 764
23.6.3 Input-ENHAUXCALC block 765
23.6.4 Output-ENHAUXCALC block 765
23.6.5 Expressions-ENHAUXCALC block 765
23.6.6 Parameters in Expressions-ENHAUXCALC block 765
23.6.7 Guidelines for Writing Expressions-ENHAUXCALC block 766
23.6.8 Enable/Disable switch example expression-ENHAUXCALC block 767
23.6.9 Scaled Input example expression-ENHAUXCALC block 767
23.6.10 Assignable Outputs-ENHAUXCALC block 768
23.6.11 ENHAUXCALC parameters 768
23.7 ENHGENLIN (Enhanced General Linearization) Block 769

23.7.1 Function-ENHGENLIN block 771
23.7.2 Configuration Parameters-ENHGENLIN block 771
23.7.3 Configuration Example-ENHGENLIN block 772
- 24 -
23.7.4 Input-ENHGENLIN block 772
23.7.5 Output-ENHGENLIN block 773
23.7.6 Error Handling-ENHGENLIN block 773
23.7.7 Strategy Optimization using ENHGENLIN block 774
23.7.8 ENHGENLIN block - Usage Scenario 774
23.7.9 ENHGENLIN parameters 781
23.8 FLOWCOMP (Flow Compensation) Block 781

23.8.1 Function-FLOWCOMP block 782
23.8.2 Configuration parameters-FLOWCOMP block 782
23.8.3 Input-FLOWCOMP block 783
23.8.4 Output-FLOWCOMP block 784
23.8.5 Equations-FLOWCOMP block 784
23.8.6 Additional considerations for FLOWCOMP Equation A 785
23.8.7 Error handling-FLOWCOMP block 788
23.8.8 Alarm behavior-FLOWCOMP block 788

23.8.9 Alarm example-FLOWCOMP block 789
23.8.10 Fail-Safe values-FLOWCOMP block 789
23.8.11 FLOWCOMP parameters 789
23.9 GENLIN (General Linearization) Block 789

23.9.1 Function-GENLIN block 791
23.9.2 Inputs 791
23.9.3 Outputs-GENLIN block 791

23.9.4 Error handling-GENLIN block 791
23.9.5 GENLIN parameters 791
23.10 LEADLAG Block 792

23.10.1 Function-LEADLAG block 794
23.10.2 Input-LEADLAG block 794
23.10.3 Output-LEADLAG block 794
23.10.4 PV status-LEADLAG block 794
23.10.5 Error handling-LEADLAG block 794
23.10.6 Equation-LEADLAG block 794
23.10.7 Time constant recommendations-LEADLAG block 795
23.10.8 Restart condition-LEADLAG block 795
23.10.9 LEADLAG parameters 795
23.11 ROC (Rate of Change) Block 796

23.11.1 Function-ROC block 799
23.11.2 Configuration examples-ROC block 801
23.11.3 Inputs-ROC block 801
- 25 -
23.11.4 Outputs-ROC block 801
23.11.5 Error handling-ROC block 801
23.11.6 ROC parameters 802
23.12 SIGNALSEL (Signal Selector) Block 803

23.12.1 Function-SIGNALSEL block 804
23.12.2 Configuration parameters-SIGNALSEL block 804
23.12.3 Configuration examples-SIGNALSEL block 807
23.12.4 Input-SIGNALSEL block 811
23.12.5 Ignore Inputs-SIGNALSEL block 811
23.12.6 Ignore Limit Checking-SIGNALSEL block 811
23.12.7 Output-SIGNALSEL block 812
23.12.8 Selection Methods-SIGNALSEL block 812
23.12.9 Force-Select-SIGNALSEL block 814
23.12.10 Bumpless Input Switching-SIGNALSEL block 814
23.12.11 Deviation Alarming-SIGNALSEL block 814

23.12.12 Deviation Alarm Deadband-SIGNALSEL block 815
23.12.13 Deviation Alarm Deadband Units-SIGNALSEL block 815
23.12.14 Error handling-SIGNALSEL block 815
23.12.15 Restart or point activation-SIGNALSEL block 815
23.12.16 Parameters for Checkpoint-SIGNALSEL block 816
23.12.17 SIGNALSEL parameters 816
23.13 TOTALIZER Block 816

23.13.1 Description 816
23.13.2 Function-TOTALIZER block 817
23.13.3 Configuration example-TOTALIZER block 817
23.13.4 Input-TOTALIZER block 819
23.13.5 Outputs-TOTALIZER block 819
23.13.6 TOTALIZER states 819
23.13.7 Accumulator target value-TOTALIZER block 820
23.13.8 Deviation trip points-TOTALIZER block 820
23.13.9 Equations-TOTALIZER block 820
23.13.10 Accumulated value calculation-TOTALIZER block 821
23.13.11 Error handling-TOTALIZER block 822
23.13.12 Restart and activation-TOTALIZER block 822
23.13.13 TOTALIZER parameters 822
Chapter 24 - Data Acquisition Functions 823

24.1 DATAACQ (Data Acquisition) Block 823
24.1.1 Function-DATAACQ block 828
- 26 -
24.1.2 CAB Insertions for DATAACQ block parameters 830
24.1.3 CAB insertion configuration considerations 831
24.1.4 Insertion type functional characteristics-DATAACQ block 831
24.1.5 Pin connections to inserted CAB instances-DATAACQ block 832
24.1.6 CAB Insertion status and fail alarm-DATAACQ block 832
24.1.7 Handling of insertion failure-DATAACQ block 833
24.1.8 CAB insertion configuration examples-DATAACQ block 833
24.1.9 Input-DATAACQ block 838
24.1.10 Input ranges and limits-DATAACQ block 838
24.1.11 P1 status 838
24.1.12 PV Characterization-DATAACQ block 839
24.1.13 Input filtering-DATAACQ block 839
24.1.14 Input clamping-DATAACQ block 840
24.1.15 Low signal cut off-DATAACQ block 840
24.1.16 Output-DATAACQ block 840

24.1.17 PV source selection-DATAACQ block 841
24.1.18 PV status-DATAACQ block 841
24.1.19 Alarm processing-DATAACQ block 841
24.1.20 Additional Rate of Change Alarm considerations-DATAACQ block 843
24.1.21 PV significant-change alarming-DATAACQ block 843
24.1.22 Bad PV alarm-DATAACQ block 844
24.1.23 DATAACQ parameters 844
Chapter 25 - Pulse Input 845

25.1 Pulse Input Block 845
25.2 PITOTALIZER Block 845
25.2.1 Function-PITOTALIZER block 846
25.2.2 Configuration example-PITOTALIZER block 846
25.2.3 Input-PITOTALIZER block 847
25.2.4 Outputs-PITOTALIZER block 847
25.2.5 PITOTALIZER states 847
25.2.6 Accumulator target value-PITOTALIZER block 848
25.2.7 Deviation trip points-PITOTALIZER block 848
25.2.8 Near-Zero Cutoff-PITOTALIZER block 849
25.2.9 Bad Input Handling and Warm-Restart Options-PITOTALIZER block 849
25.2.10 Bad Input Options (PVEQN) Selection Summary 849
25.2.11 Control Module Activation-PITOTALIZER block 850
25.2.12 Operating Algorithms-PITOTALIZER block 850
25.2.13 Pulse versus Analog Operation 851
- 27 -
25.2.14 Error handling-PITOTALIZER block 851
25.2.15 Restart and activation-PITOTALIZER block 852
25.2.16 PITOTALIZER parameters 852
Chapter 26 - Device Control 853

26.1 DEVCTL (Device Control) Block 853
26.1.1 Function-DEVCTL block 861
26.1.2 Configuration examples-DEVCTL block 864
26.1.3 Inputs-DEVCTL block 867
26.1.4 Outputs-DEVCTL block 867
26.1.5 States-DEVCTL block 868
26.1.6 State parameters and descriptors-DEVCTL block 869
26.1.7 Two-State motor input example-DEVCTL block 870
26.1.8 Valve input example-DEVCTL block 870
26.1.9 Two-Input motor example-DEVCTL block 870
26.1.10 Reversible motor input example-DEVCTL block 871

26.1.11 Four-Input two-valve example-DEVCTL block 871
26.1.12 DI to PV state map 872
26.1.13 Two-State motor with latched output example 872
26.1.14 Valve Output Example-DEVCTL block 873
26.1.15 Three-State Motor output examples-DEVCTL block 873
26.1.16 Mode and mode attribute-DEVCTL block 874
26.1.17 Safe output state-DEVCTL block 874

26.1.18 Momentary state-DEVCTL block 874
26.1.19 Local manual-DEVCTL block 875
26.1.20 Permissive interlocks-DEVCTL block 875
26.1.21 Safety Override Interlock-DEVCTL block 875
26.1.22 Override Interlocks-DEVCTL block 876
26.1.23 Configurable Override/Permissive Interlock Bypass-DEVCTL block 876
26.1.24 Alarms-DEVCTL block 876
26.1.25 Seal-In option-DEVCTL block 879
26.1.26 Initialization Manual condition-DEVCTL block 879
26.1.27 OP Initialization Option-DEVCTL block 879
26.1.28 Initialization Manual Condition with Safety Override Interlock, Override
Interlocks, LocalMan, and OP Initialization 879
26.1.29 Initialization with Pulse Output-DEVCTL block 881
26.1.30 Initialization Request Flags-DEVCTL block 882
26.1.31 OP and DO Initialization After Load-DEVCTL block 882
26.1.32 Maintenance Statistics-DEVCTL block 882
26.1.33 Output requests-DEVCTL block 883
- 28 -
26.1.34 Output command-DEVCTL block 883
26.1.35 Logic override OPREQ 884
26.1.36 DEVCTL parameters 884
26.1.37 Faceplate for VFD applications 884
Chapter 27 - Logic Functions 887

27.1 Logic Function Blocks 887
27.1.1 Parameters-Logic Functions Blocks 917
27.2 Change Execute (CHGEXEC) Block 918

27.3 CHGEXEC Usage Considerations for Change Driven
Execution 918
27.4 Change Driven Application Risk Factors 919
27.5 Blocks Qualified for Use with CHGEXEC Block 920
27.6 Experion Controller Platform Support for CHGEXEC 923
27.7 CHGEXEC Main Parameter Details 925
27.8 CHGEXEC Cascading Between Control Modules Example 927
27.8.1 Graphical Examples of Cascaded CHGEXEC control charts 928
27.8.2 Cascaded CHGEXEC functional considerations 928
27.9 CHGEXEC Cascading Within Control Module Example 929

27.9.1 EXITOPT considerations for cascaded CHGEXEC in single CM 930
27.10 Importance of Using Consistent Input Data 930

27.10.1 Wrong input data example 931
27.10.2 Correct input data example 931
27.11 Periodic Auto Trigger Function of CHGEXEC 932

27.11.1 Auto Trigger application support 932
27.11.2 ATUOPERIOD sets period for Auto Trigger 933
27.11.3 TRIGGER output and Auto Trigger execution 933
27.11.4 Relationship between Auto Trigger and AUTOPHASE for synchronization
prevention 933
27.11.5 AUTOPERIOD configuration restrictions 934
27.12 Execution Order Considerations for CHGEXEC within CM 935

27.13 CHGEXEC Behaviors for State Transitions 935
27.14 CHGEXEC Supports Checkpoint Function 938
27.15 Load Monitoring Parameters 939
27.16 Sample CHGEXEC TESTOPT Procedure 939
27.17 Examples and scenarios 940
- 29 -
27.17.1 CheckBool functionality 940
27.17.2 CheckBool scenario 1 942
27.18 Contact Monitoring (CONTACTMON) Block 944

27.18.1 Function-CONTACTMON block 944
27.18.2 Predecessor Block-CONTACTMON block 945
27.18.3 Execution-CONTACTMON block 945
Chapter 28 - Math Functions 947

28.1 Math Function Blocks 947
28.1.1 Available Math blocks and size 947
28.1.2 Math blocks functional description 948
28.1.3 Rolling Average block-CONTACTMON block 951
Chapter 29 - Power Generation Functions 955

29.1 POWERGEN Function Blocks 955
29.2 GRPCAPRBK (Group Capability and Runback) Block 956
29.2.1 Function-GRPCAPRBK block 958
29.2.2 Configuration examples-GRPCAPRBK block 960
29.2.3 Inputs-GRPCAPRBK block 960
29.2.4 Outputs-GRPCAPRBK block 960

29.2.5 Error handling-GRPCAPRBK block 960
29.2.6 GRPCAPRBK parameters 961
29.3 HTMOTOR (HT Motor Drive Control) Block 961

29.3.1 Function-HTMOTOR block 971
29.3.2 Configuration examples-HTMOTOR block 971
29.3.3 Inputs-HTMOTOR block 979
29.3.4 Outputs-HTMOTOR block 980
29.3.5 Error handling-HTMOTOR block 980
29.3.6 States-HTMOTOR block 981
29.3.7 State parameters and descriptors-HTMOTOR block 981
29.3.8 Mode and mode attribute-HTMOTOR block 982
29.3.9 Safe output state-HTMOTOR block 982
29.3.10 Command dependency on switches and Mode attribute-HTMOTOR block 982
29.3.11 Local manual-HTMOTOR block 983
29.3.12 Permissive interlocks-HTMOTOR block 983
29.3.13 Safety Override Interlock-HTMOTOR block 984
- 30 -
29.3.14 Override Interlocks-HTMOTOR block 984
29.3.15 Configurable Override/Permissive Interlock Bypass-HTMOTOR block 984
29.3.16 Alarms-HTMOTOR block 984
29.3.17 Seal-in option-HTMOTOR block 985
29.3.18 FIRSTUP functionality-HTMOTOR block 986
29.3.19 Initialization Manual condition-HTMOTOR block 986
29.3.20 OP initialization option-HTMOTOR block 986
29.3.21 Initialization Manual condition with Safety Override Interlock, Override
Interlocks, LocalMan, and OP initialization-HTMOTOR block 986
29.3.22 Initialization with pulse output-HTMOTOR block 987
29.3.23 Initialization request flags-HTMOTOR block 987
29.3.24 OP and DO initialization after load-HTMOTOR block 987
29.3.25 Maintenance statistics-HTMOTOR block 987
29.3.26 Output requests-HTMOTOR block 988
29.3.27 Output command-HTMOTOR block 988
29.3.28 Logic override OPREQ-HTMOTOR block 989

29.3.29 Monitoring HT Motor Current 989
29.3.30 HTMOTOR parameters 989
29.4 LEVELCOMP (Drum Level Computation) Block 990

29.4.1 Function-LEVELCOMP block 992
29.4.2 Inputs-LEVELCOMP block 994
29.4.3 Outputs-LEVELCOMP block 994
29.4.4 Error handling-LEVELCOMP block 994

29.4.5 LEVELCOMP parameters 995
29.5 LTMOTOR (LT Motor Drive Control) Block 995

29.5.1 Function-LTMOTOR block 999
29.5.2 Configuration examples-LTMOTOR block 999
29.5.3 Inputs-LTMOTOR block 1008
29.5.4 Outputs-LTMOTOR block 1008
29.5.5 Error handling-LTMOTOR block 1009
29.5.6 States-LTMOTOR block 1009
29.5.7 State parameters and descriptors-LTMOTOR block 1009
29.5.8 Mode and mode attribute-LTMOTOR block 1010
29.5.9 Safe output state-LTMOTOR block 1011
29.5.10 Command dependency on switches and mode attribute-LTMOTOR block1011
29.5.11 Local manual-LTMOTOR block 1011
29.5.12 Permissive interlocks-LTMOTOR block 1012
29.5.13 Safety Override Interlock-LTMOTOR block 1012
29.5.14 Override Interlocks-LTMOTOR block 1012
- 31 -
29.5.15 Configurable Override/Permissive Interlock Bypass-LTMOTOR block 1013
29.5.16 Alarms-LTMOTOR block 1013
29.5.17 Seal-in option-LTMOTOR block 1014
29.5.18 Initialization Manual condition-LTMOTOR block 1014
29.5.19 OP initialization option-LTMOTOR block 1014
29.5.20 Initialization Manual condition with Safety Override Interlock, Override
Interlocks, LocalMan, and OP initialization-LTMOTOR block 1015
29.5.21 Initialization with pulse output-LTMOTOR block 1015
29.5.22 Initialization request flags-LTMOTOR block 1015
29.5.23 OP and DO initialization after load-LTMOTOR block 1016
29.5.24 Maintenance statistics-LTMOTOR block 1016
29.5.25 Output requests-LTMOTOR block 1016
29.5.26 Output command-LTMOTOR block 1016
29.5.28 LTMOTOR parameters 1017
29.6 MAINIBV (IBV Logic) Block 1018

29.6.1 Function-MAINIBV block 1020
29.6.2 Inputs-MAINIBV block 1020
29.6.3 Outputs-MAINIBV block 1020
29.6.4 Control logic-MAINIBV block 1021
29.6.5 Open sequence logic-MAINIBV block 1022
29.6.6 Close sequence logic-MAINIBV block 1022
29.6.7 Error handling-MAINIBV block 1023

29.6.8 MAINIBV parameters 1024
29.7 SOLENOID (Solenoid Valve Drive Control) Block 1024

29.7.1 Function-SOLENOID block 1029
29.7.2 Configuration examples-SOLENOID block 1030
29.7.3 Inputs-SOLENOID block 1037
29.7.4 Outputs-SOLENOID block 1037
29.7.5 Error handling-SOLENOID block 1037
29.7.6 States-SOLENOID block 1038
29.7.7 State parameters and descriptors-SOLENOID block 1038
29.7.8 Mode and mode attribute-SOLENOID block 1039
29.7.9 Safe output state-SOLENOID block 1039
29.7.10 Command dependency on switches and mode attribute-SOLENOID
block 1040
29.7.11 Local manual-SOLENOID block 1040
29.7.12 Permissive interlocks-SOLENOID block 1041
29.7.13 Safety Override Interlock-SOLENOID block 1041
- 32 -
29.7.14 Override Interlocks-SOLENOID block 1041
29.7.15 Configurable Override/Permissive Interlock Bypass-SOLENOID block 1041
29.7.16 Alarms-SOLENOID block 1042
29.7.17 Seal-in option-SOLENOID block 1043
29.7.18 Initialization Manual condition-SOLENOID block 1043
29.7.19 OP initialization option-SOLENOID block 1043
Interlocks, LocalMan, and OP Initialization-SOLENOID block 1044
29.7.21 Initialization request flags-SOLENOID block 1044
29.7.22 OP and DO initialization after load-SOLENOID block 1044
29.7.23 Maintenance statistics-SOLENOID block 1044
29.7.24 Output requests-SOLENOID block 1045
29.7.25 Output command-SOLENOID block 1045
29.7.27 SOLENOID parameters 1046
29.8 VALVEDAMPER (Valve/Damper Drive Control) Block 1046

29.8.1 Function-VALVEDAMPER block 1054
29.8.2 Configuration examples-VALVEDAMPER block 1055
29.8.3 Inputs-VALVEDAMPER block 1061
29.8.4 Outputs-VALVEDAMPER block 1061
29.8.5 Limit Switches-VALVEDAMPER block 1062
29.8.6 Error handling-VALVEDAMPER block 1062
29.8.7 States-VALVEDAMPER block 1063

29.8.8 State parameters and descriptors-VALVEDAMPER block 1063
29.8.9 Mode and mode attribute-VALVEDAMPER block 1064
29.8.10 Safe output state-VALVEDAMPER block 1064
29.8.11 Command dependency on switches and Mode attribute-VALVEDAMPER
block 1064
29.8.12 Local manual-VALVEDAMPER block 1065
29.8.13 Permissive interlocks-VALVEDAMPER block 1065
29.8.14 Safety Override Interlock-VALVEDAMPER block 1065
29.8.15 Override Interlocks-VALVEDAMPER block 1066
29.8.16 Configurable Override/Permissive Interlock Bypass-VALVEDAMPER
block 1066
29.8.17 Alarms-VALVEDAMPER block 1066
29.8.18 Seal-in option-VALVEDAMPER block 1067
29.8.19 Initialization Manual condition-VALVEDAMPER block 1068
29.8.20 OP initialization option-VALVEDAMPER block 1068
Interlocks, LocalMan, and OP Initialization-VALVEDAMPER block 1068
- 33 -
29.8.22 Initialization request flags-VALVEDAMPER block 1069
29.8.23 OP and DO initialization after load-VALVEDAMPER block 1069
29.8.24 Maintenance statistics-VALVEDAMPER block 1069
29.8.25 Output requests-VALVEDAMPER block 1069
29.8.26 Output command-VALVEDAMPER block 1070
29.8.27 Logic override OPREQ-VALVEDAMPER block 1071
29.8.28 VALVEDAMPER parameters 1071
Chapter 30 - Thermodynamic Utility Functions 1072

30.1 Steam Property Block (STEAMPROP) 1072
30.1.1 Typical usage of STEAMPROP block 1073
30.1.2 Function 1074
30.1.3 Inputs/Outputs - STEAMPROP block 1075
30.1.4 Configuration parameters - STEAMPROP block 1076
30.1.5 Configuration example - STEAMPROP block 1077
30.1.6 Typical configuration of STEAMPROP block 1080

30.1.7 Error handling - STEAMPROP block 1081
30.1.8 STEAMPROP block parameters 1081
Chapter 31 - I/O Reference blocks 1082

31.1 Types of Reference blocks 1083
31.2 Configuration of Reference block 1084
31.2.1 Mapping between PM I/O channel types and IOREFERENCES block types 1086
31.2.2 Mapping between Series C I/O channel types and IOREFERENCES block
types 1087
31.3 Behavior of Reference blocks when REFTYPE is

configured as PARAMETER 1089
31.3.1 Guidelines for entering REF parameter value when REFTYPE is
"PARAMETER" for output reference blocks 1090
31.3.2 Function-AIREF block 1091
31.3.3 Configuration example-AIREF block 1092
31.4 AOREF (AO Reference block) 1093

31.4.1 Function-AOREF 1093
31.4.2 Configuration example-AOREF block 1094
31.5 DIREF (DI Reference block) 1095

31.5.1 Function-DIREF 1096
31.5.2 Configuration example-DIREF block 1096
31.6 DOREF (DO Reference block) 1097

31.6.1 Function-DOREF 1097
- 34 -
31.6.2 Configuration example-DOREF block 1098
31.7 Copying Reference blocks 1098

31.7.1 To copy a Reference block 1099
31.8 Bulk Build of CM containing Reference blocks 1099

31.9 Navigating from Reference block faceplate to parameters
or I/O channels 1100
31.9.1 When the REF parameter refers a "Parameter value" 1100
31.9.2 When the REF parameter refers a "Channel" 1100
31.10 UDT behavior of Reference blocks 1100

31.10.1 Configuration of Reference blocks in a UDT for I/O channels and I/O
Points 1100
31.10.2 Configuration of Reference blocks in a UDT for parameter values 1101
31.10.3 Propagation of REFTYPE, CHANTYPE, and REF parameters from parent
UDTs 1101
31.11 Limitations of Reference blocks 1101

Chapter 32 - Utility Functions 1103
32.1 Utility Function Blocks 1103
32.2 ALMWINDOW (Alarm Window -Alarm Annunciator) Block 1104
32.2.1 Function-ALMWINDOW block 1107
32.2.2 Inputs-ALMWINDOW block 1107
32.2.3 Outputs-ALMWINDOW block 1107
32.2.4 Alarms-ALMWINDOW block 1107

32.2.5 Error handling-ALMWINDOW block 1110
32.2.6 ALMWINDOW parameters 1111
32.3 ANNPANEL (Annunciator Panel) Block 1111

32.3.1 Function-ANNPANEL block 1114
32.3.2 Configuration Example-ANNPANEL block 1114
32.3.3 Inputs-ANNPANEL block 1114
32.3.4 Outputs-ANNPANEL block 1115
32.3.5 Error Handling-ANNPANEL block 1115
32.3.6 ANNPANEL parameters 1115
32.4 DIGACQ (Digital Acquisition) Block 1115

32.4.1 Function-DIGACQ block 1118
32.4.2 Configuration Scenario-DIGACQ block 1120
32.4.3 Inputs-DIGACQ block 1120
32.4.4 Outputs-DIGACQ block 1120
32.4.5 Error handling-DIGACQ block 1121
- 35 -
32.4.6 DIGACQ parameters 1121
32.5 EXECTIMER Block 1121

32.5.1 Function-EXECTIMER block 1124
32.5.2 Input-EXECTIMER block 1125
32.5.3 Output-EXECTIMER block 1125
32.5.4 EXECTIMER Parameters 1125
32.5.5 EXECTIMER Example 1125
32.5.6 Limitations-EXECTIMER block 1126
32.6 FIRSTOUT (First Out Detection) Block 1127

32.6.1 Function-FIRSTOUT block 1128
32.6.2 Inputs-FIRSTOUT block 1132
32.6.3 Outputs-FIRSTOUT block 1132
32.6.4 Error handling-FIRSTOUT block 1132
32.6.5 First out detection FB parameters 1133
32.7 FLAG Block 1133

32.7.1 Function-FLAG block 1133
32.7.2 Input/Output-FLAG block 1135
32.7.3 FLAG parameters 1135
32.8 FLAGARRAY Block 1135

32.8.1 Function-FLAGARRAY block 1135
32.8.2 Input/Output-FLAGARRAY block 1136
32.8.3 FLAGARRAY parameters 1136
32.9 MESSAGE Block 1136

32.9.1 Function-MESSAGE block 1136
32.9.2 Configuration and Operation Considerations-MESSAGE block 1138
32.9.3 Input/Output-MESSAGE block 1138
32.9.4 MESSAGE parameters 1138
32.10 NUMERIC Block 1138

32.10.1 Function-NUMERIC block 1139
32.10.2 Input/Output-NUMERIC block 1139
32.10.3 NUMERIC parameters 1139
32.11 NUMERICARRAY Block 1139

32.11.1 Function-NUMERICARRAY block 1139
32.11.2 Input/Output-NUMERICARRAY block 1140
32.11.3 NUMERICARRAY parameters 1140
32.12 PUSH Block 1140

32.12.1 Function-PUSH block 1140
- 36 -
32.12.2 Execution Status-PUSH block 1140
32.12.3 Store Status-PUSH block 1141
32.12.4 PUSH parameters 1141
32.13 TEXTARRAY Block 1141

32.13.1 Function-TEXTARRAY block 1142
32.13.2 Input/Output-TEXTARRAY block 1142
32.13.3 TEXTARRAY parameters 1142
32.14 TEXTCOMMENT (Text Comment) Block 1142

32.14.1 Benefits of using Text Comment block 1143
32.14.2 TEXTCOMMENT parameters 1143
32.15 TIMER Block 1144

32.15.1 Function-TIMER block 1144
32.15.2 Input/Output-TIMER block 1144
32.15.3 Commands-TIMER block 1144
32.15.4 TIMER parameters 1145
32.16 TYPECONVERT Block 1145

32.16.1 Function-TYPECONVERT block 1145
32.16.2 Execution status-TYPECONVERT block 1146
32.16.3 Input/Output-TYPECONVERT block 1147
32.16.4 TYPECONVERT parameters 1147
Chapter 33 - Sequential Control 1148

33.1 SCM (Sequential Control Module) Block 1148
Chapter 34 - APC 1149
34.1 PROFITCTL Block 1149
34.2 PROFITCTLIN Block 1149
34.3 PROFITCTLOUT Block 1149
Chapter 35 - Mode selection functionality 1151
35.1 Applicable Modes for REGCTL, DEVCTL and POWERGEN
blocks 1151
35.2 Mode and Mode Attribute Selection 1152
35.3 Force Mode Attribute (FORCEMODEATTR) 1154
- 37 -
CHAPTER
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.
1.1 Revision History
Revision Date Description

A February 2018 Initial release of the document.
B April 2018 Under the section 19.8.21 removed a and e in the last line.
C April Note is added regarding K ( gain)
- 38 -
CHAPTER
2 CONTROL BUILDER COMPONENTS
l Control Builder Underlying Concepts

l Control Capacity and Performance
l I/O Capacity and Performance
l Function Block Execution Schedules
l Block Configuration Load Considerations
l Memory Usage for CEE on C200/C200E, C300 or ACE
l CPU Utilization for CEE on CPM
l CEE Standard Control Blocks
l Control Component Library (CCL) Blocks
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.
l Function Block (FB)

l Control Execution Environment (CEE)
l Independent Name
l Dependent Name
l Container Block
l 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.
l In the beginning or the Single-Loop Controller Reference

l Experion architecture - partitioned functionality
l Blocks for building process control operations
l Naming convention- independent versus dependent
l Full or expanded tag name
l Parameter names
- 39 -
Chapter 2 - Control Builder Components
l Naming restrictions and conventions

l Parameter data types
l Data flow -- active versus passive
l Active and passive connectors
l Cascade loop connections
l Data pull or push
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.
l Human Interface
l Communications Driver
l Control Data Processor
l Input/Output (I/O) Interface
Figure 2.1 Generic single-loop controller functions.
A brief description of each of these functions is given in the following table.
- 40 -
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:
l Process Variable (PV)
l Set Point (SP)
l Output (OP)
l Tuning Constants, and
l 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 The communications driver serves as the translator for the data that flows
Driver between the human interface and the control data process or functions. It
translates signals into appropriate display data or control action.
Control Data The control data processor defines the operating characteristics for the
Processor 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.
- 41 -
Figure 2.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 Description Name of example block

Type in Control Builder
Container A container block can “contain” other component Control Module (CM)
blocks. It appears as a chart in Control Builder into
which component blocks are placed. Sequential Control Module
(SCM)
Component A block which exists only as a component of a PID (All blocks listed in CM
container block. It appears as a generic named and SCM Libraries in
block with configurable pins and parameters within Control Builder, with the
a container block in Control Builder. Note that a exception of CM and SCM, of
component block may also be referred to as a Basic course.)
Function Block, or just a Basic Block.
Self- A block that stands on its own. It is neither a TC-IAH061(1756-IF6I) (All

Standing container for other blocks or a component of a blocks listed in Input/Output
(or Stand- container block. It appears as an icon in the menu Module (IOM) library as well
Alone) area of Control Builder. as related blocks in Rail I/O
and Pulse Input libraries in
Control Builder.)
CPM
CEE
RM
- 42 -
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 2.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.
- 43 -
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 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 2.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.
- 44 -
l <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:
l 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.
l For an independent type block: <Independent Tag Name>.<Parameter Name>
l 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:
l CM1.PIDA.OP
l To reference the Execution State (EXECSTATE) parameter of a Control Module named
PIDLOOP, you identify the parameter as follows:
l 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.
- 45 -
Figure 2.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)
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.
l The following characters are restricted and may not be used:
` ~ ! @ # $ % ^ & * + - = ( ) { } [ ] | \ \ : ; ' <> , . ? / \ “
o Dots are allowed in parameter naming only.
l An embedded space or leading space is not allowed.

o Spaces are allowed in area naming only.
l Tabs may not be used.
- 46 -
l The name may not be null (no characters).

l One of these characters must be present in a valid name:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
l The name must be less than the maximum size allowed for a tagname:
o 40 for composites.
o 15 for basic blocks.
o 100 for parameter names.
l The name must be unique.
2.1.8 Parameter data types

Parameter values are expressed in one of the following major data types.
l BOOLEAN
l ENUM (Enumeration)
l INT16 (Signed 16-bit Integer)
l INT32 (Signed 32-bit Integer)
l UINT16 (Unsigned 16-bit Integer)
l UINT32 Unsigned 32-bit Integer)
l FLOAT32 (32-bit IEEE Floating Point)
l FLOAT64 (64-bit IEEE Floating Point)
l TIME
l 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
- 47 -
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.
Figure 2.6 Sample PID cascade loop configuration
- 48 -
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.
l Control network capacity

l C200/C200E configuration options
l C200/C200E Redundancy
l C200/C200E communication performance
l C200E Whole Array Transfer Performance
l C200/C200E processing resources
l C200/C200E Memory Resources and Block Configuration
l C300 configuration options
l C300 Redundancy
l C300 communication performance
l C300 processing resources
l C300 Memory Resources
l ACE configuration options
l ACE communication performance
l ACE processing resources
l ACE Memory Resources
2.2.1 Control network capacity

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

FTE CIP Ethernet ControlNet
(See Notes 4 to 8) (See Notes 9 to 11)
Supervisory 1 redundant network 1 non-redundant 1 redundant or non-
Networks per serviced by 1 or more network serviced by 1 redundant network
Experion Server redundant or non- redundant or non- serviced by 1 redundant
redundant Experion redundant Experion or non-redundant
server Experion Server
s up to the maximum
FTE Nodes allowed
per FTE Community.
(See Note 1)
ControlNet N/A N/A 127

Connection Limit
per PCIC
Maximum Number 330 FTE nodes per 12 32

of Nodes allowed FTE community
(See Note 2)
Controllers per Up to 20 Redundant Up to 10 Non- Up to 10 Redundant or

Server or Non-Redundant in Redundant only Non-Redundant in any
any combination combination
(See Note 3)
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
- 50 -
Topic Network Media and Limits

FTE CIP Ethernet ControlNet
(See Notes 4 to 8) (See Notes 9 to 11)
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 1

Chassis
Base Execution Periods Supported l C200: 50 ms, 5 ms*

(*Requires different firmware personality.)
l C200E: 50 ms
Loaded Controller Personality-> 5 ms CEE 50 ms CEE
Redundancy Supported No Yes
Remote I/O Supported No Yes
- 51 -
I/O Module Execution Period 5 ms 50 ms
Configurable Values for CM/SCM 5, 10, 20, 50, 100, 200 50, 100, 200, 500, 1000,
Execution Periods ms. 2000 ms.
Configurable Values of Peer Update 10, 20, 50, 100, 200, 500, 100, 200, 500, 1000 ms.
Rates (period). 1000 ms.
(See Note)
(Defines the period at which data is
updated for all 'pull/get' 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,

introduced in a redundant chassis pair) C100 CPM, TC-CEN021 Ethernet Module,
DHRIO, DeviceNet Module
Control Processing Switchover Interruption 500 ms

Time
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 l C200: 90 sec

Completion)
l C200E: 300 sec
Maximum Elapsed Time Between Commanded l C200: 150 sec

Switchover and Completion of Initial
Synchronization l C200E: 400 sec
Maximum Elapsed Time Between Switchover l C200: 200 sec

Due to Power Cycle of the Primary and
Completion of Initial Synchronization l C200E: 400 sec
Maximum OPM Control Freeze time l C200: 10 seconds

l C200E: 20 seconds
- 52 -
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 2000 PPS 2000 PPS
Rate 9
(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.
Display Data Access Capacity 5 ms CEE 50 ms CEE
Maximum Total Subscribed Parameters per 2000 2000

C200/C200E
(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. 1500 PPM Write 1500 PPM Write
Greater than 10 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 500 PPS 500 PPS
target nodes (incoming data)10
Maximum Target Response Rate to Pull/Get 500 PPS 500 PPS

Requests from all initiator nodes (outgoing
data)9,11
Peer-to-Peer Subscription Capacity / ControlNet or ControlNet or FTE3

FTE3
Update Rate
Maximum C200/C200E peer capacity per 5 @ 10 ms 50 @ 100 ms

update rate 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
- 53 -

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 50 PPS 50 PPS

nodes2
Maximum Response Rate to Push/Store 50 PPS 50 PPS

Requests from all 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 (Includes total of (Includes total of other
initiate a peer connection with other ACEs, ACEs, SIM-ACEs,
C200/C200Es, C200/C200Es, C300s,
C300s, SIM- LIOMs, SIM-C200Es, SIM-
C200Es and/or C300s, IOLIMs and/or
SIM-C300s) 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 8 8

REQUEST blocks per CEE/CPM6,7,8
- 54 -

Maximum Number of Remote Initiating Devices 8 8
for 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 capacityfor 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 500 EPS
initiator nodes)
Whole Array Capacity
Maximum Array Size for Whole Array Transfer 400bytes

(50-
floats)
- 55 -
Overall Controller Whole Array Transfer Performance 50 ms

CEE
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.
Minimum Reserved CPU to be 20%

Maintained During Runtime
(CPUFREEAVG)
CEE/CPM Configuration PU Maximum1 Maximum Cycle Loading2
50 ms CEE - Non-Redundant 3600 PU/sec 60%

Configuration
50 ms CEE - Redundant 1600 PU/sec 60%

Configuration
5 ms CEE - (Non-Redundant 2400 PU/sec 40%

only)
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.
- 56 -
Maximum Available C200/C200E CEE Memory Resources l C200: 4000

MU
l C200E:
16000 MU
Maximum Total Number of CMs, SCMs and IOMs Configurable per l C200: 1000
C200/C200E CEE
l 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
ATTENTION
C200 / C200E will continue to support a maximum of 10 parallel paths only, against a
maximum of 15 parallel paths supported by C300, SIM_C300, ACE and SIM_ACE.
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 Between 1 and

255 255
IOTA Size 6 inches 6 inches
Number of I/O Links Supported 2 2
I/O Link Speeds Available 375 Kbaud (PM 750 Kbaud (Series
I/O Link) 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 No

Series A I/O
I/O Module Execution Period 50 ms 20ms
Configurable Values for CM/SCM Execution Periods 50, 100, 200, 20, 40, 80, 200,
500ms, 1s, 2s. 400, 800ms.
Configurable Values of Peer Update Rates (period). 100, 200, 500, 100, 200, 500,
1000 ms 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
- 57 -
Configuration Options 50mSec CEE 20mSec CEE

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 50mSec CEE 20mSec CEE

Redundancy
C300 Function Block Redundancy “Module is Redundant” “Module is Redundant”
Configuration Selection:
Number of IOTAs used for 2 2

Redundant C300
Redundant Device Index Redundant Controller pairs Redundant Controller pairs

Configuration must have Device Index must have Device Index
values of n and n + 1, where values of n and n + 1, where
n is an odd value n is an 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 240 seconds 200 seconds

Sync 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.
- 58 -
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.
Overall Data Access Performance 50mSec CEE 20mSec CEE

Maximum Total Parameter Access 2500 PPS 700 PPS
Response Rate
(Includes all Server Data Requests,
Console Station Data Requests, and peer
communications including other ACEs,
C200s, C300s, and FIMs)
Overall Array Transfer Response 50mSec CEE 20mSec CEE

Performance
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 4000 1000

per C300
(Includes all Server Data Requests +
Console Station Data Requests)
Request/Response Data Access 50mSec CEE 20mSec CEE

Performance
Max Request/Response Parameter 3000 PPM Read

Access Rate
1500 PPM Write
(Includes all Slow Server Data Requests,
e.g. Greater than 10 sec OPC data, Slow
History, Data Writes, etc.)
Peer-to-Peer Performance 50mSec CEE 20mSec CEE
Maximum Initiator Pull/Get Request Rate 1000 PPS 250 PPS

to all target nodes (incoming data)7
Maximum Target Response Rate to 1000 PPS 250 PPS

Pull/Get Requests from all initiator nodes
(outgoing data)8
Peer-to-Peer Subscription Rates/ 50mSec CEE 20mSec CEE

Update Rate
Maximum C300 peer capacity per update 50 @ 100 ms 5@20 msec

rate choices1
100 @ 200 ms
250 @ 500 ms
500 @ 1 sec
Push/Store Request Performance 50mSec CEE 20mSec CEE
Maximum Push/Store Request Rate to all 50 PPS 12 PPS
- 59 -

target nodes
Maximum Response Rate to Push/Store 50 PPS 12 PPS

Requests from all initiator nodes
Peer-Peer Whole Array Transfer 50mSec CEE 20mSec CEE

Performance
Max Initiator Whole Array Request Rate 2500 EPS 625 EPS
(to all peers)
Max Target Node Response Rate to Whole 1500 EPS 375 EPS
Array Pull/Get Requests
(from all initiator nodes)
Initiator Whole Array Push/Store Rate 1000 EPS 250 EPS
Target Node Whole Array Response Rate 1000 EPS 250 EPS
to Push/Store Requests
(from all initiator nodes)
Peer-to-Peer Capacity 50mSec CEE 20mSec CEE
Peer Connection Units (PCUs) 30 3 (Includes total of other

ACEs, C200s, C300s,
(*Number of remote CEEs that this C300 (Includes total of other and/or Primary FIMs)
can initiate a peer 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 32 Not Applicable

per C300
Maximum Number of RESPONSE blocks 32 Not Applicable

per C300
Maximum Number of Target Devices for 8 Not Applicable

REQUEST blocks per C300 4
Maximum Number of Remote Initiating 8 Not Applicable

Devices for RESPONSE block data per
C300
PCDI Capacity and Performance 50mSec CEE 20mSec CEE
Maximum Number of Modbus TCP 8 3

devices
(represented by PCDI Master blocks)
Maximum Number of Serial Modbus 16 3

Devices per Gateway
Maximum Number of Serial Modbus 128 3

Devices per C300
Maximum Number of PCDI Request 64 8

blocks assigned to a PCDI Master block
Maximum Number of PCDI Request block 512 6

messages per second - includes both
Read and Write 6
(maximum size 256 byte messages
- 60 -

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
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 amount of computational (control) work.
For Maximum Cycle Loading, over a cycle (0-39), the “Average CPU Used” (CPUCYCLEAVG)
50mSec 20mSec CEE

CEE
Minimum Reserved CPU to be Maintained During 20% Greater than or
Runtime (CPUFREEAVG) 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.
- 61 -
50mSec 20mSec
CEE CEE
Maximum Available C300 CEE Memory Resources 16000 MU 16000 MU
Maximum Total Number of CMs, SCMs, and IOMs Configurable 4095 4095
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 SCM 15 Not

simultaneously applicable.
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.
- 62 -
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 1500 PPM Write
than 10 sec OPC data, Slow History, Data Writes, etc.)
Peer-to-Peer Performance 500 ms CEE
Maximum Initiator Pull/Get Request Rate to all target 1000 PPS

nodes (incoming data)4
Maximum Target Response Rate to Pull/Get Requests 1000 PPS

from all initiator nodes (outgoing 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 50 PPS

all initiator nodes
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
- 63 -
Overall Data Access Performance 500 ms CEE

(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)
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
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 amount of computational (control) work.
For Maximum Cycle Loading, over a cycle (0-39), the “Average CPU Used” (CPUCYCLEAVG)
Minimum Reserved CPU to be Maintained During Runtime 40%

(CPUFREEAVG)
(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 60%

PU/sec
2.2.16 ACE Memory Resources

The following table lists the memory units and block capacities for an ACE Controller. The memory
- 64 -
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 15
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.
l C200/C200E IO capacity
l C300 IO capacity
l IO Unit load factors
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 0 8

+ Remote Mixed Chassis + Rail Adapters (combined)
perC200/C200E3,4,5 (Local I/O Only)
Maximum Number of IO UNITS that can be 0 24

assigned per Downlink CNI1
(Local I/O Only)
Maximum Number of Downlink CNIs per 0 4

C200/C200EController Chassis
(Local I/O Only)
Maximum number of Allen Bradley variable speed 0 64

drives supported per Controller.
(Local I/O Only) (Limited to 20 per
This function requires the optional control library isolated downlink
TCABDL01 CNI)
- 65 -

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 Not supported 2

CEE/CPM
Maximum Number of DHRIO Modules per 2 2

CEE/CPM
(Local I/O Only)
Serial Interface Related Only
Maximum Number of Serial Interface Modules per 1 3

CEE/CPM
Maximum Number of FTA assemblies per Serial 2 2

Interface Module 7
Fieldbus Interface Related Only
Maximum number FF non-redundant Series A Not Supported 21

FIMs per CEE/C200/C200E8
Maximum number of Redundant Series A FIMs per Not Supported 12

C200/C200E9
Maximum number of Series C FIMs per Not Supported Not Supported

C200/C200E
PROFIBUS Related Only
Maximum number of PROFIBUS function block 2 10

modules per CPM
Maximum number of PROFIBUS function block Not Supported 4 @ 25 ms

modules per downlink CNI
2 @ 12.5 ms
(based on update rate, 25ms default)
DeviceNet Bridge Related Only
Maximum number of DeviceNet Bridge modules 2 32

per CPM
- 66 -

Maximum number of DeviceNet Bridge modules Not Supported 12
per downlink CNI
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 …
l One non-redundant or redundant PM IOP = 1 I/O Unit.

l The number of I/O Units assigned to any given Series A I/O device is specified for that
device.
l One non-redundant or redundant Series A Fieldbus Interface Module = 2 I/O Units.
l 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 64 12
C300 1,2
80 (if using PM IOPs
1. See the IO Unit load factors below only)
for details.
2. Specific IO Devices may be further
limited as described below.
Maximum Number of IOMs having Scan Not applicable. 4 modules

Rate as “Priority IOM” Per IOLINK Of
C300”
SERIES A I/O-RELATED ONLY
Maximum Number of Series A I/O 83 Not Supported

Chassis connected through FTEB per
C300
- 67 -
Function 50mSec CEE 20mSec CEE

Maximum Number of IO UNITS per 16 Not Supported
Series A I/O Chassis/FTEB
Supported Series A I/O modules: Not Supported

l Serial Interface Module
l DeviceNet interface Module
l Profibus Module
l Pulse Input Module1
Maximum Number of Serial Interface 3 Not Supported

Modules per C300
Maximum Number of Serial Interface 1 Not Supported

Modules per FTEB
Maximum Number of DeviceNet Modules 8 Not Supported

per C300
Maximum Number of DeviceNet Modules 4 Not Supported

per FTEB
Maximum Number of Profibus Modules 8 Not Supported

per C300
Maximum Number of Profibus Modules 4 Not Supported

per FTEB
Series C FIM Relate Only
Maximum number of Redundant or Non- 15 Not Supported

Redundant Series C FIMs per C300 4
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.
- 68 -
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 8 for C300
Units, respectively.
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)
- 69 -
I/O Device or Module IO Units

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 1 (for 24 Unit/CNI

network Limit)
2.4 Function Block Execution Schedules
l Schedule consideration differences

l Control Module and Sequential Control Module FBs schedule
l CM Component Function Block scheduling
l IOM FB schedule
l CPM, ACE, and CEE FBs schedule
l Cycle overruns
2.4.1 Schedule consideration differences

The CEE execution schedule considerations differ for each of the following Function Block types.
l Control Module and Sequential Control Module FBs(Container FB)
l Component FB
l IOM FB (Self-Standing FB)
l 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.
- 70 -
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.
Figure 2.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.
- 71 -
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
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
- 72 -
If Period in milliseconds is. . . And Phase is . . . Then, cycles of execution are. . .

5 ms CEE 50 ms CEE
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.
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.
- 73 -
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.
- 74 -
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.
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].
- 75 -
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.
l Unbalanced loading across the execution cycle.
l Loaded configuration is too large.
l Combination of block and communication processing is too large for a particular 50-
l ACE running instances of CAB types with string or time Value Custom Data Parameters that
- 76 -
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.

l Completes execution of all blocks on the current cycle.
l Delays execution of the waiting cycle until the start of the next 50 millisecond time interval.
l 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 CEE reports alarm if . . . CEE clears alarm if . . .

is . . .
CPM (50 ms two consecutive intervals of 2000 four consecutive intervals of 2000
BASEPERIOD) milliseconds have at least one cycle milliseconds have no cycle overruns.
overrun.
ACE (500 ms two consecutive intervals of 20 seconds four consecutive intervals of 20

BASEPERIOD) have at least one cycle overrun. seconds 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.
2.5 Block Configuration Load Considerations

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

The major data categories found in the CEE FB are summarized below.
- 77 -
Data Description
Category
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 Data that does not change frequently enough to be considered “Live” data. It
Constant 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.
l CEEFB. CEESTATE
l CMFB.EXECSTATE
l SCMFB.STATE
l IOMFB.EXECSTATE
The following table summarizes the state parameter status versus FB load permissions.
If status is . . . Then, you can load . . .

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

execution state is Inactive.
l IOMFB.EXECSTA
TE = Inactive
- 78 -
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 Description
Category
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 The load of a block is being stopped. (Note that the load of other container blocks
Error 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.)
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
- 79 -
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:
l RAIL_IO_HAZ = 125 MU
l RAIL IO = 125 MU
l EXCHANGE = 70 MU
l PLUSEINPUT = 100 MU
l FBUSIF = 90 MU
l C200/C200ECEE Processing and Memory Models

l C300 CEE Processing and Memory Models
l ACE CEE Processing and Memory Models
2.6.1 C200/C200ECEE Processing and Memory Models
Typical Module Types Processing Resource Memory

Consumption1 Resource
(FB Content in Parenthesis)
Usage
(Per Module)
(See the
ATTENTION
note above.)
50/5 ms CEE 50 ms CEE 50/5 ms
CEE
Non-Redundant Redundant
(MU/Mod)
(PU/Module (PU/Module
Execution) Execution)
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)
- 80 -

Usage
(Per Module)
(See the
ATTENTION
note above.)
CEE
(MU/Mod)
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)
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
Transitions
Sequence Control Module with an alias 2.0 3.0 128.5

table size of 45 rows by 100 columns
10 Transitions with 5 Conditions each
interspersed in all the handlers, 10
Sequence Control Module with an alias 2.0 3.0 124.5

table size of 500 rows by 9 columns
- 81 -

Usage
(Per Module)
(See the
ATTENTION
note above.)
CEE
(MU/Mod)
10 Transitions with 5 Conditions each
interspersed in all the handlers, 10
Medium sized CDB Module (CM with 1 0 0 1.5 (Note 2)

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 character STRING;
4 scalar FLOAT64;
4 scalar BOOLEAN;
1 20 element FLOAT64 array;
1 20 element BOOLEAN array.)
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
- 82 -

Usage
(Per Module)
(See the
ATTENTION
note above.)
CEE
(MU/Mod)
PBUSIF 244 MU
PULSEINPUT 90 MU
RAIL_IO 120 MU
RAIL_IO_HAZ 107 MU
2.6.2 C300 CEE Processing and Memory Models
Typical Module Types Processing Memory

Resource Resource
Consumption Usage
1
(Per Module)
50 ms C300 50 ms C300
(PU/Module (MU/Module)
Execution)
Typical I/O Module 0.2 0.5
(Average consumption of available IOMs)
Analog Digital Acquisition Module 4.4 7.2

Small Analog Data Acquisition Module 0.5 1.0

Regulatory Control Module 3.1 3.8

(1 AI, 1 DataAcq, 1 PID, 1 AO, 6 Logic FBs)
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)
- 83 -

Resource Resource
Consumption Usage
1
(Per Module)
50 ms C300 50 ms C300
Execution)
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
SCM has total of 10 Steps and 10 Transitions among the 4
Handlers
Sequence Control Module B 2.6 18.8

(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 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 rows 5.0 156.3
by 9 columns
items)
Handlers
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.)
- 84 -

Resource Resource
Consumption Usage
1
(Per Module)
50 ms C300 50 ms C300
Execution)
The RCM executes 5 Phases in parallel.
Recipe Control Module B 2.8 19.3

each.)
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.
- 85 -
Typical Module Types Processing Resource Memory Resource

Consumption1 Usage
(Per Module)
20 ms C300 20 ms C300
Execution)
Typical I/O Module Not Applicable 0.5
(Average consumption of available
IOMs)
Analog Digital Acquisition Module Not Applicable 7.2

Small Analog Data Acquisition Module Not Applicable 1.0

Regulatory Control Module Not Applicable 3.8
(1 AI, 1 DataAcq, 1 PID, 1 AO, 6 Logic

FBs)
Auxiliary Function Module Not Applicable 6.2

(10 Aux. FBs, such as AuxCalc,
Totalizer)
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
- 86 -
Typical Module Types Processing Resource Memory Resource

Consumption1 Usage
(Per Module)
20 ms C300 20 ms C300
Execution)
Servo Valve Positioner Module Not Applicable
NOTES:
2.6.3 ACE CEE Processing and Memory Models

Resource Resource
Consumption Usage
1
(Per Module)
500ms ACE 500ms ACE
CEE CEE
(PU/Module
Execution) (MU/Module)
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)
- 87 -

Resource Resource
Consumption Usage
1
(Per Module)
500ms ACE 500ms ACE
CEE CEE
(PU/Module
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
Handlers
Sequence Control Module B 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 of size 45 rows 3.0 128.5
by 100 columns

items)
Handlers
Sequence Control Module with an alias table of size 500 rows 3.0 124.5
by 9 columns
items)
Handlers
Recipe Control Module A 0.7 10.5

each.)
- 88 -

Resource Resource
Consumption Usage
1
(Per Module)
500ms ACE 500ms ACE
CEE CEE
(PU/Module
Recipe Control Module B 2.7 19.3
each.)
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
2.7.1 CPU load categories

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

(bytes) (bytes) (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
- 90 -

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
- 91 -

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
NAND 44 36 44
NE 80 72 80
NEG 48 40 48
NOON 100 92 100
NOR 44 36 44
NOT 36 28 36
- 92 -

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
- 93 -

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
- 94 -
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
- 95 -
Block Name Size (Bytes) Block Name Size (Bytes)

PICFCFB 136
TOTALIZER 204
- 96 -
CHAPTER
3 CONTROL MODULE INDEPENDENCE
l Module Independence for Flexible Modification

l CM Independence and Hypothetical Controller Comparison
l CEE Architecture
l Validation of Control Module Independence
l Resource Coupling Across Different Platforms
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 ExperionC200/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.
l Hypothetical controller structure
l Coupling effects in hypothetical controller
3.2.1 Hypothetical controller structure

For comparison purposes, consider a controller design with a software architecture that is broadly
- 97 -
Chapter 3 - Control Module Independence
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.
- 98 -
Type of Comparison Consideration

Coupling
Execution The hypothetical controller does not regulate the execution period of the
Timing 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.
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 A form of coupling exists between different control strategies in any case
Utilization 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.
- 99 -

Coupling
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
Bandwidth communication bandwidth. Similarly data transfer between control strategies
Utilization 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
l CEE controller structure
l Program and Data Partitioning
l Native program and custom program partitioning
l Regulated Base Cycle
l Coupling effects in CEE-based controller
3.3.1 CEE controller structure

The following illustration gives a high level view of the software layers in a controller hosting a
CEE.
- 100 -
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.
l Partitioning between program and data set
l 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.
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.
- 101 -
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.
l PHASE blocks
l Custom Algorithm Blocks (CAB)
l 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.
- 102 -

Coupling
Execution No coupling
Timing
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 Modules are coupled in the sense that they all use memory from a common
Utilization 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
- 103 -

Coupling
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.
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
Bandwidth for data transfer. Types of data transfer include: communication with IO
Utilization 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
- 104 -

Coupling
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.
- 105 -
Type of Test Consideration

Coupling
Execution Tested that execution timing of a particular module is independent of any
Timing 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 Explicit testing has been done on the behavior of the controller when module
Utilization 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
Bandwidth handled by each of the communication channels used at run time by a CEE-
Utilization based controller. The capacities are consistent with published Experion
specifications.
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.
- 106 -
Category Description
Programmatic These are dependencies which arise from the fact that algorithms are
Coupling 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 Other dependencies are less direct but can arise from the fact that control
Coupling 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.
- 107 -
CHAPTER
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.
l About Relative References
l Relative References structure rules
l Display options for relative references
l Control Builder functions supporting relative references
l Control Builder blocks supporting expressions
l Example of TRANSITION block using relative references
l Example of parameter connector using relative references
l Example of other parameters using relative references
l Bulk Builder and Bulk Editor support
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.
l A parameter reference on any block could refer to another parameter on the same block.
l A parameter reference on a container block could refer to a parameter of a contained basic
block.
l A parameter reference on a basic block could refer to a parameter on its container.
l 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.
- 108 -
Chapter 4 - Relative References
Reference Is Parameter to be Referenced Is Owned By

Owned By Same Block Tagged Basic Container with Same Other basic
Block same param Container block within
name as a container
basic block
Basic Block param $.tag.param $. param param or block. param

or tag.param $.param or
$.block.param
Tagged Basic param FULLNAME $.param Param or block. param

Block (Hart $.param or
enabled channel $.block.param
blocks)1
Tagged Block param or FULLNAME FULLNAME FULLNAME FULLNAME

$.param
Container Block param or $.tag.param FULLNAME param or block. param

$.param or tag.param $.param or
$.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.
l How relative reference matching function works
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.
- 109 -
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.
- 110 -
Reference Is Parameter to
Owned By be
Referenced
Is Owned By
Same Block Tagged Basic Container with Same Other basic
Block same param Container block within
name that a container
basic block has
Basic Block param FULLNAME $. param $. param block.

param
Tagged Basic param FULLNAME $. param $. param block.

Block (Hart param
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.
l How short name display option works
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.
- 111 -
4.4 Control Builder functions supporting relative references

The following Control Builder functions support the entry of parameters as relative references.
l Expressions
l Parameter Connectors
l 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.
4.5 Control Builder blocks supporting expressions

The following blocks support the use of expressions and the entry of parameters as relative
references.
l AUXCALC
l ENHAUXCALC
l ENHREGCALC
l REGCALC
l STEP
l 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
- 112 -
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.
l example_scm.COMMAND=3
l COMMAND=3
The following example illustrations show how expressions would appear with Short Name as the
selected Relative Reference Display Option.
l A container reference from a chart
l A reference to a parameter on the same block from a form
l A reference to a parameter on a different block in the same CM
l Expression display interaction
4.6.1 A container reference from a chart
4.6.2 A reference to a parameter on the same block from a form
4.6.3 A reference to a parameter on a different block in the same CM
- 113 -
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.
l A reference to a parameter on a different block in the same CM
l Parameter connector display interaction
4.7.1 A reference to a parameter on a different block in the same CM
- 114 -
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.
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.
l History, trend and group parameters that are defined on TAGGED blocks:
o GROUP.PARAM
o HIST.GATEPARAM
o HIST.PARAM
o TREND.PARAM
l Parameters on the STEP block related to procedural operations:

o CURRVALREF
o MONTASKREF
o OP[].CURRVALREF
o OP[].ENTRYVALREF
o OP[].MONTASKREF
o OP[].TARGETVALREF
l Parameters on the SCM and RCM associated with the alias table:
o ALIASREF
- 115 -
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.
l A reference to a parameter on a basic block of the CM
l Other parameters display interaction
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.
4.9 Bulk Builder and Bulk Editor support

The Bulk Builder and Bulk Editor do not support entry or display of shorthand relative references.
- 116 -
CHAPTER
5 PEER-TO-PEER FUNCTIONALITY
l Basic Peer-to-Peer Design Concepts

l Initiator Rate - Calculation
l Implications for Control Builder Configuration
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.
- 117 -
Chapter 5 - Peer-to-Peer Functionality
l Data flow models

l Peer environments and subscription periods
l Software Architecture for CPM/CEE
l A word about ACE/CEE architecture
l Peer-to-peer communication between CEE and non-CEE points
l Peer-to-peer communication between ACE/C300 and EHPM points
l Guidelines for configuring peer-to-peer communication between CEE and non-CEE points
l Renaming non-CEE point/data type change consideration in configuration
l Designing control strategy for failsafe control
l Runtime peer-to-peer behavior between CEE and non-CEE point
l Runtime peer-to-peer behavior between CEE and Experion Server points
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.
- 118 -
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.
- 119 -
Figure 5.1 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.
- 120 -
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.
l Parameter connector
l SCM expression
l SCM Alias Table
l CAB parameter references
l PHASE block parameter reference using Formula Parameter and Report Parameters
l Expressions in the AUXCALC, ENHAUXCALC, REGCALC, and ENHREGCALC blocks
ATTENTION
l Peer-to-peer communication is not supported between the non-CEE points and the
following:
o C300-20msCEE
o Fieldbus blocks
o PMIO and Series C I/O blocks
o 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
- 121 -
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.
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.
l 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.
l 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 ().
l The format for configuring the TPS points must be as follows:
<point name>.<parameter name>(<array index1>,<array index2>)
l 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.
l For TPS points, only alphanumeric characters and the following special characters can be
used while configuring the expressions.
- 122 -
o Underscore (_)
o At sign (@)
o Dollar sign ($)
ATTENTION
l Whole array peer-to-peer communication is not supported between CEE and non-
CEE points.
l CAB on ACE dynamic re-referencing is not supported for non-CEE peer-to-peer
references.
l You cannot configure non-CEE points in the Server History and Trend configuration
of CM in Control Builder
l 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.
l The following parameters of the SCM-STEP block cannot be configured for peer-to-
peer communication with the non-CEE points.
o OP[].INSTRUCTTYPE
o OP[].CURRVALREF
o OP[].ENTRYVALREF
o OP[].MONTASKREF
o OP[].TARGETVALREF
o OP[].TARGETDESCREF
o OP[].TARGETMAXREF
o OP[].TARGETMINREF
o OP[].TARGETEUDESCREF
o OP[].CURRDESCREF
o OP[].CURREUDESCREF
o OP[].ENTRYDESCREF
o OP[].ENTRYMAXREF
o OP[].ENTRYMINREF
o OP[].ENTRYEUDESCREF
Before configuring a peer-to-peer reference in the Control Builder to an Experion Server point,
you must ensure the following:
l The point to which the peer-to-peer communication is being configured must exist in the
Experion Server database.
l 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.
l 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.
l TPS points must be primed before referencing it for peer-to-peer communication.
l Array parameter of the TPS point must be configured before configuring the peer-to-peer
- 123 -
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.
l 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.
l 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.
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:
l 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
- 124 -
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.
- 125 -
ATTENTION
l 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.
l 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.
l 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.
l 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.
- 126 -
l Hold the previous good value until the non-CEE point parameter returns from control failsafe
to good values again.
l 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.
- 127 -
Data Example Point Cont Detecting Failsafe value

Type Parameter rol
Fails
afe
valu
e
SCADA ANA01.PV NaN Two different Function blocks could be used ,
Floating depending on control strategy needs as illustrated.
point
(FLOAT6 l Using CHECKBAD Function block
4)
l Using DATA ACQUISITION Function block
TPS TPS_REG001.PV NaN

Floating
Point
(FLOAT3
2)
SCADA ANA01.MODE Enu

/TPS m0
STA01.PV
Enumer
ation TPS_ALM.MODE
(ENUM)
TPS TPS_ Enu

Boolean FLG001.OFFNRMAL m0
(BOOLE
AN)
- 128 -
Data Example Point Cont Detecting Failsafe value

Type Parameter rol
Fails
afe
valu
e
SCADA ANA01.INALM 0
/TPS STA01.NumberOfInp
Integer utStates TPS_
(INT16) 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 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.
- 129 -
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.
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.
- 130 -
Other runtime considerations
l 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.
l 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.
l If the point exists and the non-CEE parameter is invalid, question mark is displayed as
“point?parameter” only in Expressions.
l 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.
l ICYCSMREQUSEDCONN[0-29] - Number of cyclic small requests per connection

l ICYCLGREQUSEDCONN[0-29] - Number of cyclic large requests per connection
l NUMCCLRQU parameter - Total number of cyclic parameter requests (initiator requests) for all
connections.
l 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.
l Configuration without peer environment table
l Configuration with 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
- 131 -
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.
Initiator Rate for the connection x1 =
3.
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.
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.
Initiator Rate for the connection y1 =
8.
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.
- 132 -
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.
- 133 -
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.
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.
l Multiple CPMs and ACEs

l CEE execution and subscription rates
l Function block support
l Peer-to-peer connections and DEF and REF blocks
l Peer-to-peer configuration example
l Peer-to-peer configuration guidelines
l Example to illustrate peer-to-peer configuration for non-CEE points
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
- 134 -
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 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 Then, It Can Be Used With This Control
in Control Builder . . . 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
ACE/CEE
CPM/CEE
ACE/CEE
CPM/CEE
CPM/CEE
CPM/CEE
CPM/CEE
- 135 -
If Function Block Is From This Library Then, It Can Be Used With This Control
in Control Builder . . . Environment . . .
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
- 136 -
configuration that uses a REMCAS block to form a cascade control loop with remote and local
primary loops.
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 5.2 View A - Remote Primary Control Loop
- 137 -
Figure 5.3 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.
- 138 -
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.
l Assign CMs with I/O Channel blocks and their associated IOM blocks to the same CEE.
l Assign CM containing ultimate secondary control block and CM containing its output channel
and IOM blocks to the same CEE.
l Assign CM containing data acquisition or regulatory control block and CM containing its input
channel and IOM blocks to the same CEE.
l Do not assign IOM blocks to multiple CEEs. Use peer-to-peer communications to share input
channel values among CMs in multiple CEEs.
l 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.
l 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.
l 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.
l 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.
l You can add CMs with REF block relationships to CEEs online at any time.
l Control Modules can contain any number of parameter references as well as any mix of intra-
CEE and inter-CEE (peer-to-peer) references.
l 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
- 139 -
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.
- 140 -
CHAPTER
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
l Local Time = UTC + bias
l Date and Time Synchronization

l C300 and Series C Fieldbus Interface Module Time Synchronization
l Time Configuration Considerations
l Examples of Time Usage in CAB and SCM
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
- 141 -
Chapter 6 - Time Support in Experion System
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 Comments
Source
CDA Time is provided by the first Windows Server/Station that makes a data connection.
Time 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.
l BOOTP Mechanism and Multiple Clusters
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 ExperionR300 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.
6.3 Time Configuration Considerations

Experion supports three time data types in CEE Blocks which encode values of time:
l TIME encodes absolute time
l TIMEOFDAY encodes time of day
l DELTATIME encodes time differences
l Time Data Types in Control Execution Environment (CEE) Blocks
- 142 -
l Time Data Types in User Algorithms and Displays

l C200/C200E, Application Control Environment (ACE) Time Parameters
l Custom Algorithm Block (CAB) on ACE Time Functions
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.
l 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.
l 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.
l 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.
- 143 -
l 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.
l 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.
l 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.
l Time zone is irrelevant to the display of DELTATIME parameters.
l 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
- 144 -
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 is Settings ‘local

set to GMT -05:00 Eastern Time HOUR’ for
use
(US & Canada)
Current time (CURTIME) = 11/02/2003 08:54:00 TIMEZONE = 0 HOUR will be
13
DAYLIGHTTIME
= OFF
Current time (CURTIME) = 06/12/2003 13:54:00 TIMEZONE = -5 HOUR will be

17
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.
- 145 -
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
l Example - Custom Algorithm Block (CAB) writes Time CDP

l Example - Custom Algorithm Block (CAB) reads Time CDP
l 6.4.3 Example - Sequence Control Module (SCM) waits for a specified Time
l Example - Sequence Control Module (SCM) records Time of process command
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
- 146 -
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.)
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.)
- 147 -
CHAPTER
7 COLD AND WARM RESTART FUNCTIONALITY
l Overview
l Planning
l Configuration of Restart Behaviors
l Warm and Cold Restart Behaviors of Cascades
l Operations
7.1 Overview
l CEE Initial Startup

l CEE Restarts
l CEE Restart Behaviors
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:
l Cold Restart initiated on transition of CEESTATE from idle to run occurs
o After the CEE FB has just been created and the initial configuration is loaded.
o 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.
- 148 -
Chapter 7 - Cold and Warm Restart Functionality
l 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:
l 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.
l 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.
l 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.
l 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.
7.2 Planning
l Invariant or Variant Restart Behaviors

l Blocks with Invariant Restart Behavior
l Blocks with Variant Restart Behavior
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.
- 149 -
l Blocks which perform the same start up initialization regardless of the type of restart in
progress
l 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.
l 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.
l 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.
l 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.
l 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.
- 150 -
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.
l 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 7.1 Special Case Blocks with Invariant Restarts
# Library Block Summary Description
Type
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.
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 CEE and CAB infrastructure leave values of all custom
Libraries Algorithm parameters unchanged across all restarts.
Created By Block Types
End Users> (CAB Types) User-implemented CAB algorithms may detect restarts and either
- 151 -
# Library Block Summary Description

Type
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.
# Library Block Type Summary Description

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.
- 152 -
# Library Block Type Summary Description

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
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
Control Module (CM) Control Module (CM)
Control Module Function Blocks Control Module Function Blocks
Sequential Control Module (SCM) Sequential Control Module (SCM)
Regulatory Cascades Regulatory Cascades
- 153 -
Topic For more information

UCNIF:UCNOUT Cascades through UCNIF: UCNOUT/EUCNOUT
Logic Block Logic Blocks
l CEE Block
l Control Module (CM)
l Control Module Function Blocks
l Logic Blocks
l Sequential Control Module (SCM)
l Summary Of SCM Restart Behavior
l Supporting SCM Functionalities
l SCM Blocks
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.
l On Warm restart, the CEE FB reports the idle to run state change event occurred with a warm
restart.
l 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 Configuration Options
Parameter
CEESTARTOPT l ALWAYSCOLD (default)
(Access Lock = For this configuration parent control modules instruct their component
ENGR) blocks to do a cold restart regardless of which restart option has been
selected for the CEE as a whole.
l 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.
l 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
- 154 -
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 Cold Restart Handling

Handling
EQA Stop accumulation while Continue after input Set PV to bad and stop
input is bad. turns valid. accumulation.
(default)
EQB Use last good value if input Continue after input Set PV to bad and stop
is bad. turns valid. accumulation.
EQC Stop if the input is bad and Continue after input Set PV to bad and stop
set PV to NaN. turns valid. accumulation.
EQD Stop accumulation while Set PV to bad and stop Set PV to bad and stop
input is bad. accumulation. accumulation.
EQE Use last good value if input Set PV to bad and stop Set PV to bad and stop
is bad. accumulation. accumulation.
EQF Stop if the input is bad and Set PV to bad and stop Set PV to bad and stop
set PV to NaN. accumulation. 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. 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.
- 155 -
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:
l NONE - normally shown.
l CMLOAD - Holds CMLOADFL true for the first execution cycle following a
load of the parent control module.
l CMACTIVE - Holds CMACTIVEFL true for the first execution cycle following
inactivation and then activation of the parent control module.
l CEECOLD -Holds CEECOLDFL true for the first execution cycle following cold
start of the CEE.
l CEEWARM -Holds CEEWARMFL true for the first execution cycle following
warm start of the CEE.
l CEESWITCH - Holds CEESWITCHFL true for the first execution cycle
following redundant switchover of the CEE on a C200/C200E.
l 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:.
l Configuration-time selection to either start at top or use a retained location indicator when CEE
restarts.
o 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.
l Run-time selection of warm or cold restart and resultant impact on SCM MODE
- 156 -
o 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.
l 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 Configuration Options

Parameter
CEESTARTOPT l ALWAYSCOLD
(Access 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.
l 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.
l 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 Configuration Options

Parameter
CEETOPTSTART l ON
(Access 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.
l OFF
When CEE restarts, the SCM starts executing a the step within the Main
handler that is indicated by the value of CEERESADDR[ ].
- 157 -
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 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 l 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.
l 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.
- 158 -
l 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 And, CEE Restart Type Is …

CEETOPSTART
Cold Warm
Is …
Then, Conditions after restart are as follows:
ON l MODE is set to Manual. l MODE is at previous value.
l SCM location counter is set to top l SCM location counter is set
of Check handler. to top of Check handler.
SCM resumes execution after the SCM resumes execution after

following actions: the following actions:
l Operator sets MODE to Auto. l If last MODE was Auto SCM

resumes without MODE
l Operator sets SCM COMMAND to
change.
Reset in order to start Check
handler l Operator sets SCM
or COMMAND to Reset in
order to start Check
the check handler starts handler
automatically if it has been
configured with a non-null invoke or
transition. the Check handler starts
automatically if it has been
configured with a non-null
invoke transition.
OFF l MODE is set Manual. l MODE is left at previous

value.
l SCM location counter is set to the
step in Main handler indicated by l SCM location counter is set
CEERESADDR[]. to the step in Main handler
indicated by CEERESADDR
SCM resumes execution after the [].
following actions:
SCM resumes execution after
l Operator sets MODE to Auto. SCM the following actions:
then continues execution, re-
sending all outputs of the active l If last MODE was Auto,
step SCM continues execution
or automatically, re-sending
all outputs of the active
operator sets COMMAND to a step.
different handler. If EXCMODEOPT
is Auto this forces MODE to Auto
and starts execution of the SCM.
7.3.7 Supporting SCM Functionalities
EXCMODEOPT
- 159 -
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 Then, Corresponding Cold Restart Behavior Is …

EXCMODEOPT
Value 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.
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.
l 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.
l 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 Then, …
Value Is …
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.
- 160 -
If RESTART Then, …
Value Is …
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:
l 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) section.
7.4 Warm and Cold Restart Behaviors of Cascades
l Definitions
l Regulatory Cascades
l CEE to CEE Cascades
l CEE to Legacy Cascade when Node hosting Primary is restarted
l CEE to EHPM FTE Cascade
l CEE to Legacy Cascade when Node hosting Secondary is restarted
l RegCtl Cascades when Node hosting the Primary is restarted
l Cascades through UCNIF: UCNOUT/EUCNOUT
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.
- 161 -
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
CEE to CEE Cascades CEE to CEE Cascades
CEE to Legacy Cascade when Node hosting CEE to CEE Cascades

Primary is restarted
CEE to Legacy Cascade when Node hosting CEE to Legacy Cascade when Node hosting
Secondary is restarted Secondary is restarted
RegCtl Cascades when Node hosting the RegCtl Cascades when Node hosting the
Primary is restarted Primary is restarted
Cascades through UCNIF:UCNOUT/EUCNOUT Cascades through UCNIF: UCNOUT/EUCNOUT
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.
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:

l the nature of the cascade relationship
l the type of node hosting the primary
l the type of node hosting the secondary
l 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.
l Warm Restart
All cascades resume processing under the mode that applied before shut down.
l 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.
- 162 -
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.
l 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.
l 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.
l 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:

l When the secondary is in Manual or Auto mode, at the conclusion of primary recovery, the
primary will be held in initialization.
l 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.
l 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.
l 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.
l 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.
- 163 -
The following table enumerates the types of events which cause each of the 4 behaviors listed
above.
Cascade Primary Cascade Event Functional

RegCtl location Secondary type Behavior of
and location Cascade
RegCtl block in ACE1 RegCtl block in ACE Shutdown and cold Recall Primary Mode
restart at primary.
RegCtl block in Shutdown and cold Recall Primary Mode

C200/C200E restart at primary.
AO block in Shutdown and cold Shed Primary Mode.

AO point under Shutdown and cold Shed Primary Mode.

C200/C200E IOLIM restart at primary.
RegCtl block in RegCtl block in ACE Shutdown and cold Recall Primary Mode
RegCtl block in Shutdown and cold Recall Primary Mode

AO block in Shutdown and cold Shed Primary Mode.

AO point under Shutdown and cold Shed Primary Mode.

C200/C200E IOLIM restart at primary.
RegCtl block in ACE1 RegCtl block in ACE Shutdown and warm Recall Primary Mode
restart at primary
RegCtl block in Shutdown and warm Recall Primary Mode

C200/C200E restart at primary
AO block in Shutdown and warm Recall Primary Mode

AO point under Shutdown and warm Recall Primary Mode

C200/C200E IOLIM restart at primary
RegCtl block in RegCtl block in ACE Shutdown and warm Recall Primary Mode
RegCtl block in Shutdown and warm Recall Primary Mode

AO block in Shutdown and warm Recall Primary Mode

AO point under Shutdown and warm Recall Primary Mode

C200/C200E IOLIM restart at primary
RegCtl block in ACE1 RegCtl block in ACE Shutdown and any Hold Primary Mode
recovery at secondary Across Secondary
Fault
RegCtl block in Shutdown and any Hold Primary Mode

C200/C200E recovery at secondary Across Secondary
Fault
AO block in Shutdown and any Shed Primary Mode

C200/C200E recovery at secondary On Secondary Fault
AO point under Shutdown and any Shed Primary Mode
- 164 -

RegCtl location Secondary type Behavior of
and location Cascade
C200/C200E IOLIM recovery at secondary On Secondary Fault
RegCtl block in RegCtl block in ACE Shutdown and any Hold Primary Mode
Fault
RegCtl block in Shutdown and any Hold Primary Mode

Fault
AO block in Shutdown and any Shed Primary Mode

C200/C200E recovery at secondary On Secondary Fault
AO point under Shutdown and any Shed Primary Mode

C200/C200E IOLIM recovery at secondary On 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.
l 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.
l 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 Cascade Secondary Event Functional

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

TPN Server restart at primary. Cascade Request
- 165 -
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 Primary Cascade Secondary Event Functional

Behavior of
Cascade
Regulatory control block in SPC cascade to regulatory Shutdown and Automatically
ACE control slot under TPN restart at TPN Resume Control
Server Server
DDC cascade to regulatory Shutdown and restart at Automatically

control slot under TPN TPN Server Resume Control
Server
SPC cascade to AO slot Shutdown and restart at Automatically

under TPN Server TPN Server Resume 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 Type of Behavior

Cascade Restart
CEE to Cold When the secondary is a regulatory control block, mode is preserved.
CEE 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- Cold Mode is preserved for all cascades. Outstanding cascade requests at
Legacy downstream secondaries are reset.
Warm Mode is preserved for all cascades. Outstanding cascade requests at

downstream secondaries are honored.
- 166 -
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 7.2 UCNOUT block: Restart functionality
Cascade Cascade Secondary Event Functional
Primary Behavior of
Cascade
Regulatory Cascade to regulatory control Shutdown and cold Clear Secondary
control block in or AO slot under TPN Server restart at primary Cascade Request
ACE
Regulatory Cascade to regulatory control Shutdown and warm Honor Secondary

control block in or AO slot under TPN Server restart at primary Cascade Request
ACE
Regulatory Cascade to regulatory control Shutdown and Automatically

control block in or AO slot under TPN Server restart at TPN Server Resume Control
ACE
Table 7.3 EUCNOUT block: Restart functionality

Secondary Behavior of
Cascade
Regulatory control Cascade to regulatory Shutdown and cold Clear Secondary
block in ACE/C300 control or AO slot in restart at primary Cascade Request1
the EHPM
Regulatory control Cascade to regulatory Shutdown and warm Honor Secondary

block in ACE/C300 control or AO slot in restart at primary Cascade Request2,3
the EHPM
Regulatory control Cascade to regulatory Shutdown and Automatically Resume

block in ACE/C300 control or AO slot in cold/warm restart at Control4,5
the EHPM the EHPM.
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.
- 167 -

Secondary Behavior of
Cascade
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 Supports Cold Supports Generic

Activation Start Idle to Run Start Idle to Run Idle to Run
Transition 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:
l “Activation” applies only to CMs, SCMs and IOMs
l “Run”, “Warm Start“ and “Cold Start“ are applied, as appropriate, to the idle to run transition of
Execution Environments
l CEE Function Block

l ACE Function Block
l CPM Function Block
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
- 168 -
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.
- 169 -
CHAPTER
8 EXTERNAL OPC SERVER SUPPORT
l OPC Data Access

l OPC Data References
l OPC Data Type Conversions
l ACE interface to TPS system as OPC server
8.1 OPC Data Access
l OPC Server function block

l OPC client/server data flow
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.
- 170 -
Chapter 8 - External OPC Server Support
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
l OPC Data Name Syntax

l Parameter connectors only
l OPC references in expressions
l OPC references in SCM Alias table
l Validation of OPC references
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
- 171 -
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.
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.
- 172 -
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.
l Choose the OPC server block as the Model Block for the given Alias.
l Choose either the External Reference (EXTREF) or the External Reference Structure
(EXTREFSTRUCT) parameters of the OPC server block for the given Alias.
o 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.
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.
- 173 -
l Gets conversions
l General data conversion considerations
l Stores conversions
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.
l The CDA-sp performs the interface specific translation of external reference type to system
type.
l The system value status is set according to the quality bit field of the OPC item state quality.
l The sub status and limits bit fields of the OPC item are ignored.
l 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.
l The OPC variant types that are not supported result in a data type mismatch error.
l The CDA-sp delivers a system value to the appropriate function block.
l 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
- 174 -
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 8.1 Keep the following considerations in mind when dealing with data conversions.
From BOOL UINT8 UINT INT8 INT ENUM FLOAT STRING TIME
UINT16 INT16 SD_
To 64 64 32
UINT32 INT32 ENUM
FLOAT
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
l 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.
o For example, an INIT16 value of 333 is converted to UNIT8 value of 255.
o 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.
o 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.
l Float to integer conversions use truncation instead of rounding. For example, a Float of 3.75
is converted to the Integer 3.
l 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:
- 175 -
o Boolean True converts to Integer 1 or Float 1.0

o Boolean False converts to Integer 0 or Float 0.0
o Integer 7 converts to Boolean True
o Integer 0 converts to Boolean False
o Integer -336 converts to Boolean True
o Float 33.33 converts to Boolean True
o Float -0.567 converts to Boolean True
o Float 0.0 converts to Boolean False
o 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.)
o Enumeration ordinal 0 converts to Boolean False
o Enumeration ordinal 8 converts to Boolean True
o Float 5.82 converts to Enumeration ordinal 5
o Float -11.0 converts to Enumeration ordinal 0
l 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 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.
- 176 -
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.
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 What the Added Functions Provides

ACE
Function
With HCI
Server
Experion Access levels for stores from Control Strategies loaded in ACE supervisory
server to controller to a TPN server in APP node are sent along with the data. The
TPS system Sequential Control Modules (SCMs) in Control Strategies use Program access
access level level, while other function blocks like the UCNOUT block use a Continuous Control
propagation access level. Since the access level definitions for an Experion system and a TPS
system are consistent, no translation is necessary.
Redirection When the Redirection Server is installed on the ACE node, the CDA-sp interfaces
Server 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.
- 177 -
- 178 -
CHAPTER
9 SYSTEM NAMESPACE WORKAROUND
l Inter-Cluster Communication
l Using the Inter Cluster Gateway for Communication between Experion Clusters
l Remote EEOUT (REEOUT) Function Block
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:
l The Inter Cluster Gateway (ICG) block

l The Remote EEOUT (REEOUT) function block
l 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))
- 179 -
Chapter 9 - System Namespace Workaround
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.
l Inter Cluster Gateway configuration guidelines
l When to use Inter Cluster Gateway
l Reviewing Inter Cluster Gateway characteristics
l Inter Cluster Gateway connectivity
9.2.1 Inter Cluster Gateway configuration guidelines
l An ICG is required for each Experion cluster which contains blocks that are secondary to
another Experion cluster.
l 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.
l There can only be one ICG per ACE.
l 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 (different Experion
cluster) 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.
- 180 -
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.
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.
- 181 -
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.
- 182 -
9.3 Remote EEOUT (REEOUT) Function Block
l Functional description-REEOUT
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).
- 183 -
CHAPTER
10 CONTROLLER REDUNDANCY FUNCTIONALITY
l Basic Redundancy Design Concepts

l Implications for Control Builder Functions
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 10.1 Typical RCP setup in 10-slot chassis.
- 184 -
Chapter 10 - Controller Redundancy Functionality
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.
l Primary - Refers to the chassis executing the assigned control functions.
l Secondary - Refers to the chassis in some state of readiness to assume the responsibilities of
the Primary.
l Switchover and Secondary readiness

l Failure conditions and switchover
l Role of the Redundancy Module
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 Then, the Secondary Chassis . . .

Secondary
Chassis
State is . . .
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:
l Loss of view of redundant partner on H1 network (applies to FIM link).
l Loss of private path connection from Primary to Secondary (lonely event).
- 185 -
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.
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.
- 186 -
Failure Conditions That Do Not Result in a Switchover - Disqualification Triggers

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 10.2 Typical redundancy communications path.
The RM functionality features the following major tasks.

l Gathers module status from all resident chassis modules.
l Gathers module status from its partner RM.
l Receives and logs event reports from resident chassis modules as well as from its partner RM.
l Resolves states based on gathered and reported data.
- 187 -
l Resolves contention situations with its partner RM.

l Coordinates state transition activity for the chassis.
l Provides redundancy-related read (status) and write (control) access to local controllers and
remote network devices.
10.2 Implications for Control Builder Functions
l Redundant C200/C200E CPM configuration

l RM configuration
l RM monitoring
l RM/RCP dialog box
l Main tab
l Summary tab
l RM Profiles tab
l Configuration tab
l Synchronization tab
l Chassis Profiles tab
l Display tab
l Server History tab
l Server Displays tab
l Auto-Synchronization events
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.
- 188 -
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 10.1 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.
- 189 -
l Primary- Relates physical hardware data for chassis identification (Chassis_A) and RM serial
number to the Primary redundancy state.
l Secondary Readiness - Shows readiness of Secondary chassis to assume the role of the
Primary if a switchover occurs. The possible readiness states are:
o UNDEFINED: Insufficient data to assess readiness. This is generally a startup state.
o NOPARTNER: Partner (Secondary) is not visible through RM-to-RM private path and
cannot assume the role of the Primary.
o DISQUALIFIED: Secondary is present and disqualified for operation as the Primary. It
o SYNCHRONIZED: Secondary is synchronized with the Primary. It can now assume the
role of the Primary.
o STANDBY: Secondary is not synchronized but it can assume the role of the Primary.
This state is not available in R120.
l 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
- 190 -
synchronization configuration and status, and a means to initiate operator commands.
l 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.
o 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.
o 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.
l 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.
l 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.
l Swap Control Button - Not active for R120.
l Swap to Standby Button - Not active for R120.
- 191 -
l 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.
l Chassis Synchronization States - Provides a status overview of the synchronization activity on
a module by module basis.
o Slot: Numbered reference to the ICP chassis slot location.
o % 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.
o 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
o 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. .
o 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.
- 192 -
l IDENTIFICATION - List of attributes that identify the given RM.

o Platform Ver. Rev: Shows version and revision numbers for the RM hardware.
o Boot Ver. Rev: Shows version and revision numbers for the RM Boot firmware
o Application Ver. Rev: Shows version and revision numbers for the RM application
firmware.
o Product Type-Code: Shows enumeration's of the RM product type (class) and product
code (class member).
o Honeywell Code: Shows enumeration of the RM manufacturer identification.
o Serial Number: Show unique identification number assigned to given RM.
o Description: Lets you enter a descriptive text string that is used by the Experion server
and visible on all RM alarms.
o Keyword: Lets you enter a definitive text string that is used on Station displays.
l SUMMARY STATUS - List of items that reflect the general status of the RM.
o 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.
o Auto-Sync Option: Shows current Auto-Synchronization option selection - See
Summary tab for more details.
ALWAYS
- 193 -
NEVER
CONDITIONAL
o Auto-Sync State: Shows current state for Auto-Synchronization relative to an event
trigger - See Summary tab for more details.
ENABLED
DISABLED
o 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.
o Error Code: Shows any detected error code in the format EXXX. Where XXX
represents an alphanumeric code.
o 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.
- 194 -
l Chassis Pair - Includes configuration selections for Auto-Synchronization and Program

Commands.
o Auto-Synchronization Option: Shows current option selection and lets you make
another selection. See the Summary tab for Auto-Synchronization details.
ALWAYS
NEVER
CONDITIONAL
o Program Command: Shows current command selection and lets you make another
selection. See the RM Profiles tab for Program Command details.
ENABLED
DISABLED
l Chassis ID - Shows current chassis ID position relative to Primary (Chassis_A) and Secondary
(Chassis_B) for given RM serial number.
o RM Serial Number: Lists unique identification number assigned to given RM.
o Chassis ID: Shows display position relative to Primary and Secondary states as
Chassis_A and Chassis_B, respectively.
l 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.
- 195 -
l Recent Synchronization Attempts - Lists the result and cause for the four most recent
synchronization attempts.
o 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
o 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.
o 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.
- 196 -
Cause Description
Message
BADSEC_EXIST Module in Secondary chassis failed prior to the synchronization attempt.
Repair or replace the failed module and retry.
COMM_ Communications failed (disconnect) during the synchronization attempt. Try

DISCONN the following recovery procedures in the order presented and retry the
synchronization attempt after each procedure.
l Check redundancy cable installation.
l Reseat each module in turn.
l Replace each RM in turn.
l Replace each module in turn.
l 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
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_ Communications error with the RM in the Secondary chassis. Try the
COMERR following recovery procedures in the order presented and retry the
synchronization attempt after each procedure.
l Check redundancy cable installation.
l Reseat each RM in turn.
l Replace each RM in turn.
- 197 -
Cause Description
Message
l Reseat each module in turn.
l Replace each module in turn.
l 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.
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.
- 198 -
l Primary/Secondary - Provides a status overview of the RCP activity on a module by module

basis for the given chassis.
o 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
o 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.
o 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
DISQUALIFIED: Secondary is present and disqualified for operation as the Primary. It
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.
o 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.
- 199 -
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.
- 200 -
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.
10.2.13 Server Displays tab

The Server Displays tab includes the following fields for configuring the parameters related to
- 201 -
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.
- 202 -
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.
l The Secondary chassis becomes disqualified for one of the following reasons:
o 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.)
o 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.
o 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.
l 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.
l Module goes invisible in the Secondary chassis.
l All major faults cleared in the Primary chassis.
l 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.
l 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
- 203 -
CHAPTER
11 CONTROL MODE SHED ON LOSS OF I/O

FUNCTIONALITY
l Basic Control Mode Shed Design Concepts

l Option to specify a time delay for the REGCTL blocks to shed the mode
l Implications for Operation
l Remote Cascade function between Controllers
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.
l How it works
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:
l Loss of communication on the I/O link.
l Failure of the I/O processor.
l Removing the I/O module from the chassis.
l Removing the local or remote CNI module from the chassis
l Disconnecting the ControlNet Cable.
l Cycling power to the remote chassis that contains an associated I/O module.
l 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.
- 204 -
Chapter 11 - Control Mode Shed on Loss of I/O Functionality
ATTENTION
These common actions do not break the communications path or initiate a control mode
shed:
l Activating/inactivating the IOM block.
l Activating/inactivating the CEE that contains the IOM block.
l 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.
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.
- 205 -
l Shed the mode to MANual immediately after an IO communication loss (existing functionality).
l Shed the mode to MANual after a specified time delay (0 to 60 seconds).
l 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.
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.
l Enabling the option of specifying time delay for REGCTL blocks to shed the mode
l Description of values for Bad Output Connection Option
l Considerations for setting the BADOCOPT value
l Applicability of BADOCOPT parameter for FANOUT blocks
l Simulation support for the BADOCOPT parameter
l Impact of BADOCOPT parameter on regulatory control functionalities
l Effects of BADOCOPT value on delay timer in various scenarios
l Auxiliary memory usage for the parameters
l Detail Displays
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:
l Enable - When this parameter is enabled, you can specify the time delay for the regulatory
control blocks to shed their mode.
l 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.
- 206 -
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.
- 207 -
Value What happens when an IO communication Restore Conditions

loss occurs?
Nan No mode shed happens. After the IO communication is
restored, the initialization
Only the initialization request for the block is set and request is reset.
the upstream blocks are initialized.
0 Mode sheds to MANual immediately. The mode After the IO communication is

attribute changes to Operator and an initialization restored, the initialization
request is set. When an initialization request is set, request is reset. You must revert
the upstream blocks are initialized and the control the mode setting manually.
freezes.
1 - 60 Mode sheds to MANual and the mode attribute After the IO communication is
changes to Operator based on the following restored, the initialization
conditions: request is reset and you must
revert the mode setting
When the BADOCOPT value is less than its manually. However, if the IO
associated Control Module's execution period, the communication is restored
mode shedding occurs after a time delay of one CM within the specified time delay,
Period. For example, if the Control Module's there is no need to revert the
execution period is 5 secs and the BADOCOPT value mode setting.
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:
l 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)
l 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.
- 208 -
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.
l 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.
l 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.
l 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.
o All the outputs connected to the block are not communicating with their secondaries.
o 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.
l The output channel is in a Control Module different than the primary regulatory block.
l 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 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.
- 209 -
11.2.7 Effects of BADOCOPT value on delay timer in various scenarios
BADOCOPT Scenario Result

Value
Between 0 - You change the Change comes into effect only when the timer is
60 secs BADOCOPT value to terminated after the period is over or the communication
a value between 0 - is restored.
60 while the delay
timer is running.
NaN You change the Change comes into effect immediately. Mode does not
BADOCOPT value to shed to MANual. Timer is reset.
NaN while the delay
timer is running.
Between 1 - You change the Mode sheds to MANual, even if the specified time delay is
60 secs mode to a non- not expired. However, if the communication error is
MANual mode after restored and restarted, the mode sheds to MANual after
the block has shed the specified time delay is expired.
to MANual after the
specified time delay
or
You set the mode to
MANual before the
delay time expires
and then change
the mode to a non-
MANual mode.
Between 1 - You set the CEE to Timer value is reset. The timer is restarted after the CEE
60 secs Idle or make the is started, Control Module is active and the IO
Control Module communication loss continues to exist.
containing the
regulatory block
inactive.
Between 1 - You perform a Checkpoint Save does not store the active delay timer
60 secs Checkpoint Save value. When the checkpoint data is restored, the
operation. BADOCOPT parameter option is restored but the delay
timer value is not restored but reset. If the IO
communication is not restored at this point, this is
considered a new instance and the delay timer is
restarted.
Between 1 - You perform an On- On-Process Migration does not restore the active delay
60 secs Process Migration. 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 - You perform a RAM RAM Retention Restart does not restore the active timer
60 secs Retention Restart. 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
- 210 -
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.
l SysDtlRegctla.htm
l sysdtlpida.htm
l sysdtlpide.htm
l sysdtlpidpla.htm
l sysdtlpidplf.htm
l sysdtlpidplaltf.htm
l sysdtlpidplalta.htm
l sysdtlrampa.htm
l 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.
- 211 -
For more information on the detail displays, refer to the following:

l HMIWeb Display Building Guide
l Operator's Guide
11.3 Implications for Operation
l Resetting mode after I/O communications are restored.

l Allowing Redundancy synchronization with lost I/O communications
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.
- 212 -
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.
l REMCAS (Remote Cascade) Block
l Peer-to-peer configuration example
- 213 -
CHAPTER
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 .
l MODESTARTMAN (Load and Start MODE in Manual)
l CEESTARTOPT (CEE Restart Option)
l 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.
l About the MODESTARTMAN parameter

l MODESTARTMAN
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.
- 214 -
Chapter 12 - Enhancements to MODE behavior of the regulatory control blocks
ATTENTION
l The MODESTARTMAN parameter is not applicable for the following blocks:
o REEOUT block
o RAMPSOAK block
o PULSECOUNT block
o PULSELENGHT block
l 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.
12.1.1 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 Checkpoint RRR followed by

followed by Restore
followed by
Warm Cold Warm Cold Warm Start Cold Start
Start Start Start 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
- 215 -
ATTENTION
l 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.
l After an RRR;
o 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.
o If the CEESTATE is RUN, the MODESTARTMAN parameter behavior then
depends on the RRRCEESTATE and the CEESTARTOPT parameters.
l 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.
12.1.2 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 RRR followed by

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

Block(s) 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)
l Sets MODE to Man and MODEATTR to Operator during controller download
and Checkpoint Restore.
l 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 Yes
Load
Active Yes
Loadable
Access Lock AppDeveloper
Residence CEE
Related MODE
Parameters
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.
l When this parameter is disabled;
l MODE and MODEATTR are downloaded as per the configuration.
l 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.
l 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;

l MODE is downloaded as Man and MODEATTR as Operator.
l Checkpoint Restore restores MODE as Man and MODEATTR as
Operator.
l 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.
- 217 -
CHAPTER
13 CONTROL BUILDER EXPORT AND IMPORT

FUNCTIONALITY
l Basic Export/Import Design Concepts
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.
l Export functionality
l Import functionality
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
- 218 -
Chapter 13 - Control Builder Export and Import Functionality
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.
- 219 -
CHAPTER
14 SCM AND CM CHART VISUALIZATION

FUNCTIONALITY
l Basic Chart Visualization Design Concepts

l Some SCM and CM Chart Operation Considerations
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.
l How SCM chart visualization works
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.
- 220 -
Chapter 14 - SCM and CM Chart Visualization Functionality
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 14.1 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.
- 221 -
Figure 14.2 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.3 View of CM102 chart in Control Builder Monitoring Tab.
- 222 -
Figure 14.4 View of CM102 chart in CM Detail display in Station.
14.2 Some SCM and CM Chart Operation Considerations
l Detail display interaction notes
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.
l 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.
l Open only one SCM or CM chart for display in Station at a time.
l You can display the same SCM or CM chart on multiple Stations at the same time.
l You can display different SCM or CM charts on multiple Stations at the same time.
l 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.
l A communications failure will result in question marks (?) being shown in place of live values
until the fault is cleared.
- 223 -
CHAPTER
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:
l on-delay time - 5 seconds
l off-delay time - 10 seconds
l deadband value - 2
l 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.
l ACE
l SIM-ACE
l C200E
l SIM-C200E
l C300
l C300 - 20msCEE
l SIM-C300
l Various configurable alarm attributes

l Blocks and applicable alarms
15.1 Various configurable alarm attributes

You can configure the following attributes for a set of analog and digital alarms.
- 224 -
Chapter 15 - Enhancements to reporting of alarms in Station
l 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.
l 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.
l 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.
o For high and high high alarms: Trip point - deadband value (configured)
o 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.
l 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.
o AUTOMAN
o ENHREGCALC
o OVRDSEL
o PID
o PIDER
o PIDFF
o PID-PL
o POSPROP
o RAMPSOAK
o RATIOBIAS
o RATIOCTL
o REGCALC
o REGSUMMER
o REMCAS
o SIGNALSEL
o SWITCH
15.2 Blocks and applicable alarms

The following table lists the function block names and the respective alarms for which you can
- 225 -
configure on-delay time, off-delay time, deadband value, and deadband units.
Block Names Alarms for which on- Alarms for which

delay time and off-delay deadband value and
time can be configured deadband units can be
configured
ALMWINDOW, CONTACTMON, l Off-Normal alarm
FLAG
AUTOMAN, ENHREGCALC, l Bad Control alarm l Output (OP) High alarm

OVRDSEL, RATIOBIAS, REGCALC,
REGSUMMER, REMCAS, SWITCH l Output (OP) High l Output (OP) Low alarm
alarm
l Output (OP) Low alarm
DATAACQ l Bad PV alarm l PV High alarm

l Negative Rate Of l PV High High alarm
Change alarm
l PV Low alarm
l Positive Rate of
l PV Low Low alarm
Change alarm
l PV High alarm
l PV High High alarm
l PV Low alarm
l PV Low Low alarm
DIGACQ l Bad PV alarm

l Off-Normal alarm
l Change Of State alarm
FANOUT l Bad Control alarm
PID, PIDER, PIDFF, RATIOCTL l Advisory Deviation l Advisory Deviation alarm

alarm
l Deviation High alarm
l Bad Control alarm
l Deviation Low alarm
l Output (OP) High alarm
l Output (OP) High
alarm
PID-PL l Advisory Deviation l Advisory Deviation alarm

alarm
l Bad Control alarm
l Output (OP) High alarm
l Output (OP) High
alarm
l Predictive PV High
alarm
- 226 -
Block Names Alarms for which on- Alarms for which

delay time and off-delay deadband value and
time can be configured deadband units can be
configured
l Predictive PV Low
alarm
POSPROP l Advisory Deviation l Advisory Deviation alarm

alarm
l Bad Control alarm
RAMPSOAK l Deviation High alarm l Deviation High alarm

l Deviation Low alarm l Deviation Low alarm
l Output (OP) High l Output (OP) High alarm
alarm
ROC l Bad PV alarm
SIGNALSEL l Deviation alarm l Deviation alarm
ATTENTION
The INALM parameter also changes based on the expiration of the alarm timer values.
l Guidelines for configuring on-delay time for BADCTL alarm

l Example to illustrate the alarm behavior based on alarm attributes
l Impact of alarm priority change on alarm behavior
l Impact of migration on alarm attributes
l Impact of OUTIND parameter on alarm attributes
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.
- 227 -
If you set the ? Then, the BADCTLALM.TM value is

?
BADCTLALM.TM to a non-zero value when the Rejected and the following message
BADCTLOPT is configured as SHEDHI, SHEDLO, appears.
SHEDSAFE, or SHEDHOLD
“Config Not Permitted With Current
BadControlOption [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
SHEDHOLD when BADCTLALM.TM is already set to following message appears.
a 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.
- 228 -
When the OP Active OP RTN of active OP High alarm occurs when ?

High alarm High
attributes are alarm
configured as? occurs
when ?
l Trip point = OP value OP value persists below 80 for 30 seconds or more.

80 exceeds 80.
l Off-delay time
= 30 sec
l Deadband
value = 0
l Trip point = OP value OP value reaches a value = trip point - deadband value, 78 in
80 exceeds 80. this example.
l Off-delay time
=0
l Deadband
value = 2
l Trip point = OP value OP value goes below a value = trip point - deadband value,
80 exceeds 80. 78 in this example, and persists in the same range for 30
sec or more.
l Off-delay time
= 30 sec
l Deadband
value = 2
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.
l 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.
l 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.
- 229 -
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.
- 230 -
CHAPTER
16 I/O LINK INTERFACE
The I/O Link supports both the:

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

l I/O Functions
l A word about Point form
l IOP validation
l I/O Link Cable Status and Statistics
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.
- 231 -
Chapter 16 - I/O Link Interface
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
l Periodic swap functionality

l Periodic swap transition diagram
l Enabling periodic channel swap
l Viewing cable status and statistics
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 Then, Cable is . . .
Status
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.
- 232 -
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.
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.
- 233 -
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.
- 234 -
CHAPTER
17 PROCESS MANAGER INPUT/OUTPUT FUNCTIONALITY
l High and Low Level Analog Input Points

l Smart Transmitter Interface Point
l Analog Output Point
l Digital Input Point
l Digital Output Point
17.1 High and Low Level Analog Input Points
l Function of high and low level analog input points

l PV Characterization
l Linear Conversions
l Square root conversion
l Thermal conversion
- 235 -
Chapter 17 - Process Manager Input/Output Functionality
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.
l Analog-to Digital Conversion
l Range Checking and PV Filtering
l PV Source Selection
l 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.
- 236 -
Sensor Type AI PVCHAR PVRAW PVCALC Bad PV

(SENSRTYP) Processor (1) Direction(2)
Options
Type
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

RHMUX thermocouple,
and range check
on PVCALC
- 237 -
Sensor Type AI PVCHAR PVRAW PVCALC Bad PV

(SENSRTYP) Processor (1) Direction(2)
Options
Type
RTD LL, LLMUX RTD Milliohms EU Range check on
PVCALC
Legend: EU = Engineering Units

l HL = High Level Analog Input, (Includes HLAIHART)
l LL = Low Level Analog Input
l LLMUX = Low Level Analog Multiplexer Input
l PVCALC = Calculated Process Variable
l PVCHAR = Process Variable Characterization
l PVRAW = Process Variable received from field and converted to digital form by the
l A/D converter.
l 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
- 238 -
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:
l For slidewire and 0 to 100 millivolts sensor types, when INPTDIR is Direct:
l For 0 to 5 Volts, 0.4 to 2 Volts, and 1 to 5 Volts sensor types, when INPTDIR is Direct:
l For slidewire and 0 to 100 millivolts sensor types, when INPTDIR is Reverse:
l 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:
- 239 -
l If PVRAW is equal or greater than 0.0 and INPTDIR is Direct:
l If PVRAW is less than 0.0 and INPTDIR is Direct:
l If PVRAW is equal or greater than 0.0 and INPTDIR is Reverse:
l 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.
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.
- 240 -
RTD Type Maximum Allowable Maximum Allowable Intrinsic

Lead Resistance Safety Barrier Resistance
Entire Loop Per Leg Entire Loop Per Leg
Pt: 100 ohm DIN 20 ohms 10 ohms 18 ohms 18 ohms

Characterization
Pt: 100 ohm JIS 20 ohms 10 ohms 18 ohms 18 ohms

Characterization
NI: 120 ohm Edison Type 7 20 ohms 10 ohms 18 ohms 18 ohms

Characterization
Cu: 10 ohm SEER 20 ohms 10 ohms 0 ohm 0 ohm

Standard Characterization
17.2 Smart Transmitter Interface Point
l Smart Transmitter support

l Multivariable transmitter support
l Transmitter parameters and database access
l STI parameter comparisons
l Transmitter communication mode
l STI IOP commands
l Point states
l STI IOP functions
l STI PV characterization
l STI linear conversion
l STI square root conversion
l STI thermal conversion
l STI PV range checking and filtering
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:
l ST3000 Smart Pressure Transmitter for differential, gauge, and absolute pressure
measurements
l STT3000 Smart Temperature Transmitter for temperature, millivolts, and ohms
measurements, and
l 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.
- 241 -
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:
l SCM3000 Smart Flow Transmitter (Coriolis method)
l Drexelbrook SLT Level Transmitter
l SMV 3000 Multivariable Pressure Transmitter
l 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.
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. )
- 242 -
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 Corresponding Remarks

Transmitter STI IOP
Database Parameter
Parameter
Upper Range URV Define the operating range of the transmitter. These
Value and Lower values correspond to the values for PVEUHI and PVEULO,
Range Value LRV respectively.
Upper Range URL These parameters are the respective built-in maximum
Limit and Lower and minimum limits of the transmitter and they cannot be
Range Limit LRL changed. 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.
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 SECVAR For a pressure transmitter, the secondary variable is the

Variable 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 PVCHAR Refer to STI PV characterization.

Root
Characterization
Communication DECONF Refer to the following section.

Mode
Cold Junction CJTACT Applicable to STT 3000 only.

Compensation
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.
- 243 -
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.
If Command Selection Then, Action Initiated Is . . .

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.
- 244 -
If Current Then, Existing Condition Is . . .

State 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
- 245 -
17.2.8 STI IOP functions

The STI IOP performs the following functions as illustrated in the following figure.
l 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.
- 246 -
Transmitter PVCHAR PVRAW PVCALC PV Detection(2)

(Sensor) Type Options (1,3)
(SENSRTYP)
Spt_Dp (Differential Linear Percent in EU Range check on PVCALC
Pressure) Water
Square Root
Spt_Gp (Gauge Linear Percent in EU Range check on PVCALC

Pressure) Water
Spt_Ap (Absolute Linear Percent in EU Range check on PVCALC

Pressure) Water
Stt (Temperature)(4) Linear Percent EU Range check on PVCALC

Millivolts
Thermocouple Percent EU Open thermocouple

degrees C detection, and range
check on PVCALC.
RTD Percent EU Range check on PVCALC

degrees C
RTD Ohms Percent EU Range check on PVCALC

Ohms
Sfm (Flow) Linear Percent EU Range check on PVCALC

cubic meters
per hour
Legend: EU = Engineering Units

l PVCALC = Calculated Process Variable
l PVCHAR = Process Variable Characterization
l PVRAW = Process Variable received from transmitter and multiplied by 100 by the
l 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.
- 247 -
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.
l For INPTDIR = Direct:
l 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.
- 248 -
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:
l The DAMPING parameter allows for better control accuracy because more PV samples are used
in calculating the filtered PV value at the transmitter.
l 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)
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
l AO functions
l AO direct/reverse output
l AO output characterization
l AO calibration compensation
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
- 249 -
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:
l Direct/reverse Output Function
l 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.
- 250 -
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
- 251 -
l DI functions
l DI status point
l DI PV source selection
l DI off-normal alarming
l Alarm delay
l Event reporting
l DI latched input point
l DI sequence of events point
l SOE definitions
l SOE resolution considerations
l DI SOE configuration considerations
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:
l The PV source has been switched to Substituted, and the point is inactive or the module status
is Idle.
l 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.
- 252 -
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
- 253 -
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.
- 254 -
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.
- 255 -
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 The smallest increment of real time that can separate two consecutive SOE
(Tres) time-stamped events. The resolution of the field-connected equipment which
first stamps an event limits the inherent resolution of the system.
Sequence The minimum difference in logged time stamps that guarantees the order of
Stamp two time stamps.
Difference
(SSD)
Minimum The smallest interval between two ideal (bounceless) physical events, so the
Physical Event events can be correctly ordered by the Sequence Stamp Difference.
Separation
(MPES)
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
l Skew: 0+0.2+0.04+0.2+0.2+0.1+0.5 = 1.24 msec
l SSD: N = 7, (7+1) * 0.200 = 1.6 msec
l MPES: 1.6 + 1.24 = 2.84 msec
For points in one IOLIM

l Skew: 0+0.2+0.04+0.2+0.2+0.2+0.5 = 1.34 msec
l SSD: N = 7, (7+1) * 0.200 = 1.6 msec
l MPES: 1.6 + 1.34 = 2.94 msec
For points in redundant IOLIMs

l Skew: 0.5*+0.4+0.04+0.2+0.2+0.2+0.5=2.04
l SSD: N = 11, (11+1) * 0.200 = 2.4
l MPES: 2.4 + 2.04 = 4.44
*Estimated value.
- 256 -
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.
l Two events within the same DI-SOE module.
l Two events within the same C300 IOLink using multiple DI-SOE modules.
l 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.)
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.
- 257 -
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.
l 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).
l 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:
o 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).
o 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.
l If the PV does not change before the delay timer runs out, no further action is taken.
l 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.
l 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:
o If the PV state is different from the state that started the timer, this event is reported.
o If the PV state is the same as the original PV state that started the timer, no event is
reported.
17.5 Digital Output Point
l DO functions
l Pulse Width Modulated (PWM) Output Type
l Status Output Type
l Initialization request flag
- 258 -
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.
- 259 -
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:
- 260 -
l a PWM type output is configured

l a Status Output type is configured and:
o the point is inactive
o the module is idle
o there is a soft failure such that the point is not working.
- 261 -
CHAPTER
18 COMPONENT CATEGORIES AND TYPES
l About categories
l Function block types and data organization
18.1 About categories

For data organizational purposes, we divide the Control Builder components into these two major
categories:
l Hardware Relation Category
l 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.
l Regulatory Control
l UCN Interface
l Exchange Functions
l Auxiliary Functions
l Data Acquisition Functions
l Pulse Input
l Device Control
l Logic Functions
l Math Functions
l Power Generation Functions
l Utility Functions
l Sequential Control
l Thermodynamic Utility Functions
- 262 -
Chapter 18 - Component Categories and Types
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.
- 263 -
CHAPTER
19 REGULATORY CONTROL
l Regulatory Control Blocks

l Clamping the output amperage to comply with the NAMUR NE 43 standard
l About Safety Interlock Function
l About Red Tagging
l AUTOMAN (Auto Manual) Block
l ENHREGCALC (Enhanced Regulatory Control Calculator) Block
l FANOUT Block
l OVRDSEL (Override Selector) Block
l PID Block
l PID-PL (Profit Loop PKS) Block
l PIDER (PID with External Reset Feedback) Block
l PIDFF (PID with Feedforward) Block
l LEGACYGAP Option in R300
l POSPROP (Position Proportional) Block
l PULSECOUNT Block
l PULSELENGTH Block
l RAMPSOAK Block
l RATIOBIAS Block
l RATIOCTL (Ratio Control) Block
l REGCALC (Regulatory Control Calculator) Block
l REEOUT (Remote EEOUT) Block
l REGSUMMER (Regulatory Summer) Block
l REMCAS (Remote Cascade) Block
l SWITCH Block
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.
- 264 -
Chapter 19 - Regulatory Control
Function Block Description

Auto Manual Tuning Provides a “bumples” output following initialization or mode
Conversions changes; typically used in a cascade where one of the
from Interactive upstream blocks may not accept an initialization request.
to Non-
Interactive PID
Enhanced ENHREGCALC Provides enhancements over the REGCALC block. The

Regulatory (Enhanced enhancements include:
Control Regulatory
Calculator Control l Expands existing arrayed input parameters XSTS and X
Calculator) from six to ten.
Block l These arrayed parameters are added to correspond to
each of the ten inputs.
l Input Description
l Enable/Disable Switch
l 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 OVRDSEL Selects one input from many based on the highest or lowest
Selector (Override input value; the OVRDSEL block always forces the unselected
Selector) Block inputs to track the selected inputs, but provides two methods
for doing so:
l Propagate override feedback data to the unselected
inputs.
l Continually initialize the unselected inputs.
Proportional, PID Block Provides an implementation of the PID algorithm, using the
Integral & Ideal form, whereby the following combinations of control
Derivative terms may be configured:
l Proportional-only (acts on the error PV -SP)
l Integral-only (acts on the error PV -SP)
l Proportional & integral (act on error PV - SP), & derivative
(acts on changes in PV)
l Proportional & derivative (act on changes in PV), &
integral (acts on the error PV - SP)
l Proportional, integral & derivative (act on the error PV -
SP)
Proportional, PID-PL (Profit Provides PID control using a model predictive control package
Integral & Loop PKS) Block called Profit Loop PKS that incorporates robust control
Derivative techniques to enhance control performance despite process
with Profit model uncertainty and measurement error.
Loop PKS
Proportional, PIDER (PID with Operates as a proportional-integral-derivative (PID) controller

Integral & External Reset that accepts a reset feedback signal, a tracking value, and a
Derivative Feedback) Block tracking control switch. It supports the same Ideal form of
with External calculating the PID terms as the PID block. It also prevents
Reset windup when the secondary does not propagate windup
Feedback status or control initialization data back to the primary of a
remote (foreign) controller
Proportional, PIDFF (PID with Provides the same classic PID function as outlined above with
- 265 -

Integral & Feedforward) the ability to accept a “feedforwar” signal. You can configure
Derivative Block the feedforward signal to be added to or multiplied by the PID's
with incremental output to meet varying control requirements.
Feedforward
Position POSPROP Provides two digital outputs for pulse control of a final control
Proportional (Position element. It accepts process variable (PV) and set point (SP)
Control Proportional) inputs.
Block
Proportional)
Block
Pulse Count PULSECOUNT Provides pulse waveform generation on its four main outputs
Block 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 PULSELENGTH Provides pulse waveform generation on its four main outputs
Length Block 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 Provides an output that follows the user configured sequence
Block 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 RATIOBIAS Provides a calculated output based on the ratio of the input
Bias Block 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 actual
Control) Block 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 REGCALC Lets you write up to eight expressions for creating custom
Control (Regulatory algorithms for Calculated Variable (CV) calculations. Provides
Calculator Control an interface to windup, initialization and override feedback
Calculator) processing, so you can add user-defined control blocks to your
Block control strategies.
Remote REEOUT Used in conjunction with the Inter Cluster Gateway to support
EEOut (Remote regulatory cascades between ACE nodes residing in two
EEOUT) Block separate Experion clusters.
Regulatory REGSUMMER Calculates an output value which is the sum of up to four

Summer (Regulatory inputs. Each of the inputs may be individually scaled. The
Summer) Block output may be scaled by an overall gain, and an overall bias
may be added to the result.
Remote REMCAS Provides automatic switching between a primary (remote) and

Cascade (Remote backup (local) cascade; typically used with a PID that normally
Cascade) Block gets its set point from a remote source, but sheds to a local
source when the remote cascade is broken.
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.
- 266 -
l Common regulatory control functions for C200/C200E and ACE controllers without insertion
points
l Common regulatory control functions for ACE controllers with insertion points
l CAB insertion configuration considerations for regulatory control blocks
l Insertion type functional characteristics for regulatory control blocks
l Functional requirements for Custom CAB algorithm for regulatory control block
l CAB insertions for Regulatory Control block parameters
l Pin connections to inserted CAB instances
l Insertion status and fail alarm for regulatory control blocks
l Handling of insertion failure on regulatory control block
l CAB insertion on regulatory control block configuration examples
l Tuning Conversions from Interactive to Non-Interactive PID
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.
- 267 -
Major Description
Function
Input Provides these functions for all Regulatory Control function blocks to be used as
Processing 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 “Mode” identifies who may store to certain Regulatory Control parameters (for
Processing 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 If a Regulatory Control block is in a Cascade strategy, this function checks if the
Control cascade has been broken. If it has, this function initializes the block and builds an
Processing initialization request for its primary or primaries.
Algorithm This involves calculations that are unique to each Regulatory Control block (for
Calculation example, PID calculation). These calculations are described more fully for each
individual block in the remainder of this section.
Output This function derives the control output (OP) from the algorithm's calculated
Processing 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 If a Regulatory Control block is in a cascade strategy, this function may propagate
Propagation 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.
- 268 -
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.
Table 19.1 CAB insertion locations in regulatory control block major functions
- 269 -
19.1.3 CAB insertion configuration considerations for regulatory

control blocks
l You cannot use CAB insertion programs with the following Regulatory Control blocks.
o POSPROP
o PULSECOUNT
o PULSELENGTH
o REGCALC
l You can insert up to 10 CAB programs in a regulatory control block.

l 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.
l You must insert CAB instances in the same Control Module that contains the regulatory control
block.
l 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.
l 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.
l 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.
l 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.
- 270 -
Insertion Function
Type
Post Input Provides the capability of performing custom functions such as:
(Post_
Input) l Custom calculations on inputs,
l Custom timeout processing function, and
l 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 Provides the capability of implementing custom initialization strategies..

Algorithm
(Pre_Alg)
Control Provides the capability of replacing the standard regulatory control block algorithm
Algorithm with user custom one written in a CAB program.
(Ctl_Alg)
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:
l Bad input handling (CV gets set to bad when input is bad).
l CV calculation for the various control states (FORWARD, MAN and INIT).
l INITVAL calculation.
l Override feedback handling, if the block is part of an override strategy.
l Input timeout processing, if required.
l 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 Provides the capability of implementing custom calculation for output values.
Algorithm
(Post_Alg)
Post Provides the capability of implementing custom windup calculations. You can use
Control parameters ARWNETIN and ARWOPIN to modify windup states.
Output
(Post_
Ctlout)
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.
- 271 -
Functio Requirement
n
Error The CAB program must not abort when the regulatory control block goes into a bad
Handling 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.
Initializati The CAB program algorithm must calculate the initialization value (INITVAL) that is to
on 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 If the regulatory control block is part of an override strategy, the CAB program must
Feedback 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 The standard Regctl algorithms include a floating bias function so that output is
Bias 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
- 272 -
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 All Regulatory Control blocks that
one flag for each primary. support insertion points
INITVAL[1..8] Initialization Value. There is one value All Regulatory Control blocks that
for each primary. support insertion points
OPBIAS.FLOAT Floating Output Bias in Engineering ENHREGCALC,

Units
PIDER,
RATIOCTL,
REGSUMMER
OPBIAS Total Output Bias for function blocks FANOUT

[1..8].FLOAT with Multiple Outputs
PV Process Variable Pid,
Pidff,
PVSTS Status of Process Variable. Pid,

Pidff,
RAMPSOAK,
RATIOCTL
TMOUTFL Timeout Flag. Indicates if an initializable All Regulatory Control blocks that
input has timed-out. support insertion points
X [..] Input Value for blocks with multiple Ovrdsel,

inputs
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 RATIOCTL

multiple inputs
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 inserted CAB blocks, during the load of insertion points
- 273 -
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:
l Pin connections always transfer data into a CAB insertion program just before execution of the
calling block.
l 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 Considerations
Type
Program CAB programs in general must not be repetitious. If repetitive calculations must be
Termination 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 If the inserted CAB program encounters an exception failure condition, the
Failures 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
- 274 -
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 19.2 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
- 275 -
Callout Description
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
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
uses a AUTOMAN block with insertion types from four CAB instances.
Figure 19.1 Configuration example using multiple CAB insertions for regulatory control block
- 276 -
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.
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 successively with no failures, the cycle is repeated during
every Control Module execution cycle. In 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.
- 277 -
Callout Description
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
uses a DATAACQ block with the same insertion type from two CAB instances.
Figure 19.2 Configuration example using two CAB insertions of the same type for regulatory control
block
- 278 -
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.
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.
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
- 279 -
Callout Description
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.
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:
- 280 -
Equation PID Type Equation

Reference
Number
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:
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
19.2 Clamping the output amperage to comply with the NAMUR NE

43 standard
This section discusses the configuration examples for clamping the output amperage in
Regulatory Control points to comply with the NAMUR NE 43 standard. It discusses how to
configure the limits to clamp the output amperage between -3% (3.5 mA) and 103% (20.5mA).
l Device needs and the standard

l Configuration
19.2.1 Device needs and the standard

NAMUR's NE 43 recommends a standardization of the signal level for failure information of digital
transmitters. Some smart valve positioners require minimum amperage of 3.5 mA. If the output
amperage drops to a value less than the required value or raises to a value more than the
required value, it might result in an erratic behavior.
The objective of the NE 43 standard is to set a basis for proactively using the transmitter failure
signals in process control strategies. Early failure signaling helps in designing appropriate
maintenance strategies to keep the plant operational.
19.2.2 Configuration
Clamping the OP amperage based on the specified limits is an existing feature. However, the
solution discussed in this section provides detailed information about configuring the higher and
lower limits appropriately to ensure that the OP amperage is clamped at 3.5 mA, when the
amperage supplied to the smart valve positioners is outside the specified limits.
The parameters, OPEXHILM, OPEXLOLM, OPHILM, and OPLOLM are used for limiting the OP
amperage.
The configuration details for the following scenarios are discussed:
- 281 -
l Regulatory blocks in MAN mode and OUTIND = Direct

l Regulatory blocks in AUTO mode and OUTIND = Direct
l Regulatory blocks in MAN mode and OUTIND = Reverse
l Regulatory blocks in AUTO mode and OUTIND = Reverse
Basic OP limit configuration requirements
The Output Extended High Limit (OPEXHILM) must be higher than or equal to the Output High
Limit (OPHILM). The Output Extended Low Limit (OPEXLOLM) must be lower than or equal to the
OP Limit (OPLOLM).
NOTE
When OUTIND=DIRECT, 4 mA indicates 0 percent and 20 mA indicates 100 percent.
Similarly, when OUTIND=REVERSE, 4 mA indicates 100 percent and 20 mA indicates 0
percent.
l OP configuration in different scenarios
OP configuration in different scenarios
The following tables discuss the OP configuration details in different scenarios.
Scenario 1: MODE=MAN, OUTIND=DIRECT
Configured OP If... Then...

limit values (in %)
OPHILM = 100 forced OP is clamped at -3% because the OP value is outside the
OP = - specified extended lower limit (OPEXLOLM = -3%).
OPLOLM = 0
5%
Note that an error message is displayed when you force the
OPEXHILM = 105 value of OP to -5%.
OPEXLOLM = -3
the displayed OP value after clamping = -3%
the output amperage to valve as measured by the multimeter =

3.52 mA
- 282 -
Figure 19.3 Sample configuration in Control Builder: Configuring the Output Limits
Figure 19.4 Displayed OP and Actual OP after OP is clamped when OUTIND=DIRECT
- 283 -
Scenario 2: MODE=AUTO, OUTIND=DIRECT
Configured OP limit If... Then...

values (in %)
OPHILM = 105 calculated OP is clamped at -3% because the OP value is outside the
OP = -5% specified lower limit (OPLOLM = -3%).
OPLOLM = -3
the displayed OP value after clamping = -3%
OPEXHILM = 105
the output amperage to valve as measured by the
OPEXLOLM = -5
multimeter = 3.52 mA
Scenario 3: MODE=MAN, OUTIND=REVERSE

values (in %)
OPHILM = 100 forced OP = OP is clamped at -3%

105%
OPLOLM = 0 the displayed OP value after clamping = 103%
OPEXHILM = 103 actual OP = -3% (OPHILM – Displayed OP)
OPEXLOLM = -3 the output amperage to valve as measured by the
multimeter = 3.52 mA
Figure 19.5 Displayed OP and Actual OP after OP is clamped when OUTIND=REVERSE
- 284 -
Scenario 4: MODE=MAN, OUTIND=REVERSE
Configured OP If... Then...

limit values (in %)
OPHILM = 100 forced OP Displayed OP value = 105%

= 105%
OPLOLM = 0 Note that OP is not clamped at -3% and no error message is
displayed in this scenario because OPEXHILM is 105%.
OPEXHILM = 105
the output amperage to valve as measured by the multimeter =
OPEXLOLM = -3
3.19 mA
NOTE
As OUTIND=Reverse, the OPEXHILM must be set to
103% to clamp the OP at -3%.
Scenario 5: MODE=AUTO, OUTIND=REVERSE

values (in %)
OPHILM = 103 calculated OP OP is clamped by OPHILM

= -5%
OPLOLM = -3 the displayed OP value after clamping = 103%
OPEXHILM = 103
OPEXLOLM = -5 multimeter = 3.52 mA
Scenario 6: MODE=AUTO, OUTIND=REVERSE

values (in %)
OPHILM = 100 calculated OP = OP is clamped by OPHILM

-5%
OPLOLM = 0 the displayed OP value after clamping = 100%
OPEXHILM = 105
OPEXLOLM = -5 multimeter = 4 mA
19.3 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.
l Safety Interlock processing
l Safety Interlock processing considerations
l Safety Interlock Alarming
19.3.1 Safety Interlock processing

If a SIFL connection exists, the regulatory control fetches the flag and checks for a change of
- 285 -
state. When SIFL is ON, the regulatory control block does the following:
l Checks if a Safety Interlock alarm should be issued.
l 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 Then, Action Is . . .

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.3.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, l MODE, MODEATTR, ESWENB and OP cannot be directly
changed by the user.
l If mode was shed, the user is prevented from changing it until
SIFL goes OFF. However, the following should be noted:
l 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.)
l If the user sets the regulatory control block inactive,
SIFL will be turned OFF.
While SIFL is On and the A change in SAFEOP/OPEXHILM/OPEXLOLM will dynamically

block has Shed once, update the OP (based on the SIOPT) only in the following cases:
l After each execution, when there is a wired connection to SIFL
and the flag is ON.
l After each store, when there is a program store to SIFL pulsed
to set it ON.
If the block is in The OP value will not be impacted by any change other than the
initialization in the INITVAL from the secondary. The OP will be dynamically updated
previous scenarios, based on the SIOPT, only after the block comes out of initialization.
When there is a Program l A change in SAFEOP/OPEXHILM/OPEXLOLM thereafter will

store configured to set the not dynamically update the OP.
- 286 -
If Condition Is . . . Then, Consider This . . .

SIFL to ON, and when the l The user has to execute the program to pulse the SIFL to ON
block has Shed once, again, for the OP to be updated.
When there is a Program l The Mode will be shed but the OP will not be set based on the
store configured to set the Shed option.
SIFL to ON once and if the
block is in initialization, l The OP will be equal to the INITVAL from the secondary in this
case.
l 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 l The function block clears the Safety Interlock alarm (if one was
ON to OFF, issued).
l 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.
l If mode was not shed, the function block clears its windup
condition .
19.3.3 Safety Interlock Alarming

The Safety Interlock Alarm Option (SIALM.OPT) indicates if SI alarming is enabled or not as follows:
l 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.)
l If SI alarming is disabled, an alarm indicator will notappear on the detail display and an alarm
will not be issued.
19.4 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.
l Regulatory Control blocks - AutoMan, Fanout, OvrdSel, PID, PIDFF, PosProp, PulseCount,
PulseLength, RampSoak, RemCas, RatioBias, RegCalc, RegSummer, and Switch.
l Device Control block
l Drive Control Blocks - HT Motor, LT Motor, Solenoid Valve, Valve/Damper
l Series C I/O - AOCHANNEL, DOCHANNEL
l Function of Red Tagging

l Before red tagging a point
- 287 -
19.4.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.4.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.5 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.
l OPHIALM.TM
l OPHIALM.TMO
l OPHIALM.DB
l OPHIALM.DBU
- 288 -
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.
- 289 -
Configuration Description
Tab
Main l Name - Block (Tag) name of up to 16 characters long. Must be unique
within the CM block containing it.
l Description (DESC) - Block descriptor of up to 132 characters long.
l 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.
l 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.
l 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.
l 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).
l 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.
l 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.
l 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.
l External request for MODE switching.
l Safety interlock request.
l 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.
l 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.
l 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).
l Enable External Mode Switching (ESWENB) - Lets you specify if external
MODE switching through user configured interlocks is enabled or not, if
- 290 -
Tab
ESWPERM is checked (Permitted). The default is Disabled (unchecked).
l 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).
l 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.
l 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.
l 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.
l 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.
l 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.
Output l 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%.
l Low Limit (%) (OPLOLM) - Lets you specify the output low limit as a
example, If the CV range is 50 to 500 and you enter a Low Limit of 10%,
the low limit in engineering units is 10% times 450 or 45 + 50 (CVEULO)
equals 95. This check is not applied for a function block that is in the
MANual mode. The default value is -5%.
l 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%.
l Extended Low Limit (%) (OPEXLOLM) - Lets you specify the output
- 291 -
Tab
extended low limit as a percent of the Calculated Variable range (CVEUHI
default value of -6.9%, the extended low limit in engineering units is -
6.9% times 450 or -31.05 + 50 (CVEULO) equals 18.95. This check is not
applied for a function block that is in the MANual mode. The default value
is -6.9%.
l 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
is Not a Number (NaN), which means no rate limiting is applied.
l 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
is 0, which means no change limiting is applied.
l Safe OP (%) (SAFEOP) - Lets you specify the safe output value as a
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.
l 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.
l 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.
l 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.
l 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.
l 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.
Alarms l 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:
l Safety Interlock (SIALM.FL)
l Bad Control (BADCTLALM.FL)
- 292 -
Tab
l OP High (OPHIALM.FL)
l OP Low (OPLOALM.FL)
l 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.
l 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.
l 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:
l NONE - Alarm is neither reported nor annunciated.
l JOURNAL - Alarm is logged but it does not appear on the Alarm
Summary display.
l LOW, HIGH, URGENT - Alarm is annunciated and appears on
the Alarm Summary display.
l 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.
l 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.
l 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
- 293 -
Tab
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.
l Deadband Units (ALMDBU/xxxxALM.DBU) - Defines the unit for the
deadband value - percent or engineering units. The default value is
percent.
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.
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.
l 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:
l 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.
l 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.
l 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).
SCM l 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:
l None
l ONESHOT
l SEMICONT
- 294 -
Tab
l CONTRTN
l CONT
l 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:
l NONE - No changes.
l MAN - Set MODEREQ = MANUAL.
l AUTO - Set MODEREQ = AUTOMATIC (not applicable to this
block).
l CAS - Set MODEREQ = CASCADE.
l FIXEDOP - Set OPREQ = Configured Value.
l HOLDPV - Set SPREQ = PV.
l FIXED SP - Set SPREQ = Configured Value and SPRATEREQ =
NaN.
l RAMPEDSP - Set SPTVREQ = Configured Value and
SPRATEREQ = Configured Rate.
l 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 Lets you select the available parameters that you want to appear on the face of
Parameters the function block in the Project tab in Control Builder.
Monitoring Lets you select the available parameters that you want to appear on the face of
Parameters the function block in the Monitoring tab in Control Builder.
Block Lets you change several block-viewing preferences including the color of the
Preferences 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:
- 295 -
K = gain for CV (user specified)
X1 = input value
OPBIAS.FIX = fixed output bias (user specified)
OPBIAS.FLOAT = floating output bias (calculated)
l K and OPBIAS.FIX may either be fixed (that is, stored manually or by the program) or external
(that is, brought from another block).
l After an initialization, the block calculates OPBIAS.FLOAT as follows:
OPBIAS.FLOAT = CVINIT - [K*X1 + OPBIAS.FIX]
where: CVINIT = initialization value from the secondary
l Function-AUTOMAN
l Configuration example-AUTOMAN
l Inputs-AUTOMAN
l Output-AUTOMAN
l Initializable inputs and outputs for AUTOMAN
l Output ranges of AUTOMAN
l Output bias-AUTOMAN
l Output Indication function for AUTOMAN
l Mode Handling-AUTOMAN
l Timeout Monitoring-AUTOMAN
l Control Initialization-AUTOMAN
l Secondary initialization option-AUTOMAN
l Override feedback processing-AUTOMAN
l Windup processing-AUTOMAN
l Anti-Reset Windup Status-AUTOMAN
l AUTOMAN parameters
19.5.1 Function-AUTOMAN
The AUTOMAN block is typically used:
l in a cascade control strategy where one of the upstream blocks may not accept an initialization
request from its secondary.
l between a FANOUT block and a final control element to provide a “bumpless” output on return
to cascade
ATTENTION
The AUTOMAN block:
l has one primary and one secondary.
l requests the primary to initialize when mode changes from CAScade to MANual.
- 296 -
19.5.2 Configuration example-AUTOMAN

uses an AUTOMAN block between a FANOUT block and a downstream PID block for quick
reference.
Table 19.3 Example of CB configuration using AUTOMAN block.
- 297 -
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.
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.
l CV = K * X1 + OPBIAS.FIX + OPBIAS.FLOAT
l where:
l K = gain for CV
l X1 = input value
l OPBIAS.FIX = fixed output bias (user-specified)
l OPBIAS. FLOAT = floating output bias (calculated)
19.5.3 Inputs-AUTOMAN
The AUTOMAN block requires one input - X1:
l X1 = initializable input which, if used, must be pulled from another block (it cannot be stored to).
l An engineering unit range for X1 (XEUHI and XEULO) must be specified.
l XEUHI and XEULO define the full range of X1:
o XEUHI represents the 100% of full-scale value.
o 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.5.4 Output-AUTOMAN
The AUTOMAN block has the following initializable outputs:
- 298 -
l OP = calculated output, in percent.

l 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.5.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 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.5.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).
l 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.
l 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.
- 299 -
19.5.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.
l 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.)
o When the function block starts up (that is, goes Active).
o When the function block initializes (for example, the secondary requests initialization).
o When the mode changes to Cascade.
l The following occurs when you set the OPBIAS value.

o The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the entered value.
o 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.
l 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.
l 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.
l 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:
o The total bias (OPBIAS) and fixed bias (OPBIAS.FIX) are both set to the new value.
l 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)
l 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
- 300 -
be zero.
If OPBIAS.FLOAT is not zero, you can configure it to ramp down to zero through the
OPBIAS.RATE parameter.
l 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.
o 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.
o 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)
l 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.5.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.
If OUTIND Then, Its Function Is …

Enumeration
Selection 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
(This is the default percent points on the OP bar graph on the faceplate display.
selection, so legacy OP
values remain the
same.)
Reverse Value reversal - output range is 100 to 0 percent, and no display

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

- 301 -

Enumeration
Selection Is …
points on the OP bar 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 Reverse of Actual OPHIALM.PR and .SV, and
and .SV 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.
- 302 -
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:
l from Direct, DirectDispInd, or ReverseDispInd to Reverse or
l 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.5.9 Mode Handling-AUTOMAN

The AUTOMAN block supports both the Cascade and Manual modes:
l If Mode is CAScade: X1 must come from another block.
l If Mode is MANual: an operator or a user program (X1 is ignored) may store OP.
19.5.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:
- 303 -
l Sets the “input timeout” flag (TMOUTFL).

l Sets the input value to Bad (NaN - Not a Number).
l 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)
l Enable timeout monitoring by setting TMOUTTIME to a non-zero value.
l Disable timeout monitoring by setting TMOUTTIME to zero.
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.5.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 -
l Initializes its output so CV = initialization value from the secondary
l Builds an initialization request for the X1 primary as follows:
INITREQ(X1) = On
l 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
- 304 -
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.5.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.
l If SECINITOPT equals Enable, it means the function block should accept initialization and
override requests from the secondary.
l If SECINITOPT equals Disable, it means the function block should ignore initialization and
19.5.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:
l does not initialize its CV, and
l computes a feedback value for its primary as follows:
feedback value for primary = (override feedback value from secondary - OPBIAS.FIX -
OPBIAS.FLOAT) / K
19.5.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.
- 305 -
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).
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.
- 306 -
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.5.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 Standard Computation ARWNET or ARWOP

Parameter Is… Logic Is … Parameter Is …
NORMAL NORMAL NORMAL
NORMAL HI HI
NORMAL LO LO
NORMAL HILO HILO
HI NORMAL HI
HI HI HI
HI LO HILO
- 307 -

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.5.16 AUTOMAN parameters

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

The ENHREGCALC block provides the following enhancements over the REGCALC block.
l Expands existing arrayed input parameters XSTS and X from six to ten.
l These arrayed parameters are added to correspond to each of the ten inputs.
o Input Description
o Enable/Disable Switch
o XSUB Substitute Parameter
l 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
l Mode can be placed in Automatic so operator or program can supply SP.
l 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.
- 308 -
l OPHIALM.TM
l OPHIALM.TMO
l OPHIALM.DB
l 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.
l
- 309 -
Tab
reports.
NOSHED.
OPERATOR, and PROGRAM. The default selection is NONE.
“runtim” based on current conditions. MODE processing checks for the
(unchecked).
- 310 -
Tab
ignore).

Setpoint l SP (SP) - Lets you specify an initial set point value. The default value is 0.
l 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.
l 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.
l Setpoint Engineering Units High Range (SPEUHI) - Lets you specify the
high SP input range value in Engineering Units that represents 100%
full scale input. The default value is 100.
l 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).
l 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.
l 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.
l 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.
l Normal Ramp Rate (SPTVNORMRATE) - Lets you specify a ramp rate in
engineering units per minute for the SP ramping function, when it is
- 311 -
Tab
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.
l 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 l X Description (XDESC[1..10]) - Lets you enter a description for a given X

input. The default value is null or blank.
l X Enable (XENABLE[1..10]) - Lets you select whether a given X input is
enabled or disabled. The default value is selected on enabled.
l X Substitute (XSUB[1..10]) - Lets you specify a substitute value to used
for the given X input. The default setting is NaN.
l XK (XK[1..10]) - Lets you specify an individual gain value for each of the
ten X inputs. The default value is 1.
l 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.
l 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]
value is 106.9%.
is -6.9%.
- 312 -
Tab
last good value. ’
when the floating bias in non-zero. See the Output Bias section for this
equation 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.
value is 240.
(K) is clamped to this value, if the specified gain is less than it. The default
value is 0.
l CV (CVSRC) - Lets you assign an input or expression result as the source
for the CV. The default selection is NONE.
l CV Initialization (CVINITSRC) - Lets you assign an input or expression
result as the source of the CV initialization. The default selection is NONE.
l CV Override (CVORFBSRC) - Lets you assign an input or expression result
as the source of the CV during override. The default selection is NONE.
l 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.
l If a source is assigned, this block uses the assigned source
value even if a secondary does exist.
l If no source is assigned and a secondary does exist, this block
uses the corresponding value from the secondary.
l If no source is assigned and there is no secondary, this block
uses default values (NaN for values, OFF for flags).
- 313 -
Tab
l 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 whether or not a source is assigned and a secondary
exists as follows.
l Override Feedback Status (ORFBSTSSRC) - Lets you assign an input or

expression result as the source of the override feedback status for the
l Override Feedback Value (ORFBVALSRC) - Lets you assign an input or

expression result as the source of the override feedback value for the
value even if a secondary exists.
l If no source is assigned and a secondary exists, this block uses
the corresponding value from the secondary.
Alarms l Type - Identifies the types of alarms this block supports. Of course, these
The types are:

You can also configure the SIALM.OPT parameter as a block pin, a
- 314 -
Tab
type (SIALM.PR, BADCTLALM.PR, OPHIALM.PR, OPLOALM.PR). The
Summary display.
type (SIALM.SV, BADCTLALM.SV, OPHIALM.SV, OPLOALM.SV) as a
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.
CB.
With R410, the 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
condition occurs.
- 315 -
Tab
percent.
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.
setting manually.
This parameter is available for configuration only if the Enable

when the OP value is less than the 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).
upon the MODE of the SCM. See the SCM Interface and CM Interaction
section in this document for selection details. The default selection is
l None
l ONESHOT
l SEMICONT
l CONTRTN
l CONT
- 316 -
Tab
l AUTO - Set MODEREQ = AUTOMATIC.
l HOLDPV - Set SPREQ = PV (not applicable to this block).
NaN (not applicable to this block).
SPRATEREQ = Configured.

respective range. For output, within OPEXLOLM to OPEXHILM and within
Number).
l 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 l Expression (C[1..8]) - Lets you write up to eight desired expressions for
Expr# 8 custom calculations. You can also write a short descriptive text for each
expression.
l See the Guidelines for writing expressions section for this block for more
details.
information
l Function-ENHREGCALC
l Configuration example-ENHREGCALC
l Operating modes and mode handling for ENHREGCALC
l Inputs-ENHREGCALC
l Initializable input-ENHREGCALC
- 317 -
l SP limit checking-ENHREGCALC
l SP target value processing-ENHREGCALC
l Initializable outputs-ENHREGCALC
l Output ranges and limits-ENHREGCALC
l Assignable outputs-ENHREGCALC
l Output assignment rules-ENHREGCALC
l Control initialization-ENHREGCALC
l Output bias-ENHREGCALC
l Output Indication Function-ENHREGCALC
l Timeout monitoring-ENHREGCALC
l Timeout processing-ENHREGCALC
l Mode shedding on timeout-ENHREGCALC
l Override feedback processing-ENHREGCALC
l Windup handling-ENHREGCALC
l Windup processing-ENHREGCALC
l Anti-Reset Windup Status-ENHREGCALC
l Expressions
l Parameters in Expressions
l Guidelines for Writing Expressions
l Enable/Disable switch example expression
l String data support in expressions
l Time support in expressions
l Restart or point activation
l ENHREGCALC parameters
19.6.1 Function-ENHREGCALC
l Each expression can contain any valid combination of inputs, operators and functions; and
may perform arithmetic or logic operations.
l 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.
l 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.
- 318 -
19.6.2 Configuration example-ENHREGCALC

The following figure shows a sample configuration using an ENHREGCALC block in a ratio control
loop.
Table 19.4 Example of CB configuration using ENHREGCALC block.
19.6.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 the block derives OP; the initializable input (SP) may be stored by the operator
(AUTO) 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.6.4 Inputs-ENHREGCALC
The ENHREGCALC block has the following inputs.
- 319 -
l 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.
l X[1] through X[10] general purpose inputs.
l XB[1..10] individually configurable bias value for each X input.
l XDESC[1..10] individually configurable description for each X input.
l XENABLE[1..10] individually configurable enable/disable switch for each X input.
l XK[1..10] individually configurable gain value for each X input.
l XKB[1..10] individual inputs with gain and bias values applied to them.
l XSTS[1..10] individual status for each X input.
l XSUB[1..10] individually configurable substitute value for each X/PX input, when
corresponding X input is disabled.
l XWHIFL - An external windup high flag.
l 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.6.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.
l SP limit checking
l 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.6.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:
l SPHILM SP high limit
l 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.6.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.
- 320 -
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:

l At configuration time, you should:
o Enable SP target value processing by setting SPTVOPT to Enable. If SPTVOPT setting
is Disable, you cannot store to any other SPTV parameter.
o 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).
l To invoke SP ramping, you must do the following:

o 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:
o The system calculates a ramp time (SPTVTIME), based on the normal ramp rate
o SPTVSTATE goes to Preset.
o 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.
l 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
l 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
l 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:
- 321 -
SPTVRATE = SPTVNORMRATESPTVTIME = |(SPTV - SP)| / SPTVRATE

Otherwise,
SPTVRATE = NaN
SPTVTIME = 0 or do a step change
Notes on SP target value processing
l To start ramping to set SPTVSTATE equals Run:

o MODE must be AUTO
o SPTVSTATE must be Preset
l SPTVSTATE automatically goes to Preset when:

o SPTV or SPTVTIME are stored
o MODE changes to Manual while SPTVSTATE is in Run
o The function block is initialized (INITMAN = ON) while SPTVSTATE is in Run
o Control Module goes to Inactive
TIP
A one shot initialization does not cause a change in SPTVSTATE.
l SPTVSTATE automatically goes to Off when:

o SP is stored by the operator, a user program or another function block
o MODE changes to Cascade or Backup Cascade
l SPTV and SPTVTIME can only be stored if:

o SPTVSTATE is Off or Preset, and
o MODE is Auto or Manual
l 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.
l 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.
19.6.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.
- 322 -
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.
l The ENHREGCALC block has the following initializable outputs:
o OP = calculated output in percent.
o 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.6.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.6.10 Assignable outputs-ENHREGCALC

You can assign expression results and/or inputs to the following parameters.
- 323 -
l CVSRC - CV output source selector.

l CVINITSRC - CVINIT source selector.
l CVORFBSRC - CVORFB source selector.
l INITREQSRC - INITREQ (initialization request flag) source selector.
l INITVALSRC - INITVAL (initialization value) source selector.
l ORFBVALSRC - ORFBVAL (override feedback value) source selector.
l 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.6.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.
l The following parameters should be assigned to an input or an expression result

o 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.
o 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.
o 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
- 324 -
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.
l The following parameters are provided to the primary through this block's BACKCALC data.
o INITREQSRC
o INITVALSRC
o ORFBVALSRC
o ORFBSTSSRC
o 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 Then, This Block. . .

... Secondary. . .
assigned does or does not uses the assigned value.
exist
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.6.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:

l initializes its output:
CV =CVINIT (an assignable output)
l 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.6.13 Output bias-ENHREGCALC

- 325 -
the ENHREGCALC block only applies OPBIAS.FLOAT to the output for the latter two conditions,
when it is the first initializable block.)
o When the mode changes to Auto or Cascade.

ATTENTION
necessary.
following occurs:
Where:
same as CVININT and OPBIAS.FLOAT will be zero. In most cases, OPBIAS.FLOAT will be zero.
be zero.
l 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.
- 326 -
o 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.
o Non-zero:
Where:
l NaN:
l After initialization, the ENHREGCALC block calculates the floating bias using the following
equation.
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.6.14 Output Indication Function-ENHREGCALC

display.
- 327 -
If OUTIND Then, Its Function Is . . .

Enumeration
Selection Is . . .
values remain the
same.)



ATTENTION
Considerations for OUTIND Reverse selection
A Get of This Parameter . . Equals This . . .

- 328 -
A Get of This Parameter . . Equals This . . .


OPROCNEGFL

FixedOp.)
ATTENTION
Migration and Checkpoint support for OUTIND
REVERSE.
- 329 -
19.6.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.

19.6.16 Timeout processing-ENHREGCALC

If SP times out, the ENHREGCALC block does the following:
l Sets the input timeout flag (TMOUTFL)
l Holds SP at its last good value.
l Sheds to a user-specified timeout mode (MODE = TMOUTMODE).
l Requests the SP primary to initialize (via BACKCALCOUT)
ATTENTION
19.6.17 Mode shedding on timeout-ENHREGCALC
l 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:
o Changes the mode back to CAScade.
o Updates the SP.
l You cannot set the CASREQFL. However, it can be cleared by setting the block's MODE to
MANUAL.
l If you want to disable the automatic return to CAScade, you may do one of the following:
o Store to MODE, which causes the CASREQFL to be cleared.
o Store to CASREQFL.
l 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.6.18 Override feedback processing-ENHREGCALC

If the ENHREGCALC block is in a cascade strategy with a downstream OVRDSEL (Override
- 330 -
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)
l 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
- 331 -
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.6.19 Windup handling-ENHREGCALC

The ENHREGCALC block derives the ARWOP from a combination of the following parameters and
the secondary's windup status.
l CV
l XWHIFL
l XWLOFL
The following table summarizes how the block derives ARWOP for some given conditions.
If XWLOFL and/or XWHIFL And a Then, the Block Derives ARWOP

are. . . Secondary. . . from . . .
True does or does not CV, XWHIFL, and XWLOFL.
exist
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.
ATTENTION
The ARWNET[1] computation is independent of whether gain (K) is positive or negative.
19.6.20 Windup processing-ENHREGCALC

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

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

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

ARWNET
Equals . . .
The CV is NaN

- 333 -

ARWNET
Equals . . .
On)

This block's output has reached its negative rate-of-change limit (OPROCNEGFL
= On)
19.6.21 Anti-Reset Windup Status-ENHREGCALC

configurable and allow stores from Sequential Control Modules (SCMs) and control algorithm block
(CAB) programs.

Parameter Is. . . Logic Is . . . 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
LO LO LO
LO HILO HILO
HILO NORMAL HILO
HILO HI HILO
- 334 -

HILO LO HILO
HILO HILO HILO
19.6.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 19.5 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 MID medium value of n arguments

bad values). (average of middle values for
even n).
If this function has a NAN
argument (bad value), it returns If this function has a NAN
- 335 -
NaN. argument (bad value), it returns
NaN.
MAX maximum of n arguments (ignore MUL product of n arguments.
bad values).
This function ignores NaN values.
If this function has a NAN However, if all arguments are
argument (bad value), it returns NaN, then it returns 1.
NaN.
AVG average of n arguments. SUM sum of n arguments.
This function ignores NaN values. This function ignores NaN values.
However, if all arguments are NaN, However, if all arguments are
then it returns NaN. NaN, then it returns 0.
String Support Functions
LEN Returns an integer length of the NUMSTR Takes the input parameter, casts
string it to a Float64 and converts it to a
string
MIDS Takes a string, an integer starting STRNUM Takes the string input parameter
position and an integer length. The and converts it to a Float64
function returns the specified
portion of the original string.
Time Support Functions
ABSTOD Takes an absolute time data type DTIMNUM Takes a delta TIME data type and
and strips off the year and date and returns a 64-bit float
returns a 64-bit float representing representing the number of
the time of day in milliseconds. milliseconds.
NOW Returns the current local date and NUMDTIM Takes a 64-bit float representing
time as an absolute time data type some number of milliseconds and
converts it to a delta TIME data
type.
NUMTIM Takes a 64-bit float representing STRTIM Takes a string input parameter
the number of milliseconds since and converts it to an Absolute
Jan 1, 1972 and converts it to time. The string must be in the
absolute TIME data type. same format as an Absolute time
constant.
TOD Returns the current local time of TIMNUM Takes an Absolute TIME data type
day as Time of Day data type and returns a 64-bit float
representing the total number of
milliseconds since Jan 1, 1972.
UTCTOD Returns the current UTC time of UTCNOW Returns the current UTC date and
day as Time of Day data type time of 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. . .)
- 336 -

E e (2.718. . .)
19.6.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 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:
l TagName.‘text’
TagName is the name of the external reference component (i.e. an OPC Server). Text can contain
any characters, space, and special characters except for the delimiter character.
When entering this format, only the syntax and TagName are checked for accuracy. The correct
syntax of TagName-dot-delimiter-text-delimiter is verified and the TagName is verified to be an
external reference component. If either of these stipulations is incorrect, an error is issued. The
text between the delimiters is not checked. It is the users responsibility to ensure that the text is
something that the external reference component will understand. If this text is incorrect, runtime
errors will occur.
ATTENTION
When the expression is sent to the external reference component, the delimiters are
removed: TagName.‘text’ becomes TagName.text.
19.6.24 Guidelines for Writing Expressions
l 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.
l 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.
- 337 -
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.
l You can mix and nest all operators and functions (including conditional assignments) in any
order as long as types match or can be converted.
l You can use blanks between operators and parameter names, but they are not required.
l 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.
l 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:
o 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:
l An expression can be configured using the expression constants parameters (CONST[1..8]).
CM1.CALC1.CONST[1] * CM1.CALC1.X[2] + CM2.REGCALCA.CV

l The expression constant parameters (CONST[1..8]) support runtime indexing in the
expressions.
CM1.CALC1.CONST[CM1.CALC1.X[1]] + CM1.CALC1.X[2]
l 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.
- 338 -
l 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.6.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.6.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”
19.6.27 Time support in expressions
Time data types
The following time data types are supported in expressions.

l Absolute Time - Is stored as a 64-bit integer representing the number of tenths of
milliseconds since 1/1/1972.
l Delta Time - Is also stored as a 64-bit integer and it represents an Absolute time difference in
tenths of milliseconds.
l Time of Day - is an unsigned 32 -bit integer that represents a time of day in tenths of
milliseconds.
- 339 -
Time constants
You can use the following valid time constants in expressions.

l An Absolute Time constant is entered MM/DD/YYY hh:mm:ss:uuuu, where uuuu is
milliseconds
l A Delta Time constant is entered as hh:mm:ss:uuuu, where uuuu is milliseconds
l 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 19.6 1The DAY, HOURS, MINS, SECS Operators are not case specific.
expression to a reference. The data type in the expression result must agree with
the data type of the reference.
+ If both operands are of the same time data type the result is the same data type.
Delta time or Time of Day can be added to an absolute time, which results in
absolute time. Time of day can be added to delta time, which results in a delta time.
See the next section Adding time data types. .
* One operand can be a delta time or time of day data type and the second operand
must be a number. The result is a delta time data type.
- 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.
DAYS 1 Takes operand and returns equivalent delta time value.
HOURS 1 Takes operand and returns equivalent delta time value.
MINS 1 Takes operand and returns equivalent delta time value.
SECS 1 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
- 340 -
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.

l MYCM.block.elapsedtime > 5 MINS
l CEE01.CURRTIME + 2 DAYS
l CEE01.CURRTIME > 10/30/2002
l CEE01.CURRTIME + CM.TIMER.SP SECS
l (CEE01.CURRTIME - 1/01/2002 10:15:01) *2.
l STRTIM("12/01/2002") > CEE01.CURRTIME
l TIMNUM(CEE01.CURRTIME)
l NUMTIM(1000.0)=NOW
l NOW - MyCM.myblock.todparam
l ABSTOD(CEE01.CURRTIME)
The following are examples of invalid expressions.
l CEE01.CURRTIME + 2
l CEE01.CURRTIME > 5.0
Refer to Time Support in Experion System for more information about time support in the system
19.6.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.6.29 ENHREGCALC parameters

the ENHREGCALC block.
19.7 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
- 341 -
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.
l BADCTLALM.TM
l BADCTLALM.TMO
Each FANOUT block supports the following user configurable attributes. The following table lists
- 342 -
Tab
reports.
document for more information. This is the block's parameter.
(zero).
(unchecked).
- 343 -
Tab
NOSHED.
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 l High Limit (%) (OPHILM) - Lets you specify the output high limit as a
Output percent of the Calculated Variable range (CVEUHI - CVEULO). For
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%.
- 344 -
Tab
is -6.9%.
last good value.
value is 240.
value is 0.
l 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.
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 l Gain (K[1..8]) - Lets you specify a gain (K) value to be factored into the
Output equation for calculating the CV output value for each individual output.
See the equation following this table for details. The default value is 1.
l Output Bias (OPBIAS[1..8].FIX) - Lets you specify a fixed bias value in
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.
l Output Bias Rate (OPBIAS[1..8].RATE) - Lets you specify an output
floating bias ramp rate in engineering units per minute for each
- 345 -
Tab
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.
l 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).
The types are:

configuration and/or a monitoring parameter so it appears on the block
in the Project and Monitoring tree view, respectively.
type (SIALM.PR, BADCTLALM.PR). The default value is LOW. The levels
are:
Summary display.
type (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.
l Deadband Time (BADCTLALM.TM) -
With R410, this parameter is introduced to define the duration in seconds
condition occurs.
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.
- 346 -
Tab
setting manually.
l 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).
l None
l ONESHOT
l SEMICONT
l CONTRTN
l 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:
l AUTO - Set MODEREQ = AUTOMATIC (Not applicable for this
block).
l HOLDPV - Set SPREQ = PV (Not applicable for this block).
NaN (Not applicable for this block).
l RAMPEDSP - Set SPREQ = Configured Value and SPRATEREQ =
Configured Rate (Not applicable for this block).
- 347 -
Tab
Number).
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)
l A separate gain [K(n)] and bias [OPBIAS(n).FIX] may be specified for each output.
l 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.
l The FANOUT block applies a separate floating bias to each output.
l 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
- 348 -
ATTENTION
The FANOUT block is the only Regulatory Control Block that can have multiple secondaries.
l Function-FANOUT block
l Configuration example-FANOUT block
l Inputs-FANOUT block
l Outputs-FANOUT block
l Initializable inputs and outputs for FANOUT block
l Output ranges for FANOUT block
l Output bias-FANOUT block
l Mode handling-FANOUT block
l Timeout monitoring-FANOUT block
l Control initialization-FANOUT block
l Secondary initialization option-FANOUT block
l Override feedback processing-FANOUT block
l BACKCALC processing
l Output Indication Function
l Windup processing in FANOUT block
l Windup processing in Regulatory blocks
l Anti-Reset Windup Status
l FANOUT parameters
19.7.1 Function-FANOUT block

The FANOUT block provides a “bumpless” output for each of up to eight outputs following
initialization or mode changes.
19.7.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.7.3 Inputs-FANOUT block

The FANOUT block requires one input - X1:
l X1 = initializable input which must come from another block (it cannot be set by an operator or
a program).
l 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.
l XEUHI and XEULO define the full range of X1:
o XEUHI represents the 100% of full scale value.
o XEULO represents the 0% of full scale value.
- 349 -
ATTENTION
The FANOUT block:
l has 1 input and as many as 8 initializable outputs, and
l has 1 primary and up to 8 secondaries.
It requests the primary to initialize when mode changes from CAScade to MANual.
19.7.4 Outputs-FANOUT block

The FANOUT block may have up to 8 initializable outputs as follows:
l OP[1..8] - calculated output, in percent.
l OPEU[1..8] - calculated output, in engineering units.
19.7.5 Initializable inputs and outputs for FANOUT block

level. A parameter with the “initializable” attribute has an associated BACKCALC parameter and,
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 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 FANOUT block to an AUTOMAN block or an AOCHANNEL
block, Control Builder automatically creates the BACKCALCOUT to BACKCALCIN connection.
l 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.)
l A separate gain and bias may be specified for each output.
l The FANOUT block applies a separate floating bias to each output.
l Gain limits may be configured with negative values, thereby making it possible to reverse
outputs by using negative gains.
l 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.7.6 Output ranges for FANOUT block
l CVEUHI[1..8] and CVEULO[1..8] define the full range of CV in engineering units for each given
output.
o 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.
o 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
- 350 -
[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.
o 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).
range. These are user-specified values. The same limits apply to all outputs.
o 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.
CV range. 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.7.7 Output bias-FANOUT block

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.
function block initializes or changes mode as long as the FANOUT block is the first initializable
block.
the function block only applies OPBIAS.FLOAT to the output for the latter two conditions, when
o 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.
necessary.
- 351 -
following occurs:
The OPBIAS.FLOAT is calculated as follows.
Where:
be zero.
l You configure the OPBIAS.RATE to apply a ramprate to the OPBIAS.FLOAT. It is only used when
o Zero:
o Non-zero:
o The function block ramps the OPBIAS.FLOAT to zero by applying the following
Where:
l NaN:
19.7.8 Mode handling-FANOUT block

The FANOUT block supports both the Cascade and Manual modes:
l If mode is CAScade, then: X1 must be pulled from another block.
l If mode is MANual, then: OP may be stored by the operator or a user-program
(X1 is ignored).
- 352 -
19.7.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:
l Sets the “input timeout” flag (TMOUTFL).
l Sets the input value to Bad (NaN - Not a Number).
l Requests the X1 primary to initialize (through X1BACKCALCOUT).
The FANOUT block does not support mode shedding on timeout.

l Disable timeout monitoring by setting TMOUTTIME to zero
ATTENTION
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
19.7.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 -
l Initializes its output so CV[1..8] = INITVAL[1..8] from corresponding secondary
l Builds an initialization request for the primary as follows:
INITREQ(X1) = On
NOTE Note
The gain value should be greater than zero.
l Where
- 353 -
(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 = fixed output bias for the last secondary

(last).FIX
K(last) = gain for the last secondary
NOTE Note
INITREQ = initialization request flag for the X1 primary

(X1)
INITVAL = initialization value for the X1 primary

(X1)
ATTENTION
l SECINITOPT may be used to ignore initialization requests from selected
secondaries.
l 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.
l 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:
o 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.
o 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.
l When FANOUT block comes out of initialization, it calculates INITVAL(X1) as follows:
l Where:
- 354 -
(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.7.11 Secondary initialization option-FANOUT block

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

The FANOUT block does not propagate override data to its primaries.
19.7.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.7.14 Output Indication Function

display.
- 355 -

Enumeration
Selection Is . . .
values remain the
same.)



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

- 356 -


OPROCNEGFL

FixedOp.)
ATTENTION
REVERSE.
- 357 -
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 l PID OUTIND = Direct
l AOCHANNEL OPTDIR = Direct
l PID OP 0% translated to 4 mA by the AO,
corresponding to the valve closed
l PID OP 100% translated to 20 mA by the
AO, corresponding to the valve open
l Unpowered state of AO results in 0 mA and
valve closed
Fail open valve; air to close - reversal handled l PID OUTIND = Direct
in AO channel
l AOCHANNEL OPTDIR = Reverse
valve open
Fail open valve; air to close - display l PID OUTIND = ReverseDispInd

indications highlight reverse acting valve
corresponding to the valve open
AO, corresponding to the valve closed
valve open
19.7.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:
l If all secondaries are in high windup, the FANOUT block propagates a high windup status to its
primary (ARWNET = Hi).
l 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.
- 358 -
The FANOUT block propagates a normal windup status to its primary under the following
conditions:
l If at least one secondary has a normal windup status.
l 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.7.16 Windup processing in Regulatory blocks


ARWOP computation

Equals …
- 359 -

Equals …
ARWNET computation

ARWNET
Equals …
The CV is NaN

On)

On)
19.7.17 Anti-Reset Windup Status

(CAB) programs.
- 360 -

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.7.18 FANOUT parameters

the FANOUT block.
- 361 -
19.8 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:
l OPHIALM.TM
l OPHIALM.TMO
l OPHIALM.DB
l OPHIALM.DBU
Each OVRDSEL block supports the following user configurable attributes. The following table lists
- 362 -
Tab
reports.
l 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.
l 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.
l 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.
secondary or not. The default selection is enabled (checked, do not
ignore).
- 363 -
Tab
(unchecked).
NOSHED.
Input l 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.
represents the 0 full scale input for all the block inputs (X[1..4]). The
default value is 0 (zero).
l 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.
disabled.
l Description - Lets you enter up to a 15-character description for each
- 364 -
Tab
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.
l 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).
l 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.
units is 106.9% times 450 or 481.05 + 50 (CVEULO) equals 531.05. The
6.9% times 450 or -31.05 + 50 (CVEULO) equals 18.95. The default
value is -6.9%.
- 365 -
Tab
last good value.
The types are:

Summary display.
the alarm processing order relative to other alarms. The default value is
0.
- 366 -
Tab
CB.
With R410, deadband value can be individually configured for each
condition occurs.
percent.
OVRDSEL block. If you configure the deadband unit as “EU or Percent”
OVRDSEL block. However, if you are migrating from pre-R410 to later
Note: You must configure identical deadband units for all alarms in the
OVRDSEL block.
setting manually.
- 367 -
Tab
Note: This parameter is available for configuration only if the Enable Bad
Output Connection Option is enabled.
l None
l ONESHOT
l SEMICONT
l CONTRTN
l CONT
l AUTO - Set MODEREQ = AUTOMATIC (Not applicable for this
block).
l HOLDPV - Set SPREQ = PV (Not applicable for this block).
NaN (Not applicable for this block).
SPRATEREQ = Configured Rate (Not applicable for this block).

Number).
- 368 -
Tab
information
l Function-OVRDSEL block
l Configuration example-OVRDSEL block
l Configuration considerations-OVRDSEL block
l Inputs-OVRDSEL block
l Input ranges for OVRDSEL block
l Input descriptors-OVRDSEL block
l Initializable outputs-OVRDSEL block
l Output ranges and limits for OVRDSEL block
l Output Indication Function-OVRDSEL block
l Mode handling-OVRDSEL block
l Timeout monitoring-OVRDSEL block
l Timeout processing-OVRDSEL block
l Bypass processing-OVRDSEL block
l Bad input option
l OVRDSEL Equations
l Input switching
l Output bias-OVRDSEL
l Bad CV processing
l Control initialization-OVRDSEL
l Restart or function block activation
l Override feedback propagation
l Recommendations on configuring override strategies
l Windup processing
l OVRDSEL parameters
19.8.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
- 369 -
selecting the Enable Override Option check box on the block's parameter configuration form.
If Then, . . .
OROPT
is . . .
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:
l 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.
l 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:
l For a given input path, propagation stops at a block that is inactive.
l For a given path, propagation is interrupted at a block with an off-node primary. The primary
resumes propagation on its next execution cycle.
l 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.
- 370 -
ATTENTION
The system's ability to interrupt and resume override propagation has advantages and
disadvantages.
l The advantages are, there are no limitations on the number of blocks in an override
strategy or where the blocks reside.
l 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
19.8.2 Configuration example-OVRDSEL block

uses an OVRDSEL block to provide override feedback data to upstream PID blocks for quick
reference.
Table 19.7 Example of CB configuration using OVRDSEL block.
- 371 -
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 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 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.
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.

l Anti-Reset Windup Status: Indicates if the secondary's initializable input (which is
this block's output) is at its high or low limit.
l 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.
l Oneshot Initialization Flag: Used to request one shot 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.
l Initialization Value: Used for continuous and one shot initialization.
l 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.
l Override Feedback Value: Similar to initialization value; this is calculated to
prevent “wind-up” in unselected primaries.
l 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.
l 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.8.3 Configuration considerations-OVRDSEL block

Keep the following considerations in mind when configuring control strategies using OVRDSEL
blocks.
- 372 -
l 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.
l 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.
o 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.
o 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.
o 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.8.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.
l X[1] through X[4] are initializable inputs.
l The inputs must be pulled from other function blocks; you cannot store to them.
l 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.8.5 Input ranges for OVRDSEL block

XEUHI and XEULO define the full range of inputs.
l XEUHI represents the 100% of full scale value.
l 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.8.6 Input descriptors-OVRDSEL block

You can define descriptor (name) of up to 15-characters for each input. The descriptors reside in
- 373 -
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.8.7 Initializable outputs-OVRDSEL block

level. A parameter with the “initializable” attribute has an associated BACKCALC parameter, and
when you create a connection between an initializable input and initializable output, you can also
create a BACKCALC connection. Control Builder automatically builds the required BACKCALC
connections, so you don't have to create them manually. These “implicit” build connections are
“hidden” from view and the related parameter pins are not exposed on the control chart.
For example, if you connect OP from a PID block to an OVRDSEL block or an AOCHANNEL block,
Control Builder automatically creates the BACKCALCOUT to BACKCALCIN connection.
The OVRDSEL block has the following initializable outputs:
l OP = Calculated output, in percent.
l 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
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.)
19.8.8 Output ranges and limits for OVRDSEL block
l CVEUHI and CVEULO define the full range of CV in engineering units.

l This block doesn't have CVEUHI and CVEULO as configurable parameters for the reasons given
below:
o 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).
l OPHILM and OPLOLM define the normal high and low limits for OP, as a percent of the CV
o 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.
l OPEXHILM and OPEXLOLM define the extended high and low limits for OP, as a percent of the
CV range. These are user-specified values.
o The operator is prevented from storing an OP value that exceeds these limits.
- 374 -
l 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.8.9 Output Indication Function-OVRDSEL block

display.
You choose from the following configuration selections to tailor the block#39;s output to meet
your particular operation and display requirements.

Enumeration
Selection Is . . .
values remain the
same.)



ATTENTION

- 375 -


OPROCNEGFL

FixedOp.)
ATTENTION
REVERSE.
- 376 -
19.8.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.)
MANual to CAScade.
19.8.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.8.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 :
l Sets the “input timeout” flag (TMOUTFL)
l Sets the input value to Bad (NaN).
l Requests the input's primary to initialize
This block does not support mode shedding on timeout.
- 377 -
ATTENTION
19.8.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:
l 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.
l ORBYPPERM- Override Bypass Enable. Indicates if the operator is allowed to bypass inputs.
19.8.14 Bad input option

The block can include or ignore inputs with bad values (NaN) per input, by setting the parameter
BADINPTOPT[1..4].
l BADINPTOPT- Bad Input Option enable. Indicates if the function block should include bad
inputs (NaN) in the selection process.
l BADINPTOPT has the following options:
o IgnoreBad (Ignore bad inputs)
o 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.8.15 OVRDSEL Equations

The OVRDSEL block selects one of the inputs according to the following user-selected equations:
l Equation A - select the highest of the non-bypassed inputs:
CV = the highest input + OPBIAS.FIX + OPBIAS.FLOAT
l 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].
- 378 -
19.8.16 Input switching

19.8.17 Output bias-OVRDSEL
l 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)
l NaN:
19.8.18 Bad CV processing

If the selected input is bad and MODE is Cascade, this block does the following:
l sets CV to Bad (NaN)
l sets the Bad Control flag (BADCTLFL)
When the selected input returns to normal, this block does the following:
l resets the Bad Control flag (BADCTLFL)
l requests the bypassed primaries to initialize (i.e., sets INTREQ(n) to On when ORBYPASSFL(n)
is On)
19.8.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
l sets SELXINP = None
l 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:
l INITREQ(n) = On
l INITVAL(n) = CV
where:
(n)=dentifies the primary to be initialized
INITREQ=initialization request flag for primary
INITVAL=initialization value for primary
- 379 -
19.8.20 Restart or function block activation

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

This block propagates override feedback data to the upstream blocks if it is,
l in the Cascade mode,
l not initializing, and
l OROPT is ON.
If these conditions are true, this block provides the following data to every upstream block:
l 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.
l Override feedback value: The OVRDSEL block sends its current CV to each of its primaries.
o The CV is clamped to OPHILM if it is greater than OPHILM and to OPLOLM if it is less
than OPLOLM.
l 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.
o If the offset flag is Off, the PID doesn't apply an offset; it initializes its CV as follows:
CV = override feedback value
o 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.
o Additionally, the Gain *(PVP - SPP) term is set to 0.0; If:
o Gain *(PVP - SPP) > 0.0 and the downstream OVRDSEL block is a High selector. Or,
o Gain *(PVP - SPP) < 0.0 and the downstream OVRDSEL block is a Low selector.
19.8.22 Recommendations on configuring override strategies
l 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.
l We do not recommend using a PID with External Reset Feedback in an override strategy.
l 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
- 380 -
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.8.23 Windup processing


ARWOP computation

Equals . . .
A secondary exists and its windup state equals HiLo.
PVSTS = MAN and PVMANOPT = NO_SHED.
- 381 -

Equals . . .
ARWNET computation

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

ARWNET will be the opposite of ARWOP).
On).

= On).

(CAB) programs.
- 382 -

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.25 OVRDSEL parameters

the OVRDSEL block.
- 383 -
19.9 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:
l Proportional, Integral, and Derivative (PID) on the error
l Proportional and Integral (PI) on the error and Derivative (D) on changes in PV
l Integral (I) on the error and Proportional and Derivative (PD) on changes in PV
l Integral (I) only
l 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.
Figure 19.6 Simple cascade control loop example.
- 384 -
l OPHIALM.TM
l OPHIALM.TMO
l OPHIALM.DB
l OPHIALM.DBU
The following parameters can be used for configuring the on-delay time and off-delay time for
the BADCTLALM alarm.
l BADCTLALM.TM
l 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
- 385 -
Tab
reports.
l 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.
l 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).
l Manual PV Option (PVMANOPT) - Lets you specify the mode and output
the block is to assume when PVSTS changes to MANual. The selections
are:
l NOSHED - No changes.
l SHEDHOLD - Sets MODE to MANual and MODEATTR to
Operator, disables external mode switching (ESWPERM), and
holds output at the last good value.
l SHEDLOW - Sets MODE to MANual and MODEATTR to
sets output to its extended low limit (OPEXLOLM) value.
l SHEDHIGH - Sets MODE to MANual and MODEATTR to
sets output to its extended high limit (OPEXHILM) value.
l SHEDSAFE - Sets MODE to MANual and MODEATTR to
sets output to the configured safe output (SAFEOP) value.
l The default selection is SHEDHOLD.

l 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.
- 386 -
Tab
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.
(unchecked).
ignore).
NOSHED.
- 387 -
Tab
Algorithm l 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.
l 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.
l T1 (minutes) (T1) - Lets you set integral time to be used for the integral
term in the control equation.
l T1 High Limit (minutes) (T1HILM) - Lets you define the high limit value in
minutes for the integral time setting. The default limit is 1440.
l T1 Low Limit (minutes) (T1LOLM) - Lets you define the low limit value in
l 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.
l 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.
l 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.
l 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:
l 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.
l 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.
l 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 applies to equations A, B, and C.
l 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.
l 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.
l Gap High Limit (GAPHILM) - Lets you define the high limit value in PV
- 388 -
Tab
engineering units to be used when calculating GAP gain.
l Gap Low Limit (GAPLOLM) - Lets you define the low limit value in PV
l 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.
l 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.
l 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.
l 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
l 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.
l 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 LEGACYGAP Option in R300
SetPoint l SP (SP) - Lets you specify an initial set point value. The default value is 0.
l Enable Advisory SP Processing (ADVDEVOPT) - Lets you specify whether
or not the block is to generate a deviation alarm when the PV deviates
- 389 -
Tab
from a user specified “advisory” SP value. The default selection is
unchecked (Disabled).
l 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.
l 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.
l 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).
more details.
l 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
l 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.
- 390 -
Tab
value is 106.9%.
is -6.9%.
last good value. ‘
l 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 default value is 100.
l 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 default value is 0 (zero).
The types are:
- 391 -
Tab
l Deviation High (DEVHIALM.FL)
l Deviation Low (DEVLOALM.FL)
l Advisory Deviation (ADVDEVALM.FL)
l 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.
l Trip Point - Lets you specify the following trip points for the given alarm.
The default value is NaN, which disables the trip point.
l OPHIALM.TP (Output High Alarm Trip Point)
l OPLOALM.TP (Output Low Alarm Trip Point
l DEVHIALM.TP (Deviation High Alarm Trip Point)
l DEVLOALM.TP (Deviation Low Alarm Trip Point)
l ADVDEVALM.TP (Advisory Deviation Alarm Trip Point)
type (OPHIALM.PR, OPLOALM.PR, DEVHIALM.PR, DEVLOALM.PR,
ADVDEVALM.PR, SIALM.PR, BADCTLALM.PR,). The default value is LOW.
The levels are:
Summary display.
type (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.
CB.
- 392 -
Tab
l 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.
R410 to late releases, refer to Impact of migration on alarm attributes.
percent.
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.
setting manually.
This parameter is available for configuration only if the Enable Bad

Output Connection Option is enabled.
- 393 -
Tab
l None
l ONESHOT
l SEMICONT
l CONTRTN
l CONT
NaN.

Number).
- 394 -
Tab
information
l Function-PID Block
l Functional scenario-PID Block
l Configuration examples-PID Block
l Operating modes and mode handling-PID Block
l Required inputs-PID Block
l Input ranges and limits-PID Block
l Initializable outputs-PID Block
l Control initialization-PID Block
l Output bias-PID Block
l Output ranges and limits-PID Block
l Direct or reverse control-PID Block
l Set Point Ramping-PID Block
l PV tracking-PID Block
l PID equations
l Gain options-PID block
l Tuning Constant Change Considerations
l Timeout monitoring-PID block
l Timeout processing-PID block
l Output Indication Function-PID block
l Windup handling-PID block
l Windup processing
l Override feedback processing-PID block
l PID parameters
19.9.1 Function-PID Block

A PID requires two inputs - a process variable (PV) and a set point (SP):
l 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.
l SP is pulled from another function block, or stored by the operator or a user program.
- 395 -
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.
l ESWAUTO, ESWCAS, ESWMAN and SI - Indicates if an external source, such as a user
program, wants to change the PID's Mode:
o If ESWAUTO = On, the external source wants to change the Mode to Auto.
o If ESWCAS = On, the external source wants to change the Mode to Cascade.
o If ESWMAN = On, the external source wants to change the Mode to Manual.
o 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:
l 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.
l 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.
l The secondary builds BACKCALCIN when it receives a read request from the primary. This way,
BACKCALCIN is guaranteed to contain the most current status.
- 396 -
19.9.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:
l 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.
l Both PID1 and 2 pull PV from Data Acquisition (DATAACQ) function blocks as shown in
following figure.
l The PID1 has an active output. As a result, it reads BACKCALCIN from and provides OP to the
secondary (PID2).
l 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.
l The PV, SP and OP connections are all good which means there are no communication errors
or timeouts.
Table 19.8 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.)
- 397 -
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.9.3 Configuration examples-PID Block
l 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.
Table 19.9 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 connection is exposed, but the implicit/hidden connection function automatically
makes a connection to a value/status parameter (PVVALSTS) when it is required.
2. Use the 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.
- 398 -
l Anti-Reset Windup Status: Indicates if the secondary's initializable input (which is this
block's output) is at its high or low limit.
l 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.
l Oneshot Initialization Flag: Used to request one shot 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.
l Initialization Value: Used for continuous and one shot initialization.
l 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.
l Override Feedback Value: Similar to initialization value; this is calculated to prevent “wind-
up” in unselected primaries.
l 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.
l 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.
l 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.10 Example of CB configuration using two PID blocks for cascade loop control.
- 399 -
1. Use the PV parameter connection to carry data from the analog input to the PID block. The
default PV connection is exposed, but the implicit/hidden connection function automatically
makes a connection to a value/status parameter (PVVALSTS) when it is required.
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.
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 BACKCALCIN/BACKCALCOUT connections for each output used are automatically
built by Control Builder as implicit/hidden connections.
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.9.4 Operating modes and mode handling-PID Block

The PID block operates in the following modes:
l MAN (MANual)
o 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.
l AUTO (AUTOmatic)
o 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.
l CAS (CAScade)
o 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.9.5 Required inputs-PID Block

The required number of inputs is determined by the mode of the PID block.
l If Mode is CAScade, two inputs are required - PV and SP.
l If Mode is AUTOmatic or MANual, only PV is required.
o SP is an initializable input; PV is non-initializable.
o 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.
o 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.
o 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.9.6 Input ranges and limits-PID Block
l You must specify a PV engineering unit range, PVEUHI and PVEULO.
- 400 -
o PVEUHI and PVEULO define the full range of PV in engineering units.

o PVEUHI represents the 100% of full scale value.
o PVEULO represents the 0% of full scale value.
o PVEUHI and PVEULO also define the engineering unit range of SP - PV and SP are
assumed to have the same range.
l 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.
l SPHILM and SPLOLM define set point operating limits in engineering units.
o 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.
l SP contains set point value in engineering units and SPP contains the value in percent.
o If Mode is AUTOmatic, the operator or a user program may store to either SP or SPP.
19.9.7 Initializable outputs-PID Block

level. A variable with the “initializable” attribute has an associated BACKCALC variable, and when a
connection is created between an initializable input and initializable output, you can also create a
so you don't have to create them manually. These “implicit” build connections are “hidden” from
For example, if you connect OP from a PID block to a PID block or an AOCHANNEL block, Control
Builder automatically creates the BACKCALCOUT to BACKCALCIN connection.
(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
you do not make multiple connections from a single PID output.
19.9.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.
- 401 -
l Note that SECINITOPT may be used to ignore initialization requests from the secondary.
l If the secondary is requesting initialization, the PID block:
o initializes its output
o sets initialization request parameters for its primary
INITREQ = On
INITVAL = SP
19.9.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.
function block initializes or changes mode as long as the PID block is the first initializable block.
the PID block only applies OPBIAS.FLOAT to the output for the latter two conditions, when it is
the first initializable block.)

ATTENTION
necessary.
following occurs:

OPBIAS.FLOAT=CVINIT - (CVUNBIASED + OPBIAS.FIX)
- 402 -
Where:
CVINIT=initialization value received from the secondary
OPBIAS.FIX=fixed bias (user-specified)
be zero.
o Zero:
o Non-zero:
Where:
o 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.9.10 Output ranges and limits-PID Block

o 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.
o If the PID block has no secondary, CVEUHI and CVEULO must be specified.
o 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).
range - these are user-specified values.
o 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.
CV range - these are user-specified values.
- 403 -
19.9.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.
l With direct-control action, an increase in the error (PV - SP) increases the PID output (CV).
l 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%.
l With direct-control action, if PVP changes to 52%, the error increases causing CV to increase.
l With reverse-control action, if PVP changes to 52%, the error increases causing CV to
decrease. .
19.9.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.
- 404 -
Normal Ramp Rate Normal ramp rate value in engineering units that you enter. The value can
(SPTVNORMRATE) be Not a Number (NaN) or greater than zero. If value is NaN, it means a
“step change” in the SP, which is the same as a ramp time of zero.
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:
l If SPTVNORMRATE is a value other than zero or NaN:
l Otherwise,:
SPTVRATE = NaN
SPTVTIME = 0 (That is, do a step change.)
Max. Ramp Lets you specify a maximum deviation in engineering units per minute
Deviation allowed between PV and SP during ramping. The value can be NaN or
(SPTVDEVMAX) 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.
- 405 -
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:
l The block calculates a ramp time (SPTVTIME).
l The SPTVSTATE goes to Preset.
l 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:
l If you specify a ramp time (SPTVTIME) value other than zero:
Otherwise:
SPTVRATE = NaN
l 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:

l Off,
l Preset, or
l 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:
l An “R” modifier appears next to the SP value on the PID detail display in
Station.
l SP begins to ramp toward SPTV and SPTVTIME decreases.
When SPTVTIME reaches zero, SP equals SPTV and the SPTVSTATE goes to Off.
Figure 19.7 PID block with SP ramping parameters configured for monitoring.
- 406 -
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:
l You set a value for SPTV or SPTVTIME.
l Mode changes to Manual while SPTVSTATE is Run.
l Block is initialized (INITMAN = ON) while SPTVSTATE is Run. However, a one shot
initialization does not cause a change in SPTVSTATE.
l Control Module goes Inactive.
The SPTVSTATE automatically goes to Off, when:

l SP is set by you, a program or another function block.
l Mode changes to Cascade or Backup Cascade.
3. You can only set a value for SPTV and SPTVTIME, when:
l SPTVSTATE is Off or Preset, and
l Mode is Auto or Manual.
ATTENTION
l When SP ramping is Enabled, the SPTVSTATE must be Off before you can make
changes to the SP limits (SPHILM and SPLOLM).
l 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.9.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).
- 407 -
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:
l PID block is in Manual mode
l PID block is initializing and not in Auto mode.
ATTENTION
l PV tracking does not occur on recovery from a bad PV.
l PV tracking does not occur if PID block is in Auto mode.
l If PID block is in Auto mode, it means SP is normally stored by the user.
l If PV tracking is initiated, this value is lost.
l 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.9.14 PID equations

The PID block provides five different equations for calculating the PID - the CTLEQN parameter is
used to specify the desired equation.
l Equation A - all three terms (Proportional, Integral, Derivative) act on the error (PV - SP) as
follows:
l Equation B - the proportional and integral terms act on the error (PV - SP) and the derivative
term acts on changes in PV as follows:
l This equation is used to eliminate derivative spikes in the control action as a result of quick
changes in SP.
l Equation C - the integral term acts on the error (PV - SP) and the proportional and derivative
terms act on changes in PV as follows:
l Equation D - integral control only as follows:
- 408 -
l 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

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

l 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:
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)
- 409 -
19.9.15 Gain options-PID block

If PID equation A, B, or C is selected, any of the following gain equations may be chosen:
l Linear Gain - provides a proportional control action that is equal to a constant (K) times the
error.
o This is the most commonly-used gain option - K is a user-specified constant and has a
default value of 1.0.
l Gap Gain - used to reduce the sensitivity of the control action when PV is in a user-specified
band (gap) around the set point.
o 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.
l 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
l Nonlinear Gain - provides control action that is proportional to the square of the error, rather
than the error itself.
o 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)
l 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.
o 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.
o For example, in controlling the level of a tank whose cross-section is not constant, the
- 410 -
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.9.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.9.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.9.18 Timeout processing-PID block

If mode is CAScade and SP times out, the PID block does the following:
l Keeps SP at its last good value.
l Changes the mode to a user-specified TMOUTMODE.
l Requests the primary to initialize.
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:
l Changes the mode back to CAScade.
l Updates the SP.
You cannot set the CASREQFL. However, it can be cleared by setting the block's MODE to MANUAL.
- 411 -
ATTENTION
19.9.19 Output Indication Function-PID block

display.

Enumeration
Selection Is . . .
values remain the
same.)



ATTENTION
- 412 -


OPROCNEGFL

FixedOp.)
ATTENTION
- 413 -
REVERSE.
- 414 -

valve closed
in AO channel
valve open

valve open
19.9.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.
l A windup condition exists if:
l PID block has a secondary and the secondary is in windup.

l PID block's output exceeds one of the user-specified output limits (OPHILM, OPLOLM).

- 415 -

ARWOP computation

Equals . . .
ARWNET computation
- 416 -

ARWNET
Equals . . .
The CV is NaN.

On).

= On).

configurable and allow stores from Sequential Control Modules (SCMs) and control algorithm
block (CAB) programs.

NORMAL HI HI
NORMAL LO LO
NORMAL HILO HILO
HI NORMAL HI
HI HI HI
- 417 -

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.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:
l Recomputes CV:
o If the override offset flag is Off:
CV=override feedback value from secondary
o If the override offset flag is On:
o For PID with Equation D,
Offset=(PVP-SPP)
o For PID with any other Equation(A,B,C,E)
Offset=K * (PVP-SPP)
o If PID is using reverse control action:
o then Offset = -Offset
o If the PID is using direct control action:
o then Offset = Offset
o Additionally, the Offset term is set to 0.0 if
o →Offset > 0.0 and the downstream OvrdSel block is a High selector, or
o →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.
o Computes a feedback value for its primary:
feedback value for primary =PV
- 418 -
Where:
K=overall gain
PV=PV in engineering units
PVP=PV in percent
SPP=SP in percent
19.9.24 PID parameters

the PID block.
19.10 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.
l OPHIALM.TM
l OPHIALM.TMO
l OPHIALM.DB
l OPHIALM.DBU
the BADCTLALM and Predicted PV alarms.
l BADCTLALM.TM
l BADCTLALM.TMO
l PREDPVHIALM.TM
l PREDPVHIALM.TMO
l PREDPVLOALM.TM
l 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:
o Processes with significant delay or inverse (wrong-way) response
o Property control employing infrequent measurement updates (such as from a gas
chromatograph)
o Noisy processes where valve wear is problematic
o Dynamically changing processes
o 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
- 419 -
Additional descriptive details are provided in the following discussions:
l Graphic presentation
l Modes
l Configurable attributes
19.10.1 Benefits
Key benefits of Profit Loop PKS include:
Benefit Discussion
Superior Because it is a predictive controller, Profit Loop PKS directly accounts for
control transportation delays and other difficult to control behavior. This approach leads
to superior control of processes with significant deadtime, inverse response, or
noisy measurement.
Valve life A well-designed robust controller maintains a balance between aggressive control
extension 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.
Single Uses a single tuning “knob,” the performance ratio. If the controller is sluggish
tuning and unresponsive, decreasing the performance ratio will improve performance. If
handle 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 Profit Loop PKS includes Profit Loop Assistant, a suite of tools for configuring,
tools 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 Based on Honeywell's award-winning Profit Controller technology.

Controller
Range Employs the patented Range Control Algorithm found in Honeywell's Profit
control 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.
- 420 -
Benefit Discussion
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 The key advantage of optimization over setpoint control is that the response of
objective the optimizer and controller can be tuned separately, providing dual objective
control control.
Discrete As a predictive controller, Profit Loop PKS models the behavior of the PV based on
analysis 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.
19.10.2 Graphic presentation

The PID-PL block looks like this graphically:
19.10.3 Modes
The PID-PL operates in one of three distinct modes:
- 421 -
l When CTLEQN is any one of the PID equations (EQA, EQB, and so on) and not PROFITLOOP,
this block behaves as a standard PID control block. (For help on the this mode, see PID Block in
the Reference Data for Functional Block Types, Regulatory Control Blocks section of this
document.)
l 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).
l 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.
19.10.4 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.
- 422 -
Tab
Main All attributes configured on this tab are the same as those for the PID block.
Refer to either the online Help in Control Builder for details, or to Reference
Data for Functional Block Types, Regulatory Control Blocks,PID Block in this
document.
Algorithm Many attributes configured on this tab are the same as those for the PID block.
Attributes specific to the PID-PL block are as follows:
l 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.
l ProfitLoop Control Mode (CTRLMODE) - Lets you select the means of
control for the PID-PL block:
l SETPOINT: With this selection, the function block will attempt to
have the PV track the setpoint (SP).
l RANGE: With this selection, the function block will attempt to
have the PV stay within high and low setpoint limits (SPHI and
SPLO).
l 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:
l The default performance ratio of 1.0 represents steady-state
control and reaches the control objective at the natural process
response time.
l 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.
l 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.
l For integrating processes, use Closed-loop response (see
below) to specify integrator performance. In this case,
Performance Ratio is set to 1.
l 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 in this
document.
SetPoint Many attributes configured on this tab are the same as those for the PID block.
- 423 -
Tab
l 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.
l 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.
l 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.
l 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.
the PID block, refer to either the online Help for Control Builder, or to
Reference Data for Functional Block Types, Regulatory Control Blocks, PID
Block in this document.
Output Many attributes configured on this tab are the same as those for the PID block.
The attribute specific to the PID-PL block is as follows:
Valve Travel Reduction (VALVETRAVELRDCT) - Allows you to select the level of
noise filtering to be applied to model bias. Possible selections are:
l NORMAL: Apply no additional noise filtering.
l MODERATE: Apply some additional filtering.
l 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.
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.
- 424 -
Tab
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.
Model area Use this form if you have a good understanding of the math and concepts
involved in model predictive control and you do not wish to use the Profit Loop
PKS Assistant.
Entries or changes in this area are treated differently, depending on whether
you are working in Project view or Monitoring view:
l 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.
l 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:
l 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.
l 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.
l 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.
l 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.
l 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.
l 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.
l Process Gain Units - The units to be used in conjunction with the process
gain:
l PVEU/OPEU: Gain expressed in engineering units.
l %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:
l 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
- 425 -
Tab
calculates the controller.
This button is inactive if the model in the configuration form matches the
model in the active controller.
l 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.
l 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.
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, With range control, because the process is no longer constrained to a setpoint,
Optimization you are free to choose the ultimate resting value for the process. The process
area 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.”
l 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:
l NONE: No optimization.
l MINIMIZE: Optimize toward the lower limit of the range
(minimize the PV).
l MAXIMIZE: Optimize toward the upper limit of the range
(maximize the PV).
l OPTTARGET: Optimize toward a specific target value (a user-
specified SP).
l 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).
- 426 -
Tab
l 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.
l Profit Loop PKS uses the following formula:
l Where:
CLOSEDLOOPRESP = Closed-loop response time
OPTSPEED = Optimization speed
OPTRESP = Settling time associated with changes induced
through optimization
l 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,
l the Control Mode (on the Algorithm form) must be set to
RANGE, and
l the Optimizer Mode (on the Advanced form) must be set to
other than NONE.
l 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.
l SP Offset, High Limit (SPHIOPTOFFSET) - Profit Loop PKS can be

is more restrictive than the normal control range bounded by SPLO and
SPHI. To do this,
RANGE, and
other than NONE.
l 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
Mode.
l OP Offset, Low Limit(OPLOOPTOFFSET) - Profit Loop PKS can be

is more restrictive than the normal control range bounded by OPLOLM
and OPHILM. To do this,
- 427 -
Tab
RANGE, and
other than NONE.
l 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
l The impact of this offset depends on the selected Optimizer
Mode.
l OP Offset, High Limit (OPHIOPTOFFSET) - Profit Loop PKS can be

is more restrictive than the normal control range bounded by OPLOLM
and OPHILM. To do this,
RANGE, and
other than NONE.
l 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
Mode.
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
PV function block does not react to obsolete information.
Configuration
area l 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.
l 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.
l 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.
l 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).
l A value greater than or equal to zero enables the predicted PV
high alarm trip point.
- 428 -
Tab
l NaN (Not a Number) disables the predicted PV high alarm.
l Predicted PV High - Priority (PREDPVHIALM.PR) - The priority level for the

corresponding alarm type can be selected, using the following categories:
l NONE: The alarm is not reported to the system and is not
annunciated.
l 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.
l 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
l Note that the default selection is LOW, and that alarm levels are
prioritized as follows: JOURNAL --> LOW --> HIGH --> URGENT
(highest priority)
l 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:
l Generally, 15 is considered most severe when specifying alarm
severity.
l The default value is 0.
l 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.
l Enter a value greater than or equal to zero, to enable the
predicted PV low alarm trip point.
l Enter NaN (Not a Number) to disable the predicted PV low
alarm.
l Predicted PV Low - Priority (PREDPVLOALM.PR) - Select the appropriate

priority level for the corresponding alarm type based on the following
categories:
l NONE: The alarm is not reported to the system and is not
annunciated.
l 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.
l LOW, HIGH, URGENT: These selections cause the alarm to be
displayed in the alarm zone at the bottom of a Station display to
- 429 -
Tab
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
l Note that the default selection is LOW, and that alarm levels are
prioritized as follows: JOURNAL --> LOW --> HIGH --> URGENT
(highest priority)
l 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:
l Generally, 15 is considered most severe when specifying alarm
severity.
l The default value is 0.
l 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.
document.
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
document.
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.
- 430 -
Tab
Template Lets you view and define parameters for associated templates.
Defining
information
l Function-PID-PL
l Configuration examples-PID-PL
l Operating modes and mode handling-PID-PL
l Required inputs-PID-PL
l Input ranges and limits-PID-PL
l Initializable outputs-PID-PL
l Control initialization-PID-PL
l Output bias-PID-PL
l Output ranges and limits-PID-PL
l Direct or reverse control-PID-PL
l Set Point Ramping-PID-PL
l Range Control Ramping-PID-PL
l PV tracking-PID-PL
l PV Bad Value Handling
l PV Calibration
l Asynchronous PV Inputs
l Control Equations-PID-PL block
l Output Indication Function
l Timeout monitoring
l Windup handling-PID-PL block
l Windup processing
l Override feedback processing-PID-PL block
l PID-PL parameters
19.10.5 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:
- 431 -
l Auxiliary Functions
l Data Acquisition Functions
l Pulse Input
l Device Control
l Logic Functions
l Math Functions
l Power Generation Functions
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.
Figure 19.8 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.
- 432 -
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.
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.
- 433 -
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.
- 434 -
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.
- 435 -
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.
- 436 -
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.
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:
- 437 -
l Because the gain multiplier is restricted to be greater than 0, the process model gain never
changes direction.
l 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:
l 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.
- 438 -
19.10.6 Configuration examples-PID-PL

Four examples are discussed in the following paragraphs:
l Utility Functions
l Device Control
l Sequential Control
l ENHREGCALC (Enhanced Regulatory Control Calculator) Block
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.
- 439 -
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.
The following table explains the callouts in the preceding table.
- 440 -
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.
- 441 -
Gain scheduling
The following figure and table show a sample configuration that uses gain scheduling with PID-PL.
In this example, the gain of a level controller depends on the level in the tank. This may occur if the
geometry of the tank changes as the level rises and falls.
Callout Description
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.10.7 Operating modes and mode handling-PID-PL

The PID-PL block operates in the following modes:
l 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.
l 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
- 442 -

l 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:
l SETPOINT - Controller alters OP so PV tracks the SP.
l 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:
l NONE - PV is allowed to freely float between SPHI and SPLO. If projected to remain in range,
no additional control action is taken.
l MINIMIZE - At steady-state, PV is minimized.
l MAXIMIZE - At steady-state, PV is maximized.
l OPTTARGET (OPTimize to TARGET) - At steady-state, PV equals SP.
l 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.10.8 Required inputs-PID-PL

The PID-PL block requires two inputs: PV and SP. See Required inputs-PID Block 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.10.9 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 for the PID block for details.
For range control,
l PVEUHI and PVEULO define the engineering unit range for MODELPV, SP, SPHI, and SPLO.
l 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.
l 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.10.10 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 for
the PID block for more details.
- 443 -
19.10.11 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.
l SECINITOPT may be used to ignore initialization requests from the secondary.
l If the secondary is requesting initialization, the PID-PL block:
CV = initialization value from the secondary.
o uses the initialized CV value in model predictions
INITREQ = On
INITVAL = SP
l 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.10.12 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 for the PID block.
19.10.13 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 for the PID block for details.
19.10.14 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 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.
l A positive process model gain leads to reverse control action.
l A negative process model gain leads to direct control action.
19.10.15 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 for the PID block for
implementation details.
19.10.16 Range Control Ramping-PID-PL

For range control, range control limit ramping provides a smooth transition from the current SPHI
- 444 -
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.10.17 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 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:
l If SPLO is greater than SP then set SPLO equal to SP
l If SPHI is less than SP then set SPHI equal to SP
ATTENTION
l SPHI and SPLO track the current SP (and only indirectly the PV).
l 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.
- 445 -
19.10.18 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.10.19 PV Calibration
On occasion, one may wish to intentionally disable the PV measurement without inactivating the
control module or placing the function block in MAN. This is most evident when the PV's sensor is
recalibrated and such recalibration causes undesirable control action. A calibration flag,
CALIBRATION, is provided for this purpose.
When CALIBRATION is set, Profit Loop PKS:
l Disables updating of bias between model prediction and PV
l Continues control action based on model prediction only
19.10.20 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
l Disables updating of bias between model prediction and PV
l 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:
l 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.
l OnPvChange - PV bias is updated only when there is a change in the PV value from one
- 446 -
execution period to the next.

o Note: Avoid this setting if noise alters the PV value between analyzer updates.
l 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
l Logic blocks should be employed to set and reset the NEWSAMPLE flag. It is the
users responsibility to design and construct the appropriate logic.
l The PID-PL block makes no attempt to set or reset this flag.
l 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.10.21 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 for the PID block.
19.10.22 Output Indication Function

display.
- 447 -

Enumeration
Selection Is . . .
values remain the
same.)



ATTENTION

- 448 -


OPROCNEGFL

FixedOp.)
ATTENTION
REVERSE.
- 449 -

valve closed
in AO channel
valve open

valve open
ATTENTION
- 450 -
mode.
19.10.24 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.25 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.
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.


- 451 -
ARWOP computation

Equals . . .
ARWNET computation

ARWNET
Equals . . .
The CV is NaN.
- 452 -

ARWNET
Equals . . .
On).

= 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
- 453 -

HILO LO HILO
HILO HILO HILO
19.10.28 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 for
the PID block.
19.10.29 PID-PL parameters

the PID-PL block.
- 454 -
19.11 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).
l Integral (I) only
- 455 -
The PIDER block may be used in a single control loop or with multiple PIDs in a cascade
strategy.
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.
l OPHIALM.TM
l OPHIALM.TMO
l OPHIALM.DB
l OPHIALM.DBU
l BADCTLALM.TM
l BADCTLALM.TMO
l Configuration example-PIDER block

l Function
l Operating modes and mode handling-PIDER block
l Required inputs-PIDER block
l Input ranges and limits-PIDER block
l Initializable outputs-PIDER block
l Control initialization-PIDER block
l Output bias-PIDER block
l Output ranges and limits-PIDER block
l Direct or reverse control-PIDER block
l Set Point Ramping-PIDER block
l PV tracking
l PID equations for PIDER block
l PIDER equation variations
l Gain options
l Output Indication Function- PIDER block
l Timeout monitoring
l Timeout processing
l Windup handling
l Windup processing
l Override feedback processing-PIDER block
l Error handling for RFB and TRFB inputs
l Restart or point activation
l PIDER parameters
19.11.1 Configuration example-PIDER block

The following illustration shows a PIDER block configured in a cascade control strategy.
- 456 -
Table 19.11 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
- 457 -
Tab
l Item Name - The name of the Entity that the Control Module containing
the block will be associated with in the Enterprise Model Builder
hierarchy.
reports.
are:
holds output at the last good value
l The default selection is SHEDHOLD.

l 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.
- 458 -
Tab
(unchecked).
ignore).
NOSHED.
to use. The selections are EQA, EQB, EQC, and EQD. See the PID
- 459 -
Tab
is 240.
value is 0.
input value from either the process, another function block, or a
user program. You can use this option to compensate for
- 460 -
Tab
1.0.
gain option.
K = KLIN*KMODIFEXT
default value is 1.
controller. See LEGACYGAP Option in R300
- 461 -
Tab
deviation alarm.
more details.
block for more details.
l 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.
value is 106.9%.
- 462 -
Tab
is -6.9%.
last good value.
The types are:
- 463 -
Tab

Interlock.
The levels are:
Summary display.
ADVDEVALM.SV, SIALM.SV, BADCTLALM.SV,) as a number between 0 to
CB.
- 464 -
Tab
condition occurs.
percent.
With R410, the cannot individually configure the deadband unit for the
PIDER 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 PIDER
block. However, if you are migrating from pre-R410 to later releases, refer
Note: You must configure identical deadband units for all alarms in the PIDER
block.
setting manually.
Note: This parameter is available for configuration only if the
Enable Bad Output Connection Option is enabled.

- 465 -
Tab
l None
l ONESHOT
l SEMICONT
l CONTRTN
l CONT
NaN.

Number).
- 466 -
Tab
information
19.11.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.
l 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).
l 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.
l TRFB is pulled from another function block. You cannot store a value to this parameter.
l 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.
program, wants to change the PIDER's Mode:
o 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 is wound-up or if it wants the PIDER to initialize.
l 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.
- 467 -
19.11.3 Operating modes and mode handling-PIDER block

The PIDER block operates in the following modes:
l MAN (MANual)
o 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.
l AUTO (AUTOmatic)
l CAS (CAScade)
inactive or initializing) or the connection is bad, the PIDER block invokes timeout
processing.
19.11.4 Required inputs-PIDER block

The required number of inputs is determined by the mode of the PIDER block.
l If Mode is CAScade, five inputs are required - PV, SP, RFB, TRFB and S1.
l If Mode is AUTOmatic or MANual, PV, RFB, TRFB and S1 are required.
o SP is the only initializable input; other inputs are non-initializable.
o The PIDER block may have one primary or none, depending on whether SP is
configured or not; there is one primary per initializable input.
o 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.
o S1 can be triggered by another function block or set by a user-written program.
19.11.5 Input ranges and limits-PIDER block

o 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.
l The PIDER block assumes PV is within PVEUHI and PVEULO - it applies no range check -
and range check.
- 468 -
the primary or a user program attempts to store a value outside of the limits, the
PIDER block clamps it to the appropriate limit and sets the primary's windup status.
o 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).
o The PIDER block monitors SP for time-out.
l The RFB and TRFB values typically come from a remote controller. The PIDER block applies no
range check for these parameters.
l The S1 input is a Boolean flag and the values are only On and Off.
19.11.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.11.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
l If the secondary is requesting initialization, the PID block:
INITREQ = On
INITVAL = SP
- 469 -
19.11.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.
function block initializes or changes mode as long as the PIDER block is the first initializable block.
the PIDER block only applies OPBIAS.FLOAT to the output for the latter two conditions, when it
is the first initializable block.)

ATTENTION
necessary.
following occurs:

Where:
CVUNBIASED =unbiased calculated value (based on input from the primary)
be zero.
- 470 -
o Zero:
o Non-zero:
Where:
o NaN:
19.11.9 Output ranges and limits-PIDER block

o 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.
another block or user program attempts to store an OP value that exceeds them.
o The operator may store an OP value that is outside of these limits.
l MAXRFBDEV is the maximum deviation allowed between CV and RFB, in percent. It is used to
provide windup protection for OP.
o 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.11.10 Direct or reverse control-PIDER block

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

l SPTVRATE = SPTVNORMRATE
l SPTVTIME = |(SPTV - SP)| / SPTVRATE
Otherwise,:
l SPTVRATE = NaN
l SPTVTIME = 0 (That is, do a step change.)
done.
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).
in Station.
- 472 -
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.
Otherwise:
SPTVRATE = NaN
Otherwise,:
SPTVRATE = NaN
Auto or Manual.

l Off,
l Preset, or
l Run
this occurs:
l An “R” modifier appears next to the SP value on the PIDER detail display in
Station.
Figure 19.9 PIDER block with SP ramping parameters configured for monitoring.
- 473 -
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.11.12 PV tracking
The PV Tracking option sets SP equal to PV when a cascade is broken due either to function block
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
mode.
- 474 -
If PV tracking is configured, the block sets SP equal to PV (subject to SP limits) when either of the
following conditions exist:
l block is in Manual mode
l block is initializing and not in Auto mode.
ATTENTION
l PV tracking does not occur if block is in Auto mode.
l If block is in Auto mode, it means SP is normally stored by the user.
l If PV tracking is initiated, this value is lost.
19.11.13 PID equations for PIDER block

The PIDER block provides four different equations for calculating the PID - the CTLEQN parameter
is used to specify the desired equation.
Equation A - all three terms (Proportional, Integral, Derivative) act on the error (PV - SP) as
follows:
Equation B - the proportional and integral terms act on the error (PV - SP) and the derivative
changes in SP.
Equation C - the integral term acts on the error (PV - SP) and the proportional and derivative
- 475 -
l This equation provides the smoothest and slowest response to SP changes.

Equation D - integral control only as follows:
ATTENTION

Where:
CV = output of PID (Equations A, B, C, D) in percent
PVP = PV in percent
SPP = SP in percent
19.11.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:
- 476 -
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.
CV = full value output of the PID block. This is an internal calculated parameter and is not
PID 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.11.15 Gain options

If equation A, B, or C is selected, any of the following gain equations may be chosen:
error.
- 477 -
parameters:

K = KLIN
K = KLIN*KMODIFGAP
Where:
NLFORM = nonlinear gain form (user-configured;

may be 0 or 1)
K = KLIN*KMODIFEXT
Where:
- 478 -
19.11.16 Output Indication Function- PIDER block

display.

Enumeration
Selection Is . . .
values remain the
same.)
Reverse1 Value reversal - output range is 100 to 0 percent, and no display



1 The PIDER block does not support the Reverse option selection.
ATTENTION
- 479 -

valve closed
in AO channel
valve open

valve open
ATTENTION
mode.
19.11.18 Timeout monitoring

If mode is CAScade, the block performs timeout monitoring on SP - if a good SP value is not
- 480 -
received within a predefined time, the block invokes timeout processing.

19.11.19 Timeout processing

If mode is CAScade and SP times out, the block does the following:
l Holds SP at its last good value.
l 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 value. When it receives a good SP value, the block does the following:
l Updates the SP.
You cannot set the CASREQFL. However, it can be cleared by setting the block's MODE to
MANUAL. This allows you to disable the automatic return to Cascade mode.
l The block only sets CASREQFL if the original mode was Cascade, the SP input times-out, and
TMOUTMODE = AUTO.
ATTENTION
19.11.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.
o PID block has a secondary and the secondary is in windup.
o PID block's output exceeds one of the user-specified output limits (OPHILM,
OPLOLM).

- 481 -

ARWOP computation

Equals . . .
ARWNET computation
- 482 -

ARWNET
Equals . . .
The CV is NaN.

On).

= On).


NORMAL HI HI
NORMAL LO LO
NORMAL HILO HILO
HI NORMAL HI
HI HI HI
- 483 -

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.23 Override feedback processing-PIDER block

The PIDER block does not support override feedback processing.
19.11.24 Error handling for RFB and TRFB inputs
l If the tracking control switch (S1) is Off and the reset feedback value (RFB) is bad, this block
sets CV to NaN (Bad).
o When the RFB returns to good, CV is initialized, and the dynamic PID terms are
returned to steady-state.
l If S1 is On and the tracking value (TRFB) is bad, the block sets CV to NaN (Bad).
o 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.11.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.11.26 PIDER parameters

the PIDER block.
- 484 -
19.12 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.
l Integral (I) only
l 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.
- 485 -
Table 19.12 Simple PID with feedforward control loop example.
l OPHIALM.TM
l OPHIALM.TMO
l OPHIALM.DB
l OPHIALM.DBU
l BADCTLALM.TM
l BADCTLALM.TMO
Each PIDFF block supports the following user configurable attributes. The following table lists the
- 486 -
Tab
reports.
in engineering units that represents the 0% full scale PV input for the
are:
holds output at the last 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.
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.
- 487 -
Tab
(unchecked).
ignore).
NOSHED.

- 488 -
Tab
l 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.
to use. The selections are EQA, EQB, EQC, EQD, and EQE. See the PID
l T1 High Limit (minutes) (T1HILM) - Lets you define the high limit value
in minutes for the integral time setting. The default limit is 1440.
l T2 High Limit (minutes) (T2HILM) - Lets you define the high limit value
in minutes for the derivative time setting. The default limit is 1440.
is 240.
value is 0.
input value from either the process, another function block, or
a user program. You can use this option to compensate for
- 489 -
Tab
1.0.
gain option.
K = KLIN * KMODIFEXT
default value is 1.
controller See LEGACYGAP Option in R300
l 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.
l Gain (KFF) - Lets you specify the desired gain for the feedforward input. It
is clamped between GAINLOLM and GAINHILM. The default setting is 1.
l Bias (BFF) - Lets you specify the desired bias value for the feedforward
input. The default setting is 0.
l Low Limit (SPLOLM) - Lets you specify a low limit value for the SP. If the
- 490 -
Tab
deviation alarm.
more details.
l 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.
- 491 -
Tab
example, if the CV range is 50 to 500 and you enter a Low Limit of 10%,
is -6.9%.
last good value. ’
the block, if the block has no secondary. The default value is 100.
block, if the block has no secondary. The default value is 0 (zero).
- 492 -
Tab
The types are:

Interlock.
The levels are:
Summary display.
ADVDEVALM.SV, SIALM.SV, BADCTLALM.SV) as a number between 0 to
- 493 -
Tab
CB.
condition occurs.
percent.
PIDFF 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 PIDFF
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 PIDFF
block.
- 494 -
Tab
setting manually.

upon 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:
l None
l ONESHOT
l SEMICONT
l CONTRTN
l CONT
NaN.

respective range. For output, within OPEXLOLM to OPEXHILM and
- 495 -
Tab
within SPLOLM to SPHILM, for set point. The default value is NaN (Not a
Number).
l Rate (STARTRATE, STOPRATE, HOLDRATE) - When the RAMPEDSP
option is selected, lets you specify a rate value (STARTRATE, STOPRATE,
information
l Function-PIDFF block
l Functional scenario-PIDFF block
l Operating modes and mode handling-PIDFF block
l Required inputs-PIDFF block
l Input ranges and limits-PIDFF block
l Initializable outputs-PIDFF block
l Control initialization-PIDFF block
l Output bias-PIDFF block
l Output ranges and limits-PIDFF block
l Direct or reverse control for PIDFF block
l Set Point Ramping-PIDFF block
l PV tracking-PIDFF block
l Feedforward add or multiply action and equations-PIDFF block
l Feedforward value status-PIDFF block
l PID equations-PIDFF block
l Gain options-PIDFF block
l Output Indication Function-PIDFF block
l Tuning Constant Change Considerations-PIDFF block
l Timeout monitoring-PIDFF block
l Timeout processing-PIDFF block
l Windup handling-PIDFF block
l Windup processing-PIDFF block
l Anti-Reset Windup Status-PIDFF block
l Bypassing feedforward control action-PIDFF block
l Override feedback processing-PIDFF block
- 496 -
l PIDFF parameters
19.12.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.
l 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.
l 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.
program, wants to change the PID's Mode:
o 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 is wound-up or if it wants the PIDFF to initialize.
l 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.12.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:
l The PIDFF's' Mode is AUTOmatic. As a result, SP is set by the operator or a user program.
l PIDFF pulls PV from Data Acquisition (DATAACQ) function block as shown in the following
- 497 -
figure.
l PIDFF pulls FF from the LEADLAG function block as shown in the following figure.
l The PV, FF, and OP connections are all good which means there are no communication errors
or timeouts.
Table 19.13 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.12.3 Operating modes and mode handling-PIDFF block

The PIDFF block operates in the following modes:
- 498 -
l MAN (MANual)
o 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.
l AUTO (AUTOmatic)
l CAS (CAScade)
inactive or initializing) or the connection is bad, the PIDFF block invokes timeout
processing.
19.12.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.
l 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.
l 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.
l 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.12.5 Input ranges and limits-PIDFF block

l The PIDFF block assumes PV is within PVEUHI and PVEULO - it applies no range check -
and range check.
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.
19.12.6 Initializable outputs-PIDFF block

- 499 -
For example, if you connect OP from a PIDFF block to a PID block or an AOCHANNEL block, Control
Builder automatically creates the BACKCALCOUT to BACKCALCIN connection.
(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
19.12.7 Control initialization-PIDFF block

The PIDFF block brings initialization requests from its secondary through BACKCALC. In addition,
the secondary may propagate one shot initialization requests to this block.
l If the secondary is requesting initialization, the PIDFF block:
INITREQ = On
INITVAL = SP
INITMAN = On
19.12.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.
function block initializes or changes mode as long as the PIDFF block is the first initializable block.
- 500 -
the PIDFF block only applies OPBIAS.FLOAT to the output for the latter two conditions, when it
is the first initializable block.)

ATTENTION
necessary.
following occurs:

Where:
be zero.
o Zero:
o Non-zero:
- 501 -


Where:
l NaN:
19.12.9 Output ranges and limits-PIDFF block

o 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.
o If the PIDFF block has no secondary, you can configure the CVEUHI and CVEULO
values. The default values are 100 and 0, respectively.
o 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).
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.
19.12.10 Direct or reverse control for PIDFF block

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

- 502 -
l Otherwise:
SPTVRATE = NaN
done.
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).
in Station.
- 503 -
l The block calculates a ramp time (SPTVTIME).
Station.
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.

l Off,
l Preset, or
l Run
this occurs:
Station.
- 504 -
Callout Description
1 Block's mode must be Auto and SPTVSTATE must be Preset, before you can start SP
ramping by setting SPTVSTATE to Run with SPTV set to desired value.
2 The SPTVSTATE automatically goes to Preset, when:


3 You can only set a value for SPTV and SPTVTIME, when:
ATTENTION
19.12.12 PV tracking-PIDFF block

The PV tracking option sets SP equal to PV when a cascade is broken due either to function block
PV tracking is configured by setting PVTRAKOPT = Track.
- 505 -
Typically, PV tracking is configured for PIDFF blocks in a cascade configuration strategy. This allows
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:
l PIDFF block is in Manual mode
l PIDFF block is initializing and not in Auto mode.
ATTENTION
l 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.12.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.
l If the configured control equation (CTLEQN) is A, B, C, or D and the feedforward action is
Additive, then:
o If the feedforward value (FFn) is good (symbols are defined below):
CVn = Cvn-1 + DELCV + KFF* (FFn - FFn-1 )
o If the status of FFn or FF n-1 is Bad:
CVn = Cvn-1 + DELCV
l If the configured control equation (CTLEQN) is E and the feedforward action is Additive, then:
o 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.)
o 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.)
l If the configured control equation (CTLEQN) is A, B, C, or D and the feedforward action is

Multiplicative, then:
- 506 -

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.)
o 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.)
l 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) )
o 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.12.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.
- 507 -
19.12.15 PID equations-PIDFF block

The PIDFF block provides five different equations for calculating the PID - the CTLEQN parameter
is used to specify the desired equation.
ATTENTION
The CV term used in the following PID equations is the same as the CVpid term used in the
previous feedforward equations. It represents the full value output of the PID function
without the FF term added.
l Equation A - all three terms (Proportional, Integral, Derivative) act on the error
(PV - SP) as follows:
l Equation B - the proportional and integral terms act on the error (PV - SP) and the derivative
changes in SP.
l Equation C - the integral term acts on the error (PV - SP) and the proportional and derivative
l This equation provides the smoothest and slowest response to SP changes.

l 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
- 508 -
l 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
L -1 = inverse of the LaPlace transform
PVP = PV in percent
SPP = SP in percent
OPBIAS.FIX = fixed bias (Equation E only)
OPBIAS.FLOAT = floating bias (Equation E only)
19.12.16 Gain options-PIDFF block

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

K = KLIN
K = KLIN * KMODIFGAP
Where:
NLFORM = nonlinear gain form (user-configured; may be

0 or 1)
K = KLIN*KMODIFEXT
Where:
19.12.17 Output Indication Function-PIDFF block

display.
- 510 -

Enumeration
Selection Is . . .
values remain the
same.)

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


ATTENTION

- 511 -


OPROCNEGFL

FixedOp.)
ATTENTION
REVERSE.
- 512 -


valve closed
in AO channel
valve open

valve open
19.12.18 Tuning Constant Change Considerations-PIDFF block
ATTENTION
- 513 -
mode.
19.12.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.12.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 value. When it receives a good SP value, the block does the following:
l Updates the SP.
l Clears CASREQFL.
ATTENTION
19.12.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.
- 514 -

o PIDFF block has a secondary and the secondary is in windup.
o PIDFF block's output exceeds one of the user-specified output limits (OPHILM,
OPLOLM).
19.12.22 Windup processing-PIDFF block


ARWOP computation

Equals . . .
PVSTS = MAN and PVMANOPT = NO_SHED
- 515 -

Equals . . .
ARWNET computation

ARWNET
Equals . . .
The CV is NaN.

On).

= On).
19.12.23 Anti-Reset Windup Status-PIDFF block

(CAB) programs.
- 516 -

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.12.24 Bypassing feedforward control action-PIDFF block

An operator or a user program may bypass the feedforward action as follows.
l 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.
l 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.
19.12.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 section for the PID Block
for more information.
- 517 -
l 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)
l 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)
l 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.12.26 PIDFF parameters

Refer to Control Builder Components Reference for a complete list of the parameters used with the
PIDFF block.
19.13 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
- 518 -
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.
l Legacy gap gain option
l Equation-LEGACYGAP
l Configuration-LEGACYGAP
l Migration-LEGACYGAP
19.13.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.13.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
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
- 519 -
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.13.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.13.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.
- 520 -
19.14 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 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
DEVHIALM parameter.
l DEVHIALM.TM
l DEVHIALM.TMO
l DEVHIALM.DB
l DEVHIALM.DBU
BADCTL alarms.
l BADCTLALM.TM
l BADCTLALM.TMO
Each POSPROP block supports the following user configurable attributes. The following table lists
- 521 -
Tab
reports.
l 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.
l 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).
are:
l NO_SHED - Idle.
l SHEDHIGH - Raise.
l SHEDLOW - Lower
l SHEDSAFE - Depends on Safe State.
l SHEDHOLD - Idle
- 522 -
Tab
(unchecked).
ignore).
NOSHED.
Algorithm l Cycle Time (CYCLETIME) - Lets you specify a pulse cycle time in seconds.
The default value is 10 seconds.
l 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.
l [Raise] Output Desc (RAISEDESC) - Lets you specify a description of up to
15 characters for the raise output.
l [Raise] Overall Gain (KR) - Lets you specify an overall gain for the raise
pulse generation. The default value is 1.
l [Raise] Output Stroke Rate (RAISERATE) - Lets you specify a rate in
percent per second for the raise stroke for the final control element. The
l [Raise] Stiction Compensation (STICTIONR) - Lets you specify a stiction
compensation in seconds for raising the final control element. The default
value is 0.
l [Raise] Backlash Compensation (BACKLASHR) - Lets you specify a
backlash compensation when raising the final control element. The
default value is 0.
l [Raise] Min. Pulse Time (MINPULSER) - Lets you specify the minimum
pulse time in seconds for the raise pulses. The default value is 0.
l [Raise] Max. Pulse Time (MAXPULSER) - Lets you specify the maximum
pulse time in seconds for the raise pulses. The default value is 60.
l [Raise] Error Deadband (ERRORDBR) - Lets you specify the error
deadband in percent for the raise pulses.
l Safe Output Command (SAFEOPCMD) - Lets you select the output mode
- 523 -
Tab
to shed to for Bad control condition. The default selection is Idle.
l Manual Pulse Time (MANPULSETIME) - Lets you specify the pulse time in
seconds to be used in Manual mode. The default value is 1.
l No Command (PULSECMDTEXT[0]) - Lets you specify a text description
for the no command condition. The default text is Idle.
l Low Command (PULSECMDTEXT[1] - Lets you specify a text description
for the Raise Command condition. The default text is Raise.
l Raise Command (PULSECMDTEXT[2]) - Lets you specify a text
description for the Low Command condition. The default text is Low.
l [Lower] Output Desc (LOWERDESC) - Lets you specify a description of up
to 15 characters for the lower output.
l [Lower] Overall Gain (KL) - Lets you specify an overall gain for the lower
pulse generation. The default value is 1.
l [Lower] Output Stroke Rate (LOWERRATE) - Lets you specify a rate in
percent per second for the lower stroke for the final control element. The
l [Lower] Stiction Compensation (STICTIONL) - Lets you specify a stiction
compensation in seconds for lowering the final control element. The
default value is 0.
l [Lower] Backlash Compensation (BACKLASHL) - Lets you specify a
backlash compensation when lowering the final control element. The
default value is 0.
l [Lower] Min. Pulse Time (MINPULSEL) - Lets you specify the minimum
pulse time in seconds for the lower pulses. The default value is 0.
l [Lower] Max. Pulse Time (MAXPULSEL) - Lets you specify the maximum
pulse time in seconds for the lower pulses. The default value is 60.
l [Lower] Error Deadband (ERRORDBL) - Lets you specify the error
deadband in percent for the lower pulses.
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
- 524 -
Tab
deviation alarm.
more details.
The types are:

Interlock.
type (DEVHIALM.PR, DEVLOALM.PR, ADVDEVALM.PR, SIALM.PR,
BADCTLALM.PR,). The default value is LOW. The levels are:
- 525 -
Tab
Summary display.
type (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.
l 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.
l 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.
example, DEVHIALM.TM and DEVLOALM.TM) 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.
l Deadband Units (ALMDBU) - Lets you specify if the deadband value
represents percent or engineering units. The default value is percent.
example, DEVHIALM.DBU and DEVLOALM.DBU) 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.
l None
l ONESHOT
l SEMICONT
l CONTRTN
l CONT
- 526 -
Tab
l FIXEDOP - Set OPREQ = Configured Value (Not applicable to
this block).
NaN.

Number).
information
l Function-POSPROP block
l Operating modes and mode handling-POSPROP block
l Required inputs-POSPROP block
l Input ranges and limits-POSPROP block
l Output-POSPROP block
l Initializable inputs and outputs-POSPROP block
l Output ranges-POSPROP block
l Set Point Ramping-POSPROP block
l Timeout monitoring-POSPROP block
- 527 -
l Timeout processing-POSPROP block

l Equations-POSPROP block
l Control Initialization-POSPROP block
l Secondary initialization option-POSPROP block
l Override feedback processing for POSPROP block
l Raise/Lower limit switches of POSPROP block
l Bad control processing-POSPROP block
l Windup processing-POSPROP block
l Anti-Reset Windup Status-POSPROP block
l POSPROP parameters
19.14.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.
l Error signal (PV - SP)

l Raise or lower gain setting (KR or KL)
l Raise or lower pulse stroke rate (RAISERATE or LOWERRATE)
l 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.
l 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.
Figure 19.11 Example of Position Proportional loop for controlling valve position through pulse length
or pulse count function.
- 528 -
19.14.2 Operating modes and mode handling-POSPROP block

The POSPROP block operates in the following modes:
l MAN (MANual)
o 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.
l AUTO (AUTOmatic)
l CAS (CAScade)
o 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.14.3 Required inputs-POSPROP block

The required number of inputs is determined by the mode of the POSPROP block.
l If Mode is CAScade, two inputs are required - PV and SP.
l If Mode is AUTOmatic or MANual, only PV is required.
o SP is an initializable input; PV is non-initializable.
stored by the operator.
o 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.
- 529 -
19.14.4 Input ranges and limits-POSPROP block
l You must specify a PV engineering unit range through the configurable PVEUHI and PVEULO
parameters.
l The POSPROP block assumes PV is within PVEUHI and PVEULO - it applies no range check -
and range check.
o 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.14.5 Output-POSPROP block

The POSPROP block has the following initializable outputs:
l RAISETIME = Raise pulse duration.
l LOWERTIME = Lower pulse duration.
l 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.14.6 Initializable inputs and outputs-POSPROP block

level. A parameter with the “initializable” 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
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).
- 530 -
19.14.7 Output ranges-POSPROP block

The POSPROP block uses the maximum and minimum pulse parameters to define pulse duration
ranges and limits.
l 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.
l 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.14.8 Set Point Ramping-POSPROP block

- 531 -
l Otherwise,:
SPTVRATE = NaN
done.
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).

while monitoring the control strategy through Control Builder or the Point Detail display in Station.
- 532 -
l The block calculates a ramp time (SPTVTIME) .
Station.
Otherwise:
SPTVRATE = NaN
Otherwise:
SPTVRATE = NaN
Auto or Manual.

l Off,
l Preset, or
l Run
this occurs:
Station.
- 533 -
Callout Description
1 Block's mode must be Auto and SPTVSTATE must be Preset, before you can start SP
ramping by setting SPTVSTATE to Run with SPTV set to desired value.
2 The SPTVSTATE automatically goes to Preset, when:


3 You can only set a value for SPTV and SPTVTIME, when:
ATTENTION
19.14.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.
- 534 -

19.14.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:
l Updates the SP.
ATTENTION
19.14.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.
l 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
l 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.
- 535 -
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.
SPP=SP in percent.
l The PULSETIME output is set to either the RAISETIME or -LOWERTIME, when either
RAISETIME or LOWERTIME is non-zero.
19.14.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:
l Mode is MANual.
l The POSPROP block is being processed for the first time after being activated.
l The POSPROP block is a secondary and is going through one-shot initialization.
19.14.13 Secondary initialization option-POSPROP block

l If SECINITOPT equals Enable, it means the function block should accept initialization request
from the secondary.
l If SECINITOP equals Disable, it means the function block should ignore initialization request
from the secondary.
19.14.14 Override feedback processing for POSPROP block

The POSPROP block does not propagate override feedback data. It ignores any override feedback
requests.
19.14.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.
- 536 -
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.14.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 Then, control processing is…

Control
Option 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.
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.14.17 Windup processing-POSPROP block


- 537 -
ARWOP computation
If Any of the Following are True … Then, ARWOP Equals …

A secondary exists but this block cannot fetch secondary data

from it (communications or configuration error).
This block's output is at its low

limit (OPLOFL = On).
ARWNET computation
- 538 -

ARWNET
Equals …
The CV is NaN.

On).

On).
19.14.18 Anti-Reset Windup Status-POSPROP block


NORMAL HI HI
NORMAL LO LO
NORMAL HILO HILO
HI NORMAL HI
HI HI HI
- 539 -

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.14.19 POSPROP parameters

the POSPROP block.
19.15 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 given name of the “Tab”in the parameter configuration form and then briefly describes
- 540 -
Tab
l 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.
l 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.
Configuration Lets you select the available parameters that you want to appear on the face
Parameters of the function block in the Project tab in Control Builder.
Monitoring Lets you select the available parameters that you want to appear on the face
Parameters of the function block in the Monitoring tab in Control Builder.
information
l Function-PULSECOUNT block
l Required inputs-PULSECOUNT block
l Output-PULSECOUNT block
l Initializable inputs and outputs-PULSECOUNT block
l PULSECOUNT parameters
19.15.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.
- 541 -
l The + PULSETIME or -PULSETIME come from the POSPROP block at the beginning of a
control interval.
l The control interval is a property of the connected POSPROP block.
l The individual pulses are generated in relation to the configured POPERIOD. The number of
pulses is determined as follows: Pulse Count = PULSETIME / POPERIOD
l 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 19.14 Example of pulse count control algorithm outputs
19.15.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.
19.15.3 Output-PULSECOUNT block

The PULSECOUNT block has the following initializable outputs:
l PORAISE = Pulse output for Raise pulses. These pulses are generated if the pulse width
specified by the PULSETIME input is positive.
l POLOWER = Pulse output for Lower pulses. These pulses are generated if the pulse width
specified by the PULSETIME input is negative.
l PO = Pulse output for both Raise and Lower pulses. These pulses are generated as a logical OR
between the PORAISE and POLOWER pulses.
l 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:
- 542 -
l 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.
l 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.15.4 Initializable inputs and outputs-PULSECOUNT block

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 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 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.15.5 PULSECOUNT parameters

PULSECOUNT block.
19.16 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
- 543 -
Tab
l 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.
information
l Function-PULSELENGTH block
l Required inputs-PULSELENGTH block
l Output-PULSELENGTH block
l Initializable inputs and outputs-PULSELENGTH block
l PULSELENGTH parameters
19.16.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 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.
l The + PULSETIME or -PULSETIME come from the POSPROP block at the beginning of a
control interval.
l The control interval is a property of the connected POSPROP block.
l The PODIR only changes at the beginning of a control interval. The sample pulse shown in the
- 544 -
following figure has a configured Direction Change Delay (PDELAYDIRCHG) of Zero (0).
Table 19.15 Example of pulse length control algorithm outputs
19.16.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.16.3 Output-PULSELENGTH block

The PULSELENGTH block has the following initializable outputs:
l PORAISE = Pulse output for Raise pulses. These pulses are generated if the pulse width
specified by the PULSETIME input is positive.
l POLOWER = Pulse output for Lower pulses. These pulses are generated if the pulse width
specified by the PULSETIME input is negative.
l PO = Pulse output for both Raise and Lower pulses. These pulses are generated as a logical OR
between the PORAISE and POLOWER pulses.
l 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:
l 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.
- 545 -
l 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.16.4 Initializable inputs and outputs-PULSELENGTH block

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
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.16.5 PULSELENGTH parameters

the PULSELENGTH block.
19.17 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:
- 546 -
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 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.
l OPHIALM.TM
l OPHIALM.TMO
l OPHIALM.DB
l OPHIALM.DBU
Each RAMPSOAK block supports the following user configurable attributes. The following table lists
- 547 -
Tab
reports.
l High Limit (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.
l Low Limit (PVEULO) - Lets you specify the low input range value in
engineering units that represents the 0 full scale PV input for the block.
BackupCAScade, and NONE. All selections are not valid for a given block.
following conditions, and changes 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.)
- 548 -
Tab
(unchecked).
secondary or not. The default selection is Enabled (checked, do not ignore
l 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.)
l 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,
Profile l Profile ID - List box shows the configured profiles. The New, Copy, and
Delete buttons let you manipulate profiles as desired.
l 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.
l 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.
l 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.
l 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.
l Starting OP Value (STARTOP[n]) - Lets you specify a desired starting
output (OP) value for each profile. The default value is 0.
l Starting Segment ID (STARTSEG[n]) - Lets you specify the starting
- 549 -
Tab
segment for each profile. The ramp segments have odd numbers and the
soak segments have even numbers. The default value is 1.
l 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.
l 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.
l 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 l Graph - Shows you a graphic representation of the configured set point
versus time profile.
l Profile ID - List box shows configured profiles that you can select for
display in the graph.
l No. of Segments - Number of segments in selected profile.
l Target Profile Time (TOTALTIME[n]) - Total time in minutes to complete
the selected profile.
l 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.
Active Profile l Graph - Shows you a graphic representation of the configured set point
Graph versus time profile with real time data when profile is running in CB
Monitoring tab.
l Mode (MODE) - Shows current mode selection and lets you change the
mode of running profile in CB Monitoring tab.
l Current Profile ID (CURPROFILEID) - Shows number of profile currently
running.
l No. of Segments - Shows the total number of segments in the current
profile.
l Current Segment ID (CURSEGID) - Shows the number of the segment
currently being executed in the selected profile.
l Total Elapsed Time (TOTELAPSEDTM) - Shows the total elapsed time for
current profile execution. It includes time for stopped timers due to
deviation exceeding limits.
l Net Elapsed Time (NETELAPSEDTM) - Shows the net elapsed time for
- 550 -
Tab
current profile execution. It does not include the time for stopped timers
due to deviation exceeding limits.
l Rem Soak Time (REMSOAKTIME) - Shows the remaining soak time for the
current soak segment.
l Soak Duration - Shows the duration of the current soak segment.
l 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.
in the MANual mode. The default value is 105%. (Note that you cannot
change this value through Monitoring mode after the configuration is
loaded in the Controller.)
MANual mode. The default value is -5%. (Note that you cannot change
this value through Monitoring mode after the configuration is loaded in
the Controller.)
value is 106.9%. (Note that you cannot change this value through
Monitoring mode after the configuration is loaded in the Controller.)
is -6.9%. (Note that you cannot change this value through Monitoring
mode after the configuration is loaded in the Controller.)
- 551 -
Tab
last good value.
Safety Interlock Option (SIOPT). The types are:
l Enable Alarm SIALM.OPT ) - Lets you enable or disable Safety Interlock

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.
l OPLOALM.TP (Output Low Alarm Trip Point)
SIALM.PR). The default value is LOW. The levels are:
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.
- 552 -
Tab
CB.
condition occurs.
percent.
RAMPSOAK block. If you configure the deadband unit as “EU or Percent”
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.
- 553 -
Tab
setting manually.
l None
l ONESHOT
l SEMICONT
l CONTRTN
l CONT
l HOLDPV - Set SPREQ = PV. (Not applicable for RAMPSOAK
block)
NaN. (Not applicable for RAMPSOAK block)
SPRATEREQ = Configured Rate. (Not applicable for RAMPSOAK
block)
- 554 -
Tab
Number).
information
l Function-RAMPSOAK block
l Required inputs-RAMPSOAK block
l Input ranges and limits-RAMPSOAK block
l Initializable outputs-RAMPSOAK block
l Output ranges and limits-RAMPSOAK block
l Mode handling-RAMPSOAK block
l Hold command-RAMPSOAK block
l CEE idle or Control Module inactivate command-RAMPSOAK block
l Profile statistics-RAMPSOAK block
l Guaranteed ramp rate-RAMPSOAK block
l Guaranteed soak time-RAMPSOAK block
l Event timer functions-RAMPSOAK block
l Control initialization-RAMPSOAK block
l Override feedback processing-RAMPSOAK block
l Output Indication Function-RAMPSOAK block
l Windup processing-RAMPSOAK block
l Anti-Reset Windup Status-RAMPSOAK block
l RAMPSOAK parameters
19.17.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.
- 555 -
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 19.16 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.
l Calculates its output based on whether the current segment is a ramp or a soak.
o 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]).
o 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.
l 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].
- 556 -
19.17.2 Required inputs-RAMPSOAK block

The RAMPSOAK block only requires a PV input for the guaranteed ramp option.
l PV is non-initializable.
l 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.17.3 Input ranges and limits-RAMPSOAK block
l You must specify a PV engineering unit range, PVEUHI and PVEULO. The default range is 0 to
100.
l 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.17.4 Initializable outputs-RAMPSOAK block

level. A variable with the “initializabl” attribute has an associated BACKCALC variable, and when a
For example, if you connect OP from a RAMPSOAK block to SP on a PID block, Control Builder
(OPX/OPEUX) connection when required. For example, if you 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.17.5 Output ranges and limits-RAMPSOAK block

o If the RAMPSOAK block has a secondary, it brings the secondary's input range
through BACKCALC and sets its CV range to that.
o 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
- 557 -
default range of 0 to 100.
range. You can also configure values for these limits. The default limits are 105% and -5%,
respectively.
another block or user program attempts to store an OP value that exceeds them.
CV range. 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.17.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.
l 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.
l 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.17.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.
l When the HOLDCMD changes from OFF to ON, the profile stops, including all timers.
l When the HOLDCMD changes from ON to OFF, the profile starts where it left off.
19.17.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.
- 558 -
l Sets mode to MANual.

l Sets CV to NaN.
l Resets internal ramp/soak timers.
l Sets current profile ID to 1 (first profile).
l Sets current segment ID to 1 (first ramp segment).
19.17.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.
l ACTRAMPRATE[n,s] - The actual rate for each ramp segment in engineering units per minute.
l ACTSOAKVAL[n,s] - The actual end value for each ramp segment in engineering units.
l ACTSOAKTIME[n,s] - The actual duration of each soak segment in minutes.
l ACTSTARTSEG[n] - The actual starting segment number for each profile.
l 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.17.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.
l 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.17.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.
l If the input (PV) is greater than the CV.
l If the PV is less than the CV.
- 559 -
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.17.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.17.13 Control initialization-RAMPSOAK block

The RAMPSOAK block brings initialization requests from its secondary through BACKCALC. In
addition, the secondary may propagate one shot initialization requests to this block.
l If the secondary is requesting initialization, the RAMPSOAK block:
19.17.14 Override feedback processing-RAMPSOAK block

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

display.
- 560 -

Enumeration
Selection Is . . .
values remain the
same.)
Reverse1 Value reversal - output range is 100 to 0 percent, and no display



1 The RAMPSOAK block does not support the Reverse option selection.
19.17.16 Windup processing-RAMPSOAK block


- 561 -
ARWOP computation

Equals . . .
ARWNET computation

ARWNET
Equals . . .
The CV is NaN

- 562 -

ARWNET
Equals . . .
On)

= On)
19.17.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
LO LO LO
LO HILO HILO
HILO NORMAL HILO
HILO HI HILO
- 563 -

HILO LO HILO
HILO HILO HILO
19.17.18 RAMPSOAK parameters

the RAMPSOAK block.
19.18 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:
l OPHIALM.TM
l OPHIALM.TMO
l OPHIALM.DB
l OPHIALM.DBU
BADCTL alarms.
l BADCTLALM.TM
l 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
- 564 -
Tab
reports.
l 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.
l X1 High Limit (XEUHI) - Lets you specify the high input range value in
engineering units that represents 100% full scale input for the block.
l 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
l Ratio High Limit (RTHILM) - Lets you specify the high ratio limit value in
engineering units. The default value is 100.
l Ratio Low Limit (RTLOLM) - Lets you specify the low ratio limit value in
engineering units. The default value is 0.001.
- 565 -
Tab
(unchecked).
ignore).
SHEDLOW, SHEDHIGH, and SHEDSAFE. The default selection is NO_
SHED.
- 566 -
Tab
is -6.9%.
- 567 -
Tab
The types are:

Summary display.
0.
CB.
- 568 -
Tab
condition occurs.
percent.
RATIOBIAS block. If you configure the deadband unit as “EU or Percent”
RATIOBIAS block. However, if you are migrating from pre-R410 to later
RATIOBIAS block.
setting manually.

- 569 -
Tab
l None
l ONESHOT
l SEMICONT
l CONTRTN
l CONT
SPRATEREQ = Configured Rate (not applicable to this block).

Number).
insertion configuration considerations for regulatory control blocksfor more
information
l Function-RATIOBIAS block
l Configuration example-RATIOBIAS block
l Operating modes and mode handling-RATIOBIAS block
- 570 -
l Required inputs-RATIOBIAS block

l Input ranges and limits-RATIOBIAS block
l Initializable outputs-RATIOBIAS block
l Output ranges and limits-RATIOBIAS block
l Control initialization-RATIOBIAS block
l Ratio bias option-RATIOBIAS block
l Output bias-RATIOBIAS block
l Timeout monitoring-RATIOBIAS block
l Timeout processing-RATIOBIAS block
l Override feedback processing
l Output Indication Function-RATIOBIAS block
l Windup handling-RATIOBIAS block
l Windup processing-RATIOBIAS block
l Anti-Reset Windup Status-RATIOBIAS block
l RATIOBIAS parameters
19.18.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.
- 571 -
19.18.2 Configuration example-RATIOBIAS block

uses a RATIOBIAS block to form a ratio control loop for quick reference. The view in the following
figure depicts a configuration in Project mode.
Table 19.17 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 connection is exposed, but the implicit/hidden connection
function automatically makes a connection to a value/status parameter (PVVALSTS)
when it is required.
2 Use the DATAACQ block to define input range values and provide alarm monitoring on
the analog input.
3 Use the RATIOBIAS block in cascade mode to accept X1 and RT primary inputs from
other blocks.
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.
- 572 -
Callout Description
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
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.18.3 Operating modes and mode handling-RATIOBIAS block

The RATIOBIAS block supports the Manual, Automatic, and Cascade modes of operation.
If Mode Then,
is . . .
Manual the output can be set by the operator or a user program. The X1 and RT inputs are
(MAN) ignored. The block continually initializes both primaries, while in this mode.
Automatic the X1 input comes from another function block and the RT input can be set by the
(AUTO) operator or a user program. The block continually initializes the RT primary, while in
this mode.
Cascade both X1 and RT inputs come from other function blocks.

(CAS)
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.18.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.
l 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
l The X1 input must come from another function block. You cannot set this value.
l 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.18.5 Input ranges and limits-RATIOBIAS block
l You must specify an X1 engineering unit range, XEUHI and XEULO.
- 573 -
o XEUHI and XEULO define the full range of X1 in engineering units.

l This block assumes X1 is within XEUHI and XEULO - it applies no range check
l 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.
o 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.18.6 Initializable outputs-RATIOBIAS block

when a connection is created between an initializable input and initializable output, you can also
For example, if you connect OP from a RATIONBIAS block to SP on a PID block, Control Builder
l The RATIOBIAS block has the following initializable outputs:
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
you do not make multiple connections from a single RATIOBIAS output.
19.18.7 Output ranges and limits-RATIOBIAS block

CV range to that. If it has no secondary, CVEUHI and CVEULO track the X1 input range (XEUHI
and XEULO).
- 574 -
ATTENTION
These are user-specified values.
OPHILM and OPLOLM define the extended high and low limits for OP, as a percent of the CV
This block calculates CV using this equation:
l CV = X1 * RT + OPBIAS.FIX + OPBIAS.FLOAT
19.18.8 Control initialization-RATIOBIAS block

The RATIOBIAS block brings initialization requests from its secondary through BACKCALC. In
If the secondary is requesting initialization, the RATIOBIAS block:
o CV = initialization value from the secondary
l calculates initialization values for the X1 and RT primaries:

o INITVAL[1] = (CV - OPBIAS.FIX) / RT
o 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.)
l requests both primaries to initialize:
o INITREQ[1] = ON
o 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.18.9 Ratio bias option-RATIOBIAS block

The following table summarizes block operation for given ratio bias option (RBOPTION) selection.
- 575 -
If RBOPTION Then, Block Behavior Is. . .

Selection 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.
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.18.10 Output bias-RATIOBIAS block

- 576 -
the RATIOBIAS block only applies OPBIAS.FLOAT to the output for the latter two conditions,

ATTENTION
necessary.
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)].”
following occurs:

Where:
be zero.
- 577 -
o Zero:
o Non-zero:
configured for the OPBIAS.RATE parameter. The function block ramps the
OPBIAS.FLOAT to zero by applying the following calculation each time it executes.
Where:
o NaN:
19.18.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.18.12 Timeout processing-RATIOBIAS block
l If RT times out, the RATIOBIAS block does the following:

o Holds RT at its last good value.
o Changes the mode to a user-specified TMOUTMODE.
o Requests the RT primary to initialize.
l If X1 times out, the RATIOBIAS block does the following:

o 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.
- 578 -
ATTENTION
19.18.13 Override feedback processing

If the RATIOBIAS 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
When the override status changes from selected to unselected, the RATIOBIAS block does the
following:
l 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.18.14 Output Indication Function-RATIOBIAS block

display.
- 579 -

Enumeration
Selection Is . . .
values remain the
same.)



ATTENTION

OPHIALM.PR and .SV, and Reverse of Actual OPHIALM.PR and .SV, and
OPLOALM.PR and .SV OPLOALM.PR and .SV
- 580 -

OPROCPOSFL AND OPROCNEGFL Reverse of Actual OPROCPOSFL and OPROCNEGFL
STARTVAL, STOPVAL, HOLDVAL 100 - Actual STARTVAL, STOPVAL, HOLDVAL (Applicable

only when corresponding option is FixedOp.)
ATTENTION
REVERSE.
- 581 -
19.18.15 Windup handling-RATIOBIAS block

The RATIOBIAS block computes these three anti-reset windup status parameters.
l ARWOP
l ARWNET[1]
l 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 Hi HiLo Hi
its high limit
clamped at is Lo Lo HiLo
low limit
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; And ARWOP = Lo; And ARWOP = Hi;
then, ARWNET[2] =. . . then, ARWNET[2] =. . then, ARWNET[2] =. .
. .
not NORMAL Lo Hi
clamped
clamped at Hi HiLo Hi
its high
limit
clamped at Lo Lo HiLo
is low limit
19.18.16 Windup processing-RATIOBIAS block


- 582 -
ARWOP computation

Equals . . .
ARWNET computation
- 583 -

ARWNET
Equals . . .
The CV is NaN

On)

= On)
19.18.17 Anti-Reset Windup Status-RATIOBIAS block

(CAB) programs.

Parameters is… Logic Is . . . Parameter Is . . .
NORMAL HI HI
NORMAL LO LO
NORMAL HILO HILO
HI NORMAL HI
HI HI HI
HI LO HILO
- 584 -

Parameters is… Logic Is . . . Parameter Is . . .
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 RATIOBIAS parameters

the RATIOBIAS block.
19.19 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:
- 585 -
l OPHIALM.TM
l OPHIALM.TMO
l OPHIALM.DB
l OPHIALM.DBU
The following parameters can be used for configuring the on-delay time and off-delay time for the
BADCTLALM alarm.
l BADCTLALM.TM
l BADCTLALM.TMO
Each RATIOCTL block supports the following user configurable attributes. The following table lists
- 586 -
Tab
hierarchy.
reports.
(unchecked).
- 587 -
Tab
ignore).
SHED.
to use. The selections are EQA, EQB, EQC, and EQD. See the Equations-
RATIOCTL block section for this block for details. The default selection is
EQA.
l X1 High Limit (XEUHI) - Lets you specify the high input range value in
engineering units that represents 100% full scale input for the block.
l 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
l X1 Input Bias (X1BIAS) - Lets you specify a bias value for the X1 input.
l X2 Input Bias (X2BIAS) - Lets you specify a bias value for the X2 input.
l X1 Scale Factor (K1) - Lets you specify a scaling factor for the X1 input.
l X2 Scale Factor (K2) - Lets you specify a scaling factor for the X2 input.
is 240.
value is 0.
Set Point l SP (SP) - Lets you specify an initial set point value. The default value is 0.
- 588 -
Tab
from a user specified “advisor” SP value. The default selection is
deviation alarm.
more details.
l 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.
- 589 -
Tab
is -6.9%.
l Process Variable (PV) - Lets you view the actual ratio between inputs X1
and X2.
- 590 -
Tab
l OP Tolerance Limit in % - Lets you specify a tolerance limit in percent for
the OP output.
The types are:

selection is a 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.
Summary display.
0.
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 R500.1, once the deadband value was configured, this value was
CB.
l With R410, the deadband value can be individually configured for each
OPLOALM.DB as 3. However, if you are migrating from pre-R500.1 to
later releases, refer to Impact of migration on alarm attributes.
- 591 -
Tab
condition occurs.
Prior to R500.1, once configured, this value was loaded to the individual
l With R410, the deadband time can be individually configured for each
R500.1 to later releases, refer to Impact of migration on alarm attributes.
percent. Prior to R500.1, 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.
RATIOCTL block. If you configure the deadband unit as “EU or Percent”
RATIOCTL block. However, if you are migrating from pre-R500.1 to later
RATIOCTL block.
setting manually.

configured Off-delay time. However, if you are migrating from pre-R500.1
- 592 -
Tab
l None
l ONESHOT
l SEMICONT
l CONTRTN
l CONT

Number).
Identification Lets you view the template properties for the block. You need the Template
license to use this form.
- 593 -
Tab
information
l Function-RATIOCTL block
l Configuration example-RATIOCTL block
l Operating modes and mode handling-RATIOCTL block
l Required inputs-RATIOCTL block
l Input ranges and limits-RATIOCTL block
l Initializable outputs-RATIOCTL block
l Output ranges and limits-RATIOCTL block
l Control initialization-RATIOCTL block
l Equations-RATIOCTL block
l Output bias-RATIOCTL block
l Timeout monitoring-RATIOCTL block
l Timeout processing-RATIOCTL block
l Override feedback processing-RATIOCTL block
l Output Indication Function-RATIOCTL block
l Windup handling-RATIOCTL block
l Windup processing-RATIOCTL block
l Anti-Reset Windup Status-RATIOCTL block
l Restart or point activation-RATIOCTL block
l Error handling-RATIOCTL block
l RATIOCTL parameters
19.19.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.19.2 Configuration example-RATIOCTL block

The following figure shows a sample configuration that uses a RATIOCTL block to form a ratio
- 594 -
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 19.13 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.
19.19.3 Operating modes and mode handling-RATIOCTL block

The RATIOCTL block supports the Manual, Automatic, and Cascade modes of operation.
- 595 -
If Mode Then,
is …
Manual the block does not compute OP; it maintains the user-specified OP value and
(MAN) ignores all input.
When MODE is changed to Man, the block:
l 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.
l 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 The function block derives OP and the initializable input (SP) may be stored by the
(AUTO) operator or a user program.
Cascade The function block fetches its intializable input (SP) from the primary, and calculates
(CAS) OP. The primary may be on-node or off.
19.19.4 Required inputs-RATIOCTL block
l A RATIOCTL block requires these three inputs:

o X1 - the actual value of the controlled flow.
o X2 - the actual value of the uncontrolled flow
o SP - the target ratio between the controlled and uncontrolled flows.
l 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.
l The X1and X2 inputs must come from other function blocks. You cannot store to them.
l If Mode is Cascade, SP is pulled from another function block. If Mode is Automatic, it may be
19.19.5 Input ranges and limits-RATIOCTL block
l You must specify X1 and X2 engineering unit range, XEUHI and XEULO.
o XEUHI and XEULO define the full range of the X inputs in engineering units.
l This block assumes X inputs are within XEUHI and XEULO - it applies no range check
l 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.19.6 Initializable outputs-RATIOCTL block

- 596 -
when a connection is created between an initializable input and initializable output, you can also
For example, if you connect OP from a RATIOCTL block to SP on a PID block, Control Builder
l The RATIOCTL block has the following initializable outputs:
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
you do not make multiple connections from a single RATIOCTL output.
19.19.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.
These are user-specified values.
- 597 -
19.19.8 Control initialization-RATIOCTL block

The RATIOCTL block brings initialization requests from its secondary through BACKCALC. In
If the secondary is requesting initialization, the RATIOCTL block:
l Builds an initialization request for its primary based on CTLEQN selected as follows:
If CTLEQN And, Initialization Request for Then, Initialization Value for the
Is… Primary Primary Is…
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.19.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:
- 598 -
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:
- 599 -
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.19.10 Output bias-RATIOCTL block

l OPBIAS is recomputed under the following conditions to avoid a bump in the output.

ATTENTION
necessary.
following occurs:
- 600 -
Where:
be zero.
o Zero:
o Non-zero:
Where:
l NaN:
19.19.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.19.12 Timeout processing-RATIOCTL block

If MODE is Cascade and SP times-out, the RATIOCTL block does the following:
- 601 -

l Holds SP at its last good value
l Changes the mode to a user-specified “timeout mode” (MODE = TMOUTMODE)
l 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
l The RATIOCTL block only sets CASREQFL if the original mode was Cascade, the SP input
times-out, and TMOUTMODE = Auto.
l You may clear the CASREQFL but you cannot set it. This lets you disable the automatic return
to Cascade mode.
l If you change mode, the CASREQFL is cleared, which disables the return to Cascade mode.
ATTENTION

19.19.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.
l the block's windup state changes
l the block is requested to do a one shot initialization
l 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
When the override status changes from selected to unselected, this block does the following:
l Does not initialize its CV
l Computes a feedback value for the SP primary depending on the CTLEQN selected as follows:
- 602 -
If CTLEQN Is … Then, Feedback Value for Primary Is …

A
Where:
K1 = gain for X1
K2 = gain for X2
X2BIAS= bias for X2
19.19.14 Output Indication Function-RATIOCTL block

display.

Enumeration
Selection Is …
values remain the
same.)



- 603 -
ATTENTION


OPROCNEGFL

FixedOp.)
- 604 -
ATTENTION
REVERSE.
19.19.15 Windup handling-RATIOCTL block

The RATIOBIAS block computes these three anti-reset windup status parameters.
l ARWOP
l ARWNET[1]
l 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.)
- 605 -
If OP is… And Secondary's And Secondary's And Secondary's

Windup = Normal; then, Windup = Lo; then, Windup = Hi; then,
ARWOP =… ARWOP =… ARWOP =…
not NORMAL Lo Hi
clamped
clamped Hi HiLo Hi
at its high
limit
clamped Lo Lo HiLo
at is low
limit
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 = And ARWOP =

ARWNET[2] =… Lo; then, Hi; then,
ARWNET[2] =… ARWNET[2] =…
not clamped NORMAL Lo Hi
clamped at its Hi HiLo Hi

high limit
clamped at is Lo Lo HiLo
low limit
19.19.16 Windup processing-RATIOCTL block


- 606 -
ARWOP computation

Equals …
ARWNET computation

ARWNET
Equals . . .
The CV is NaN

- 607 -

ARWNET
Equals . . .
On)

= On)
19.19.17 Anti-Reset Windup Status-RATIOCTL block

(CAB) programs.

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
- 608 -

HILO LO HILO
HILO HILO HILO
19.19.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.19.19 Error handling-RATIOCTL block

The RATIOCTL block performs the following error checking:
l Check for Bad Control alarm conditions
l Check if X1 and X2 are valid:
o 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.
o When X1 and X2 return to normal, the block initializes CV to the following:
19.19.20 RATIOCTL parameters

the RATIOCTLblock.
- 609 -
19.20 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.
l OPHIALM.TM
l OPHIALM.TMO
l OPHIALM.DB
l OPHIALM.DBU
l BADCTLALM.TM
l BADCTLALM.TMO
Each REGCALC block supports the following user configurable attributes. The following table lists
- 610 -
Tab
reports.
When an operator changes the mode (MODE), then Mode
Attribute (MODEATTR) is changed to OPERATOR automatically.
This allows single button access by the operator.
(unchecked).
- 611 -
Tab
ignore).
disabled.
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.
l XK (XK[1..6]) - Lets you specify an individual gain value for each of the six
X inputs. The default value is 1.
l 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.
- 612 -
Tab
is -6.9%.
equation for calculating the CV output value. This value helps guarantee
that the output is “bumpless” following initialization or mode changes.
value is 240.
value is 0.
l 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.
- 613 -
Tab
l 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.
l 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 connected to an initializable input of its secondary block.
l 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.
l 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.
l 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).
l 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 connected to an initializable input of its
secondary block.
l 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.
value to set the primary initialization value (PRIMDATA
(1).INITVAL).
l 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).
l 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).
- 614 -
Tab
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)
l 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 whether or not a source is assigned and a secondary exists as
follows.
l If a source is assigned, this block uses the assigned source flag
to set the primary override initialization flag (PRIMDATA
(1).ORFBSTS).
l 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).
l Override Feedback Value (ORFBVALSRC) - Lets you assign an input or

expression result as the source of the override feedback value for the
selection is NONE. The REGCALC block uses different values for this
value even if a secondary exists.
l If no source is assigned and a secondary exists, this block uses
the corresponding value from the secondary.
l 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)
- 615 -
Tab
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.
The types are:

Summary display.
0.
CB.
- 616 -
Tab
condition occurs.
percent.
REGCALC block. If you configure the deadband unit as “EU or Percent”
REGCALC block. However, if you are migrating from pre-R410 to later
Note:You must configure identical deadband units for all alarms in the
REGCALC block.
setting manually.
Disable - An alarm is not notified whenever a mode shed
This parameter is available for configuration only if the Enable

- 617 -
Tab
l None
l ONESHOT
l SEMICONT
l CONTRTN
l CONT
block).

respective range. For output, within OPEXLOLM to OPEXHILM and
within SPLOLM to SPHILM, for set point. The default value is NaN (Not a
Number).
Expr# 1 to Expression (C[1..8]) - Lets you write up to eight desired expressions for custom
Expr# 8 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.
- 618 -
Tab
information
l Function-REGCALC block
l Operating modes and mode handling-REGCALC block
l Inputs-REGCALC block
l Input ranges and limits-REGCALC block
l Initializable outputs-REGCALC block
l Output ranges and limits-REGCALC block
l Assignable outputs-REGCALC block
l Output assignment rules-REGCALC block
l Control initialization-REGCALC block
l Output bias-REGCALC block
l Timeout monitoring-REGCALC block
l Timeout processing-REGCALC block
l Override feedback processing-REGCALC block
l Output Indication Function-REGCALC block
l Windup handling-REGCALC block
l Windup processing-REGCALC block
l Anti-Reset Windup Status-REGCALC block
l Expressions-REGCALC block
l Parameters in Expressions-REGCALC block
l Guidelines for Writing Expressions-REGCALC block
l String data support in expressions-REGCALC block
l Time support in expressions-REGCALC block
l REGCALC parameters
19.20.1 Function-REGCALC block
l Each expression can contain any valid combination of inputs, operators and functions; and
may perform arithmetic or logic operations.
l 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.
l 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.
- 619 -
19.20.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.
MANual to CAScade.
19.20.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.
l X[1] - An initializable input that must come from another block, an operator cannot set it.
l X[2] through X[6] general purpose inputs.
l XK[1..6] individually configurable gain value for each input.
l XB[1..6] individually configurable bias value for each input.
l XKB[1..6] individual inputs with gain and bias values applied to them.
l XWHIFL - An external windup high flag.
l 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
19.20.4 Input ranges and limits-REGCALC block
l If this block has a primary, you must specify an X[1] engineering unit range, XEUHI and
XEULO. These only apply to initializable input.
o XEUHI and XEULO define the full range of X1 in engineering units.
l 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.
19.20.5 Initializable outputs-REGCALC block

level. A parameter with the “initializabl” attribute has an associated BACKCALC variable, and when
a connection is created between an initializable input and initializable output, you can also create a
so you don't have to create them manually. These “implici” build connections are “hidde” from view
and the related parameter pins are not exposed on the control chart.
if you connect OP from a REGCALC block to SP on a PID block, Control Builder automatically
creates the BACKCALCOUT to BACKCALCIN connection.
- 620 -
l 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
you do not make multiple connections from a single REGCALC output.
19.20.6 Output ranges and limits-REGCALC block

CV range to that. If it has no secondary, you must specify the values for CVEUHI and CVEULO.
ATTENTION
You must specify these values.
range. You must specify these values.
19.20.7 Assignable outputs-REGCALC block

You can assign expression results and/or inputs to the following parameters.
l CVSRC - CV output source selector.
l CVINITSRC - CVINIT source selector.
l CVORFBSRC - CVORFB source selector.
- 621 -
l INITREQSRC - INITREQ (initialization request flag) source selector.

l INITVALSRC - INITVAL (initialization value) source selector.
l ORFBVALSRC - ORFBVAL (override feedback value) source selector.
l 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.20.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.
l The following parameters should be assigned to an input or an expression result

o 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.
o 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.
o 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.
l The following parameters are provided to the primary through this block's BACKCALC data.
- 622 -
o INITREQSRC
o INITVALSRC
o ORFBVALSRC
o ORFBSTSSRC
o 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 Then, This Block…

… Secondary…
assigned does or does not uses the assigned value.
exist
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.20.9 Control initialization-REGCALC block

The REGCALC block brings initialization requests from its secondary through BACKCALC. In
If the secondary is requesting initialization, the REGCALC block:
CV =CVINIT (an assignable output)
l 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:
l Connecting X[1] for input from the primary.
l Assigning CVSRC to X[1] input.
l Configuring all other parameters like OPBIAS.RATE the same as you would for an AUTOMAN
block.
19.20.10 Output bias-REGCALC block

- 623 -
the REGCALC block only applies OPBIAS.FLOAT to the output for the latter two conditions,

ATTENTION
necessary.
following occurs:

Where:
be zero.
- 624 -
o Zero:
o Non-zero:
Where:
cycles_per_min
=
number of times the function block executes per minute (calculated)
o NaN:
l After initialization, the REGCALC block calculates the floating bias using the following equation.
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.20.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.20.12 Timeout processing-REGCALC block

If X[1] times out, the REGCALC block does the following:
l Sets the input timeout flag (TMOUTFL).
l Requests the X[1] primary to initialize.
- 625 -
ATTENTION
19.20.13 Override feedback processing-REGCALC block

If the REGCALC 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
When the override status changes from selected to unselected, the REGCALC block does the
following:
CV=CVORFB (an assignable output)
l 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.
- 626 -
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.20.14 Output Indication Function-REGCALC block

display.

Enumeration
Selection Is …
values remain the
same.)



ATTENTION
Considerations for OUTIND Reverse selection-REGCALC block
- 627 -


OPROCNEGFL

FixedOp.)
ATTENTION
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.
- 628 -
REVERSE.
19.20.15 Windup handling-REGCALC block

The REGCALC block derives the ARWOP from a combination of the following parameters and the
secondary's windup status.
l CV
l XWHIFL
l XWLOFL
The following table summarizes how the block derives ARWOP for some given conditions.
If XWLOFL and/or XWHIFL And a Then, the Block Derives ARWOP

are… Secondary… from …
True does or does not CV, XWHIFL, and XWLOFL.
exist
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.20.16 Windup processing-REGCALC block

- 629 -

ARWOP computation

Equals …
ARWNET computation
- 630 -

ARWNET
Equals …
The CV is NaN

On)

On)
19.20.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
- 631 -

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.20.18 Expressions-REGCALC block

inputs, operators, and functions. Table 2 lists the expression operators and functions supported by
this block for reference as well as some case sensitive strings that can be used for special value
constants in expressions.
ATTENTION
Do not use equality operands = and <> to compare FLOAT64 and FLOAT32 floating point
values in expressions. Use inequality operands Less Than (<), Less Than or Equal To (<=),
Greater Than (>), or Greater Than or Equal To (>=) instead.
Table 19.18 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
COS 1 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
- 632 -
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 MID medium value of n arguments

bad values). (average of middle values for even
n).
If this function has a NAN argument
(bad value), it returns NaN. If this function has a NAN
argument (bad value), it returns
NaN.
MAX maximum of n arguments (ignore MUL product of n arguments.
bad values).
This function ignores NaN values.
If this function has a NAN argument However, if all arguments are NaN,
(bad value), it returns NaN. then it returns 1.
AVG average of n arguments. SUM sum of n arguments.
This function ignores NaN values. This function ignores NaN values.
However, if all arguments are NaN, However, if all arguments are NaN,
then it returns NaN. then it returns 0.
String Support Functions
LEN Returns an integer length of the NUMSTR Takes the input parameter, casts it
string to a Float64 and converts it to a
string
MIDS Takes a string, an integer starting STRNUM Takes the string input parameter
position and an integer length. The and converts 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
strips off the year and date and returns a 64-bit float representing
returns a 64-bit float representing the number of milliseconds.
the time of day in milliseconds.
NOW Returns the current local date and NUMDTIM Takes a 64-bit float representing
time as an absolute time data type some 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
number of milliseconds since Jan 1, converts it to an Absolute time. The
1972 and converts it to absolute string must be in the same format
TIME data type. as an Absolute time constant.
TOD Returns the current local time of day TIMNUM Takes an Absolute TIME data type
as Time of Day data type and 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
as Time of Day data type time of day as an absolute time
data type
- 633 -
1Be sure you specify the trigonometric functions cosine, sine, and tangent in radians and not
degrees.

NAN IEEE NaN value
+INF IEEE + Infinity value
-INF IEEE - Infinity value
PI PI (3.14159. . .)
E e (2.718. . .)
19.20.19 Parameters in Expressions-REGCALC block

You must specify a parameter by its full tag name (for example, “CM25.PumpASelect.PVFL”, or
an expression.
The expression syntax has been expanded. Delimiters (') can be used in an expression containing
something that the external reference component will understand. If this text is incorrect, runtime
errors will occur.
ATTENTION
19.20.20 Guidelines for Writing Expressions-REGCALC block
l 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.
- 634 -
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
numeric types.
TIP
parameters.
l 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:
o 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

expressions.
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
retains its values.
- 635 -
19.20.21 String data support in expressions-REGCALC block

The following operators can have string constants and/or string references as operands.
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”
19.20.22 Time support in expressions-REGCALC block
Time data types
The following time data types are supported in expressions.

l Absolute Time - Is stored as a 64-bit integer representing the number of tenths of
milliseconds since 1/1/1972.
l Delta Time - Is also stored as a 64-bit integer and it represents an Absolute time difference in
tenths of milliseconds.
l 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.

l An Absolute Time constant is entered MM/DD/YYY hh:mm:ss:uuuu, where uuuu is
milliseconds
l A Delta Time constant is entered as hh:mm:ss:uuuu, where uuuu is milliseconds
l 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:
- 636 -
expression to a reference. The data type in the expression result must agree with
the data type of the reference.
+ If both operands are of the same time data type the result is the same data type.
Delta time or Time of Day can be added to an absolute time, which results in
absolute time. Time of day can be added to delta time, which results in a delta time.
See the next section Adding time data types. .
* One operand can be a delta time or time of day data type and the second operand
must be a number. The result is a delta time data type.
- 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.
DAYS 1 Tskes operand and returns equivalent delta time value.
HOURS 1 Takes operand and returns equivalent delta time value.
MINS 1 Takes operand and returns equivalent delta time value.
SECS 1 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
Operand 2 Data Type Operand 1 Data Type

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
- 637 -
Time expression examples
The following are examples of some valid time expressions.

l MYCM.block.elapsedtime > 5 MINS
l CEE01.CURRTIME + 2 DAYS
l CEE01.CURRTIME > 10/30/2002
l CEE01.CURRTIME + CM.TIMER.SP SECS
l (CEE01.CURRTIME - 1/01/2002 10:15:01)*2.
l STRTIM(“12/01/2002”") > CEE01.CURRTIME
l TIMNUM(CEE01.CURRTIME)
l NUMTIM(1000.0)
l NOW - MyCM.myblock.todparam
l ABSTOD(CEE01.CURRTIME)
The following are examples of invalid expressions.

l CEE01.CURRTIME + 2
l CEE01.CURRTIME > 5.0
Refer to the section Time Support in Experion System for more information about time support in
the system
19.20.23 REGCALC parameters

the REGCALC block.
19.21 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:
- 638 -
Each REEOUT block supports the following user configurable attributes. The following table lists
attributes associated with that TAB. This data is only provided as a quick document reference, since
Tab

the 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
l Function-REEOUT block
l Configuration Example-REEOUT block
l Inputs-REEOUT block
l Outputs-REEOUT block
l Push of SP to secondary cluster's regulatory FBs-REEOUT block
l REEOUT parameters
19.21.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.
19.21.2 Configuration Example-REEOUT block

A sample usage of the block in conjunction with the Inter Cluster Gateway is shown in the
following figure:
- 639 -
19.21.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:
l BACKCALCOUT: The ACE BACKCALC structure is a hidden connection that is automatically
made by the system.
l 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.21.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.21.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.21.6 REEOUT parameters

the REEOUT block.
19.22 REGSUMMER (Regulatory Summer) Block

This function block calculates an output value which is the sum of up to four inputs. Each of the
- 640 -
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:
l OPHIALM.TM
l OPHIALM.TMO
l OPHIALM.DB
l OPHIALM.DBU
BADCTLALM alarm.
l BADCTLALM.TM
l 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
- 641 -
Tab
reports.
a number between 1 and 32767. The default value is 10. Refer to the
l 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
ignore).
- 642 -
Tab
NOSHED.

(zero).
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.
l XDESC[1..4] - Lets you specify a text string of up to 23 characters to
identify inputs 1..4.
l XK(1)..XK(4) - Lets you specify the scaling factors for inputs 1..4
- 643 -
Tab
value is 106.9%.
is -6.9%.
example, if the CV range is 0 to 500 and you enter a Safe OP of 50%, the
last good value.
l 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.
equation for calculating the CV output value. See the equation following
this table for details. The default value is 1.
value is 240.
(K) is clamped to this value, if the specified gain is less than it is. The
default value is 0.
- 644 -
Tab
Alarms l Type - Identifies the types of alarm this block supports. Of course, these
The types are:

selection is a 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.
type (SIALM.PR, BADCTLALM.PR, OPHIALM.PR, and OPLOALM.PR). The
Summary display.
type (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.
CB.
- 645 -
Tab
condition occurs.
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 an alarm, this configuration is identical for the all other
alarms in the REGSUMMER block. However, if you are migrating from
pre-R410 to later releases, refer to Impact of migration on alarm
attributes.
Note:You must configure identical deadband units for all alarms in the
REGSUMMER block.
setting manually.
Note:This parameter is available for configuration only if the

- 646 -
Tab
l None
l ONESHOT
l SEMICONT
l CONTRTN
l CONT
block).
NaN.

Number).
information
- 647 -
Tab
Defining
l Equation-REGSUMMER block
l Function-REGSUMMER block
l Configuration example-REGSUMMER block
l Inputs-REGSUMMER block
l Outputs-REGSUMMER block
l Initializable inputs and outputs-REGSUMMER block
l Output Ranges-REGSUMMER block
l Output bias-REGSUMMER block
l Mode handling-REGSUMMER block
l Control initialization-REGSUMMER block
l Override feedback processing-REGSUMMER block
l Output Indication Function-REGSUMMER block
l Windup processing-REGSUMMER block
l REGSUMMER parameters
19.22.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.22.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.
- 648 -
19.22.3 Configuration example-REGSUMMER block

The following screen shot depicts the scenario wherein the REGSUMMER block is used:
19.22.4 Inputs-REGSUMMER block

The RegSummer block accepts up to four inputs -- X(1) through X(4).
l 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.
l The inputs must be pulled from other function blocks; the user cannot store to them.
l This block has one primary. (There is one primary per initializable input.)
l 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”
l NUMXINPT represents the number of input connections that has been made to this block
19.22.5 Outputs-REGSUMMER block

The REGSUMMER block has the following initializable outputs:
l OP - Calculated output, in percent
l OPEU - Calculated output, in engineering units
- 649 -
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.22.6 Initializable inputs and outputs-REGSUMMER block

“Initializable output” and “Initializable input” are variable attributes, similar to data type or access
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.22.7 Output Ranges-REGSUMMER block
l CVEUHI and CVEULO define the full range of CV, in engineering units.
l 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).
l 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).
l 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.
l 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.
l The operator is prevented from storing an OP value that exceeds these limits.
l 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.22.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
- 650 -
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.22.9 Mode handling-REGSUMMER block

This function block supports the Cascade and Manual modes:
l If MODE = Cascade, X[1] input must be pulled from another function block.
l If MODE = Manual, OP may stored by the operator or a user program. (All inputs are ignored.).
l The inputs X(2) to X(4) have to be pulled from other function blocks irrespective of whether
MODE is Cascade or Manual.
l This block requests all primaries to initialize after any mode-change.
19.22.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.

l Initializes its output:
o If the initialization value received from the secondary is within the output limits of this
function block:
o Otherwise, CV is clamped to the appropriate limit.
Builds an initialization request for the X(1) primary as follows:

INITREQ = On
- 651 -
NOTE Note
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
NOTE 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.22.11 Override feedback processing-REGSUMMER block

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 Selector block). The offset flag only applies to PID-type function blocks.
ATTENTION
SECINITOPT may be used to ignore override requests from the secondary.
l Calculates a feedback value for its primary:
- 652 -
primary feedback =
NOTE Note
where:
OPBIAS.FIX = Fixed output bias
OPBIAS.FLOAT = Floating output bias
When only the X1 input is used:
19.22.12 Output Indication Function-REGSUMMER block

display.

Enumeration
Selection Is . . .
values remain the
same.)



- 653 -

Enumeration
Selection Is . . .
ATTENTION
Considerations for OUTIND Reverse selection-REGSUMMER block


- 654 -
ATTENTION
REVERSE.
19.22.13 Windup processing-REGSUMMER block


- 655 -
ARWOP computation

Equals . . .
ARWNET computation
- 656 -

ARWNET
Equals . . .
The CV is NaN

On)

= On)
19.22.14 REGSUMMER parameters

Refer to Control Builder Components Referencefor a complete list of the parameters used with the
REGSUMMER block.
- 657 -
19.23 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:
l 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.
l If TRACKING is Off, this block does not initialize the unselected input.
whether TRACKING is On or Off.
l OPHIALM.TM
l OPHIALM.TMO
l OPHIALM.DB
l OPHIALM.DBU
BADCTLALM alarm.
l BADCTLALM.TM
l BADCTLALM.TMO
- 658 -
Each REMCAS block supports the following user configurable attributes. The following table lists
- 659 -
Tab
reports.
a number between1 to 32767. The default value is 10. Refer to the
Enabled (checked) . A store to MODE does not change the NORMMODE.
(unchecked).
represents 100% full scale input for the block. The default value is 100.
represents the 0 full scale input for the block. The default value is 0
- 660 -
Tab
(zero).
l X1 (XDESC[1]) - X1 input descriptor of up to 15 characters long.
l X2 XDESC[2]) - X2 input descriptor of up to 15 characters long.
l 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.
l When TRACKING is ON, the block only propagates to the
selected input.
l When TRACKING is OFF, the block propagates changes in the
windup status and override feedback data to all inputs.

ignore).
disabled.
SHED.
- 661 -
Tab
value is 106.9%.
is -6.9%.
last good value.
The types are:
- 662 -
Tab

Summary display.
CB.
condition occurs.
- 663 -
Tab
percent.
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 block. However, if you are migrating from pre-R410 to later
You must configure identical deadband units for all alarms in the REMCAS
block.
setting manually.
l None
l ONESHOT
l SEMICONT
- 664 -
Tab
l CONTRTN
l CONT
block).

Number).
information
l Function-REMCAS block
l Configuration example-REMCAS block
l Inputs-REMCAS block
l Input ranges and limits-REMCAS block
l Input descriptors-REMCAS block
- 665 -
l Outputs-REMCAS block
l Output ranges and limits-REMCAS block
l Output Indication Function-REMCAS block
l Mode handling-REMCAS block
l Timeout monitoring-REMCAS block
l Timeout processing-REMCAS block
l Input switching-REMCAS block
l Equations-REMCAS block
l Output bias-REMCAS block
l Control Initialization-REMCAS block
l Override feedback processing-REMCAS block
l Windup processing-REMCAS block
l Anti-Reset Windup Status-REMCAS block
l REMCAS parameters
19.23.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 19.19 Functional block diagram of typical remote cascade operation.
19.23.2 Configuration example-REMCAS block

The following figure (Views A and B) and its companion callout description table show a sample
- 666 -
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.
Figure 19.14 View A - Remote Primary Control Loop
Figure 19.15 Example of CB configuration using REMCAS block
- 667 -
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 BACKCALCIN/BACKCALCOUT connections for each output used
are automatically built by Control Builder as implicit/hidden connections.
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
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
- 668 -
Callout Description
connection function automatically makes a connection to a value/status parameter
(PVVALSTS) when it is required.
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.23.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.
l X1 and X2 are both initializable inputs.
l X1 and X2 must be pulled from other function blocks; they cannot be stored manually.
l This block has two primaries. (There is one primary per initializable input.)
19.23.4 Input ranges and limits-REMCAS block
l 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%.
l XEUHI and XEULO apply to both inputs (X1 and X2).
l This block assumes both inputs are within XEUHI and XEULO; it applies no range-checks.
19.23.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.23.6 Outputs-REMCAS block

The REMCAS block has the following initializable outputs:
- 669 -
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.23.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
19.23.8 Output Indication Function-REMCAS block

display.

Enumeration
Selection Is . . .
values remain the
same.)


- 670 -

Enumeration
Selection Is . . .
ATTENTION


OPROCNEGFL

FixedOp.)
- 671 -
ATTENTION
REVERSE.
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.
- 672 -

Fail close valve; air to open - normal case l REGCTL OUTIND = Direct
l REGCTL OP 0% translated to 4 mA by the
l REGCTL OP 100% translated to 20 mA by
the AO, corresponding to the valve open
valve closed
Fail open valve; air to close - reversal l REGCTL OUTIND = Direct

handled in AO channel
valve open
Fail open valve; air to close - display l REGCTL OUTIND = ReverseDispInd

l REGCTL OP 100% translated to 20 mA by
the AO, corresponding to the valve closed
valve open
19.23.9 Mode handling-REMCAS block

This block supports the Cascade, Backup Cascade, and Manual modes:
l If the remote source (X1) is the currently selected input, the MODE is CAScade
l If the backup source (X2) is the currently selected input, the MODE is Backup CAScade
l If the MODE is MANual, an operator or user program may store OP. In this case, X1 and X2 are
ignored.
Regarding mode-changes:
l This block requests both primaries to initialize after any mode-change except MANual to
CAScade and CAScade to Backup CAScade.
19.23.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.
- 673 -

19.23.11 Timeout processing-REMCAS block

If the MODE is CAScade and an input times out, this block does the following :
l If X1 times out, but X2 is good, the block:
o sets the “input timeout” flag (TMOUTFL)
o sets the MODE to Backup Cascade
o sets the currently selected input (SELXINP) to X2
o requests the X1 primary to initialize
l If X2 times out, but X1 is good, the block:

o requests the X2 primary to initialize
o If X1 is good, then the MODE is CAScade and X1 is already the currently selected
input.
l If both inputs timeout, the block:

o sets CV to NaN, which forces a “Bad Control” condition. You specify what actions to
take on Bad Control through the BADCTLOPT parameter.
o sets the currently selected input (SELXINP) to None
o 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.
l This block only sets CASREQFL if the original mode was Cascade, the X1 input times out, and
TMOUTMODE = Backup Cascade.
l 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:
l If SELXINP is X2, and X1 is good, (i.e., X1 just changed from bad to good) , the block:
o sets SELXINP to X1
o changes MODE to Cascade
19.23.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).
- 674 -
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.23.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.23.14 Output bias-REMCAS block

the REMCAS block only applies OPBIAS.FLOAT to the output for the latter two conditions, when

ATTENTION
When the function block goes Active or the Mode changes to Cascade, OPBIAS and
necessary.
- 675 -
following 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.
If OPBIAS.FLOAT is not zero, you can configure it to ramp down to zero through the OPBIAS.RATE
parameter.
o Zero:
o Non-zero:
Where:
NaN:
19.23.15 Control Initialization-REMCAS block

This block brings initialization requests from its secondary through BACKCALCIN. In addition, the
You may use SECINITOPT to ignore initialization requests from the secondary.
- 676 -
l builds an initialization request for the X1 primary as follows:
INITREQ[1] = On
INITVAL[1] = CV - OPBIAS.FIX
l Parameters are defined below.

o 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.23.16 Override feedback processing-REMCAS block

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 Selector block). The offset flag only applies to PID-type function blocks.
You may use SECINITOPT to ignore override requests from the secondary.
l Computes a feedback value for the selected primary:
feedback value for selected primary = BACKCALOUT.ORFBVAL-OPBIAS.FIX - OPBIAS.FLOAT
l 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 TRACKING is On or Off.
19.23.17 Windup processing-REMCAS block

- 677 -

ARWOP computation

Equals . . .
ARWNET computation
- 678 -

ARWNET
Equals . . .
The CV is NaN

On)

= On)
19.23.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
- 679 -

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.19 REMCAS parameters

the REMCAS block.
19.24 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:
- 680 -
l 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.
l If TRACKING is Off, this block does not initialize the unselected inputs.
l OPHIALM.TM
l OPHIALM.TMO
l OPHIALM.DB
l OPHIALM.DBU
the BADCTLALM alarm
l BADCTLALM.TM
l BADCTLALM.TMO
Each SWITCH block supports the following user configurable attributes. The following table lists
- 681 -
Tab
reports.
l 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.
l 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.
l 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.
l When TRACKING is OFF, the block does not initialize the
unselected inputs.

ignore).
- 682 -
Tab
(unchecked).
NOSHED.
l Time (sec) (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
disabled.
l 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
- 683 -
Tab
SELXINP is updated.
l 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).
value is 106.9%.
is -6.9%
- 684 -
Tab
The types are:

Summary display.
- 685 -
Tab
CB.
For example, you can configure OPHIALM.DB as 5 and OPLOALM.DB as
3. However, if you are migrating from pre-R410 to later releases, refer to
Impact of migration on alarm attributes.
condition occurs.
percent.
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 block. However, if you are migrating from pre-R410 to later
SWITCH block.
setting manually.

- 686 -
Tab
l None
l ONESHOT
l SEMICONT
l CONTRTN
l CONT
block)..

Number).
- 687 -
Tab
information
l Function-SWITCH block
l Inputs-SWITCH block
l Input ranges and limits-SWITCH block
l Input descriptors-SWITCH block
l Initializable Outputs-SWITCH block
l Output ranges and limits-SWITCH block
l Mode handling-SWITCH block
l Timeout monitoring-SWITCH block
l Timeout processing-SWITCH block
l Equations-SWITCH block
l Bad input handling-SWITCH block
l Bypass processing-SWITCH block
l Input switching-SWITCH block
l Output bias-SWITCH block
l Error handling-SWITCH block
l Control initialization-SWITCH block
l Override feedback processing-SWITCH block
l Output Indication Function-SWITCH block
l Windup processing-SWITCH block
l Anti-Reset Windup Status-SWITCH block
l SWITCH parameters
19.24.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:
l Equation A. You store the number of the input to be selected to SELXINP.
l 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.
l 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.
- 688 -
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.
Figure 19.16 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.
Figure 19.17 Example CB configuration using multiple SWITCH blocks to assign a primary to a
different secondary.
- 689 -
19.24.2 Inputs-SWITCH block

The SWITCH block accepts up to eight inputs - X[1] through X[8].
l X[1] through X[8] are initializable inputs.
l The inputs must be pulled from other function blocks; you cannot store to them.
l 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.24.3 Input ranges and limits-SWITCH block
l You must specify an engineering unit range for the X inputs, by entering values for XEUHI and
XEULO.
l 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%.
l XEUHI and XEULO apply to all of the X inputs.
l This block assumes all of the X inputs are within XEUHI and XEULO; it applies no range checks.
19.24.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.24.5 Initializable Outputs-SWITCH block

- 690 -
For example, if you connect OP from a SWITCH block to SP on a PID block, Control Builder
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.24.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
OP will be clamped to these limits if the algorithm's calculated result (CV) exceeds them, or
19.24.7 Mode handling-SWITCH block

This block supports the Cascade and Manual modes:
l If MODE = Cascade, all inputs are pulled from other function blocks.
l If MODE = Manual, OP may stored by the operator or user program; inputs are ignored.
Regarding mode-changes:
l This block requests all primaries to initialize when mode changes from CAScade to MANual.
19.24.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
- 691 -
described in the next section.

19.24.9 Timeout processing-SWITCH block

If MODE is Cascade and an input times out, this block does the following :
l Requests the input's primary to initialize
ATTENTION
19.24.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:
l Equation A: You select an input by storing to SELXINP. (SELXINP identifies the input to be
selected.) When SELXINP is updated, equation A:
o 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.
o copies the selected input's descriptor to SELXDESC.
o 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]).
l 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:
o turns all other selection flags Off,
o updates SELXINP and SELXDESC, and
o calculates CV as noted above for Equation A.
Equation B prevents you from storing to SELXINP.
l 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:
- 692 -
o scans all flags in ascending order - from SELXFL[1] to SELXFL[8],

o 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.
o updates SELXINP and SELXDESC.
o 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
FL[1] FL[2] FL[3] FL[4] FL[5] FL[6] FL[7] FL[8] States Select Input…
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.24.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 = IncludeBad:
(i)
CV is set to NaN,
the selected input does not change (no automatic switching).
BADINPTOPT = IgnoreBad
(i)
An attempt is made to automatically switch to the next input. If a good input is
found, then the Swith selection changes to this input; if a good input is not found,
then CV is set to NaN and the selected input does not change.
Based on the configured equation, the SWITCH block automatically switches to the next input as
follows:
l 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
- 693 -
Switch, then the next input for X[5] is X[1].

l 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.24.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:
l IgnoreBad (Ignore bad inputs)
l IncludeBad (Include bad inputs)
For this block, a bad input will cause CV to go bad. This means Bad Control.
19.24.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.24.14 Output bias-SWITCH block

the SWITCH block only applies OPBIAS.FLOAT to the output for the latter two conditions, when
- 694 -

ATTENTION
When the function block goes Active or the Mode changes to Cascade, OPBIAS and
necessary.
following occurs:

OPBIAS.FLOATCVINIT - (CVUNBIASED + OPBIAS.FIX)
Where:
be zero.
o Zero:
o Non-zero:
o The function block ramps the OPBIAS.FLOAT to zero by applying the following
- 695 -
OPBIAS.FLOATOPBIAS.FLOAT - (OPBIAS.RATE / cycles_per_Min)

Where:
NaN:
19.24.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.24.16 Control initialization-SWITCH block

This block brings initialization requests from its secondary through BACKCALC. In addition, the
You may use SECINITOPT to ignore initialization requests from the secondary.
CV=initialization value from the secondary
l 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
l 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.24.17 Override feedback processing-SWITCH block

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.
You may use SECINITOPT to ignore override requests from the secondary.
- 696 -
l Computes a feedback value for the selected primary:

feedback value for selected primary = BACKCALCOUT.ORFBVAL - OPBIAS.FIX - OPBIAS.FLOAT
l 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
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.
19.24.18 Output Indication Function-SWITCH block

display.

Enumeration
Selection Is . . .
values remain the
same.)



ATTENTION
- 697 -


ATTENTION
- 698 -
REVERSE.
19.24.19 Windup processing-SWITCH block


ARWOP computation
- 699 -

Equals . . .
ARWNET computation

ARWNET
Equals . .
.
The CV is NaN
The ARWOP equals Hi (Pid function blocks have a configurable Control Action Hi
option (CTLACTN). If CTLACTN = Reverse , ARWNET will track ARWOP; but if
CTLACTN = Direct , ARWNET will be the opposite of ARWOP.)
On)
The ARWOP equals Lo (Pid function blocks have a configurable Control Action LO
option (CTLACTN). If CTLACTN = Reverse , ARWNET will track ARWOP; but if
CTLACTN = Direct , ARWNET will be the opposite of ARWOP.)
On)
- 700 -
19.24.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.24.21 SWITCH parameters

the SWITCH block.
- 701 -
CHAPTER
20 UCN INTERFACE
l Universal Control Network (UCN) Interface Block Library

l UCNOUT/EUCNOUT block
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.
- 702 -
Chapter 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.
- 703 -
Translates secondary data The data structures for SECDATA and BACKCALC pass
(SECDATA) from Process information back up the control path from secondaries to
Manager regulatory control primaries. They contain data like initialization request,
points to ACE/C300 initialization value, and anti-reset windup status.
controller compatible back
calculation (BACKCALC) Since SECDATA does not provide override feedback propagation
data. 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 If Process Manager/EHPM regulatory control point is configured

Cascade Request protocol for Remote Cascade and the MODE is changed to Cascade, the
for a Process MODE does not change immediately. The UCNOUT/EUCNOUT
Manager/EHPM regulatory block receives the Remote Cascade request and then stores
control point MODE Cascade to the MODE for the Process Manager point to complete
changes. the formation of the cascade strategy.
Forwards inputs from The Process Manager/EHPM point uses the Engineering Units
primary regulatory control obtained from the SECDATA fetch to convert stores to its
blocks in ACE/C300 regulatory control point setpoint to Engineering Units. The
supervisory controller to a BACKCALC structure supports the same Engineering Units
Process Manager/EHPM information function for ACE/C300 regulatory control blocks.
regulatory control point.
l About remote cascade - UCNOUT/EUCNOUT block

l Configuration form overview
l Input/Output - UCNOUT/EUCNOUT block
l Configuration example - UCNOUT/EUCNOUT block
l UCNOUT/EUCNOUT parameters
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.
- 704 -
Table 20.1 UCNOUT block

Remote Description
Cascade
Type
SPC - Used for Supervisory to Level 1 controller cascade - UCNOUT block writes to the
Setpoint setpoint (SP) of the Process Manager regulatory control point, when the point is in
Control Cascade (CAS) mode.
DDC - Used for Supervisory store to Output directly - UCNOUT block writes to the output
Direct (OP) of the Process Manager regulatory control point, when the point is in
Digital Cascade (CAS) mode.
Control
RSP - Used for Supervisory to Level 1 controller cascade with a backup primary also
Remote existing in Level 1 - UCNOUT block writes to the setpoint (SP) of the local backup
Setpoint Process Manager regulatory control point, when the point is in Automatic Mode
Control and being initialized by its secondary, which is in either SPC or DDC control by ACE
supervisory controller.
DDCRSP - Used for Supervisory store to Output directly - UCNOUT block writes to output (OP)
Direct of the Process Manager regulatory control point, when the point is in Cascade
Digital (CAS) mode. UCNOUT block also writes to the setpoint (SP) of the same Process
Control Manager regulatory control point to supply a backup SP.
with
Remote
Setpoint
Table 20.2 EUCNOUT block

Remote Description
Cascade
Type
SPC - Used for Supervisory to Level 1 controller cascade - The ACE/C300 control strategy
Setpoint writes to the setpoint (SP) of the EHPM regulatory control point, when the point is
Control in Cascade (CAS) mode. This option is configured by setting RCASOPT to SPC.
DDC - Used for Supervisory store to Output directly - The ACE/C300 control strategy
Direct writes to the output (OP) of the EHPM regulatory control point and the OP of the
Digital EHPM analog output, when the point is in CAS mode. The output limits are not
Control 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 - Used for Supervisory to Level 1 controller cascade with a backup primary also
Remote existing in Level 1 - The ACE/C300 control strategy writes to the SP through an
Setpoint ACE/C300 output connection, subject to the SP limits, when the point is in
Control 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 - Used for Supervisory store to Output directly - The ACE/C300 control strategy
Direct writes to the OP of the EHPM regulatory control point, when the point is in CAS
Digital mode. The ACE/C300 also writes to the SP of the same EHPM regulatory control
Control point subject to the SP limits.
with
Remote PV tracking is not performed in CAS mode. This option is used primarily when a
- 705 -
Remote Description
Cascade
Type
Setpoint 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.
Tab
hierarchy.
l 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
for more information.
l 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
Configuration Used for selecting the available parameters that you want to appear on the
Parameters face of the function block in the Project tab in Control Builder.
Monitoring Used for selecting the available parameters that you want to appear on the
Parameters face of the function block in the Monitoring tab in Control Builder.
Block Used for selecting several block-viewing preferences including the color of the
- 706 -
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 Then, Connect SP Or, Connect RSP Or, Connect OP

Type Is . . . Input (SPPIN) . . . Input (RSPPIN) . . . Input (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
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 And/or, Connect

SPOUT . . . OPOUT . . .
SPC - Setpoint Control Yes No
DDC - Direct Digital Control No Yes
RSP - Remote Setpoint Control Yes No
DDCRSP - Direct Digital Control with Yes Yes

Remote 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.
- 707 -
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
- 708 -
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:
l CASSTS = CASOK: Shows that remote cascade match is found between ACE/C300 and
UCN/EUCN regulatory control point.
l CASSTS = CASMISMATCH: Shows that remote cascade mismatch was found between
ACE/C300 and UCN/EUCN regulatory point.
l CASSTS = SECDATANOTREAD: Shows that secondary data from UCN/EUCN regulatory control
point is not being fetched.
20.2.5 UCNOUT/EUCNOUT parameters

the UCNOUT/EUCNOUT block and the Control Builder Parameter Reference for definitions of each
parameter.
- 709 -
CHAPTER
21 HIWAY INTERFACE
l Hiway Interface (HIWAYIF) Block Library

l HIWAYOUT Block
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.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.
- 710 -
Chapter 21 - Hiway Interface
Stores to Translates secondary data (SECDATA) from Data Hiway regulatory control points
regulatory to ACE controller compatible back calculation (BACKCALC) data.
points.
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.
Stores to Participates in Remote Cascade Request protocol for Data Hiway regulatory
Analog control point MODE changes.
Output and
Composite If a user or a program attempts to change the MODE of a Data Hiway point to
Points. 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.
l About remote cascade-HIWAYOUT Block

l Configuration form overview-HIWAYOUT Block
l Input/Output-HIWAYOUT Block
l Configuration example-HIWAYOUT Block
l Load and Execution-HIWAYOUT Block
l HIWAYOUT parameters
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.
Remote Description
Cascade
Type
SPC - Used for Supervisory to Level 1 controller cascade - HIWAYOUT block writes to the
Setpoint setpoint (SP) of the Data Hiway regulatory control point, when the point is in
Control Cascade (CAS) mode.
DDC - Used for Supervisory store to Output directly - HIWAYOUT block writes to the output
Direct (OP) of the Data Hiway regulatory control, Analog Output (AO), or Analog Composite
Digital (AC) point, when the point is in Cascade (CAS) mode.
Control
- 711 -
21.2.2 Configuration form overview-HIWAYOUT Block

The following table identifies the tabs and parameters associated with each one for quick
reference.
Tab
hierarchy.
l Remote Cascade Type (REMCASTYPE) - Lets you select the type of remote
cascade function the HIWAYOUT block is to support. See the previous
section
l About remote cascade - UCNOUT/EUCNOUT block for more information.
l 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.
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.
- 712 -
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 Then, Connect Or, Connect Then, Connect Or, Connect OP

Cascade SP Input OP Input SP Output Output
Type Is . . . (SPPIN) . . . (OPIN). . . (SPOUT). . . (OPOUT). . .
SPC - Setpoint Yes No Yes No
Control
DDC - Direct No Yes No Yes

Digital Control
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.
Figure 21.1 Example of HIWAYOUT block used to do setpoint control of a regulatory Control Builder
point
- 713 -
Table 21.1 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:
- 714 -
l CASSTS = CASOK: Shows that remote cascade match is found between ACE and HIWAY
regulatory control point.
l CASSTS = CASMISMATCH: Shows that remote cascade mismatch was found between ACE and
HIWAY regulatory point.
l CASSTS = SECDATANOTREAD: Shows that secondary data from HIWAY regulatory control point
is not being fetched.
21.2.6 HIWAYOUT parameters

the HIWAYOUT block.
- 715 -
CHAPTER
22 EXCHANGE FUNCTIONS
l Exchange Function Blocks

l REQFLAGARRAY Block
l REQNUMARRAY Block
l REQTEXTARRAY Block
l RSPFLAGARRAY Block
l RSPNUMARRAY Block
l RSPTEXTARRAY Block
22.1 Exchange Function Blocks

Exchange function blocks provide a variety of configurable functions for storing and retrieving
selected control data.
configuration of the associated Exchange function blocks. Functional descriptions for each block
are given in the following subsections.

Initiate REQFLAGARRAY Used to define up to 512 two separate states (Off/On) to
read/write of Block indicate status of a particular input. CPM initiates
multiple two- read/write transactions to other connected devices using
state values either the PCCC or CIP communications protocol.
Initiate REQNUMARRAY Used to store up to 64 floating point values for use in a

read/write of Block control strategy. CPM initiates read/write transactions to
multiple other connected devices using either the PCCC or CIP
floating point communications protocol.
values
Initiate REQTEXTARRAY Used to store up to 64 ASCII characters for use in a control

read/write of Block strategy. CPM initiates read/write transactions to other
multiple text connected devices using either the PCCC or CIP
strings communications protocol.
Respond to RSPFLAGARRAY Used to define up to 512 two separate states (Off/On) to

read/write of Block indicate status of a particular input. CPM responds to
multiple two- read/write transactions from other connected devices
state values using either the PCCC or CIP communications protocol.
- 716 -
Chapter 22 - Exchange Functions

Respond to RSPNUMARRAY Used to define up to 64 floating point values for use in a
read/write of Block control strategy. CPM responds to read/write transactions
multiple from other connected devices using either the PCCC or CIP
floating point communications protocol.
values
Respond to RSPTEXTARRAY Used to define up to 64 ASCII characters for use in a

read/write of Block control strategy. CPM responds to read/write transactions
multiple text from other connected devices using either the PCCC or CIP
strings 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:
- 717 -
Tab
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
l 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.)
l Number of Flag Values (NFLAG) - Lets you set the amount of Flags you
want to control (1 .. 512).
Communications l 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.
l 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)
l 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,
l 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
- 718 -
Tab
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,
l 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,
l 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,
l 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
l 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.
- 719 -
Tab
l 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.
l 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.
l 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).
l 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.
l 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.
l 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.
l 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.
l Function-REQFLAGARRAY Block
l Input/Output-REQFLAGARRAY Block
l REQFLAGARRAY parameters
- 720 -
22.2.1 Function-REQFLAGARRAY Block

Used to define two separate states (Off/On) to indicate status of a particular input.
l Number of flag values (NFLAG) is user configurable.
l 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

the 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:
- 721 -
Tab
CIPWRITE.
l Number of Numeric Values (NNUMERIC) - Lets you set the amount of
floating point integers you want to control (1 .. 64).
l 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.
chassis)

l 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.
- 722 -
Tab
For example,
l 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.

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

l 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) scenario: When the X path is 1, the Y path denotes a slot
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,
l 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.
- 723 -
Tab
controller tags.
selected (CHECKED).
Channel A.
0.
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.
l Function-REQNUMARRAY Block
- 724 -
l Input/Output-REQNUMARRAY Block
l REQNUMARRAY parameters
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.
l 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

the 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:
- 725 -
Tab
CIPWRITE.
l Number of String Values (NSTRING) - Lets you set the amount of ASCII
strings needed (1..8).
l 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.)
Note: You cannot use the REQTEXTARRAY block to transfer text data
with a CL5550 PLC.
chassis)

2, 10.0.0.6 is a valid path segment from an originator C300 to a target
- 726 -
Tab
C300 having the IP address 10.0.0.6.
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.
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.
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) scenario: When the X path is 1, the Y path denotes a slot
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.
- 727 -
Tab
controller tags.
selected (CHECKED).
Channel A.
0.
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.
l Function-REQTEXTARRAY Block
l Input/Output-REQTEXTARRAY Block
- 728 -
l REQTEXTARRAY parameters
22.4.1 Function-REQTEXTARRAY Block

The REQTEXTARRAY block outputs (STR[n]) can be used to provide predefined text strings to other
function blocks.
l A configurable Number of String Values (NSTRING) which lets you specify the desired number
of string values (up to 64) to be supported.
l 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

the 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:
- 729 -
Tab
l 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.
l 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).
l Number of Flag Values (NFLAG) - Lets you set the amount of Flags you
want to control (1 .. 512). The default value is 1.
l 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.
l Function-RSPFLAGARRAY Block
l Input/Output-RSPFLAGARRAY Block
l RSPFLAGARRAY parameters
22.5.1 Function-RSPFLAGARRAY Block

l 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.
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
- 730 -
22.5.3 RSPFLAGARRAY parameters

the RSPFLAGARRAY function block.
22.6 RSPNUMARRAY Block

The RSPNUMARRAY 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:
Tab
l 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.
l 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.
l Process Value, from device (PV) - Contains the data values to be read
from or written to by the remote device.
l Function-RSPNUMARRAY Block
l Input/Output-RSPNUMARRAY Block
l RSPNUMARRAY parameters
- 731 -
22.6.1 Function-RSPNUMARRAY Block

The RSPNUMARRAY 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).
l A configurable Number of Numeric Values (NNUMERIC) lets you specify the desired number of
numeric values to be supported.
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

the RSPNUMARRAY function block.
22.7 RSPTEXTARRAY Block

The RSPTEXTARRAY 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:
- 732 -
Tab
l Number of String Values (NSTRING) - Lets you set the amount of ASCII
strings needed (1..8).
l 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.)
l Process Value, from device (STR) - Contains the array of strings to be
read from or written to by the remote device.
l Function-RSPTEXTARRAY Block
l Input/Output-RSPTEXTARRAY Block
l RSPTEXTARRAY parameters
22.7.1 Function-RSPTEXTARRAY Block

The RSPTEXTARRAY block outputs (STR[n]) can be used to provide predefined text strings to other
function blocks.
The RSPTEXTARRAY block supports a maximum size of 64 two-byte characters. The following table
- 733 -

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
22.7.3 RSPTEXTARRAY parameters

the RSPTEXTARRAY function block.
- 734 -
CHAPTER
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.
configuration of the 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 Compute a PV value Lets you create custom algorithms by writing up to
(Auxiliary eight expressions. Each expression can contain any
Calculation) valid combination of inputs, operators and functions;
Block and may perform arithmetic or logic operations, test
conditions, etc. Optionally, it can accept up six inputs.
AUXSUMMER Calculate a PV value Lets you configure up to ten inputs to provide an

(Auxiliary from up to ten inputs overall result that can be scaled and biased.
Summer) Block
CTUD Counts the inputs Lets you configure the algorithm to start functioning
(COUNTER values according to the status of the count on level flag
UP/DOWN) (CNTLVLFL).
Block
DEADTIME Delay processing of Lets you specify a fixed or a variable “dead-time”

Block input value changes before a change in input value is calculated as a
corresponding change in PV.
ENHAUXCALC Provide l Expands existing arrayed input parameters

(Enhanced enhancements to PSTS and P from six to ten.
Auxiliary AUXCALC block
Calculation) functions l These arrayed parameters are added to
Block correspond to each of the ten inputs.
l Input Description
l Scaling Factor
l Enable/Disable Switch
l PSUB Substitute Parameter
l PP Scaled Input
ENHGENLIN Generate a Computes an output value in PV as a function of

(Enhanced linearization output values in inputs P1 and ACTLINSEG based on
General for an input with non- configuration in linearization segment table. Typically
Linearization) linear characteristics used to provide a linearized PV (in engineering units)
- 735 -
Chapter 23 - Auxiliary Function Blocks

Block and value of the for a sensor actuator, or process with nonlinear
ACTLINSEG characteristics.
parameter.
FLOWCOMP Operates on Computes a flow compensation factor based on

(Flow uncompensated flow variations in parameters like temperature, pressure,
Compensation) measurements of specific gravity, and molecular weight. The block
Block liquids, steam, gases derives a compensated flow value as its output.
or vapors.
FANOUT Block Generate a linearized Computes an output value that is a user-defined

output for an input function of the input. You may define 2 to 13
with non-linear coordinates, which, together, approximate a
characteristics. 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 Provides lead and lag compensation to a change in
compensation input value calculation for corresponding change in
PV.
ROC (Rate of Limits the rate of Provides computational block intended for use on the
Change) Block input and provides input side of function blocks for limiting the input
the output variable variable to the block (typically SP).
based on the rate trip
limits
SIGNALSEL Select one of up to six The Signal Selector function block accepts as many
(Signal input signals or as six input signals, and may be configured to do one
Selector) Block calculate the average of the following on these inputs:
of a set of 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 Periodically adds an input value to an accumulator

Block flows value, sets status flags to indicate when accumulator
TOTALIZER value is near user-specified target values (“near”,
Block “nearer”, “actual target value”). Typically used to
accumulate total flows. Block also supports warm
restarts.
l Common auxiliary block functions

l AUXCALC (Auxiliary Calculation) Block
l AUXSUMMER (Auxiliary Summer) Block
l CTUD (COUNTER UP/DOWN) Block
l DEADTIME Block
l ENHAUXCALC (Enhanced Auxiliary Calculation) Block
l ENHGENLIN (Enhanced General Linearization) Block
l FLOWCOMP (Flow Compensation) Block
l GENLIN (General Linearization) Block
- 736 -
l LEADLAG Block
l ROC (Rate of Change) Block
l SIGNALSEL (Signal Selector) Block
l TOTALIZER Block
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.
Major Description
Function
Input Auxiliary blocks get input data from other function blocks. Input processing gets
Processing this data, checks that its valid, and updates the appropriate block parameters.
Algorithm This involves calculations that are unique to each block. The result or output is
Calculation stored in PV. Depending of the particular Auxiliary block, additional functions may
be included.
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.
l Function-AUXCALC block
l Configuration example-AUXCALC block
l Input-AUXCALC block
l Output-AUXCALC block
l Expressions-AUXCALC block
l Parameters in Expressions-AUXCALC block
l Guidelines for Writing Expressions-AUXCALC block
l Assignable Outputs-AUXCALC block
l AUXCALC parameters
- 737 -
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 23.1 AUXCALC block major functions
- 738 -
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.
l exprn# 1 is: SQRT(PIDLOOP1.AUXCALC2.P[1])
Table 23.2 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]):
l All inputs are optional.
l Must fetch all inputs from other function blocks.
l 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:
- 739 -
l PV and its status, PVSTS

l As many as eight expression results (C[1] through C[8]) and their statuses
23.2.5 Expressions-AUXCALC block

inputs, operators, 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
an expression.
something that the external reference component will understand. If this text is incorrect runtime
errors will occur.
ATTENTION
23.2.7 Guidelines for Writing Expressions-AUXCALC block
l 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.
- 740 -

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
numeric types.
TIP
parameters.
ATTENTION
Example:
expressions.
Example:
The results of the expressions, which use the CONST [1…8] parameters, are affected if you
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.
l With R410, whenWhen you write the expressions using the TPS point's parameter references,
23.2.8 Assignable Outputs-AUXCALC block

Produces these outputs according to the values you assign to them.
l PV and its status PVSTS
l Up to eight expression results (C[1] to C[8]) and their statuses
- 741 -
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

the 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.
l Function-AUXSUMMER block
l Configuration parameters-AUXSUMMER block
l Configuration example-AUXSUMMER block
l Input-AUXSUMMER block
l Output-AUXSUMMER block
l Error handling-AUXSUMMER block
l Restart or point activation-AUXSUMMER block
l AUXSUMMER parameters
23.3.1 Function-AUXSUMMER block

The AUXSUMMER block uses the following equation to calculate the PV value based on up to ten
- 742 -
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.
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 Description

Name
PV Display PVFORMAT Lets you define the decimal format to be used to display the PV
Format value. The choices are D0 (None), D1 (One), D2 (Two), or D3
(Three). The default value is D1.
Overall Scaling CPV Lets you define the scaling factor to be applied to the PV value to
Factor for PV 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 DPV Lets you define the bias factor to be applied to the PV value to
PV meet your process requirements. This parameter can be
changed at any time and can be changed by another block in
value is 0.
Input PDESC Lets you define a specific description for each input. This
Description [1..10] parameter can only be changed in the Project mode in Control
Builder before the block is loaded or re-loaded.
Enable/Disable PENABLE Lets you enable or disable a given input for the block. This
Switch [1..10] 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 C[1..10] Lets you define a scaling factor for the given input to meet your
for Inputs 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.
- 743 -

Name
Input PSUB Lets you define a substitute value to be used for the
Substitute [1..10] corresponding disabled input (P[1..10]). This parameter can be
Value changed at any time and can be changed by another block in
value is NaN (Not a Number).
Bias Values for D[1..10] Lets you define the bias value to be applied to the corresponding
Inputs 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 NUMPINPT This is a read-only parameter that shows the number of inputs
Process Input connected to the block. This parameter does not appear on the
Connections Main tab. It can be configured as monitoring parameter on the
face of the block.
- 744 -
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 23.3 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]).
l At least one input (P[i]) must be configured for the block to operate.
l All inputs must be fetched from other function blocks
l 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

- 745 -
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

the AUXSUMMER block.
- 746 -
23.4 CTUD (COUNTER UP/DOWN) Block

Prior to R400, digital counter function was typically implemented as follows:
l By using a Totalizer or an Auxiliary function block with external additional logic, or
l 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.
l C300 Controller
l C200E Controller
l ACE Controller
l ACE-T Controller
l SIM-C300
l SIM-C200E
l SIM-ACE
CTUD block is graphically represented in the following figure.
l Function-CTUD block
l Inputs-CTUD block
l Outputs-CTUD block
l Edge or Level trigger mechanism-CTUD block
l Supported algorithms-CTUD block
l Counter overflow and underflow conditions-CTUD block
l Effects of restart or point activation on CTUD
l Effects of Import or Export on CTUD
l Effects of Checkpoint operations CTUD
l Parameter error handling-CTUD block
l CTUD parameters
- 747 -
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.
23.4.2 Inputs-CTUD block

CTUD block accepts the following input format.
l Integer 32
l Float 64
l Boolean
l 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.
l If SELINT32FL is set to “FALSE”, the float input (INFLOAT64) is used.
l 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.
l Boolean value
o If the input is 0, it is stored as 0.
o 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.
l Integer value
Full ranges of signed integer values (- 2,147,483,648 to + 2,147,483,647) are accepted.
l Floating point value
- 748 -
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.
l 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 INCLAMPOPT FLOAT64 Value for Value for limit

tried to store status value Counter load checking
(INFLOAT64) operation
+Infinity TRUE 2,147,483,647.0 2,147,483,647 2,147,483,647
+Infinity FALSE NaN Retain previous The limit

internal counter comparison is
value and never always FALSE
load the counter. (NaN).
Greater than TRUE 2,147,483,647.0 2,147,483,647 2,147,483,647

2,147,483,647.0
Greater than FALSE NaN Retain previous The limit

2,147,483,647.0 internal counter comparison is
Between - TRUE/FALSE Float value is Float value is Float value is

2,147,483,648.0 truncated to truncated to truncated to
and integer integer integer
+2,147,483,647.0 equivalent. equivalent, then equivalent, then
cast to INT32 cast to INT32
Less than - TRUE - -2,147,483,648 -2,147,483,648

2,147,483,648.0 2,147,483,648.0
Less than - FALSE NaN Retain previous The limit

2,147,483,648.0 internal counter comparison is
-Infinity TRUE - -2,147,483,648 -2,147,483,648

2,147,483,648.0
-Infinity FALSE NaN Load inhibited. NaN
NaN TRUE/FALSE NaN Retain previous The limit

internal counter comparison is
Pause, Load, and Reset parameters
- 749 -
l Pause (PAUSEFL) - When this parameter is set to “TRUE”, the CTUD stops counting.
l 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.
l 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.
Figure 23.1 Example CNTUPFL parameter configuration using edge-triggered
The following diagram displays how the transition occurs in case of edge-trigger.
Figure 23.2 Example diagram for edge-triggered
- 750 -
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.
Figure 23.3 Example CNTUPFL parameter configuration using level-triggered
- 751 -
The following diagram displays how the transition occurs in case of level trigger.
Figure 23.4 Example diagram for level-triggered
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.
- 752 -
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 Underflow conditions and

and results results
A, B, E, F 2,147,483,647 l Condition: If the l Condition: If the counter
to counter value is value is lesser than -
+2,147,483,647 greater than 2,147,483,647.
+2,147,483,647.
l Result: The Counter
l Result: The Counter value is set to the
value is set to the - +2,147,483,647 and the
2,147,483,647 and counter operation
the counter operation continues.
continues.
C 0 to l Condition: If the l Condition: If the counter

+2,147,483,647 counter value is value is lesser than zero.
greater than the value
l Result: The counter
+2,147,483,647.
value is set to
l Result: The counter +2,147,483,647 and
value is set to zero and continues the operation.
continues the
operation.
D 0 to IN l Condition: If the l Condition: If the counter

Note: This counter value is value is lesser than zero.
equation greater than the IN
requires IN >0 parameter values
value is set to the IN
for counting (ININT32/INFLOAT6
parameter values
correctly 4).
(ININT32/INFLOAT64)
l Result: The Counter and continues the
value is set to zero and operation.
continues the
operation.
G -2,147,483,648 l Condition: If the l Condition: If the counter

to 0 counter value is value is lesser than -
greater than zero. 2,147,483,647,
l Result: The Counter l Result: The Counter
value is set to - value is set to zero and
2,147,483,647 and continues the operation.
continues the
operation.
H IN to 0. l Condition: If the l Condition: If the counter

Note: This counter value is value is lesser than the
equation greater than the IN IN parameter
requires IN < 0 value (ININT32/INFLOAT64)
for counting (ININT32/INFLOAT6 value.
correctly. 4).
l Result: The counter value is set to zero
value is set to the IN continues the operation.
value
- 753 -
Algorithm Range Overflow conditions Underflow conditions and

and results results
(ININT32/INFLOAT64)
continues the
operation.
ATTENTION
The CTUD excludes a gap between zero and IN (INT32/FLOAT64) value for the following
scenarios.
l The IN value is greater than zero when using Equation D.
l 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
- 754 -
Algorithm QUFL (TRUE) QDFL(TRUE)

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.
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.
- 755 -
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
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
l The CTUD evaluates parameter stores on two levels,

o User entries from Property dialogs boxes are assessed against entry limits and
immediately reported.
o 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.
l 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.
l Warnings are displayed while storing out-of-range or NaN floating point values.
l You can see errors while entering configuration values or dialog entry failures due to access
- 756 -
lock. (For example, while trying to store a parameter with insufficient access level.)
l 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

the CTUD block.
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 name of the “Tab”in the parameter configuration form and then briefly describes the
- 757 -
Tab
l Overall Scale Factor (CPV) - Lets you specify the overall-scaling factor for
the PV output. The default value is 1.
l Factor for P1 (C1) - Lets you specify the scaling factor for the P1 input.
l 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.
l Overall Bias (DPV) - Lets you specify an overall bias for the PV output. The
default value is zero (0).
l Bias for P1 (D1) - Lets you specify a bias for the P1 input. The default
value is zero (0).
l 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).
l Delay Type (DELAYTYP) - Lets you select the delay type as either Fixed or
Variable. The default selection is Fixed.
l 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).
l 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
l 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.
l Function-DEADTIME block
l Input-DEADTIME block
l Output-DEADTIME block
l PV status-DEADTIME block
l Error handling-DEADTIME block
- 758 -
l Delay type-DEADTIME block

l Delay table-DEADTIME block
l Restart condition-DEADTIME block
l DEADTIME parameters
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.
23.5.2 Input-DEADTIME block

The block requires one or two inputs depending on the type of delay action selected.
l If delay type is Fixed or Variable, P1 must be brought from another block.

l 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:
l Bad - which means that PV is NaN (Not a Number)
l Normal - which means PV is OK.
l Manual - which means P1 source (for example, DATAACQ block) is in manual PV source.
l 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:
l PVSTSFL.BAD - if PVSTS = Bad, this flag is on; otherwise it is off.
l PVSTSFL.NORM - if PVSTS = Normal, this flag is on; otherwise it is off.
l PVSTSFL.MAN - if PVSTS = Manual, this flag is ON; otherwise it is off.
l 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.
- 759 -
23.5.6 Delay type-DEADTIME block

The DEADTIME block gives you choice of either a Fixed or Variable delay type.
l 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)
l 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.
- 760 -
l The sample rate of the P1 input value. This is the execution rate of the block.
l The delay time (DELAYTIME). For Fixed delay, delay time is user configured. For Variable delay,
the delay time is derived from the P2 input.
l 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.
l P2<=1 / (Period * NUMLOC)
l 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
l 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.
l 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.
l 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.
l 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

the DEADTIME block.
23.6 ENHAUXCALC (Enhanced Auxiliary Calculation) Block

The ENHAUXCALC block provides the following enhancements over the AUXCALC block.
- 761 -
l Expands existing arrayed input parameters PSTS and P from six to ten.
l These arrayed parameters are added to correspond to each of the ten inputs.
o Input Description
o Scaling Factor
o Enable/Disable Switch
o PSUB Substitute Parameter
o PP Scaled Input
l 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.
l Function-ENHAUXCALC block
l Configuration parameters-ENHAUXCALC block
l Input-ENHAUXCALC block
l Output-ENHAUXCALC block
l Expressions-ENHAUXCALC block
l Parameters in Expressions-ENHAUXCALC block
l Guidelines for Writing Expressions-ENHAUXCALC block
l Enable/Disable switch example expression-ENHAUXCALC block
l Scaled Input example expression-ENHAUXCALC block
l Assignable Outputs-ENHAUXCALC block
l ENHAUXCALC parameters
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.
- 762 -
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.
l If PENABLE = 0 (Disable), then:
PP[i] = PSUB[i] * CP[i]
l 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.
l If PENABLE = 1 (Enable), then:
P[I] = The original input
PP[i] = P[I] * CP[I]
l 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.
- 763 -
Figure 23.5 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

Name
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 PDESC Lets you type your own description for each input.
Description [1..10]
Enable PENABLE Lets you Enable or Disable a corresponding input.

[1..10]
Scaling CP[1..10] Lets you define a scaling factor for a corresponding input. The
Factor default value is 1.
Input PSUB[1..10] Lets you define a substitute value for corresponding input/scaled
Substitute input when the input is disabled. The default is NaN.
Value
Scaled PP[1..10] Lets you use a scaled input value in your expressions. This is a
Input read-only parameter with a NaN value in the Project tab.
- 764 -
23.6.3 Input-ENHAUXCALC block

This function block accepts as many as ten inputs (P[1..10]):
l All inputs are optional.
l Must fetch all inputs from other function blocks.
l The number of process input connections are equal to the number of inputs; the default is 1.
23.6.4 Output-ENHAUXCALC block

l As many as eight expression results (C[1] through C[8]) and their statuses
23.6.5 Expressions-ENHAUXCALC block

inputs, operators, 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
an expression. Also, the size of each expression in the ENHAUXCALC block is limited to 1024
characters. If the size of the expression exceeds 1024 characters, the following message appears.
You can use the following additional arrayed parameters in expressions.

l CP[1..10] PP[1..10] PENABLE[1..10]
l 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.
l For example: MIN(CM.ENHAUXCALCA.P[1],value2,value3)
- 765 -
l TagName.'text'
something that the external reference component 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
ATTENTION
removed: TagName.'text' becomes TagName.text.
23.6.7 Guidelines for Writing Expressions-ENHAUXCALC block
l 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.
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
numeric types.
TIP
parameters.
- 766 -
ATTENTION
Example: CM1.CALC1.CONST[1] * CM1.CALC1.X[2] + CM2.REGCALCA.CV
expressions.
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
ATTENTION
retains its values.
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).
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]
- 767 -
MIN(PP[10],P[2],C[1])
(PP[7] <> 12)? 10 : PP[7]
SQRT(PP[5])
23.6.10 Assignable Outputs-ENHAUXCALC block

Produces these outputs according to the values you assign to them.
l PV and its status PVSTS
l 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

the ENHAUXCALC block.
- 768 -
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.
l C300 (20 ms CEE and 50 ms CEE)
l C200E
l ACE
l SIM C200E
l 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].
- 769 -
When it finds a segment that intersects with the input, the block displays the respective output
value (PV) as follows:
l 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]
l If P1 is less than IN value in the first linearization point (IN[i][0]), the first segment is
extrapolated:
l If P1 is greater than the IN value in the last linearization point (IN[i][n]), the last segment is
extrapolated:
l 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.
l Function-ENHGENLIN block
l Configuration Parameters-ENHGENLIN block
l Configuration Example-ENHGENLIN block
l Input-ENHGENLIN block
l Output-ENHGENLIN block
l Error Handling-ENHGENLIN block
l Strategy Optimization using ENHGENLIN block
l ENHGENLIN block - Usage Scenario
l ENHGENLIN parameters
- 770 -
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.

Name
Number of NUMLINSEG Let you select the maximum number of allowed linearization
Tables segment tables. Maximum four linearization segment tables
are supported.
Active ACTLINSEG Lets you assign the linearization segment table based on the
Linearization number of segment tables for PV calculation.
Segment Table
Number of NUMSEGS Lets you select the number of segments for the linearization
Segments [INDEX1] 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.
- 771 -

Name
Input Co IN [INDEX1] Lets you to type the input values for the linearization segment
ordinate [INDEX2] table.
Output Co OUT Lets you to type the output values for the linearization
ordinate [INDEX1] segment table.
[INDEX2]
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.
23.7.4 Input-ENHGENLIN block

Two input values are required:
l P1 must be fetched from another function block.
l ACTLINSEG parameter value must be given by the user or it can be fetched from the
TYPECONVERT block.
- 772 -
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
l PV.
l 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
l The ENHGENLIN block modifies the PVSTSFL.BAD status to ON if the following conditions are
satisfied:
l P1input status (P1STS) is Bad.

l 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.
l The Control Module containing the ENHGENLIN block cannot change the EXECSTATE status
to ACTIVE, if the following conditions are satisfied:
l Any of the segment co-ordinates (IN [ ] [ ] or OUT [ ] [ ]) contains NaN in the NUMSEGS range of
the two coordinate arrays.
l The IN [ ][ ] parameter values are not in ascending order. The values must be monotonically
strictly increasing.
l The OUT [][] parameters values are not in ascending order.
- 773 -
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.
There are two different modes of Governor Valve (GV) operations performed by the ENHGENLIN
block.
l Full Arc mode of governing (Uniform Operations)
l 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.
- 774 -
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
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.
- 775 -
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.
sequence.
sequence.
The sequences and the related operation of the Governor Valves operation with respect to the load
are explained in the following table.
- 776 -
Sequenc Description
e
Number
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:
l Governor Valves 3, 5, and 6 are fully opened
l GV4 is opened 25 % (approx)
l GV1 is opened 8% (approx.)
l GV2 is opened 0%
l GV4 is opened 0%
- 777 -
Sequenc Description
e
Number
l GV1 is opened 0%
The co-ordinates for the Governor Valves for each sequence are explained in the following table.
For Governor Valves 1:
- 778 -
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
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:
- 779 -

SEQ1 SEQ2 SEQ3
X - COR Y - COR X - COR Y - COR X - COR Y - COR
-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
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
- 780 -
23.7.9 ENHGENLIN parameters

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.
l Function-FLOWCOMP block
l Configuration parameters-FLOWCOMP block
l Input-FLOWCOMP block
- 781 -
l Output-FLOWCOMP block
l Equations-FLOWCOMP block
l Additional considerations for FLOWCOMP Equation A
l Error handling-FLOWCOMP block
l Alarm behavior-FLOWCOMP block
l Alarm example-FLOWCOMP block
l Fail-Safe values-FLOWCOMP block
l FLOWCOMP parameters
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.
23.8.2 Configuration parameters-FLOWCOMP block

The following table provides a summary of the FLOWCOMP specific parameters that you can
Title Parameter Name Description

PV Display PVFORMAT Lets you define the decimal format to be used to display
Format the PV value. The choices are D0 (None), D1 (One), D2
(Two), or D3 (Three). The default value is D1.
Overall Scaling CPV Lets you define the overall scaling factor to be applied
Factor for PV to the PV value to meet your process requirements. The
default value is 1.
Flow CF1 Lets you define a compensation factor to use for

Compensation converting units of measurement for the
Factor 1 uncompensated flow to units for the compensated flow,
or correcting for assumed design conditions The default
value is 1.
Flow CF2 Lets you define a compensation factor to use for

Compensation converting units of measurement for the
Factor 2 uncompensated flow to units for the compensated flow,
or correcting for assumed design conditions The default
value is 1.
- 782 -

Compensation COMPHILM Lets you define a high limit for the flow compensation
Term High Limit term The default value is 1.25.
Compensation COMPLOLM Lets you define a low limit for the flow compensation
Term Low Limit term The default value is 0.8.
PV Equation PVEQN Lets you select the flow compensation equation type
Type the block is to use. The default value is EQA (Equation
A).
PV PVCHAR Lets you specify square root as the PV characterization

Characterization to use. The default value is SQUAREROOT.
Option
Bad Comp Term BADCOMPTERM.PR Lets you specify the priority level for a bad COMPTERM
Alarm Priority alarm. The default value is LOW.
Bad Comp Term BADCOMPTERM.SV Lets you specify the severity level for a bad COMPTERM
Alarm Severity alarm. The default value is 0.
Alarm Filter MAXCYCLE Lets you specify the number of filter cycles before a bad
Cycles COMPTERM alarm is generated. The default value is 0.
If the value is NaN, the COMPTERM is frozen at its last
good value for indefinite period
Zero Ref. for P0 Lets you specify the zero pressure reference value for
Pressure equations that require it. The default value is 0.
Zero Ref. for T0 Lets you specify the zero temperature reference value
Temperature for equations that require it. The default value is 0.
Specific Gravity RG Lets you specify the specific gravity reference value for
equations that require it. The default value is 1.
Pressure RP Lets you specify the absolute pressure reference value

for equations that require it. The default value is 1.
Steam Quality RQ Lets you specify the steam quality reference value for
Temperature RT Lets you specify the temperature reference value for

Steam RX Lets you specify the steam compressibility reference

Compressibility value for equations that require it. The default value is
1.
Reference RMW Lets you specify the molecular weight reference value
Molecular for equations that require it. The default value is 1.
Weight
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.
- 783 -
If PVEQN is Then, It Requires These And, It Is Used For . . .

... Inputs . . .
Equation A uncompensated flow (F) and mass-flow or volumetric-flow compensation
(EQA) of liquids.
specific gravity (G).
Equation B uncompensated flow (F), mass-flow compensation of gases or vapors

(EQB)
pressure (P), and
temperature (T).
Equation C uncompensated flow (F), mass-flow compensation of gases or vapors.

(EQC)
pressure (P),
temperature (T), and
specific gravity (G).
Equation D uncompensated flow (F), volumetric-flow compensation of a gas or

(EQD) vapor.
pressure (P),
temperature (T), and
molecular weight (MW).
Equation E uncompensated flow (F), mass-flow compensation of steam.

(EQE)
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
Where:
CPV = Overall scale factor for PV
CF1 = Compensation factor
CF2 = Compensation factor
- 784 -
F = Uncompensated flow input
COMPTERM = A calculated flow compensation term

l The PVCHAR parameter is the COMPTERM Characterization option. Default
value is SQUAREROOT. Valid options are SQUAREROOT and NONE.
l If COMPTERM is greater than COMPHILM then COMPTERM is clamped to
COMPHILM.
l If COMPTERM is less than COMPLOLM then COMPTERM is clamped to
COMPLOLM.
l 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.

l If PVCHAR = SQUAREROOT, then:
l 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.
l If the variation in density caused by fluid-composition changes is not significant, then:
o G = Gravity of the actual fluid at flowing conditions
o RG = Gravity at flowing conditions used in design basis
l If the variations in density caused by fluid-composition changes are significant, C1 and C2 of

the FLOWCOMP should be manipulated as follows:
o C1 is set to the Gravity at reference conditions used in the design basis.
o 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.
o 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.
l For these cases:
- 785 -
o G = Gravity of the actual fluid at flowing conditions

o RG = Gravity at flowing conditions used in design basis
o C1 = Gravity at reference conditions used in design basis
o 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.
- 786 -
Equation E
Used for mass-flow compensation of steam.

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)
- 787 -
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:
l If Cycle is less than MAXCYCLE or MAXCYCLE = NaN, then:

o Freeze the COMPTERM to last good value
o Set PVSTS to UNCERTAIN
o Increment Cycle count
l Else, if after MAXCYCLE cycles or if MAXCYCLE equals 0, then:

o Trigger a BAD COMPTERM alarm
o 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::
l NaN - In this case:
l COMPTERM will freeze to its last good value
l COMPTERM will never go to bad
l PV status will be set to UNCERTAIN
l 0 - In this case:
l If the COMPTERM is BAD, BAD COMPTERM alarm is raised right
away, PV status will be set to UNCERTAIN.
l Greater than 0 - In this case

l COMPTERM will be frozen at its last good values till the MAXCYCLE
cycles.
l 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.
- 788 -
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.
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:
- 789 -
l 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]
l If P1 intersects the first segment (that is, P1 < IN[1]):
l If P1 intersects the last segment (that is, P1 > IN[i] for i = NUMSEGS - 1)):
l 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
l 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.
l The segment coordinate values (IN[i]) must be specified in ascending order, from
smallest to largest value.
l Function-GENLIN block
l Inputs
l Outputs-GENLIN block
l Error handling-GENLIN block
l GENLIN parameters
- 790 -
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):
l P1 must be brought from another function block.
l P1STS represents the status of P1.
23.9.3 Outputs-GENLIN block

The GENLIN block produces the following output:
l 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
l If P1STS is Uncertain, the GENLIN block sets PVSTS to uncertain.

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

the GENLIN block.
- 791 -
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
- 792 -
Tab
l 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.
l 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. .
l 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.
l 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.
l Overall Scale Factor (CPV) - Lets you specify the overall-scaling factor for
the PV output. The default value is 1.
l Overall Bias (DPV) - Lets you specify an overall bias for the PV output. The
default value is zero (0).
l Function-LEADLAG block
l Input-LEADLAG block
l Output-LEADLAG block
l PV status-LEADLAG block
l Error handling-LEADLAG block
l Equation-LEADLAG block
l Time constant recommendations-LEADLAG block
l Restart condition-LEADLAG block
l LEADLAG parameters
- 793 -
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).
23.10.4 PV status-LEADLAG block

l Bad - which means that PV is NaN (Not a Number)

l Manual - which means P1 source (for example, DATAACQ block) is in manual PV source.
l Uncertain - which means that PV is OK but P1 status is uncertain.
PVSTS:
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
- 794 -
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.
l The first order lag time (LAG1TIME) should be greater than or equal to 2 * TS. Where TS is the
sample time in minutes.
l The second order lag time (LAG2TIME) should be greater than or equal to 2 * TS.
l 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.
l 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

the LEADLAG block.
- 795 -
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.
delay time for BADPV alarms.
l BADPVALM.TM
l BADPVALM.TMO
- 796 -
The Rate of Change 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 that tab.
- 797 -
Tab
a number between 1 to 32767. The default value is 10.
reports.
l 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.
l 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.
l 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.
l 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.
l Deadband Time (BADPVALM.TM) -
With R410, thisparameter is introduced to define the duration in seconds
condition occurs.
You can configure individual deadband time for BADPVALM. However, if
migration on alarm attributes
l Off-delay Time (BADPVALM.TMO) - With R410, thisparameter is
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
- 798 -
Tab
Configuration Lets you select the available parameters that appear on the face of the
Parameters function block in the Project tab in Control Builder.
Defining
l Function-ROC block
l Configuration examples-ROC block
l Inputs-ROC block
l Outputs-ROC block
l Error handling-ROC block
l ROC parameters
23.11.1 Function-ROC block
l Limits the rate of input and provides the output variable based on the rate trip limits.
l 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.
l Uses the PVROCBYPASSFL parameter to BYPASS the rate trip limit.
l Provides a Bad PV alarm based on the status of the output.
l Rate limit is not applied and PV is set to P1 if the rate limits are NaN.
l For an invalid input (=NAN), rate limiting is not done and the output is NaN.
- 799 -
ATTENTION
l The ROC block is basically a Math block.
l 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.
l 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
- 800 -
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
PVROCNEGLM = 60
PVEULO = 0
PVEUHI = 100
23.11.3 Inputs-ROC block
l P1 - Process Input 1.
l PVROCPOSLM - PV Rate of Change limit in the positive direction.
l PVROCNEGLM - PV Rate of Change limit in the negative direction.
23.11.4 Outputs-ROC block
l PVROCPOSFL - This flag turns ON when rate limiting is done in the positive direction.
l PVROCNEGFL - This flag turns ON when rate limiting is done in the negative direction.
l PV - Output of ROC.
l BADPVFL - This flag is set when a bad input is received at the block.
23.11.5 Error handling-ROC block
l Access lock and index are verified during Load and Store of the block's parameters.
l If the positive limit is greater than span in EUs/min or less than 0, then a
“LimitOrRangeCrossover” Error is reported.
l If P1 is set to NaN, then, PV is set to NaN and BADPVFL is set to TRUE.
l If negative limit is greater than the span in EUs/min or less than 0 %, then
- 801 -
“LimitOrRangeCrossover” Error is reported.

l If PVEULO has a value NaN, then “InvalidValue” Error is reported.
l If PVEULO is greater than PVEUHI, then “LimitOrRangeCrossover”Error is reported.
l 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.
l If PVEUHI is NaN, then “InvalidValue” error is reported.
l If PVEUHI is lesser than PVEULO, a “LimitOrRangeCrossover”error is reported.
l 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

the Rate of Change block.
- 802 -
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:
l Select the input with the minimum value.
l Select the input with the maximum value.
l Select the median input.
l Calculate the average of the inputs.
l Select an input based on the Multiplex value; i.e., act as a multiplexer.
It looks like this graphically:
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.
l DEVALM.TM
l DEVALM.TMO
l DEVALM.DB
l DEVALM.DBU
l Function-SIGNALSEL block
l Configuration parameters-SIGNALSEL block
l Configuration examples-SIGNALSEL block
l Input-SIGNALSEL block
- 803 -
l Ignore Inputs-SIGNALSEL block

l Ignore Limit Checking-SIGNALSEL block
l Output-SIGNALSEL block
l Selection Methods-SIGNALSEL block
l Force-Select-SIGNALSEL block
l Bumpless Input Switching-SIGNALSEL block
l Deviation Alarming-SIGNALSEL block
l Deviation Alarm Deadband-SIGNALSEL block
l Deviation Alarm Deadband Units-SIGNALSEL block
l Error handling-SIGNALSEL block
l Restart or point activation-SIGNALSEL block
l Parameters for Checkpoint-SIGNALSEL block
l SIGNALSEL parameters
23.12.1 Function-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.
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.
- 804 -
Tab
reports.
l 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
slowdown in response time caused by this rate limiting. The default value
l 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
value before you tune the loop, to enable tuning to accommodate any
slowdown in response time caused by this rate limiting. The default value
Input l 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.
l Ignore Highest Inputs (IGNORHI) - Lets you select the number of highest
inputs to be ignored.
l Ignore Lowest Inputs (IGNORLO) - Lets you select the number of lowest
inputs to be ignored.
l Ignore Limit (IGNORLM) - Lets you set the maximum allowable range
between the lowest and highest input.
l Ignore Time (IGNORTM) - Lets you set the time limit beyond which inputs
that are outside the IGNORLM value will be ignored.
l Deviation Alarm Trippoint (DEVALM.TP) - Lets you set the trip point for the
deviation alarm.
l Deviation Alarm Priority (DEVALM.PR) - Lets you set the priority of the
deviation alarm.
- 805 -
Tab
l Deviation Alarm Severity (DEVALM.SV) - Lets you set the severity of the
deviation alarm.
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.
loaded to the individual alarm parameters (for example, DEVALM.DB)
parameters as Monitoring Parameters for the block, you could change the
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
alarm attributes.
nuisance alarms from being reported repeatedly during 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.
alarm parameters (for example, DEVALM.TM) when the CM was loaded. If
you configured the individual alarm parameters as Monitoring
With R410, deadband time can be individually configured for each alarm.
For example, you can configure DEVALM.TM as 5 seconds. However, if
percent.
alarm parameters (for example, DEVALM.DBU) when the CM was loaded.
If you configured the individual alarm parameters as Monitoring
With R410, deadband unit can be individually configured for each alarm.
For example, you can configure DEVALM.DBU as percent. However, if you
are migrating from pre-R410 to later releases, refer to Impact of
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
- 806 -
Tab
l Forced Select Permissive (FRCPERM) - Lets you allow the operator to
force select an input.
l Forced Select (FRCSEL) - Lets you override the selected input.
l Forced Request (FRCREQ)
Defining
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:
- 807 -
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.
Case 4:
- 808 -
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:
- 809 -
If the block is configured with Selection Method = MUX and BOOLMUX= On, it would function as
follows.
- 810 -
23.12.4 Input-SIGNALSEL block
l 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]).
l All inputs shall be fetched from other function blocks.
l 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.
l 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.
l 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.
l If all the inputs are ignored, output shall go Bad.
l 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:
l It ignores Bad inputs (NaN), and the highest and lowest inputs (defined by IGNORHI and
IGNORLO).
l If there are no remaining inputs, ignore limit checking is not done for the block.
l It calculates a “center value” from the inputs that remain:
o If the number of remaining inputs is odd, the “center value”= the median input.
o If the remaining inputs is even, “center value” = the average of the middle two inputs.
l It calculates a high and low ignore limit from specified limit (IGNORLM):
o High ignore limit = “center value” + IGNORLM / 2
o Low ignore limit = “center value” - IGNORLM / 2
l It compares each of the remaining inputs with the high and low ignore limits.
l 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,
- 811 -
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).
l The center value, high and low ignore limits shall be computed every cycle of execution of the
block.
l 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
l This auxiliary PV block shall have output PV and its status PVSTS.
l It shall have a parameter SELIN denoting which input, if any has been selected as the output.
l The block shall have the following output flags
o One flag denoting if any of the inputs is ignored or not (IGNORD).
o 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.
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
- 812 -
l The output (PV) gets the minimum value of all the valid (not ignored) inputs.
l The selected input shall be the input that has this minimum value.
l 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
l PV gets the maximum value of all the valid inputs.

l The selected input shall be the input that has this maximum value.
l 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
l PV shall be the average of only the valid inputs.

l The selected input shall be None because PV is a calculated value and not any input by itself.
MED
l All the valid inputs are arranged in ascending order and median value is taken as PV.
l 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.
l 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)':
l If MEDOPT is MIN, then PV shall be the minimum of the middle two values and the respective
input shall be selected input.
l If MEDOPT is MAX, then PV shall be the maximum of the middle two values and the respective
input shall be selected input.
l 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
l 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.
l 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.
l 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
- 813 -
remains selected.
l 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.
l 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.
l If the Boolean selected input is not connected, then the PV value goes bad (NaN) and SELIN
will have the index of unconnected input.
l 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.
l Bad inputs may also be selected.
l Ignoring of Inputs and deviation alarming are not applicable for MUX. Also, the deviation
alarm state should return to normal.
l PV gets the value of the selected input.
l 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
l The operator or a user program may override the selection method and “force select” a
particular input.
l Force-select may override only the following selection methods: MIN, MAX, MED, or AVG and is
not applicable if the selection method is MUX.
l If the force selected input is not connected, then the PV value goes Bad (NaN) and the
respective unconnected input remains selected
l 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:
l The selected input changes.
l 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
l 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.
l 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.
l Once deviation alarm is triggered, a deviation alarm flag is set. When the alarm goes off, the
flag is reset.
- 814 -
23.12.12 Deviation Alarm Deadband-SIGNALSEL block
l The SIGNALSEL block also has a deadband (DEVALM.DB) for the deviation alarm.
l The purpose of this parameter is to prevent recurring alarms and returns-to-normal due to
noise.
l 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.
23.12.13 Deviation Alarm Deadband Units-SIGNALSEL block
l The SIGNALSEL block also has a parameter called deadband units (DEVALM.DBU) for the
deviation alarm.
l 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:
l An input selection is forced and the status of that input is Uncertain.
l The selection method is MIN, MAX, or MUX, and the status of the selected input is Uncertain.
l The selection method is AVG, and the status of any input is Uncertain.
l 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:
l An input selection is forced and the status of that input is Manual.
l The selection method is MIN, MAX, or MUX, and the status of the selected input is Manual.
l The selection method is AVG, and the status of any input is Manual.
l 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:
l Forced selection is in effect, and the status of that input is Bad.
l 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
- 815 -
l PV is set to NaN.
l P(1) through P(6) values are set to NaN.
l PSTS(1) through PSTS(6) are set to BadValSts.
l CURPINPT is set to zero.
l DEVALM.FL and INALM alarming flags are set to OFF.
l 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.
23.13 TOTALIZER Block
l Description
l Function-TOTALIZER block
l Configuration example-TOTALIZER block
l Input-TOTALIZER block
l Outputs-TOTALIZER block
l TOTALIZER states
l Accumulator target value-TOTALIZER block
l Deviation trip points-TOTALIZER block
l Equations-TOTALIZER block
l Accumulated value calculation-TOTALIZER block
l Error handling-TOTALIZER block
l Restart and activation-TOTALIZER block
l TOTALIZER parameters
23.13.1 Description
The TOTALIZER block periodically adds an input value (P1) to an accumulator value (PV). It looks
like this graphically:
- 816 -
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

uses a TOTALIZER block in a flow control loop for quick reference. The view in the following figure
depicts a loaded configuration in Monitoring mode.
- 817 -
Figure 23.6 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
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.
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.
l 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.
l ACCDEV.FL[1] turns ON at PV = 90
- 818 -
Callout Description
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):
l P1 is the value to be accumulated - the input value may be real, integer, or Boolean, but is
always stored as a real number.
l P1 must be brought from another block.
23.13.5 Outputs-TOTALIZER block

The TOTALIZER block produces the following outputs:
l The accumulated value (PV) and its status (PVSTS).
l 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:
l 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:
o 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.
o Stop - requests the TOTALIZER to stop the accumulation (change STATE to Stopped).
o 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”.
- 819 -
l 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.
o Operator - only the operator may store to COMMAND.
o OtherFB- only a program through another function block may store to COMMAND;
the operator may override the program by setting CMDATTR = Operator.
l STARTFL (Start Flag): Allows either a Logic block or user-written program to store to
COMMAND.
o Off-to-On transitions cause the TOTALIZER state to change to Running.
l STOPFL (Stop Flag): Allows either a Logic block or user-written program to store to COMMAND.
o Off-to-On transitions cause the TOTALIZER state to change to Stop.
l RESETFL (Reset Flag): Allows either a Logic block or user-written program to store to
COMMAND.
o 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 NaN. Continue after input turns valid
D Use zero if input is bad. Stop after a warm restart.
- 820 -
Equation Bad Input Handling Warm Restart Handling

E Use last good value if input is bad. Stop after a warm restart.
F Stop if the input is bad and set PV to NaN. Stop after a warm restart.
The following table summarizes block actions associated with a given PVEQN handling option
relative to the accumulator state and the input status. .
If Accumulator And Then, block …

is … Option
is …
Running (STATE Use zero Sets the input value (P1) to zero and sets PVSTS to Uncertain.
= RUNNING) and if input is
the input status bad When the input status (P1STS) returns to normal, PVSTS
(P1STS) is BAD remains Uncertain until a Reset command is received.
Running (STATE Use last Sets the input value (P1) to its last good value and sets PVSTS to
= RUNNING) and good Uncertain
the input status value if
(P1STS) is BAD input is When the input status (P1STS) returns to normal, PVSTS
bad remains Uncertain until a Reset command is received.
Running (STATE Stop if Sets the input value (P1) to NaN (Not a Number) and sets PVSTS
= RUNNING) and the input to Bad.
the input status is bad
(P1STS) is BAD When the input status (P1STS) returns to 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 Continue Sets PVSTS to Uncertain and continues accumulation from last
= RUNNING) after a value of PV.
warm
restart PVSTS remains Uncertain until a Reset command is received.
Running (STATE Stop Sets the accumulated value (PV) to NaN (Not a Number), sets
= RUNNING) after a PVSTS to Bad, and stops the accumulation. The operator must
warm intervene to restart the accumulator.
restart
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
- 821 -
time_ = (TS*60) if TIMEBASE = seconds

scale
(TS) if TIMEBASE = minutes
(TS / 60) if TIMEBASE = hours
where TS = TOTALIZER block's processing
interval, in minutes
23.13.11 Error handling-TOTALIZER block
l PVSTS is set to UNCERTAIN when:

o The status of the input (P1STS) is Uncertain.
o 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).
o The TOTALIZER block is in warm restart and the “continue”option is configured
(Equation A, B, or C).
l PV is set to NaN (Not a Number) and PVSTS is set to Bad, when:

o The status of the input (P1STS) is Bad and the “stop if input is bad” option is
configured (Equation C or F).
o The TOTALIZER block is in warm restart and the “stop” option is configured (Equation
D, E, or F).
l 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:
l PV is set to NaN (Not a Number).
l PVSTS is set to Bad.
l The accumulator is stopped (that is, STATE = Stopped).
23.13.13 TOTALIZER parameters

the TOTALIZER block.
- 822 -
CHAPTER
24 DATA ACQUISITION FUNCTIONS
l DATAACQ (Data Acquisition) Block
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.
on-delay time, off-delay time, deadband values, and deadband units for the PVHIALM parameter.
l PVHIALM.TM
l PVHIALM.TMO
l PVHIALM.DB
l PVHIALM.DBU
BADPVALM, ROCPOSALM, and ROCNEGALM alarms.
l BADPVALM.TM
l BADPVALM.TMO
l ROCPOSALM.TM
l ROCPOSALM.TMO
l ROCNEGALM.TM
l ROCNEGALM.TMO
- 823 -
Chapter 24 - Data Acquisition Functions
Each DATAACQ block supports the following user configurable attributes. The following table lists
- 824 -
Tab
reports.
l 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.
l 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.
l 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.
l 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.
l 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.
l 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.
l 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.
l 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
- 825 -
Tab
clamping is applied.
l 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.
Alarms l 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:
l PV High High (PVHHALM.FL
l PV High (PVHIALM.FL)
l PV Low (PVLOALM.FL)
l PV Low Low (PVLLALM.FL)
l Positive Rate of Change (ROCPOSALM.FL)
l Negative Rate of Change (ROCNEGALM.FL)
l Bad PV (BADPVALM.FL)
l High Significant Change (PVHISIGCHG.TP)
l Low Significant Change (PVLOSIGCHG.TP)
l PVHHALM.TP (PV High High Alarm Trip Point)
l PVHIALM.TP (PV High Alarm Trip Point
l PVLOALM.TP (PV Low Alarm Trip Point)
l PVLLALM.TP (PV Low Low Alarm Trip Point)
l ROCPOSALM.TP (Positive Rate of Change Alarm Trip Point)
l ROCNEGALM.TP (Negative Rate of Change Alarm Trip Point)
l PVHISIGCHG.TP (High Significant Change Alarm Trip Point)
l PVLOSIGCHG.TP TP (Low Significant Change Alarm Trip Point)
type (PVHHALM.PR, PVHIALM.PR, PVLOALM.PR, PVLLALM.PR,
ROCPOSALM.PR, ROCNEGALM.PR, and BADPVALM.PR). The default
value is LOW. The levels are:
Summary display.
type (PVHHALM.SV, PVHIALM.SV, PVLOALM.SV, PVLLALM.SV,
ROCPOSALM.SV, ROCNEGALM.SV, and BADPVALM.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.
- 826 -
Tab
loaded to the individual alarm parameters (for example, PVHIALM.DB and
PVLOALM.DB) when the CM was loaded. If you configured the individual
CB.
alarm. For example, you can configure PVHIALM.DB as 5 and
PVLOALM.DB as 3. However, if you are migrating from pre-R410 to later
l 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.
alarm parameters (for example, PVHIALM.TM and PVLOALM.TM) when
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.
l Deadband Units (ALMDBU/xxxx.ALMDBU) - Defines the unit for the
percent.
alarm parameters (for example, PVHIALM.DBU and PVLOALM.DBU) when
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.
- 827 -
Tab
information
l Function-DATAACQ block
l CAB Insertions for DATAACQ block parameters
l CAB insertion configuration considerations
l Insertion type functional characteristics-DATAACQ block
l Pin connections to inserted CAB instances-DATAACQ block
l CAB Insertion status and fail alarm-DATAACQ block
l Handling of insertion failure-DATAACQ block
l CAB insertion configuration examples-DATAACQ block
l Input-DATAACQ block
l Input ranges and limits-DATAACQ block
l P1 status
l PV Characterization-DATAACQ block
l Input filtering-DATAACQ block
l Input clamping-DATAACQ block
l Low signal cut off-DATAACQ block
l Output-DATAACQ block
l PV source selection-DATAACQ block
l PV status-DATAACQ block
l Alarm processing-DATAACQ block
l Additional Rate of Change Alarm considerations-DATAACQ block
l PV significant-change alarming-DATAACQ block
l Bad PV alarm-DATAACQ block
l DATAACQ parameters
24.1.1 Function-DATAACQ block
C200/C200E Controller and ACE Controller without CAB insertion points
- 828 -
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:
l Input Processing - fetches input data from another block through process connections,
checks its validity, and updates input parameters P1 and P1STS as appropriate.
l 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).
l 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.
l Low Signal Cut Off - Applies a user configurable low signal cut off limit to the PVAUTO value
after filtering and clamping.
l 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.
l 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.
- 829 -
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.
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
- 830 -
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
l You can insert up to 10 CAB programs in DATAACQ block.

l You must insert CAB instances in the same Control Module that contains the DATAACQ block.
l 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.
l 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.
l 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.
l 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 section for more information.
l 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.
- 831 -
Insertion Type Function

Process Variable Provides the capability of performing a calculation on the fetched input value.
Algorithm (PV_ The user-written algorithm must store the computed value into the process
Alg) 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 Provides the capability of implementing a custom filtering function. The

Characterization filtered value is stored in P1EU. You can also implement custom clamping
(Post_PVchar) 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.
Post Clamping Provides the capability of implementing custom source selection strategies
and Filtering and bypass the built source selection. The final value is stored in PV. The CAB
(Post_Clampfilt) program should also set PVSTS, PVEXHIFL, and PVEXLOFL parameters to
the appropriate states.
Post PV Source Provides the capability of implementing custom PV calculations. The CAB
(Post_PVsrc) 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 Provides the capability of modifying the built-in alarm processing.
Processing
(Post_ For example, selected alarms can be disabled in the next execution cycle by
Alarmproc) 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:
l Pin connections always transfer data into a CAB insertion program just before execution of the
calling block.
l 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
- 832 -
execution status as follows.

l If the program execution runs till completion, the status will read NORMAL.
l If the program does not run till completion, it returns a non-normal status.
l 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.
l PVAUTO is set to NaN
l IF PVSOURCE = AUTO, the PV status is set to bad and a BADPV alarm condition is set to TRUE
l P1FILTINIT is set to TRUE. This will reset the P1 value during filtering
l Insertion fail alarm condition is set to TRUE, if the status is not a termination
l 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
uses a DATAACQ block with an insertion type from a single CAB instance.
Figure 24.1 Configuration example using single CAB insertion.
- 833 -
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.
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.
activated, the daca 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.
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.
- 834 -
Callout Description
Failure Scenario
If the CAB_1 program does not run till completion and returns a non-normal status, the
following action takes place:
l The value of PVAUTO and PV are set to NaN.
l If PVSOURCE is configured as AUTO, PV status is set to BAD and BADPV alarm condition is
set to TRUE
l P1FILTINIT is set to TRUE. This will reset the filtered P1 value in the next cycle.
l INSFAILFl parameter is set to TRUE.
l BADPV alarm is generated.
Multiple CAB insertions
uses a DATAACQ block with insertion types from four CAB instances.
Figure 24.2 Configuration example using multiple CAB insertions
- 835 -
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.
activated, the daca 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.
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 (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
If any of the programs CAB_1A, CAB_2A or CAB_3A return a non normal status, the following
actions are taken.
l PVAUTO and PV are set to NAN.
set to TRUE
l P1FILTINIT is set to TRUE
l 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
uses a DATAACQ block with the same insertion type from two CAB instances.
Figure 24.3 Configuration example using two CAB insertions of the same type
- 836 -
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.
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.
activated, the daca 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.
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.
- 837 -
Callout Description
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:
l The value of PVAUTO and PV are set to NaN.
set to TRUE
l P1FILTINIT is set to TRUE. This will reset the filtered P1 value in the next cycle.
l INSFAILFl parameter is set to TRUE.
l 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.
l PVEUHI represents the 100% of full-scale value.
l PVEULO represents the 0% of full-scale value.
PVEXHILM and PVEXLO.LM define the high and low limits of P1 in engineering units.
l 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.
l If the P1 source provides a value and status, the status (P1STS) may have one of the following
values:
o BAD - value is NaN (Not a Number)
o Normal - value is OK.
o Manual - value is OK, but was stored by an operator (at the source block)
o Uncertain - value is OK, but was stored by a user-program (at the source block)
l If the P1 source provides a value only, the block derives P1STS as follows:
o If P1 is NaN (Not a Number), then: P1STS = Bad.
o Otherwise, P1STS = Normal.
l If P1 cannot be fetched (for example, due to a communications error), P1 is set to NaN and
P1STS is set to Bad.
- 838 -
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.
l 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.
l 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.
o For P1 input greater than or equal to zero (0):
P1EU SQRT (P1 /100) * (PVEUHI - PVEULO) + PVEULO
o 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.
l 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.
l FilteredP1 is computed as follows:
FilteredP1 = FilteredP1 LAST + (P1 - FilteredP1 LAST)* Ts / (Ts + P1FILTTIME)
where:
FilteredP1 LAST = previous filtered value
Ts = elapsed time in minutes
P1FILTTIME = filter lag time in minutes
- 839 -
l 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.
l Status of the filtered/clamped value is stored in PVAUTOSTS.
l If P1 is bad (NaN), the block stops filtering and sets PVAUTO to NaN. When P1 returns to good,
the block sets FilteredP1 LAST equal to the new P1EU, and starts filtering again.
l P1FILTTIME may have a value of 0 to 1440 minutes (or fractions thereof). Given a single-step
change in P1:
o FilteredP1 = 63.2% of P1EU after P1FILTTIME.
o FilteredP1 = 86.5% of P1EU after 2 * P1FILTTIME.
o FilteredP1 = 95.0% of P1EU after 3 * P1FILTTIME.
o 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:
l 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:
o P1 = Actual input value
o P1STS = Normal
o PVAUTO = Exceeded limit
o PVAUTOSTS = Uncertain (because the value was clamped)
o Appropriate “limit exceeded” flag is set (PVEXHIFL or PVEXLOFL)
l 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:
o P1 = Actual input value
o P1STS = Normal
o PVAUTO = NaN
o PVAUTOSTS = Bad
o 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).
- 840 -
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:
l AUTO (Automatic) - indicates that PVAUTO is used as the PV (where PVAUTO contains the
clamped and filtered value of P1) and PVSTS tracks PVAUTOSTS.
l MAN (Manual) - indicates that the operator may enter the PV and:
o sets PVSTS to Manual.
o rejects any attempts by the operator to store a value that exceeds the PV limits
(PVEXHILM and PVEXLOLM.
o applies no filtering on operator-entered values.
l SUB (Substitution) - indicates that a user program may enter the PV and -
o sets PVSTS to uncertain
o 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.
o applies no filtering on program-entered values.
24.1.18 PV status-DATAACQ block

l Bad - which means that PV is NaN (Not-a-Number)
l Manual - which means that PV is OK, but was stored by an operator.
l Uncertain - which means that PV is OK but was stored by a program.
PVSTS:
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:
l 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.
l 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
- 841 -
(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.
l 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.
l 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.
l 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
l The rate-of-change trip point is specified in EUs per minute.
l ROCPOSALM.TP is expressed as a positive number in EUs per minute.
l 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
l The rate-of-change trip point is specified in EUs per minute.
l ROCNEGALM.TP is expressed as a positive number in EUs per minute.
The following parameters also apply to each of the previously specified alarms:
l 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).
l Alarm Deadband Value (PVHIALM.DB, PVHHALM.DB, etc.) - Note that alarm deadband is not
- 842 -
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.
l 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.
l Alarm flag (PVHIALM.FL, PVHHALM.FL, ROCNEGALM.FL, etc.) - Indicates if the corresponding
alarm condition exists.
l Alarm priority (PVHIALM.PR, PVHHALM.PR, ROCNEGALM.FL, etc.) - Indicates the relative
priority of the alarm.
l 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:
l The calculation of the ROC trip point should be twice the current Period.
o 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.
o 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:
l 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.
l 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:
- 843 -
l PVLOSIGCHG.TP - the PV Low Significant-Change Trip Point.

l 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).
l The Bad PV alarm priority and severity parameters (BADPVALM.PR and BADPVALM.SV) are
configurable.
l Setting BADPVALM.PR to No Action disables alarming.
24.1.23 DATAACQ parameters

the DATAACQ block.
- 844 -
CHAPTER
25 PULSE INPUT
l Pulse Input Block

l PITOTALIZER Block
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.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.
l Function-PITOTALIZER block
l Configuration example-PITOTALIZER block
l Input-PITOTALIZER block
l Outputs-PITOTALIZER block
- 845 -
Chapter 25 - Pulse Input
l PITOTALIZER states
l Accumulator target value-PITOTALIZER block
l Deviation trip points-PITOTALIZER block
l Near-Zero Cutoff-PITOTALIZER block
l Bad Input Handling and Warm-Restart Options-PITOTALIZER block
l Bad Input Options (PVEQN) Selection Summary
l Control Module Activation-PITOTALIZER block
l Operating Algorithms-PITOTALIZER block
l Pulse versus Analog Operation
l Error handling-PITOTALIZER block
l Restart and activation-PITOTALIZER block
l PITOTALIZER parameters
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.
Note the following:

l 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.
- 846 -
l 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.
l When the accumulated value (P1) reaches the accumulated target value (ACCTV), the
accumulated target value flag (ACCTVFL) turns on.
l 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
l 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.2.3 Input-PITOTALIZER block

The PITOTALIZER block requires one input (P1):
l P1 is the value to be accumulated - the input value (P1) must be an integer value.
l 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:
l The accumulated value (PV) and its status (PVSTS).
l 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:
l 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.
- 847 -
o Start - requests the PITOTALIZER to start the accumulation (change STATE to

Running).
o Stop - requests the PITOTALIZER to stop the accumulation (change STATE to
Stopped).
o 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”.
l 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.
o Operator - only the operator may store to COMMAND.
o Program - only a program may store to COMMAND; the operator may override the
program by setting CMDATTR = Operator.
l STARTFL (Start Flag): Allows either a Logic block or user-written program to store to
COMMAND.
o Off-to-On transitions cause the PITOTALIZER state to change to Running.
l STOPFL (Stop Flag): Allows either a Logic block or user-written program to store to COMMAND.
o Off-to-On transitions cause the PITOTALIZER state to change to Stop.
l RESETFL (Reset Flag): Allows either a Logic block or user-written program to store to
COMMAND.
o Off-to-On transitions cause the PITOTALIZER to be reset.
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.
- 848 -
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 command is received.
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.
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
- 849 -
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:
PVi = PV (i - 1) + (RATE * TS)
- 850 -
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:

l TS = CM Execution Period in sec, if TIMEBASE is seconds
l TS = CM Execution Period in sec / (60sec/min), if TIMEBASE is minutes
l 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:
l TS = CM Execution Period in sec, if TIMEBASE is seconds

l TS = CM Execution Period in sec / (60sec/min), if TIMEBASE is minutes
l 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
l PVSTS is set to UNCERTAIN when:

o The status of the input (P1STS) is Uncertain.
o 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).
o The PITOTALIZER block is in warm restart and the “continue”option is configured
(Equation A, B, or C).
l PV is set to NaN (Not a Number) and PVSTS is set to Bad, when:
- 851 -
o The status of the input (P1STS) is Bad and the “stop if input is bad” option is
configured (Equation C or F).
o The PITOTALIZER block is in warm restart and the “stop” option is configured
(Equation D, E, or F).
l 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:
l PV is set to NaN (Not a Number).
l PVSTS is set to Bad.
l The accumulator is stopped (that is, STATE = Stopped).
25.2.16 PITOTALIZER parameters

the PITOTALIZER block.
- 852 -
CHAPTER
26 DEVICE CONTROL
l DEVCTL (Device Control) Block
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 that Tab. This data is only provided as a quick document reference,
- 853 -
Chapter 26 - Device Control
Tab
reports.
document for more 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,
l 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.
l SUB - Provided by an SCM.
l MAN - Operator stores value directly.
l AUTO - Derived from the parameter PVAUTO (GPVAUTO)
representing the assigned state of the actual inputs DI[1..4].
l TRACK - Derived directly for the commanded output state (OP).
Use this online when a limit switch has failed, or as a debug
mode.
l Number Of Inputs (NUMDINPUTS) - Lets you specify the number of

digital inputs to be used with the block. The default is 2.
l Number of Outputs (NUMDOUTS) - Lets you specify the number of digital
outputs to be used with block. The default is 1.
l Number of States (NUMSTATES) - Lets you define the number of settable
states as two or three. The default is 2 states.
l 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 l Number of Digital Inputs (NUMINPTS) - Same as entry on Main tab.
- 854 -
Tab
l 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.
Output l 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.
l 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.
l 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.
l 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.
l 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.
l 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.
l 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.
l 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.
l 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.
Maintenance l Enable Accumulation of Statistics (MAINTOPT) - Lets you specify if the
- 855 -
Tab
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.
l NUMTRANS[0..2] - Accumulated number of transitions of PV to
each state, since the last statistics reset.
l NUMSIOVRD - Accumulated number of safety interlock trips
that result in OP changing state, since the last statistics reset.
l STATETIME[0..2] - Accumulated time of PV in each state, since the last

statistics reset.
l None
l ONESHOT
l SEMICONT
l CONTRTN
l CONT
l 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.
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.
Alarms l 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.
- 856 -
Tab
l 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.
l 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.
l 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.
l 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.
l Command Disagree - Lets you configure the following parameters for this
alarm.
l 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.
l Time to State 1 (or assigned State Name) (CMDDISALM.TM[1]):
l Time to State 2 (or assigned State Name) (CMDDISALM.TM[2]):
This can only be configured if the number of states is 3.
l Priority (CMDDISALM.PR): Lets you select the priority level as
NONE, JOURNAL, LOW, HIGH, or URGENT. The default setting
is LOW.
l 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.
l Command Fail - Lets you configure the following parameters for the
command fail alarm.
l Time to State0 (or assigned State Name) (CMDFALALM.TM[0]):
This value must be less than the value set for CMDDISALM.TM
[0].
l Time to State 1 (or assigned State Name) (CMDFALALM.TM[1]):
[1].
- 857 -
Tab
l Time to State 2 (or assigned State Name) (CMDFALALM.TM[2]):
[2]. This can only be configured if the number of states is 3.
l Priority (CMDFALALM.PR): Lets you select the priority level as
is LOW.
l 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.
l Uncommanded Change - Lets you configure the following parameters for

this alarm.
l Priority (UNCMDALM.PR): Lets you select the priority level as
is LOW.
l 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.
l Bad PV - Lets you configure the following parameters for this alarm.
l Priority (BADPVALM.PR): Lets you select the priority level as
is LOW.
l Severity (BADPVALM.SV): Lets you set the relative severity of
l Override Alarms - The following alarms are configurable to represent

override interlock conditions.
l Safety Override Interlock (SIALM.FL): This alarm may be
generated when the safety override interlock (SI) occurs, and
has caused an OP state change.
l 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.
l 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.
l Override Alarms - Lets you configure the following parameters for the
safety override interlock alarm.
l Option (SIALM.OPT): Lets you specify whether the safety
override interlock alarm is enabled or not. The default setting is
DISABLED.
l Priority (SIALM.PR): Lets you select the priority level as NONE,
JOURNAL, LOW, HIGH, or URGENT. The default setting is LOW.
l 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
- 858 -
Tab
default setting is 0.
l State 0 Override Interlock Alarm - Lets you configure the following

parameters for this alarm.
l Option (OIALM[0].OPT): Lets you specify whether the State 0
DISABLED.
l Priority (OIALM[0].PR): Lets you select the priority level as
is LOW.
l Severity (OIALM[0].SV): Lets you set the relative severity of the

DISABLED.
is LOW.

DISABLED.
is LOW.
l Off Normal Condition - Lets you configure the following parameters for
this alarm.
l Priority (OFFNRMALM.PR): Lets you select the priority level as
is LOW.
l Severity (OFFNRMALM.SV): Lets you set the relative severity of
l DEVCTL block provides a feature to configure change of state (COS)

alarm with Delay option for Digital Inputs (DI). The following parameters
are introduced to enable/disable and to configure the priority, severity
and delay time of this alarm.
l CHGOFSTALMENB
l CHGOFSTALM.PR
- 859 -
Tab
l CHGOFSTALM.SV
l CHGOFSTALM.TM
l Function-DEVCTL block
l Configuration examples-DEVCTL block
l Inputs-DEVCTL block
l Outputs-DEVCTL block
l States-DEVCTL block
l State parameters and descriptors-DEVCTL block
l Two-State motor input example-DEVCTL block
l Valve input example-DEVCTL block
l Two-Input motor example-DEVCTL block
l Reversible motor input example-DEVCTL block
l Four-Input two-valve example-DEVCTL block
l DI to PV state map
l Two-State motor with latched output example
l Valve Output Example-DEVCTL block
l Three-State Motor output examples-DEVCTL block
l Mode and mode attribute-DEVCTL block
l Safe output state-DEVCTL block
l Momentary state-DEVCTL block
l Local manual-DEVCTL block
l Permissive interlocks-DEVCTL block
l Safety Override Interlock-DEVCTL block
l Override Interlocks-DEVCTL block
l Configurable Override/Permissive Interlock Bypass-DEVCTL block
l Alarms-DEVCTL block
l Seal-In option-DEVCTL block
l Initialization Manual condition-DEVCTL block
l OP Initialization Option-DEVCTL block
l Initialization Manual Condition with Safety Override Interlock, Override Interlocks, LocalMan,
and OP Initialization
l Initialization with Pulse Output-DEVCTL block
- 860 -
l Initialization Request Flags-DEVCTL block

l OP and DO Initialization After Load-DEVCTL block
l Maintenance Statistics-DEVCTL block
l Output requests-DEVCTL block
l Output command-DEVCTL block
l Logic override OPREQ
l DEVCTL parameters
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 Taggingsection 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.
Figure 26.1 DEVCTL block major functions and parameters.
- 861 -
Figure 26.2 More DEVCTL block major functions and parameters.
- 862 -
In summary, the DEVCTL block provides these major features.
l Up to 4 inputs, 3 states, and 3 outputs.

l PV Source Selection, PV has 3 basic states plus in-between and faulty.
l Latched and pulsed outputs.
l Momentary states.
l Initialization, Local Manual and Redtagging.
l BADPV, Command Disagree, Uncommanded Change and Command Fail alarms.
l PV Change of state event.
l Permissive and Override Interlocks for each state.
l Interlock trip alarms.
l Seal In option.
l Maintenance statistics.
l The Safety Interlock enforces the defined safe state.
l Safe State explicitly configured. Cannot be momentary.
l Generic State parameters defined as consistent data types.
- 863 -
l Initialization has OPFINAL based configuration.

l Boolean Command option
l Batch level 1 driver option.
l OFF Normal Alarm associated with requested OP.
Support for Change of State (COS) Alarm
The DEVCTL block is enhanced for you to configure the same for generation of COS alarms. A COS
alarm is reported when the time delay expires. If there is a state change before the time delay
expires the time delay is reset and COS alarm is not reported.
To accomplish this, new parameters CHGOFSTALMENB,CHGOFSTALM.PR, CHGOFSTALM.SV,
CHGOFSTALM.TM are introduced in the DEVCTL block.
l To configure CHGOFSTALM.PR, CHGOFSTALM.SV, CHGOFSTALM.TM parameters you need
to enable/disable the CHGOFSTALMENB parameter.
l The COS alarm is reported in the station with the priority defined in priority column of the
CHGOFSTALM.PR parameter. The possible priorities are None, Journal, Low, High and
Urgent.
l The COS alarm is reported in the station with given severity defined in the Severity column of
the CHGOFSTALM.SV parameter.
l The COS alarm is reported in the station whenever there is a state change after a configured
delay time defined in CHGOFSTALM.TM parameter.
26.1.2 Configuration examples-DEVCTL block
l 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.
- 864 -
Figure 26.3 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.
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
- 865 -
Callout Description
as implicit/hidden connections.)
The secondary data contains this information for DEVCTL blocks.
l 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.
l Initialization value - provides continuous and one shot initialization.
l 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 26.4 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.
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.
- 866 -
Callout Description
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:

l 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.
l 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:

l 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.
l 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
l 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.
l 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.
l An output to any connection except to a DOCHANNEL block is a Boolean output (DO [1 .. 3])
only.
l 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.
- 867 -
o DOC.SO may be connected to DO [1 .. 3].

o DOC.ONPULSE may be connected to pulsed outputs PO [1 .. 3].
o DOC.OFFPULSE may be connected to pulsed outputs PO [1 .. 3].
l 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.
l 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.
l 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.
o 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.
o 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
l For pulsed outputs (ONPULSE and OFFPULSE), only one of these inputs may be
connected for any one DOCHANNEL block.
l 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.
- 868 -
26.1.6 State parameters and descriptors-DEVCTL block

The DEVCTL block includes these two sets of parameters for state associations.
l State Parameters
o PV
o PVAUTO
o OP
o OPFINAL
l Generic State Parameters

o GPV (generic version of PV)
o GPVAUTO (generic version of PVAUTO)
o GOP (generic version of OP)
o 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:
l Null - Stands for Bad Value.
l Inbet - Represents an in between state and could be designated MOVPV for moving PV.
l 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.
l Safe - Stands for SAFEOP. If an external FB issues a Safe command to GOP, the internal value
is set to the designated SAFEOP.
l S0 -Represents settable output State 0.
l S1 - Represents settable output State 1.
l 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
- 869 -
If STATETEXT is … Then, default name is… And, GENSTAT_ENM is…

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

DI[1] DI[2] GENSTAT
0 0 Moving Inbet
1 0 Open SO
0 1 Closed S1
1 1 Fault Null
(bad)* X Fault Null
X * Fault Null
state cannot occur.
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
- 870 -
reference.

DI[1] DI[2] GENSTAT
0 0 Fault Null
1 0 Stop S0
0 1 Run S1
1 1 Run S1
(bad)* X Fault Null
X (bad)* Fault Null
state cannot occur.
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.

DI[1] DI[2] GENSTAT
0 0 Stop S0
1 0 Run S1
0 1 Reverse S2
1 1 Fault Null
(bad)* X Fault Null
X (bad)* Fault Null
state cannot occur.
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.
- 871 -
Input States Configured State Related DIPVMAP and

DI[1] DI[2] DI[3] DI[4] Name GENSTAT
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
state cannot occur.
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.
- 872 -
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.

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

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
l Mode (MODE) is fixed at MANual. The Normal Mode (NORMMODE) parameter is also fixed at
MANual.
l 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:
o OPERATOR = only the operator may command the output state.
o PROGRAM = only other function blocks (such as Logic blocks, SCM programs) may
command the output state by setting OPREQ.
o 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.
l When NUMSTATES = 2, then State 2 is illegal for SAFEOP.
l SAFEOP may not be assigned to a state, which is already configured as momentary.
l 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).
*Fixed Time is defined:

l For containing CM periods< 5 seconds. Momentary States are≈5 seconds for all possible CM
periods.
l For periods> 5 seconds (ACE). Momentary states are at least one execution cycle, which can
be up to 20 seconds on ACE.
- 874 -
The following table summarizes the MOMSTATE parameter selections.
If Momentary Then,
State selection
is …
NONE No state is momentary.
STATE_0 State 0 is momentary and it must not be configured as the safe output.
STATE_1 State 1 is momentary and it must not be configured as the 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.
STATE_2 State 2 is momentary and it must not be configured as the 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.
l For OP to be changed to the desired state, the corresponding Permissive Interlock parameter
must be set to ON.
l 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.1.21 Safety Override Interlock-DEVCTL block

The Safety Override Interlock (SI) forces the commanded output state (OP) to the Safe Output
- 875 -
State (emay como a different state while SI is active

l 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.
l SI is defaulted to OFF, it must be set to ON to force OP to go to SAFEOP.
l When SI turns OFF, OP = SAFEOP is maintained until changed by:
o the operator
o a user program
o 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.
l 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.
l 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.
l 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:
o 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.
l When BYPASS is ON, OP can be changed regardless of the state of the Override Interlocks.
l When BYPASS is reset to OFF, existing Override Interlocks (if any) take effect immediately.
l BYPASS does not affect the Safety Override Interlock (SI).
l When BYPPERM is OFF, BYPASS defaults to OFF and is read-only.
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.
- 876 -
l 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.
o 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].
l Bad PV Alarm - generated whenever the Current Active State (PV) is detected to be a NULL (or
bad) state.
l 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.
l 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.
l 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.
l 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.
o 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.
l 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.
o 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:
- 877 -
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.
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.
l 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.
l Override Interlock Alarms - When the alarm is enabled and the active interlock causes an OP
state change, the alarm will be generated.
l Safety Override Interlock Alarm - When the alarm is enabled and the active interlock causes an
OP state change, the alarm will be generated.
o 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.
l Change of State Alarm - When a PV state change occurs and the time-delay expires the COS
alarm is reported. New parameters CHGOFSTALM.ALL, CHGOFSTALM.FL, CHGOFSTALM.PR,
CHGOFSTALM.SV and CHGOFSTALM.TM are introduced to configure the priority, severity and
delay time of this alarm.
o CHGOFSTALM.FL is set to ON whenever there is a state change in DIGACQ block.
o The COS alarm is reported in the station with the priority defined in priority column of
the CHGOFSTALM.PR parameter. The possible priorities are None, Journal, Low, High
and Urgent.
o The COS alarm is reported in the station with given severity defined in the Severity
column of the CHGOFSTALM.SV parameter.
o The COS alarm is reported in the station whenever there is a state change after a
configured delay time defined in CHGOFSTALM.TM parameter.
PV Off Normal Alarm - The normal PV state and based on which the PV Off Normal Alarm
will be generated.
o A new parameter PVNORMAL is introduced to store the PV Normal state set.
o This parameter will allow to set States based on the state names configured. Similar to
the states list available for configuration of inputs.
o PVNORMAL parameter by default will be set to Bad as the normal value.
o A new parameter PVNORMALFL is introduced to store if Normal state configuration
should be allowed or not.
o PVNORMALFL parameter by default will be set to False. This it will help not to
generate OffNormal Alarm during migration.
o During load of DevCtl block there will be a check made to get the configured input
states based on which user will show an error message if the Normal state is not set
as per that. Since the same configured states is what PV can take too and OffNormal
alarm can be generated only based on these states.
o Off Normal Alarm configuration can be done in Alarms tab.
o New parameters OFFNRMPVALM.ALL, OFFNRMPVALM.FL, OFFNRMPVALM.PR,
OFFNRMPVALM.SV and OFFNRMPVALM.TM is introduced to store the PV Off Normal
alarm flag, PV Off Normal alarm priority, PV Off Normal alarm severity and PV
OffNormal On Delay time respectively.
- 878 -
o User will be allowed to set NONE, JOURNAL, LOW, HIGH AND URGENT priorities for
the Off Normal Alarm priority.
o Alarm will be generated once the PV goes to a state other than the Normal state set in
PVNORMAL parameter.
o User will be allowed to set all these parameters from monitoring side too.
o The priority of PVOFFNORMAL alarm will be handled similar to other alarm tags.
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.
l Seal-In option and Momentary state are mutually exclusive. The Momentary state has to be
None to configure the Seal-In option.
l You can configure the seal-in option through the SEALOPT (Enable/Disable) parameter.
l 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.
l 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.
l This is a structure containing the INITREQ status and the DOC.SO present value.
l INITCONNECTD[1..3] - This parameter is set by the FB Builder when the corresponding
INITDOWN[] is connected.
l 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.
l INITOPOPT = NORMALOPT, perform normal initialization as described below in Initialization
Manual Condition with Safety Override Interlock, Override Interlocks, LocalMan, and OP
Initialization.
l INITOPOPT = SAFEOPOPT, OP is set to SAFEOP
l INITOPOPT = HOLDOPOPT, initialization will not be performed. OP remains the last value.
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
- 879 -
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:
l If the Safety Interlock is active, the OP is set to SAFEOP;
l Otherwise, if any of the Override Interlocks are active and not bypassed, the OP is set to the
highest priority Override Interlock;
l 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;
l Otherwise, if OP Initialization is configured as HOLDOPOPT, OP value depends on the
LEGACYINITOPT parameter value;
o 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.
l If LEGACYINITOPT = DISABLE, OP is either back initialized from the outputs if a valid OP can be
constructed or OP is set to SafeOP.
l Otherwise, if OP Initialization is configured as SAFEOPOPT, OP is set to SafeOP;

l 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 );
l Otherwise, OP value is back-initialized from the output connections if
o there are no output types of ONPULSE/OFFPULSE, and
o 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.
- 880 -
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 :
l When PV is good, OP and OpFinal are initialized to PV, no pulses should be generated.
l When PV is Bad, OP and OpFinal are initialized to SafeOp, pulses should be generated.
l 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.
Outp INITOPOPT PV State Changes to Output Pulses

ut When When When When
Type LEGACYINITO LEGACYINITO LEGACYINITO LEGACYINITO
PT is disabled PT is enabled PT is disabled PT is enabled
Pulse NORMALOPO Goo PV PV No No

PT d
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 NORMALOPO Goo PV PV N/A N/A

PT d
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
- 881 -
Outp INITOPOPT PV State Changes to Output Pulses

ut
Type outputs
SAFE N/A Saf SafeOp N/A N/A

OPOP eOp
T
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.
- 882 -
l MAXTRANS [0 .. 2] - maximum number of transitions of PV to each state. Useful to compare

these values to NUMTRANS [0 .. 2].
l 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:

l NUMTRANS [0 .. 2] - accumulated number of transitions of PV to each state (since the last
statistics reset).
l STATETIME [0. 2] - accumulated time of PV in each state (since the last statistics reset).
l 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.
l If SAFEOP is SO, the priority is OPCMD[0], OPCMD[1], OPCMD[2].
l If SAFEOP is S1, the priority is OPCMD[1], OPCMD[0], OPCMD[2].
l 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.
- 883 -
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, 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

the DEVCTL block.
26.1.37 Faceplate for VFD applications

VFD's (Variable frequency drive) are becoming the preferred final control element (vs. control
valves). To achieve the same user create a CM having PID function block to control the speed of
the drive and a separate CM with Device control function block to START/STOP the drive. To
operate the VFD from station user need to call two different faceplate (one PID faceplate linked to
PID block container CM and DEVCTL faceplate linked to DEVCTL block container CM.) which is
inconvenient. This function enables user to operate VFD from a single faceplate.
To use the new set of faceplate/detail display function block in the CM should follow the standard
naming convention. (Ex: Data acquisition block should be named as DACA, PID function block
should be named as PIDA and Device control function block to be named as DEVCTLA.
CM containing PID function block must be associated with the new set of faceplate/detail display in
the Server display tab of CM configuration form.
There will be additional parameter on the PID function block which will allow to enter/select the
CM name which contains the Devctl function block which is used to command (START/STOP) the
VFD.
- 884 -
The VFD applications have nine tabs for different functions. They are:
l VFD application point detail display main tab.
A new point detail display can be invoked by entering CM name containing PID function
block in station and press F12 key. CM general parameters like execution state, CEE state,
execution period, execution phase, will appear for both CM. There are Alarm enable,
Journal only option and control module in alarm status will appear for both CM. In case
PID function block and Devctl function block be in the same CM only one column will
appear showing the CM general parameters. Main tab of detail display shows the
information in two column. Left column shows the information related to the Devctl
function block (Ex: Permissive and Override interlocking, Mode attribute and selection)
Right column shown the information related to PID function block (Ex: Control windup,
Mode and Mode attribute and other settings).
l VFD application point detail display loop tune tab.
This tab shows information related to the PID function block tuning and the information
presented here is same set of parameters available in the standard PID function block
detail display.
l VFD application point detail display Set Point tab.
This tab shows the same set of information available in the standard PID function block
detail display.
l VFD application point detail display PV and OP tab.
This tab shows same set of information available in the standard PID function block detail
display.
l VFD application point detail display I/O States tab.
- 885 -
This tab shows information about the different states configured and the individual digital
input and digital output states of the device control function block.
l VFD application point detail display Alarms tab
This page enables user to monitor and configure the various alarms for the DACA and PID
function block. User have the option to scroll down and monitor and configure the
DEVCTLA function block alarms as well. Using scroll bar at the right side, user will be able
scroll between the DACA, PID function block alarm configuration and Devctl function block
alarm configuration.
l VFD application point detail display Chart tab.
This page enable the user to view the CM chart view in station. In this page chart view will
be loaded of the CM containing PID function block.
This page enable the user to monitor some statistics parameter when the CM execution is
driven from SCM. This tab will be visible only when CM parameter SCM option is set to
COMMON. This page shows the statistics of the CM containing PID function block.
Faceplate enables user to monitor and control some key parameters like SP, OP, and PV.
Faceplate for VFD application has all behaviors same as PID function block, except mode
attribute has been removed. User can command the VFD by selecting appropriate
command from the command dropdown on the lower panel. This is mapped with the OP
parameter of the Devctl block. FB, feedback is mapped to PV of Devctl function block. In
case of some interlocking set to Devctl function block like Permissive and Override
interlock, the standard symbol will be shown to the faceplate. Next to feedback L symbol is
used to show the Localman status of the Devctl function block. In case of auto selection
behavior, SP and OP parameter of the PID function block will be selected depending the
mode AUTO and MAN. Mode attribute parameter of both PID function block and Devctl
function block has been moved to main page uder sub heading mode attribute.
- 886 -
CHAPTER
27 LOGIC FUNCTIONS
l Logic Function Blocks

l Change Execute (CHGEXEC) Block
l CHGEXEC Usage Considerations for Change Driven Execution
l Change Driven Application Risk Factors
l Blocks Qualified for Use with CHGEXEC Block
l Experion Controller Platform Support for CHGEXEC
l CHGEXEC Main Parameter Details
l CHGEXEC Cascading Between Control Modules Example
l CHGEXEC Cascading Within Control Module Example
l Importance of Using Consistent Input Data
l Periodic Auto Trigger Function of CHGEXEC
l Execution Order Considerations for CHGEXEC within CM
l CHGEXEC Behaviors for State Transitions
l CHGEXEC Supports Checkpoint Function
l Load Monitoring Parameters
l Sample CHGEXEC TESTOPT Procedure
l Examples and scenarios
l Contact Monitoring (CONTACTMON) Block
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.
l Bitwise Boolean functions
l Comparison functions
l Arithmetic functions
l Selection functions
l Bistable (flip-flop) functions
l Edge triggered functions
l Timed functions
l 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.
- 887 -
Chapter 27 - Logic Functions
Block Name/ Graphic Description Function
2003 2-out-of-3 Voting block Sets the

outputs (DISCREP and output
MAJ) are determined (DISCREP) to
as follows: ON if NOT all
inputs agree
l DISCREP = OFF for a specified
when all inputs time duration
are equal. (DELAY);
= ON when all otherwise, it
inputs are not is set to OFF.
equal for time >=
DELAY.
l 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- Turns the

input AND algorithm, digital output
meaning that it (OUT) ON
performs the Boolean only when all
operation of inputs (IN[1],
conjunction. Each IN[2], …, IN
input (IN[1], IN[2], …, [8]) are ON.
IN[8]) has the Therefore:
capability of being
optionally inverted, if l If all
required. inputs
are ON,
then:
OUT =
ON.
l If any
input is
OFF,
then:
- 888 -
OUT =
OFF.
CHECKBAD Provides bad input Checks if
handling for desired input (IN)
input. value equals
NaN.
l If IN =
NaN
l Then,
OUT =
ON
l Else,
OUT =
OFF
CHECKBOOL Provides the ability toDetermines
modify the OUTPUT the action to
based on be taken in
programmable the event of
parameters where the an invalid
OUTPUT will either input. If the
track the INPUT, latch value of
the OUTPUT, (ON or INSTS[1..8] is
OFF), or latch the kBadValSts,
OUTPUT to a specific the value
known good value for a passed
specific time based on through the
configuration block, from IN
parameters associated [1..8] to OUT
with the block. [1..8], will be
modified
See CheckBool
based on the
functionality under configuration
Examples and of the
Scenarios for Use Case BADINACT
examples of the [1..8]
CheckBool block. parameter.
If BADINACT
is configured
as OFF, then
OUT[1..8] is
set equal to
OFF
If BADINACT
is configured
as ON, then
OUT[1..8] is
set equal to
“ON”
If BADINACT
is configured
as HoldLast,
then OUT
[1..8] is set
equal to
LASTIN[1..8]
- 889 -
CHGEXEC The Change Execution Refer to the

block helps in Change
optimizing the Execute
performance of control (CHGEXEC)
modules (CM) used Block section
exclusively for logic following this
computation. table for
more
information
about this
block's
functions.
The CONTACTMON block can only be used with C300, C200E, and ACE Controllers.
CONTACTMON The Contact Inputs:

Monitoring block,
available under the l IN[1..2]
Logic library, is used - Input
for limit switches with paramet
NO and NC Contact er
with the same correspo
nding to
activation mechanism.
In most cases, the limit the NO
switch serves some and NC
critical applications. An Contact
alarm is generated of a
when both digital micro
inputs are ON or OFF Switch.
at the same time,
indicating a switch Outputs:
malfunction. The l PVFL -
Contact Monitoring this
block allows the user to gives
generate an alarm the
whenever the state of negated
both inputs is XOR
simultaneously ON or results
OFF based on the of IN[1]
NORMAL state and IN
configuration. [2]
See Contact l OUT1 -
Monitoring Tracks
(CONTACTMON) block IN[1]
under Examples and when
Scenarios section for both
sample block function inputs of
and execution. COC are
not ON
- 890 -
l OUT2 -
Tracks
IN[2]
when
both
inputs of
COC are
not ON
Error
Handling:
l The
block
displays
an error
when an
invalid
index or
access
lock is
detected
during
loading.
l SR
paramet
ers are
not
editable
on the
monitori
ng side.
A string
input to
the SR
paramet
er
results
in an
error
messag
e being
reported
during
configur
ation
and the
input
string is
rejected.
l The
alarm
flags are
cleared
when
the CM
is
inactivat
ed or
- 891 -
CEE is
made
IDLE.
DELAY Provides the ability to The OUT
delay the output (OUT) always
response to the given follows the
input (IN) by a sample input (IN)
cycle time. action by a
sample cycle
time.
EQ Provides a 2-input Turns the
Compare Equal (with digital output
deadband range) (OUT) ON
function, meaning that only when
it compares two inputs the two
for equality within a inputs (IN[1]
specified deadband and IN[2])
range. are
considered
equal within
a specified
deadband
range or, for
single inputs,
a designated
trip point
parameter
(TP) as
follows:
l If ((IN[1]
- IN[2)
<=
DEADBA
ND1),
then:
OUT =
ON.
l If ((IN[1]
- IN[2]) >
DEADBA
ND2),
then:
OUT =
OFF.
l Else
OUT is
not
change
d.
DEADBAND1
and
DEADBAND2
must satisfy
the following
constraint:: 0
<=
- 892 -
DEADBAND1
<=
DEADBAND2
If either input
(IN[1] or IN
[2]) is NaN,
the output
(OUT) is set to
INBADOPT.
FTRIG Falling edged Trigger Provides
Block sets the output falling edged
(OUT) to ON following change
the ON-to-OFF detection,
transition of the input thereby
and stays ON until the turning the
next execution cycle, at output ON if
which time it returns to an ON-to-
OFF. OFF
transition is
detected.
Module determines how the FTRIG block OUT responds as a result of block state transitions such
as activate, warm start, cold start or RAM Retention Restart (RRR). The following table
summarizes the possible OUT action for a given LOGICINITOPT configuration.
If Configured LOGICINITOPT Value Is … And, Current IN Value Is … Then, OUT Value After
PULSEEXPIRED ANY OFF
PULSEREADY ANY May pulse depending

on value of current
input and value of
input at last execution.
GE Provides a 1- or 2- Turns the

input Compare Greater digital output
Than or Equal (with (OUT) ON
deadband) function, only when
meaning it checks to one
see if one designated designated
input (IN[1]) is greater input (IN[1])
than or equal to either is greater
a second input (IN[2]) than or equal
or, for single inputs, a to a second
designated trip point input (IN[2])
parameter (TP). or, for single
inputs, a
designated
trip point
parameter
(TP) as
follows:
l If IN[1]
>= IN[2],
then:
- 893 -
OUT =
ON.
l If IN[1] <
(IN[2] -
DEADBA
ND),
then:
OUT =
OFF.
l If (IN[2]
-
DEADBA
ND) < IN
[1] < IN
[2], then
OUT is
not
change
d.
If either input
(IN[1] or IN
[2]) is NaN,
the output
(OUT) is set to
INBADOPT.
GT Provides a 1- or 2- Turns the
input Compare Greater digital output
Than (with deadband) (OUT) ON
it checks to see if one one
designated input (IN designated
[1]) is greater than input (IN[1])
either a second input is greater
(IN[2]) or, for a single than a
input, a designated trip second input
point parameter (TP). (IN[2]) or, for
single input,
a designated
trip point
parameter
(TP) as
follows:
l If IN[1] >
IN[2],
then:
OUT =
ON.
l If IN[1]
<= (IN[2]
-
DEADBA
ND),
then:
OUT =
OFF.
- 894 -
l If (IN[2]
-
DEADBA
ND) < IN
[1] <= IN
[2],
then:
OUT is
not
change
d.
If either input
(IN[1] or IN
[2]) is NaN,
the output
(OUT) is set to
INBADOPT.
LE Provides a 1- or 2- Turns the
input Compare Less digital output
Than or Equal (with (OUT) ON
deadband) function, only when
meaning it checks to one
see if one designated designated
input (IN[1]) is less input (IN[1])
than or equal to either is less than or
a second input (IN[2]) equal to a
or, for a single input, a second input
designated trip point (IN[2]) or, for
parameter (TP). a single
input, a
designated
trip point
parameter
(TP) as
follows:
l If IN[1]
<= IN[2],
then:
OUT =
ON.
l If IN[1] >
(IN[2] +
DEADBA
ND),
then:
OUT =
OFF.
l If IN[2] <
IN[1] <=
(IN[2] +
DEADBA
ND),
then:
OUT is
not
change
d.
- 895 -
If either input
(IN[1] or IN
[2]) is NaN,
the output
(OUT) is set to
INBADOPT.
LIMIT Provides a 3-input limit Provides an
function, meaning that output that is
it provides an output maintained
that is maintained within a
within a specified specified
range as defined by range as
user-specified follows:
minimum and
maximum values. l MN ≤
OUT
≤MX
l If IN is
not NaN,
OUT =
MIN (
MAX (
IN, MIN
), MAX )
l If IN =
NaN,
OUT =
NaN
LT Provides a 1- or 2- Turns the
input Compare Less digital output
Than (with deadband) (OUT) ON
it checks to see if one one
designated input (IN designated
[1]) is less than either input (IN[1])
a second input (IN[2]) is less than a
or, for a single input, a second input
designated trip point (IN[2]) or, for
parameter (TP). a single
input, a
designated
trip point
parameter
(TP) as
follows:
l If IN[1] <
IN[2],
then:
OUT =
ON.
l If IN[1]
>= (IN[2]
+
DEADBA
ND),
then:
OUT =
OFF.
- 896 -
l If IN[2]
<= IN[1]
< (IN[2]
+
DEADBA
ND),
then:
OUT is
not
change
d.
If either input
(IN[1] or IN
[2]) is NaN,
the output
(OUT) is set to
INBADOPT.
MAX Provides an N-input Used to
MAX function, isolate the
meaning that it highest value
provides an output of multiple
that is the maximum input values
value of N-inputs. and use it as
a designated
output value.
MAXPULSE Provides a maximum Used to limit
time limit pulse output the output
(OUT) each time the (OUT) pulse
input (IN) transitions to a
from OFF to ON. You maximum
specify the maximum width.
output pulse width
(PULSEWIDTH) in l If the
seconds through input
configuration. (IN)
pulse
time is
less
than or
equal to
the
specified
PULSE
WIDTH
time, IN
is
assume
d to
equal
one
output
(OUT)
pulse.
l If the IN
pulse
time is
greater
- 897 -
than the
specified
PULSE
WIDTH
time,
OUT
pulse
terminat
es at
end of
specified
PULSE
WIDTH
time.
MAXPULSE timing diagram:
Module determines how the MAXPULSE block OUT responds as a result of block state
transitions such as activate, warm start, cold start or RAM Retention Restart (RRR). The following
table summarizes the possible OUT action for a given LOGICINITOPT configuration.
PULSEREADY ANY May pulse depending on

value of current input
and value of input at last
execution.
MIN Provides an N-input Used to

MIN function, meaning isolate the
that it provides an lowest value
output that is the of multiple
minimum value of N- input values
inputs. and use it as
a designated
output value.
MINPULSE Provides a minimum Used to
time limit pulse output define the
(OUT) each time the minimum
output (OUT)
- 898 -
input (IN) transitions pulse width.

from OFF to ON. You
specify the minimum l If the
output pulse width input
(PULSEWIDTH) in (IN)
seconds through pulse
configuration. time is
less
than or
equal to
the
specified
PULSE
WIDTH
time,
output
(OUT)
pulse
width
equals
the
specified
time.
l If the IN
pulse
time is
greater
than the
specified
PULSE
WIDTH
time,
OUT
pulse
width
tracks IN
pulse
time, so
OUT
pulse
exceeds
specified
time.
MINPULSE timing diagram:
- 899 -
Module determines how the MINPULSE block OUT responds as a result of block state transitions
such as activate, warm start, cold start or RAM Retention Restart (RRR). The following table

execution.
MUX Provides an up to 8- Sets the

input Extensible actual output
Multiplexer algorithm, (OUT) to a
meaning that it selects particular
1 of “N” inputs input (IN[1],
depending on a IN[2], …, IN
separate input K. [8])
depending on
the value of a
separate
input K.
l OUT =
INk+1
MUX-REAL Provides an up to 8- Sets the
input Extensible actual output
Multiplexer algorithm, (OUT) to a
meaning that it selects particular
1 of “N” inputs input (IN[1],
depending on a IN[2], …, IN
separate input K. [8])
depending on
the value of a
separate
input K.
l OUT =
INk+1
MVOTE Provides an output Sets the MAJ
(MAJ) value that output equal
equals the value of the to the value
majority of the inputs of the
(IN[1..8]) and sets majority of
another output the inputs (IN
(DISCREP) to ON if not [1..8]).
all inputs agree for a
specified time (DELAY). Sets the
You specify the time DISCREP
(DELAY) in seconds output to ON,
through configuration. if not all
You must also specify inputs agree
the number of inputs during the
(NUMOFINPUTS) specified time
(DELAY).
- 900 -
through configuration. DELAY is a

unit integer
with time unit
in seconds.
Module determines how the MVOTE block output DISCREP responds as a result of block state
transitions such as activate, warm start, cold start or RAM Retention Restart (RRR). The delay
timing starts fresh whenever a state transition occurs. Disagreement in inputs causes DISCREP
to go to On only if it persists throughout the DELAY interval following a state transition. The
following table summarizes the possible DISCREP action for a given LOGICINITOPT
configuration.
If Configured LOGICINITOPT Value Is … And, Some IN Disagree … Then, DISCREP Value After
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.
NAND Provides an up to 8- Turns the

input NAND algorithm, digital output
meaning that it (OUT) OFF
performs an inverted only when all
AND function. Each inputs (IN[1],
input (IN[1], IN[2], …, IN[2], …, IN
IN[8]) has the [8]) are ON;
capability of being therefore:
optionally inverted, if
required. l If all
inputs
are ON,
then:
OUT =
OFF.
l If any
input is
OFF,
then:
OUT =
ON.
NE Provides a 1- or 2- Turns the
input Compare Not digital output
Equal (with deadband (OUT) ON
range) function, only when
meaning that it checks the two
to see if one inputs (IN[1]
designated input (IN and IN[2])
[1]) is not equal to are not
either a second input considered
- 901 -
(IN[2]) or, for a single equal within

input, a designated trip a specified
point parameter (TP). deadband
range or, for
single inputs,
a designated
trip point
parameter
(TP) as
follows:
l If ((IN[1]
- IN[2)
<=
DEADBA
ND1),
then:
OUT =
OFF.
l If ((IN[1]
- IN[2]) >
DEADBA
ND2),
then:
OUT =
ON.
l Else
OUT is
not
change
d.
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.
nOON n-out-of-N voting Provides
block; outputs are VOTED,
computed as follows: ORED and
ALARM
l VOTED output is outputs in
set to ON if at support of
least n inputs are logical
ON, otherwise it is functions.
set to OFF.
l ORED output is
set to ON if any
- 902 -
input is ON,
otherwise it is set
to OFF.
l 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.
Module determines how the nooN block OUT responds as a result of block state transitions such

execution.
NOR Provides an up to 8- Turns the

input NOR algorithm, digital output
meaning that it (OUT) OFF if
performs an inverted any one input
OR function. Each (IN[1], IN[2],
input (IN[1], IN[2], …, …, IN[8]) is
IN[8]) has the ON;
required. l If all
inputs
are OFF,
then:
OUT =
ON.
l If any
one
input is
ON,
then:
OUT =
OFF.
NOT Provides a NOT Reverses the
algorithm, meaning it state of a
performs an inversion digital input
- 903 -
function. (IN) such that

the output
(OUT) is the
complement
of the single
input;
therefore:
l OUT =
opposite
of IN
l If IN =
ON,
then:
OUT =
OFF.
l If IN =
OFF,
then
OUT =
ON.
OFFDELAY Delays the input signal Used to delay
supplied at the input the input by a
(IN) when the input specified
signal transitions from delay time
ON to OFF. after an
ON/OFF
device
transitions
from the ON
state to the
OFF state.
l Delay
time is
specified
by the
DELAYTI
ME
paramet
er.
OFFDELAY timing diagram:
- 904 -
Module determines how the OFFDELAY block OUT responds as a result of block state transitions
PULSEEXPIRED ON ON
PULSEREADY ANY May delay depending on

execution.
ONDELAY Delays the input signal Used to delay

supplied at the input the input by a
(IN) when the input specified
signal transitions from delay time
OFF to ON. after an
ON/OFF
device
transitions
from the OFF
state to the
ON state.
l Delay
time is
specified
by the
DELAYTI
ME
paramet
er.
ONDELAY timing diagram:
Module determines how the ONDELAY block OUT responds as a result of block state transitions
- 905 -
PULSEEXPIRED ON ON
PULSEREADY ANY May delay depending on

execution.
OR Provides an up to 8- Turns the

input OR algorithm, digital output
meaning that it (OUT) ON if
performs the inclusive any one input
OR Boolean function. (IN[1], IN[2],
Each input (IN[1], IN …, IN[8]) is
[2], …, IN[8]) has the ON;
required. l If all
inputs
are OFF,
then:
OUT =
OFF.
l If any
one
input is
ON,
then:
OUT =
ON.
PULSE Provides a fixed pulse Used to
output (OUT) each define the
time the input (IN) fixed output
transitions from OFF to (OUT) pulse
ON. You specify the width.
fixed output pulse
width (PULSEWIDTH) l If the
in seconds through input
configuration. (IN)
pulse
time is
less
than or
equal to
the fixed
PULSE
WIDTH
time,
output
(OUT)
pulse
width
equals
the fixed
time.
- 906 -
l If the IN
pulse
time is
greater
than the
fixed
PULSE
WIDTH
time,
OUT
pulse
width is
restricte
d to the
fixed
time.
Another
output
pulse
cannot
be
generat
ed until
the
precedin
g pulse
has
complet
ed.
PULSE timing diagram:
Module determines how the PULSE block OUT responds as a result of block state transitions
PULSEEXPIRED ON ON

execution.
- 907 -
QOR Qualified OR - provides Turns the

an (N + 1)-input digital output
generic-qualified OR (OUT) ON if a
function, meaning that specified
the output (OUT) is number (k) of
turned ON if a certain total digital
number (k) of total inputs is ON.
inputs (IN[n]) is ON.
Each input (IN[1], IN
[2], …, IN[8]) has the
capability of being
required.
ROL Provides a 16-bit Used to shift
integer output (OUT) out bits in the
that is rotated to the output (OUT)
left by the number of by rotating
bits (N) specified from the bits in the
the 16-bit integer input (IN) left
input (IN). You specify by the
the number of bits number of
through configuration. bits (N)
specified.
l OUT = IN
left
rotated
by N
bits,
circular.
ROL execution diagram:
ROR Provides a 16-bit Used to shift

that is rotated to the output (OUT)
right by the number of by rotating
the 16-bit integer input (IN)
input (IN). You specify right by the
specified.
l OUT = IN
right
rotated
by N
bits,
circular.
ROR execution diagram:
- 908 -
RS Reset - provides a Specifies the

bistable Reset output (Q) of
Dominant flip-flop as the flip-flop
defined in the IEC DIS as a function
1131-3 standard. of the input S
(Set), the
input R
(Reset), and
the last state
of Q.
RTRIG Rising-Trigger - sets Provides
the output (OUT) to ON rising edge
following the OFF-to- change
ON transition of the detection,
input (IN) and stays at thereby
ON until the next turning the
execution cycle, at output ON if
which time it returns to an OFF-to-
OFF. ON transition
is detected.
Module determines how the RTRIG block OUT responds as a result of block state transitions
PULSEEXPIRED ON ON

execution.
SEL Provides a 3-input Sets the

selector function, actual output
meaning it selects 1 of (OUT) equal
2 inputs (IN[1] and IN to the value
[2]) depending on the of 1 of 2
separate input G. inputs (IN[1]
or IN[2]),
depending on
the value of a
separate
input (G).
l If G =
OFF,
OUT =
IN1
- 909 -
l If G =
ON, OUT
= IN2
SEL-REAL Provides a 3-input Sets the
selector function, actual output
meaning it selects 1 of (OUT) equal
2 inputs (IN[1] or IN to the value
[2]) depending on the of 1 of 2
separate input (G). inputs (IN[1]
or IN[2]),
depending on
the value of a
separate
input (G).
l If G =
OFF,
OUT =
IN1
l If G =
ON, OUT
= IN2
SHL Provides a 16-bit Used to shift
that is shifted to the output (OUT)
left by the number of by shifting
the 16-bit integer input (IN) left
input (IN). You specify by the
the number of bits (N) number of
specified.
l OUT = IN
left
shifted
by N
bits,
zero
filled on
right.
SHL execution diagram:
SHR Provides a 16-bit Used to shift

that is shifted to the output (OUT)
right by the number of by shifting
the 16-bit integer input (IN)
input (IN). You specify right by the
specified.
- 910 -
l OUT = IN
right
shifted
by N
bits,
zero
filled on
left.
SHR execution diagram:
SR Provides a bistable Set Specifies the

Dominant flip-flop as output (Q) of
defined in the IEC DIS the flip-flop
1131-3 standard. as a function
of the input S
(set), the
input R
(Reset), and
the last state
of Q.
STARTSIGNAL Supports handling of Supports an
restarts within Control enumeratio
Modules (CM). Can be n-valued
used within any CM to summary
provide better control parameter
over how the module named
initializes in response RESTART.
to events such as Cold The normal
or Warm restart. value for the
RESTART
Provides 7 read-only parameter is
parameters that can NONE.
be accessed to drive Following a
initialization actions. transition, it
Each parameter has shows a
“pulse” characteristics, value other
so it normally holds a than NONE
value which indicates until the end
that no initialization is of the first
required. When a block
transition occurs execution.
appropriate The possible
parameters acquire an enumeration
informative value. This values for
value lasts until the RESTART are
end of the first block as follows:
execution, which
follows the transition. NONE(0)
After first execution,
the parameter is reset CMLOAD (1)
to a value which CMACTIVE (3)
indicates that no
restart has occurred CEECOLD (4)
- 911 -
since the last CEEWARM

execution. A (5)
STARTSIGNAL
instance must always CEESWITCH
be configured so that (6)
its ORDERINCM The
parameter places its CEESWITCH
execution after that of value
any blocks which read indicates that
its parameters. the parent
CM in a
C200/C200E
Controller is
executing for
the first time
following a
redundancy
switchover.
Since 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,
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. CMLOA
D
2. CMACT
IVE
3. CEECO
LD
4. CEEWA
RM
- 912 -
5. CEESW
ITCH
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
Note that there is no implied priority or mutual exclusivity holds True
among the flag parameters described here. For example, for the first
if a CEE starts in idle, has a control module loaded, is execution
activated, and then CEE is warm started, the first cycle
execution of the CM parameters CMLOADFL, following a
CMACTIVEFL, CEEWARMFL, AND ANYRESTARTFL will be load of the
True. Parameters CEECOLDFL and CEESWITCHFL will be parent CM.
False. Parameter RESTART will have the value CMLOAD.
CMACTIVEFL This
parameter
holds True
for the first
execution
cycle
following
inactivation
and then
activation of
the parent
CM.
CEECOLDFL This
parameter
holds True
for the first
execution
cycle
following cold
start of the
CEE.
CEEWARMFL This
parameter
holds True
for the first
execution
- 913 -
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 l An Off to
(change detect) On or
function block. The On to
input (IN) and output Off
(OUT) types must be transitio
type BOOLEAN. n of the
IN sets
the OUT
to On
and it
stays On
until the
next
executio
n cycle
when it
returns
to Off.
l The IN is
assume
d to start
at the
- 914 -
Off
stage
when
the
function
block is
first
turned
On.
Module determines how the TRIG block OUT responds as a result of block state transitions such
PULSEEXPIRED ON ON

execution.
WATCHDOG Monitors other system Used to

functions or remote monitor other
devices and sets the system
output (OUT) to ON if functions or
the monitored function remote
or device fails to devices.
communicate.
l Monitor
Example: Applications ed
like TotalPlant Batch function
uses the Watchdog or
item to determine the device
communication must set
between TotalPlant IN
Batch server (TPB) and paramet
Experion controllers. er to ON
within a
Watchdog also specified
provides a Watch dog time
protocol in Experion, interval
which is simple (DELAYT
set/reset protocol. The IME),
application such as otherwis
TPB server sets the e it is
Watch dog by writing assume
one to the watchdog d to
item. The Experion have
controller accessed failed
through the data and
server is referred as output
TPB Phase Data (OUT) is
Interface on Experion set to
.It is expected to reset ON.
the watchdog to zero
- 915 -
when a non-zero value l If output

is detected. Therefore, (OUT) is
when you reset the ON, it is
watch dog values, TPB reset to
server can detect the OFF as
presence of a healthy soon as
controller. However, IN is set
the controller can to ON.
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- Turns digital
input XOR algorithm, output (OUT):
meaning it performs
the exclusive OR l OFF
function. when
even
OUT = IN[1] XOR IN[2] number
XOR IN[3] … XOR IN[n] of inputs
(2, 4, 6,
Each input (IN[1], IN or 8) are
[2], …, IN[8]) has the ON.
capability of being
optionally inverted, if l ON
required. when
odd
number
of inputs
(1, 3, 5,
or 7) are
ON.
This action
adheres to
the IEC DIS
- 916 -
1131-3
standard.
But, this may
not be the
expected
behavior for
an XOR with
more than
two inputs.
l Parameters-Logic Functions Blocks
27.1.1 Parameters-Logic Functions Blocks

the named logic function block.
- 917 -
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).
l Supports up to 32 change detected Boolean inputs.
l Supports output of captured inputs to downstream blocks to prevent consumption of
inconsistent data during CM execution.
l Supports a cascade output that allows operation of multiple CHGEXEC instances to be
coordinated.
l Supports a slow, periodic, background execution for convenience in strategy design.
l 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 27.1 CHGEXEC block graphical representation in control drawing
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.
- 918 -
When you Then, take this into consideration

use
CHGEXEC
to
Optimize CHGEXEC receives a set of Boolean inputs and identifies if and when they
Control change. If any input has changed since the last execution cycle, the CM
Module containing the CHGEXEC block runs to completion in normal fashion. If none of
performance the inputs have changed, the CM exits immediately after the CHGEXEC block
when used completes, leaving the subsequent blocks within the CM unexecuted for that
exclusively cycle to optimize performance.
for logic
computation.
Create Using CHGEXEC to create CM logic strategies that execute most of their logic by
Control exception, reduces the average processing power consumed by the strategy.
Module logic
strategies to Be sure you are fully aware of the advantages, disadvantages and constraints of
execute most designing control strategies that execute by exception. You are responsible for
of their logic identifying and resolving any design issues with your given strategy.
by exception.
Vary the When ordinary CMs are scheduled to run continuously, it is relatively easy to
control judge the controller processing load and risk of CEE cycle overruns. In contrast,
module's the processing load for a CM using a CHGEXEC block can vary greatly depending
processing on whether the input state has changed since the last execution cycle or not.
load.
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.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.
- 919 -
Risk What does it mean

Factor
Qualified You can only use the block types listed in the following section within the context of
Block Types change driven execution.
Consistent Do not use logic gates to directly access input data that is monitored for change.
Input Data Read data from the output pins on the CHGEXEC block instead.
Variability Execution load of a change-driven strategy varies tremendously depending on

of whether or not an input change has occurred. The statistical rate of input changes
Execution impacts the average CPU consumed by the controller. Bursts of input changes
Load 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 Most change driven configurations only work with single CHGEXEC defined within
CHGEXEC the parent CM. The only exception would be when two CHGEXEC blocks are placed
blocks in in the same CM to expand the number of change detected inputs. See the
same Cascading within a CM Example section for more information.
Control
Module
Increased Using a CHGEXEC block within a logic strategy always adds processing weight to
Processing the CM. The execution of the CHGEXEC block itself and the data flow processing of
Weight 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.
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.
- 920 -
Block Type Qualified Comment

For 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
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.
- 921 -

For Use
With
CHGEXEC
MIN Yes
MINPULSE Yes See comment above for the MAXPULSE block type.
MUX Yes
MUXREAL Yes
MVOTE Yes
NAND Yes
NE Yes
NOON Yes See comment above for the MAXPULSE block type.
NOR Yes
NOT Yes
OFFDELAY Yes See comment above for the MAXPULSE block type.
ONDELAY Yes See comment above for the MAXPULSE block type.
OR Yes
PULSE Yes See comment above for the MAXPULSE block type.
QOR Yes
ROL Yes
ROR Yes
RS Yes
RTRIG Yes See comment above for the DELAY block type.
SEL Yes
SELREAL Yes
SHL Yes
SHR Yes
SR Yes
STARTSIGNAL Yes
TRIG Yes See comment above for the DELAY block type.
WATCHDOG Yes See comment above for the MAXPULSE block type.
XOR Yes
Utility Library
FLAG Yes
FLAGARRAY Yes
MESSAGE Yes
NUMERIC Yes
- 922 -

For Use
With
CHGEXEC
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.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 SIM-C300 Simulator 50 milliseconds Yes

Controller
C200E Embedded SIM-C200E Simulator 50 milliseconds Yes

Controller
C200 Embedded -------- 5 milliseconds No1

Controller
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.
l When the CM is loaded to the CEE the load fails.
- 923 -
Controller Simulator CEE Base Cycle CHGEXEC

Supported
l The returned error message is “Component block type reference error”, error number
101.2013.
1 TheC200 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.
- 924 -
27.7 CHGEXEC Main Parameter Details

The following table identifies the main configuration parameters associated with a CHGEXEC block
and defines their function.
If Then, Its Function Is . . .

Parameter
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 An indexed parameter of type Boolean holding the value of the input array, DATA
[1..32 ] [ ], 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”).
l CHGEXEC behavior when EXITOPT is configured as EXITONEQU is as
follows.
l 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.
l EXITOPT == EXITONEQU corresponds to the majority use case for
CHGEXEC and is the default configuration.
l CHGEXEC behavior when EXITOPT is configured as CONTONEQU is as

follows.
- 925 -
If Then, Its Function Is . . .

Parameter
Is . . .
l 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
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.
l 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.
- 926 -
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 27.1 Control Modules With Cascaded CHGEXEC Instances
l Graphical Examples of Cascaded CHGEXEC control charts

l Cascaded CHGEXEC functional considerations
- 927 -
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 27.2 Primary Control Module in Cascaded CHGEXEC (CM_CHGEXEC_PRI)
Table 27.2 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.
- 928 -
Consideration Description
Coordinated A CHGEXEC cascade crossing CM boundaries would probably involve
Logic 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 of block execution must be deliberately assigned for any CM strategy,
Order 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 When a change-driven logic strategy is split across CMs, execution order of
Execution Order the CMs must still be deliberately assigned. ORDERINCEE would be set up so
that secondary followed primary as shown in the Control Module figures
above.
EXITOPT For cascades between CMs, EXITOPT is set to EXITONEQU for both the
Setting primary CHGEXEC and the secondary CHGEXEC. This is shown in the Control
Module figures above.
TRIGGER with In cascaded CHGEXEC strategies, multiple secondaries can follow a single
Multiple primary with all consuming the primary's TRIGGER output. In this case, each
Secondaries of the secondary CHGEXEC's would be triggered to run to completion by a
change in the primary's TRIGGER parameter.
Secondary Be careful when building CHGEXEC cascades across CMs. In some strategies,
Control Module it may save time to have the secondary CM connect to outputs from the
Output primary CM without first passing those values through the secondary's
Connections CHGEXEC. This should work as long as:
l the primary and secondary execute with the same PERIOD and PHASE
and
l no I/O or peer data is used without passing it explicitly through the
secondary's CHGEXEC.
Strategy defects can arise from using I/O or peer data which is not
guaranteed to have the same value as that which triggered the change
execution. See the Importance of Using Consistent Input Data section for
more information
Cascades that Be careful when using CHGEXEC cascades that cross CEE boundaries. In
Cross CEE general, if a CHGEXEC pulls the TRIGGER parameter from a CHGEXEC in a
Boundaries 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.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.
- 929 -
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 27.3 Cascaded CHGEXEC Within Single Control Module
l EXITOPT considerations for cascaded CHGEXEC in single CM
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.
l The leading CHGEXEC must have EXITOPT = CONTONEQU.
l The following CHGEXEC must receive the TRIGGER output of the leading CHGEXEC as an
input.
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.
- 930 -
l 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.
l 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.
l 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.
l Wrong input data example

l Correct input data example
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 27.4 Wrong Use Of CHGEXEC: Downstream Logic Pulls Change Data Directly
27.10.2 Correct input data example

Based on the previous example, the proper configuration would be one which pulled the
- 931 -
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 27.5 Correct Use Of CHGEXEC: Downstream Logic Pulls From CHGEXEC Output
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 ).
l 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.
l When TESTOPT == EXECALL, there is no auto-trigger processing since the CM executes to
completion once every cycle.
l Auto Trigger application support

l ATUOPERIOD sets period for Auto Trigger
l TRIGGER output and Auto Trigger execution
l Relationship between Auto Trigger and AUTOPHASE for synchronization prevention
l AUTOPERIOD configuration restrictions
27.11.1 Auto Trigger application support

The CHGEXEC blocks support of auto-trigger meets the following two needs in applications
- 932 -
scenarios.
Application Auto Trigger Support

Need
Human In some cases, logic control strategies are designed to process not only IO inputs
Input and Boolean inputs from other strategies, but Boolean commands from human
Commands 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 Periodic auto-trigger does not provide a reliable time tick for blocks whose
On Time Out execution is gated by a CHGEXEC. Timing blocks such as MAXPULSE and
Delays ONDELAY use an internal clock as their time base rather than relying on the
periodicity of their own execution. However, CHGEXEC support for auto-trigger
does put an upper limit on how much time can pass after a time out has expired
and before the block reacts. Timing logic blocks listed as qualified in section
Blocks Qualified for Use with CHGEXEC Block can be used within change driven
strategies as long as a time out response on the order of seconds is sufficiently
fast.
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.
l 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.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.
l 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.
- 933 -
l 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.
l 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.
l 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.
l CHGEXEC.AUTPERIOD greater than CM.PERIOD
l 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 C200/C200E, C300

Supported
0.50 Not Not Supported C200/C200E, C300,

Supported Supported ACE
1.00 Not Not Supported C200/C200E, C300,

Supported Supported ACE
Greater Than or Equal Not Not Not C200/C200E, C300,

2.00 Supported Supported Supported ACE
l 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.
l 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.
- 934 -
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.
l Execution Segment 1: Blocks ordered to execute ahead of the CHGEXEC.
l 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.
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
l 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.
l The TRIGGER toggles whenever the parent CM is allowed to run to completion.
Consequently, it toggles at least once whenever a state change occurs.
- 935 -
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 Parent CM Unchanged Unchanged Changes On first cycle

until inputs until set state on CM and
See Note 1 are pulled equal to first cycle of children
on first DATA[ ] on execution. start
cycle of first cycle of Changes executing.
execution. execution. state again CHGEXEC
on second overrides
cycle of change
execution. detection to
allow CM to
See Note 4 run to
completion
regardless
of whether
or not DATA[
] has
changed.
Inactivation of Parent CM Unchanged Unchanged Unchanged CM and all

children
stop
executing.
CEE Execution Start Unchanged Unchanged Changes On first cycle

until inputs until set state on CM and
See Note 2 are pulled equal to first cycle of children
See Note 5 on first DATA[ ] on execution. start
cycle of first cycle of executing.
execution. execution. See Note 4 CHGEXEC
overrides
change
detection to
allow CM to
run to
completion
regardless
of whether
or not DATA[
] has
changed.
CEE Execution Stop Unchanged Unchanged Unchanged CM and all

children
stop
executing.
- 936 -

[]
Redundancy Role Change Unchanged Unchanged Unchanged CM and
until inputs until set unless children run
See Note 3 are pulled equal to DATA[ ] has to
on first DATA[ ] on changed completion
cycle of first cycle of since last or exit early
execution. execution. execution based on
before role normal
change. operation of
CHGEXEC.
CHGEXEC
does not
override
change
detection.
Note:
1. Activation of Parent CM consists
of the following transition.
l EXECSTATE changes from
Inactive to Active on
parent CM when
CEESTATE is Run.
2. CEE Execution Start can be any

of the following transitions.
l Cold Restart changes
CEESTATE from Idle to
Run when EXECSTATE of
parent CM is Active.
l Warm Restart changes
l RAM Retention Restart
when CEESTATE is Run
and EXECSTATE of parent
CM is Active.
3. CEE Execution Start can be any

of the following transitions.
l Cold Restart changes
l Warm Restart changes
l RAM Retention Restart
when CEESTATE is Run
and EXECSTATE of parent
CM is Active.
- 937 -

[]
4. In the case of transition
Activation of Parent CM, the
TRIGGER parameter emits a full
pulse (both the positive going
edge and the negative going
edge) over the course of the
first two execution cycles. This
is to insure that for any
cascaded CHGEXECs in
different CMs, the downstream
(secondary) CM is guaranteed
to execute at least once when
the upstream (primary) CM
executes. Since the state of
LASTDATA[ i] in the
downstream CM could be On or
Off the TRIGGER must emit
both edges.
In the case of transition CEE
Execute Start, forcing both
edges is not necessary. Each
CHGEXEC within the CEE will
allow its parent CM to run to
completion as a result of the
CEE-wide state transition.
5. If CHGEXEC is used heavily
within a CEE it is possible for
cycle overruns to occur as a
result of CEE Execute Start
transitions (Cold Restart, Warm
Restart or RAM Retention
Restart). These transitions force
all CHGEXEC CMs to run to
completion during the first
execution of each CEE cycle.
After all cycles have executed
no more overruns will occur
within a properly balanced CEE
configuration. CEE will not
report any alarms as a result of
startup transition overruns.
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.
- 938 -
l EXITOPT
l NUMDATA
l AUTOPERIOD
l AUTOPHASE
l 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).
l DATA[ ]
l LASTDATA[ ]
l TRIGGER
l CHGINDEX
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.
l CPUCYCLEAVG (CEE block)
l CPUCYCLEMAX (CEE block)
l CPUFREEAVG (CEE block or Platform block)
l CPUFREEMIN (CEE block or Platform block)
l CRCYCLEORN (CEE block)
l LSCYCLEORN (CEE block)
l 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.
l CRCYCLEORN[40]
l CPUCYCLEAVG[40]
l 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.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.
- 939 -
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.
17 This completes the procedure.
27.17 Examples and scenarios
l CheckBool functionality
l CheckBool scenario 1
27.17.1 CheckBool functionality

The CHECKBOOL block evaluates its input connections and passes these input values through to
- 940 -
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 27.3 Sample CHECKBOOL Strategy linking Control Modules in Project Mode
Table 27.4 Viewing Sample CHECKBOOL Strategy Linking Control Modules in Monitoring Mode
- 941 -
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.
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
- 942 -
when an INSTS is “BAD”. Once the Bad Input Detection Threshold Time has elapsed, the output
values will track those of the input.

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

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.18 Contact Monitoring (CONTACTMON) Block
l Function-CONTACTMON block
l Predecessor Block-CONTACTMON block
l Execution-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:
l 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
- 944 -
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 BADPVALM. However, if you are migrating from
pre-R410 to later releases, refer to Impact of migration on alarm attributes.
l 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
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
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
- 945 -
PVFL STATE0 STATE1 NORMAL Alarm Generated

X X X None No
- 946 -
CHAPTER
28 MATH FUNCTIONS
l Math Function Blocks
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:
l If a NaN input is encountered when calculating, the result (and the output) shall be NaN.
l Disconnected inputs have a default value of zero (with the exception of multiply where the
input(s) default is one).
l 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.
l Available Math blocks and size

l Math blocks functional description
l Rolling Average block-CONTACTMON block
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 Function Approximate Size in Bytes

Library
Name
ABS Absolute value 50
ADD Sum of n arguments 110
DIV Division 60
EXP e to the power of x 50
- 947 -
Chapter 28 - Math Functions
Block Function Approximate Size in Bytes

Library
Name
LN Natural logarithm of a 50
number (log to the
base of e)
LOG Base 10 logarithm of a 50

number
MOD (x MOD y) 60
MUL Product of n 110

arguments
NEG -(x) 50
POW (x^y) 60
ROUND Rounded up to nearest 50

integer value
SQRT square root 50
SUB Subtraction 60
TRUNC Round down to 50

nearest integer value
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.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.
- 948 -
Block Name/ Description Function

Graphic
ABS Provides the At runtime, the
absolute output (OUT)
value becomes the
function. absolute value of
the user
connected input
(IN[1]).
ADD Provides the Sums the value

addition of the number of
function. inputs (IN[1..8])
configured by the
user as the
output (OUT).
DIV Provides the At runtime, the

divide output (OUT)
function. becomes the
quotient of input
1 (IN[1]) divided
by input 2 (IN[2]).
EXP Provides the At runtime, the

exponent output (OUT)
exponent of the
user connected
input (IN[1]).
LN Provides the At runtime, the

natural output (OUT)
logarithm becomes the
function. natural logarithm
of the user
connected input
(IN[1], log to the
base of e).
LOG Provides the At runtime, the

logarithm output (OUT)
base 10
logarithm of the
user connected
input (IN[1]).
MOD Provides the At runtime, the

modulo user connected
function. inputs (IN[1], IN
[2]) are
truncated to
integer and the
output (OUT)
becomes the
- 949 -

Graphic
Remainder of IN
[1] divided by IN
[2].
MUL Provides the At runtime, the

multiply output (OUT)
Product of the
user connected
inputs (IN[1..8]).
NEG Provides the At runtime, the

negative output (OUT)
negative (-)
equivalent of the
user connected
input (IN[1]).
POW Provides the At runtime, the

raise to output (OUT)
power becomes the
function. user connected
input 1 (IN[1])
raised to the
power the user
connected input
2 (IN[2]).
ROUND Provides the At runtime, the

round up output (OUT)
user connected
input (IN[1])
rounded up to
the nearest
integer value.
SQRT Provides the At runtime, the

square root output (OUT)
square root of
the user
connected input
(IN[1]).
SUB Provides the At runtime, the

subtract output (OUT)
user connected
input 1 (IN[1])
minus the user
connected input
2 (IN[2]).
TRUNC Provides the At runtime, the

truncate output (OUT)
- 950 -

Graphic
user connected
input (IN[1])
rounded down to
the nearest
integer value.
ROLLAVG Provides the At runtime, the

rolling output (OUT)
average becomes the
function. 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.
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.
l 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).
l ROLLFRBASE - Unit of time that is associated with the frequency of sample collection. This
could be seconds, minutes, or hours.
- 951 -
o For example if ROLLFREQ is “5”, and ROLLFRBASE is “Seconds” then samples are
collected every 5 seconds.
l ROLLBUF - Defines how long the samples must be collected.

l ROLLBFBASE - Defines the unit of time for the collection buffer (ROLLBUF).
o 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.

l CM Period =5 Secs
l ROLLFREQ =5
l ROLLFRBASE = Sec
l ROLLBUF = 20
l 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:
l CM EXECSTATE transitions from INACTIVE to ACTIVE.
l CEE transitions from IDLE to RUN.
l 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).
- 952 -
l 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.
l 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.
l 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.
parameters.
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:
l 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.
l The number of samples in the sample buffer exceeds its limits (greater than 3800).
l The frequency of sample collection (ROLLFREQ) is lesser than 1 or greater than 3800.
l 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).
l 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).
l 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.
l 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.
parameters.
Memory size for the block
The estimated memory size for the Rolling Average function block is as follows:
l Estimated user memory (RAM) is 112 bytes per instance. (This size is reflected in the block size
information).
l Estimated code size (firmware) is 3100 bytes. (This size is not reflected in the block size
information).
l 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).
- 953 -
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
l The CEE calculates and verifies the memory associated with the block to be within the range
(1 to 3800).
l 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.
Scenarios during which the block does not execute
The Rolling Average function block does note execute in the following scenarios:
l CM Period is “None” and SCALEPERIOD parameter is “NaN.”
l CM BPS parameter is stored as a result of a process special execution and CM Period is a
value other than “None.”
parameters.
- 954 -
CHAPTER
29 POWER GENERATION FUNCTIONS
l POWERGEN Function Blocks

l GRPCAPRBK (Group Capability and Runback) Block
l HTMOTOR (HT Motor Drive Control) Block
l LEVELCOMP (Drum Level Computation) Block
l LTMOTOR (LT Motor Drive Control) Block
l MAINIBV (IBV Logic) Block
l SOLENOID (Solenoid Valve Drive Control) Block
l VALVEDAMPER (Valve/Damper Drive Control) Block
29.1 POWERGEN Function Blocks

Power Generation function blocks provide a variety of configurable functions for supporting
control strategies designed for power plant applications
configuration of the 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 GRPCAPRBK (Group Used to define associated equipment
Master Control Capability and capability including alarms and ROC limit
scheme Runback) Block output.
Support HT motor HTMOTOR (HT Motor Used to define inputs and interlocks for
drive control Drive Control) Block conventional HTMOTOR drive.
requirements
Support drum level LEVELCOMP (Drum Used to compute drum level from measured
computation Level Computation) differential pressure and other field specific
Block constants.
Support LT motor LTMOTOR (LT Motor Used to define inputs and interlocks for
drive control Drive Control) Block conventional LTMOTOR drive.
requirements
Provide Integral MAINIBV (IBV Logic) Used to define configurable timing logic for
Block the main valve.
- 955 -
Chapter 29 - Power Generation Functions

Bypass Valve (IBV)
logic
Support solenoid valve SOLENOID (Solenoid Used to define inputs and interlocks for
drive control Valve Drive Control) conventional solenoid valve drive control.
requirements Block
Support valve/damper VALVEDAMPER Used to define configurable operation

control requirements (Valve/Damper Drive requirements for valve/damper control.
Control) Block
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.
- 956 -
Tab
Main l Name: Block (Tag) name of up to 16 characters long. Must be unique
l Execution Order in CM (ORDERINCM): Specifies the execution order of
a number between 1 and 32767. The default value is 10.
l Description (DESC): Block descriptor of up to 132 characters long.
l Engineering Units (EUDESC): Lets you specify a text string of up to 16
characters to identify the variable values associated with this block.
l 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.
l 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.
l 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.
l Alarms -Lets you specify the priority and severity for following alarms.
l 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.
l 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.
l 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.
l 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.
- 957 -
Tab
Defining
l Function-GRPCAPRBK block
l Configuration examples-GRPCAPRBK block
l Inputs-GRPCAPRBK block
l Outputs-GRPCAPRBK block
l Error handling-GRPCAPRBK block
l GRPCAPRBK parameters
29.2.1 Function-GRPCAPRBK block
l This block provides the capability for a group of same type of equipments depending upon the
equipment status.
l This block provides the Group Capability and Group Runback Rate for the configured number
of equipments.
l The block accepts configurable number of equipments' input status and desired unit load set
point.
l The block provides a configurable parameter NUMBEROFEQP which represents the number of
equipments used for input connection to the block.
l The block enables the user to configure equipment OFF state Capability Value (OFFCAP) and
ON state Capability Value (ONCAP) for individual equipment.
l 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.
l 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:
l Auxcalc - (Most often used) - OUTCAP and ROCLM to P1
l Signalsel - (Often used) - OUTCAP and ROCLM to P1
- 958 -
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.
l 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:
l DigAcq (PVFL) or Digital Inpits - For DI
l Blocks from Regctl suite (AUTOMAN - Uses OP) for LOADSP
Predecessor Block
The input IN of this block can be from any block with digital output. The input LOADSP of this block
can be from any Regulation Control block like AUTOMAN, SWITCH or RATIOBIAS.
Successor Block
The outputs OUTCAP and ROCLM of this block can be connected to any block with analog input (for
example, LOGIC:MIN). The output RUNBKACTFL of this block can be connected to any block with
digital input (for example, LOGIC:OR).
- 959 -
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
l LOADSP - Load Set point

l DI[1..10]
29.2.4 Outputs-GRPCAPRBK block
l OUTCAP - Output capability

l RUNBKACTFL - Runback control flag
l ROCLM - Current ROC Limit
l SAFEOPTRIGFL- Safe output triggered
29.2.5 Error handling-GRPCAPRBK block
l 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.
l This block supports the invalid index check and Access level checks for all parameters specific
to the block.
- 960 -
l On CM inactivation or CEE state IDLE, all output values are set to default values.
l If LOADSP status is BAD , then:
o 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.
o The RUNBKACTFL is set to FALSE.
l If all the DISTS of the Configured Number of Equipment are BAD, then:
o ROCLM is retained at the last value if ROCLMOPT= LASTVAL is selected. If ROCLMOPT
= SAFEVAL, the user selected value is substituted for ROCLM.
o The RUNBKACTFL is set to FALSE.
o OUTCAP is retained at the last value if CAPVALOPT = LASTVAL is selected. If
ROCLMOPT = SAFEVAL, the user selected value is substituted for OUTCAP.
l 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.
l OFFCAP[], ONCAP[] and RBROCLM parameters are not allowed to be changed/edited when the
CM is active.
l 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
l 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.
l 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:
- 961 -
The following diagram illustrates the START logic flow for an HT Motor block.
The following diagram illustrates the STOP logic flow for an HT Motor block.
- 962 -
The following diagram illustrates the TRIP logic flow for an HT Motor block.
- 963 -
Each HT Motor Control 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 that tab
- 964 -
Tab
default selection is ALL.
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 l 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.
l 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.
l 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.
l 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.
l 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.
l 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.
l 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
- 965 -
Tab
is OFF (unchecked). Operator cannot bypass override interlocks to change
OP.
Maintenance l 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.
l 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.
l Maint. stats. reset flag (RESETFL) - An operator, a user program or
anytime.
l No. of safety ovr. trips (NUMSIOVRD)- Accumulated number of safety
interlock trips that result in OP changing state, after the last statistics
reset.
l No. of all PV transitions (NUMALLTRANS) - Accumulated number of
transitions of PV to each state, after the last statistics reset.
l Track State Time (TRKSTATETIME) - When enabled or box checked, you
can track the amount of time the drive is in different states.
l RUNTIME - Accumulated time the drive spends in the RUN
state.
l STOPTIME - Accumulated time the drive spends in the STOP
state.
l TRIPTIME - Accumulated time the drive spends in the STOP
state because of a trip.
SCM l SCM Mode Tracking Opt (MODETRACK) - Lets you select the desired
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.
to take when the SCM is in an abnormal state.
l 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.
l 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.
l The Hold State Option (HOLDOPT) applies when the SCM state
is Holding or Hold. The options are NONE, SAFEOP. The default
selection is NONE.
l 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. The default selection is
NONE.
Alarms The following alarms are configurable to represent disagreements between

the commanded state (OP) and the feedback state (PV).
l Command Disagree (CMDDISALM.FL): This alarm is generated when the
commanded output state (OP) changes and the feedback state (PV) does
- 966 -
Tab
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.
l 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.
l 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.
l 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.
l 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.
l 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
l Priority (CMDDISALM.PR): Lets you select the priority level as NONE,
l 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.
l 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].
l 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
l Priority (CMDFALALM.PR): Lets you select the priority level as NONE,
l Severity (CMDFALALM.SV): Lets you set the relative severity of the alarm
Uncommanded Change - Lets you configure the following parameters for this
alarm.
l Priority (UNCMDALM.PR): Lets you select the priority level as NONE,
l 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.
- 967 -
Tab
Bad PV - Lets you configure the following parameters for this alarm.
l Priority (BADPVALM.PR): Lets you select the priority level as NONE,
l Severity (BADPVALM.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.
Safety Override Alarms - Lets you configure the following parameters for the
safety override interlock alarm.
l Safety Override Interlock (SIALM.FL): This alarm is generated when the
safety override interlock (SI) causes an OP state change.
l Option (SIALM.OPT): Lets you specify whether the safety override
interlock alarm is enabled or not. The default setting is DISABLED.
l Priority (SIALM.PR): Lets you select the priority level as NONE, JOURNAL,
LOW, HIGH, or URGENT. The default setting is LOW.
l 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.
l Option (OIALM[0].OPT): Lets you specify whether the STOP override
l Priority (OIALM[0].PR): Lets you select the priority level as NONE,
l Severity (OIALM[0].SV): Lets you set the relative severity of the alarm on a
l 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.
l Option (OIALM[1].OPT): Lets you specify whether the RUN override
Equipment safety alarm- Lets you configure parameters for the following
alarms.
Motor trip alarm: Lets you configure the following parameters for this alarm
l Option (MOTORTRIPALM.OPT): Lets you specify whether the motor trip is
enabled or not. The default setting is ENABLE.
l Priority (MOTORTRIPALM.PR): Lets you select the priority level as NONE,
l 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
- 968 -
Tab
Lockout Relay Reset alarm: Lets you configure the following parameters for
this alarm.
l Option (LRRALM.OPT): Lets you specify whether the lockout relay reset
alarm is enabled or not. The default setting is ENABLE.
l Priority (LRRALM.PR): Lets you select the priority level as NONE,
l 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
Winding Temperature Trip alarm: Lets you configure the following parameters
for this alarm.
l Option (WDGTEMPALM.OPT): Lets you specify whether the winding
temperature trip alarm is enabled or not. The default setting is ENABLE.
l Priority (WDGTEMPALM.PR): Lets you select the priority level as NONE,
l 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.
l Option (BRNGTEMPALM.OPT): Lets you specify whether the bearing
temperature trip alarm is enabled or not. The default setting is ENABLE.
l Priority (BRNGTEMPALM.PR): Lets you select the priority level as NONE,
l 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
Vibration Trip alarm: Lets you configure the following parameters for this
alarm.
l Option (VIBRALM.OPT): Lets you specify whether the vibration trip alarm
is enabled or not. The default setting is ENABLE.
l Priority (VIBRALM.PR): Lets you select the priority level as NONE,
l 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
l 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.
l Priority (OFFNRMALM.PR): Lets you select the priority level as NONE,
l Severity (OFFNRMALM.SV): Lets you set the relative severity of the alarm
- 969 -
Tab
0.
Defining
l Function-HTMOTOR block
l Configuration examples-HTMOTOR block
l Inputs-HTMOTOR block
l Outputs-HTMOTOR block
l Error handling-HTMOTOR block
l States-HTMOTOR block
l State parameters and descriptors-HTMOTOR block
l Mode and mode attribute-HTMOTOR block
l Safe output state-HTMOTOR block
l Command dependency on switches and Mode attribute-HTMOTOR block
l Local manual-HTMOTOR block
l Permissive interlocks-HTMOTOR block
l Safety Override Interlock-HTMOTOR block
l Override Interlocks-HTMOTOR block
l Configurable Override/Permissive Interlock Bypass-HTMOTOR block
l Alarms-HTMOTOR block
l Seal-in option-HTMOTOR block
l FIRSTUP functionality-HTMOTOR block
l Initialization Manual condition-HTMOTOR block
l OP initialization option-HTMOTOR block
l Initialization Manual condition with Safety Override Interlock, Override Interlocks, LocalMan,
and OP initialization-HTMOTOR block
l Initialization with pulse output-HTMOTOR block
l Initialization request flags-HTMOTOR block
l OP and DO initialization after load-HTMOTOR block
- 970 -
l Maintenance statistics-HTMOTOR block

l Output requests-HTMOTOR block
l Output command-HTMOTOR block
l Logic override OPREQ-HTMOTOR block
l Monitoring HT Motor Current
l HTMOTOR parameters
29.3.1 Function-HTMOTOR block
l The HT Motor Control block has two inputs, two states, and two outputs.
l Provides PV Source Selection; PV has 2 basic states such as RUN and STOP plus an additional
BAD state.
l Provides latched and pulsed outputs.
l Provides Initialization, Local Manual and Redtagging.
l Provides BADPV, Command Disagree, Equipment Safety, Uncommanded Change, Command
Fail, and Interlock trip alarms.
l Provides PV change of state event.
l Provides Permissive and Override Interlocks for each state.
l Provides Seal In option.
l Provides predefined Safe State.
l Provides generic state parameters defined as consistent data types.
l Provides initialization with OPFINAL based configuration.
l Provides Boolean command option.
l Provides Batch level 1 driver option.
l Provides OFF Normal alarm associated with requested OP.
l Provides First out detection mechanism to detect the input that acted first to cause the motor to
trip.
l 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.
l 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 Blocksection 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:
- 971 -
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:
- 972 -
- 973 -
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
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.
- 974 -
Scenario 2
Safety, Override, and Permissive logic and MCC Inputs.
- 975 -
Callout Description
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
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
Equipment trips and UCP Start/Stop logic and MCC Inputs.
- 976 -
- 977 -
- 978 -
Callout Description
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.
- 979 -
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 DOCHANNEL (Digital Output Channel) block.
l An output to any connection except to a DOCHANNEL block is a Boolean output only.
l 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.
l DOC.SO can be connected to the latched outputs like CmdRun and CmdStop.
l DOC.ONPULSE can be connected to pulsed outputs PORun and POStop.
l DOC.OFFPULSE can be connected to pulsed outputs PORun and POStop.
l 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.
l You can configure an individual PULSEWIDTH for each PO*. The setting range is between
l 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.
l 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.
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
l LOCALSTART can be initiated only when ‘Other FB’ access lock, Operator mode and
Local/Remote selection switch is at LOCAL.
l AUTOSTART can be initiated only when access lock in not ‘Other FB’ and local/remote switch is
at REMOTE.
l SEQSTART can be initiated only when the mode is at PROGRAM.
l UCPSTART can be initiated only when access lock is not OtherFB and UCP RELEASE is
available.
- 980 -
l RUNTIME, STARTTIME, TRIPTIME accept a value between 0 and 96000.

l TRKTRIPTIME, TRKRUNTIME, TRKSTOPTIME requires Engineer Access lock.
l For the HT Motor FB, if both feedback status is ON and OFF, a fault status is flagged and output
generation is not processed.
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.
l State parameters
l PV
l PVAUTO
l OP
l OPFINAL
l Generic State parameters
l GPV (generic version of PV)
l GPVAUTO (generic version of PVAUTO)
l GOP (generic version of OP)
l GOPFINAL (generic version of OPFINAL)
The State parameters are an enumeration with an assigned text name, which tracks the names
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:
l NULL - Stands for Bad Value.
l INBET - Represents an in between state and could be designated MOVPV for moving PV.
l 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.
l SAFE - Stands for SAFEOP. If an external FB issues a Safe command to GOP, the internal value
l S0 -Represents settable output State 0 (STOP).
l S1 - Represents settable output State 1 (RUN).
- 981 -

the members of the generic state enumerations. This allows the various State parameters to have
labels unique to each state. The following table lists the default name for a given STATETEXT[0..6]
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
MANual.
l 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:
o OPERATOR = only the operator can command the output state.
o PROGRAM = only other function blocks (such as Logic blocks, SCM programs) can
assumed.
l 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.
l 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
- 982 -
HT MOTOR Local\Remote Switch ModeAttribute

ConsoleStart REMOTE OPER
LocalStop LOCAL
UCPStop
AutoStop REMOTE PROG
SeqStop REMOTE PROG
ConsoleStop OPER
Ignore
Check
29.3.11 Local manual-HTMOTOR block

HAND/OFF/AUTO (also called HAND/OFF/REMOTE) switch on the field device. You can hard wire
the AUTO position of the switch to a digital input. The state of the digital input can be stored to the
LOCALMAN pin added to the HT Motor block through a DICHANNEL connection. The control
system cannot have control over the field device when the HAND/OFF/AUTO switch is not in AUTO
position, the LOCALMAN parameter provides feedback of the switch position.
PV is in a non-settable state, OP is set to STOP. This ensures that the last commanded state agrees
with the current value of the feedback state, when the LOCALMAN is turned OFF. You cannot
directly command the OP (GOP) if LOCALMAN is ON.
You cannot access LOCALMAN, if the HT Motor block has no inputs or no outputs connected. PV is
illegal for no inputs and OP is illegal for no outputs, and therefore LOCALMAN has no meaning for
these conditions.
When LOCALMAN is ON, the OP and OPFINAL follow PV (if it is in a settable state). The digital
outputs CmdRun/Stop will follow OPFINAL.
ATTENTION
LOCALMAN can be used, when the LT Motor commands are commanded by Local, and
controlled directly from the MCC and not from the DCS.
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.
must be set to ON.
- 983 -
29.3.13 Safety Override Interlock-HTMOTOR block

State (STOP) when active. OP cannot be commanded to a different state when SI is active.
l SI may be connected to other blocks or may be directly set by an operator if the MODEATTR
l SI is defaulted to OFF, it must be set to ON to force OP to go to STOP.
l When SI turns OFF, OP = STOP is maintained until changed by:
o the operator
o a user program
29.3.14 Override Interlocks-HTMOTOR block

l Override Interlocks may be connected to other block outputs or may be directly set by an
OFF.
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
parameter BYPASS.
l BKTBYPASS bypasses OI and PIs when BKT is ON. It is independent of BYPERM.
29.3.16 Alarms-HTMOTOR block

Commanded Output State (OP) and the Current Active State (PV). A Safety Override Interlock alarm
- 984 -
l Command Fail alarm - generated when the Current Active State (PV) fails to change from an
commanded.
the Alarms tab on HT Motor block configuration form. The value of OP just
commanded determines which CMDFALALM.TM[0..1] is active. The CMDFALALM.TM
[0..1] setting range is 0 to 1000 seconds. Setting a given CMDFALALM.TM[0..1]
parameter to 0 disables the alarm for the associated state[0..1]. The alarm function is
ATTENTION
l The CMDFALALM.TM[0..1] cannot be configured if CMDDISALM.TM[0..1] has not
been configured.
l The CMDFALALM.TM[0..1] setting must be less than the CMDDISALM.TM[0..1]
setting for the same state[0..1].
l Bad PV alarm - generated whenever the Current Active State (PV) is detected to be a NULL (or
bad) state.
l Command Disagree alarm - generated when the Commanded Output State (OP) is changed
o The feedback time (CMDDISALM.TM[0..1) for each state has to be configured on the
Alarms tab on HT MOTOR block configuration form. The value of OP just commanded
determines which CMDDISALM.TM[0..1] is active. The CMDDISALM.TM[0..1] setting
range is 0 to 1000 seconds. Setting a given CMDDISALM.TM[0..1] parameter to 0
disables the alarm for the associated state[0..1]. The alarm function is automatically
disabled, if there are no inputs or no outputs. CMDDISALM.TM[0..1] changes from or
to 0, require CM InActive or CEE Idle.
o This alarm condition returns to NORMAL when the input PV state becomes equal to
the OP state.
l Uncommanded Change alarm - generated if the actual input state (PV) changes but has not
Command Disagree alarm is configured.
the commanded OP state.
l Off Normal alarm - This alarm is generated whenever PV does not match OPREQ, if OPREQ is
not Null.
l Override Interlock alarms - When the alarm is enabled and the active interlock causes an OP
state change, an alarm is generated.
l 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
- 985 -
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.
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

Outputs cannot be commanded when INITMAN is TRUE.
l 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.
l This is a structure containing the INITREQ status and the DOC.SO current value.
[i].STATUS is TRUE.
29.3.20 OP initialization option-HTMOTOR block

l 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.
l 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
- 986 -
works. When the INITMAN parameter transitions from ON to OFF, the HT Motor FB provides an
l If the Safety Interlock is active, the OP is set to STOP
l If any of the Override Interlocks are active and not bypassed, the OP is set to the highest
priority Override Interlock
l 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
l If OP Initialization is configured as HOLDOPOPT, OP remains on the last value
l If OP Initialization is configured as SAFEOPOPT, OP is set to STOP
l 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)
l 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:
l When PV is good, OP and OPFinal are initialized to PV, no pulse is generated.
l 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.
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:
- 987 -
l NUMTRANS[0,1] - Number of transitions of PV to each state. This can be enabled provided

TRKNUMTRANS is enabled.
l NUMALLTRANS - Number of all PV transitions. This can be enabled provided TRKNUMTRANS is
enabled.
l 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.
(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
There is no direct access to OPREQ when MODEATTR is PROGRAM. It can be changed as part of a
control request from SCM. When MODEATTR is OPERATOR, an operator can change OPREQ, but
this does not block a control request. This means a program store to OPREQ cannot be rejected,
and no error is returned. The FB retains the stored value until it is overwritten, except in certain
non-stored cases when the level 1 drivers are active. OPREQ acts like a repeated attempt to store
to OP. The OPREQ is always active unless it is Null. This means the OPREQ continues to attempt
stores even if attributes, such as interlocks, become active and block changes to OP. Thus, once
the attributes blocking change to OP have reset OPREQ stores the commanded state 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).
l 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).
l 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.
l 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
- 988 -
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
l UCP START/STOP, SEQ START/STOP, LOCAL START/STOP work on OFF to ON
transitions. So, there is no priority for them.
l AUTO START/STOP work on priority as per SAFEOP which is STOP since they are
latched.
l LOCAL START/STOP, UCP START/STOP commands change the MODEATTR to
Operator.
l AUTO START/STOP, SEQ START/STOP, UCP START, CONSOLE START depends on
REMOTESWITCH which should be ON.
l 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.
l UCP STOP and CONSOLE STOP ignore the switches for its operation.
l 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.
l Restarting the motor is possible without resetting FIRSTUPACTED. An Auto reset of
the FIRSTUPACTED on restarting the motor can be achieved though Engineering
solution.
l 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.
l 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
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.
29.3.30 HTMOTOR parameters

the Drive Control block.
- 989 -
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:
l h: Drum level to be measured
l H: Length of stand pipe.
l DP: Differential pressure of the drum
l ρ Ref: Density of water in wet leg (This computation uses the Water Leg temperature)
l ρ S: Density of steam
l ρ 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.
- 990 -
Tab
reports.
l Process Value Hi Range (PVEUHI) - Lets you specify the high input range
value in engineering units that represents 100% full scale PV input for
l 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.
l 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.
l DP Slope (DPSLOPE) - Defines the slope to be applied to DP parameter.
Default value =1.
l DP Bias (DPBIAS) - Defines the bias to be applied to the DP parameter.
Default value = 0.
l Pressure Slope (PRSLOPE) - Defines the slope component of Modified
Drum Pressure. Default value = 0.
l Pressure Bias (PRBIAS) - Defines the bias component of Modified Drum
Pressure. Default value =1
l 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.
l 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
default value is 0.
l DP Engineering Unit Selection - Lets you select the DP Engineering Unit
l Pressure Engineering Unit Selection (DPENGUNIT) - Lets you
select the Absolute Pressure Engineering Unit
l Engineering Unit Selection for Temperature (PRENGUNIT) -
Lets you select the Engineering Unit Selection for Temperature
l Temperature Engineering Unit Selection - Allows the user to
configure the temperature's engineering unit.
l PV Engineering Unit Selection (PVENGUNIT) - Allows the user to

configure the Pressure Signal's Engineering Unit.
- 991 -
Tab
Defining
l Function-LEVELCOMP block
l Inputs-LEVELCOMP block
l Outputs-LEVELCOMP block
l Error handling-LEVELCOMP block
l LEVELCOMP parameters
29.4.1 Function-LEVELCOMP block
l The Drum Level Computation function block computes the drum level from the measured DP,
Pressure and other field specific constants.
l The block has an algorithm for generating steam and water density from the given pressure
input as long as the pressure input is good.
l The Level Status (PV) becomes bad when one of the input's status becomes bad and PV is not
be computed
l 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.
- 992 -
Predecessor Block
l Block 1: Channel Block
The channel blocks bring in analog channels such as DP and pressure to the Drum level
Computation.
l Block 2: DACA Block
This block is required as the transmitter selection block does not have alarm capability.
l Block 3: Transmitter Selection Block
The signals involved - Pressure and DP, employs dual/triple redundant configuration. Therefore
this block supports “median value selection.”
l Block 4: Drum level computation block
This block eventually computes the drum level.

l Block5: DACA
This block is optional for exclusive alarms and ranging.
Successor Block
The output of the Drum Level Computation block has a direct connectivity to a DACA block.
- 993 -
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
l DP - Differential Pressure of the drum

l PRESSURE - Pressure input parameter.
29.4.3 Outputs-LEVELCOMP block
l PV - Drum level.
l PVP - Drum level in %
l DENSTEAM - Density of steam in drum
l DENWATER - Density of water in drum
l DENWATERREF - Density of WETLEG water
29.4.4 Error handling-LEVELCOMP block
l 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.
l 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).
l The PRESSURE and DP parameters do not accept negative values.
l If PVSTS is bad, PV is not computed and assigned with a NaN.
l If the inputs go to NaN, PV is not calculated and assigned with a NaN.
- 994 -
l 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.
l 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

the Drum Level Computation block.
29.5 LTMOTOR (LT Motor Drive Control) Block

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.
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 given name of the “Tab” in the parameter configuration form and then briefly
describes the attributes associated with that Tab.
- 995 -
Tab
l 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
Output l 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.
l OP Initialization Option (INITOPOPT)- Lets you specify the state to which
NORMALOPT, HOLDOPT and SAFEOPOPT. By default, the option is
NORMALOPT.
Selections are DISABLE and ENABLE. If ENABLE, the field output
destinations are set to SAFEOP but OP is not altered.
l 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.
parameter.

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 are not collected.
- 996 -
Tab
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.
l Maint. stats. reset flag (RESETFL) - An operator, a user program or
anytime.
l No. of safety ovr. Trips (NUMSIOVRD) - Accumulated number of safety
reset.
l (Total number of statet transitions (NUMTRANS) - The accumulated
number of transitions to the reference state since the last reset of
Maintenance Statistics.
l 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.
l RUNTIME - Accumulated time the drive spends in the RUN
state.
l STOPTIME - Accumulated time the drive spends in the STOP
state.
l TRIPTIME - Accumulated time the drive spends in the STOP
state because of a trip.
l Abnormal State Options - Lets you specify the action the function block
should take when the SCM is in an abnormal state.
selection is NONE.
NONE.
Alarms The following alarms are configurable to represent disagreements between

the commanded state (OP) and the feedback state (PV).
OP state.
feedback time after the OP- state
997 -is commanded. For slow responding
Tab
0..
Defining
l Function-LTMOTOR block
l Configuration examples-LTMOTOR block
l Inputs-LTMOTOR block
l Outputs-LTMOTOR block
l Error handling-LTMOTOR block
l States-LTMOTOR block
l State parameters and descriptors-LTMOTOR block
l Mode and mode attribute-LTMOTOR block
l Safe output state-LTMOTOR block
l Command dependency on switches and mode attribute-LTMOTOR block
l Local manual-LTMOTOR block
l Permissive interlocks-LTMOTOR block
l Safety Override Interlock-LTMOTOR block
l Override Interlocks-LTMOTOR block
l Configurable Override/Permissive Interlock Bypass-LTMOTOR block
l Alarms-LTMOTOR block
l Seal-in option-LTMOTOR block
l Initialization Manual condition-LTMOTOR block
l OP initialization option-LTMOTOR block
l Initialization Manual condition with Safety Override Interlock, Override Interlocks, LocalMan,
and OP initialization-LTMOTOR block
l Initialization with pulse output-LTMOTOR block
l Initialization request flags-LTMOTOR block
- 998 -
l OP and DO initialization after load-LTMOTOR block

l Maintenance statistics-LTMOTOR block
l Output requests-LTMOTOR block
l Output command-LTMOTOR block
l LTMOTOR parameters
29.5.1 Function-LTMOTOR block
l The LT Motor function block has two inputs, two states, and two outputs.
l Allows PV source selection (PVSRC) as RUN, STOP or faulty (BAD) state.
l Provides BADPV, Command Disagree, Equipment Safety, Uncommanded Change, Command
Fail, and interlock trip alarms.
l Provides PV Change of state event.
l Provides Seal In option.
l Enables the Safety Interlock to enforce the defined safe state.
l Provides an explicitly configured Safe State.
l Provides generic State parameters defined as consistent data types.
l Provides Initialization with OPFINAL based configuration.
l Provides Boolean Command option.
l Provides batch level 1 driver option.
l Provides OFF Normal Alarm associated with requested OP.
l 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 Taggingsection 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 DO or further connected to subsequent logic, if necessary.
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.
- 999 -
- 1000 -
- 1001 -
- 1002 -
Callout Description
DICHANNEL block to the LT Motor block.
In the LT Motor block, the MCC inputs (MTR, MTS) provide the feedback that the
Use the PV parameter connection to carry MCC trip input (MTT) from the DICHANNEL
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
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
Scenario 2
Safety, Override and permissive inputs and MCC inputs.
- 1003 -
- 1004 -
- 1005 -
Callout Description
(SI, OI[0], PI[1]) from the DICHANNEL block to the LT Motor.
Scenario 3
UCP Start/Stop logic and MCC Inputs.
- 1006 -
- 1007 -
Callout Description
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
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 DOCHANNEL (Digital Output Channel) block.
l An output to any connection except a DOCHANNEL block is a Boolean output only.
l 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.
l DOC.SO can be connected to the latched outputs like CmdRun and CmdStop.
l DOC.ONPULSE can be connected to pulsed outputs PORun and POStop.
l DOC.OFFPULSE can be connected to pulsed outputs PORun and POStop.
l 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.
l Each PO* can be configured with an individual PULSEWIDTH. The setting range is between
l 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
- 1008 -
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.
l 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.
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
l LOCALSTART can be initiated only when access lock is ‘Other FB’, mode is Operator and
Local/Remote selection switch is at local.
l AUTOSTART can be initiated only when access lock in not ‘Other FB’ and local/remote switch is
at remote.
l SEQSTART can be initiated only when the mode is at Program.
l UCPSTART can be initiated only when access lock is not OtherFB and UCP RELEASE is
available.
l RUNTIME, STARTTIME, TRIPTIME do not accept a value less than 0 or more than 96000.
l TRKTRIPTIME, TRKRUNTIME, TRKSTOPTIME requires Engineer Access lock.
l 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
state of the LT Motor.
the field device to the associated state, such as RUN or STOP. The OP parameter represents the
monitors the PV, and produces alarms based on the state assignment configurations, which
29.5.7 State parameters and descriptors-LTMOTOR block

The block includes the following set of parameters for state associations.
l State parameters
l PV
l PVAUTO
l OP
l OPFINAL
- 1009 -

The Generic State parameters are consistent data types, which can be compared with each other
l 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.
l S0 -Represents settable output State 0 (STOP).

l S1 - Represents settable output State 1 (RUN).


STATETEXT[3] Safe(STOP) Safe
STATETEXT[4] STOP S0
STATETEXT[5] RUN S1
29.5.8 Mode and mode attribute-LTMOTOR block
MANual.
l 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:
- 1010 -

assumed.
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
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 AUTO position of the switch to a digital input. You can then have the state of the digital input
stored to the LOCALMAN pin added to the LT Motor block through a DICHANNEL connection. The
control system cannot have control over the field device when the HAND/OFF/AUTO switch is not
in the AUTO position, the LOCALMAN parameter provides feedback of the switch position.
PV is in a non-settable state, OP is set to STOP. This ensures that the last commanded state agrees
with the current value of the feedback state, when the LOCALMAN is turned OFF. You cannot
directly command the OP (GOP) while the LOCALMAN is ON.
The LOCALMAN cannot be accessed, if the LT Motor block has no inputs or no outputs connected.
PV is illegal for no inputs and OP is illegal for no outputs, and therefore LOCALMAN has no
meaning for these conditions.
- 1011 -
outputs CmdRun/Stop follows OPFINAL.
ATTENTION
LOCALMAN can be used, when the LT Motor commands are commanded by Local, and
controlled directly from the MCC and not from the DCS.
29.5.12 Permissive interlocks-LTMOTOR block

PI[0..1]are Permissive Interlocks which are inputs that can be connected to an external function
commanded output (OP) of the LT Motor block to a specific state. Permissive Interlocks themselves
never cause OP to change.
must be set to ON.
29.5.13 Safety Override Interlock-LTMOTOR block

State (STOP) when active. OP cannot be commanded to a different state when SI is active.
l SI can be connected to other blocks or can be directly set by an operator if the MODEATTR
l SI is defaulted to OFF, it must be set to ON to force OP to go to STOP.
l When SI turns OFF, OP = STOP is maintained until changed by:
o the operator
o a user program
29.5.14 Override Interlocks-LTMOTOR block

l Override Interlocks can be connected to other block outputs or can be directly set by an
OFF.
Interlocks are determined by the state assigned to predefined SAFEOP that is STOP and the
priority is SI, OI[0], OI[1].
- 1012 -
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
parameter BYPASS.
29.5.16 Alarms-LTMOTOR block

An available set of PV state alarms can be configured to represent disagreements between the
l Command Fail alarm - generated when the Current Active State (PV) fails to change from an
commanded.
the Alarms tab on LT Motor block configuration form. The value of OP just
ATTENTION
been configured.
l Bad PV alarm - generated whenever the Current Active State (PV) is detected to be a NULL (or
bad) state.
l Command Disagree alarm - generated when the Commanded Output State (OP) is changed
o You can configure the feedback time (CMDDISALM.TM[0..1) for each state through
the Alarms tab on LT MOTOR block configuration form. The value of OP just
commanded determines which CMDDISALM.TM[0..1] is active. The CMDDISALM.TM
[0..1] setting range is 0 to 1000 seconds. Setting a given CMDDISALM.TM[0..1]
automatically disabled, if there are no inputs or no outputs. CMDDISALM.TM[0..1]
the OP state.
l Uncommanded Change alarm - generated if the actual input state (PV) changes but has not
- 1013 -
o Off Normal alarm - This alarm is generated whenever PV does not match OPREQ, if
OPREQ is not Null.
l Override Interlock alarms - When the alarm is enabled and the active interlock causes an OP
state change, an alarm is generated.
l Safety Override Interlock alarm - When the alarm is enabled and the active interlock causes an
OP state change, an alarm is generated.
state and related alarm notification) always occurs regardless of effects of the other alarm.
29.5.17 Seal-in option-LTMOTOR block

destinations are set to the Safe Output State (STOP), but OP is not altered. You can observe
OPFINAL to determine what state was actually commanded to the output destinations. The
OPFINAL is displayed in reverse video while monitoring Control Builder if it differs from OP.
OPFINAL is set equal to OP on the next store to OP, which clears the “seal” condition.
ATTENTION
configured.
29.5.18 Initialization Manual condition-LTMOTOR block

l INITDOWN[1..2] - This is an input which may be connected to the DOC INITREQ output. When
29.5.19 OP initialization option-LTMOTOR block

- 1014 -

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:
l If the Safety Interlock is active, the OP is set to STOP;
l If any of the Override Interlocks are active and not bypassed, the OP is set to the highest
priority Override Interlock;
l 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;
l If OP Initialization is configured as HOLDOPOPT, OP remains on the last value;
l If OP Initialization is configured as SAFEOPOPT, OP is set to STOP;
l 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)
l 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:
l When PV is good, OP and OPFinal are initialized to PV, no pulse is generated.
l 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 indicates that the block cannot be
- 1015 -
29.5.23 OP and DO initialization after load-LTMOTOR block

feature is 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.
l 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.
(after the last statistics reset). This can be enabled provided TRKSIOVRD is enabled.
LT MOTOR block anytime irrespective of Redtagging, unlike the DEVCTL block.
29.5.25 Output requests-LTMOTOR block

Whenever an external FB attempts to change the commanded state OP, the LT MOTOR block uses
store to OP. The OPREQ is always active unless it is Null. This means the OPREQ continues to
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).
l 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).
l Similarly, you can command the LT Motor block through LOCAL START/STOP, UCP
- 1016 -
START/STOP provided the following conditions are met:

o Both LOCAL and UCP commands ignore MODEATTR
o LOCAL START/STOP depends on the LOCAL SWITCH which should be ON.
o UCP STOP ignores the LOCAL/REMOTE SWITCH condition.
o UCP START depends on REMOTE SWITCH which should be ON.
l Similarly, you can command the LT Motor block through Console START/STOP provided the
following conditions are met:
o MODEATTR should be OPER
o Console STOP ignores LOCAL REMOTE SWITCH condition.
o 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 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 LT Motor can also be commanded by SCM through SEQ START/STOP when SCM option is
FIXED and MODEATTR is PROGRAM.
ATTENTION
l UCP START/STOP, SEQ START/STOP, LOCAL START/STOP work on OFF to ON
l AUTO START/STOP work on priority as per SAFEOP which is STOP since they are
latched.
l LOCAL START/STOP, UCP START/STOP commands change the MODEATTR to
Operator.
l AUTO START/STOP, SEQ START/STOP, UCP START, CONSOLE START depends on
REMOTESWITCH which should be ON.
l AUTO START/STOP, SEQ START/STOP is not allowed when BYPASS is ON.
l UCP STOP and CONSOLE STOP ignore switches for its operation.
l 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

- 1017 -
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
the attributes associated with that tab.
- 1018 -
Tab
l 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
l 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.
l 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.
l Open Seq Fail Alarm Priority (OPENSEQALM.PR) - Indicates the relative
l Open Seq Fail Alm Severity (OPENSEQALM.SV) - Indicates the relative
l Close Seq Fail Alm Priority (CLOSESEQALM.PR) - Indicates the relative
l Close Seq Fail Alm Severity (CLOSESEQALM.SV) - Indicates the relative
l BAD PV Alarm Priority (BADPVALM.PR) - Lets you set the desired priority
l BAD PV Alarm Severity (BADPVALM.SV) - Lets you assign a relative
default value is 0.
- 1019 -
Tab
Defining
l Function-MAINIBV block
l Inputs-MAINIBV block
l Outputs-MAINIBV block
l Control logic-MAINIBV block
l Open sequence logic-MAINIBV block
l Close sequence logic-MAINIBV block
l Error handling-MAINIBV block
l MAINIBV parameters
29.6.1 Function-MAINIBV block
l 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.
l Triggers an open sequence failure alarm in case an OPEN command fails to open the Main
valve.
l Triggers a close sequence failure alarm in case a CLOSE command fails to close Main valve.
l Triggers a BADPV alarm in case the IBV open feedback or Main close feedback is in BAD state.
l Commands the Drive Control blocks for further operation of Main and IBV valve.
l 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
l OPENSEQ - Open Sequence command from PROGRAM to the valve system.

l CLOSESEQ - Close Sequence command from PROGRAM to the valve system.
l IBVOPENFDBK - IBV open feed-back switch
l MAINCLOSEFDBK - Main valve close-feedback switch.
29.6.3 Outputs-MAINIBV block
l OPENIBV\CLOSEIBV - Open/Close command to IBV drive control.

l OPENMAIN\CLOSEMAIN - Open/Close command to Main Valve drive control.
- 1020 -
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
l SCM writes directly to OPENSEQ and CLOSESEQ from SCM Expressions.
l 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.)
l Operator can take control of Valve Damper/ Drive/ Dev ctl by changing mode
attribute to operator whenever required for bypassing the MAINIBV.
- 1021 -
29.6.5 Open sequence logic-MAINIBV block

The Open sequence logic is illustrated by the following flow-chart:
29.6.6 Close sequence logic-MAINIBV block

The Close sequence logic is illustrated in the following flow-chart:
- 1022 -
ATTENTION
l 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.
l An Interlock error is displayed if the open cmd is issued when
CLOSEMAINFEEDBACK is OFF.
l 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.
l 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
- 1023 -
l Displays an error for invalid input index while loading or accessing parameters.
l Verifies parameter access level during download and accessing.
l Limits the range of DELAY input for the user. Only a positive value can be entered for DELAY
on the Project and Monitoring side.
l Reports an error during download if the input value for OPENTIMEOUT or CLOSETIMEOUT is
zero on the project side.
29.6.8 MAINIBV parameters

the Main-IBV Logic block.
29.7 SOLENOID (Solenoid Valve Drive Control) Block

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. The states have to be
configured before using the block. There is a single permissive and interlock input for each state.
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.
- 1024 -
Tab
l 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
Output l 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.
l 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.
l 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.
Selections are DISABLED and ENABLED. If ENABLED, the field output
SEALOPT can be enabled only when CMDDISALM.TM[0..1] is configured.

parameter.

or 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.
- 1025 -
Tab
checked, 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.
l 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 RESETFL parameter to reset statistics anytime.
l No. of safety ovr. trips (NUMSIOVRD))- Accumulated number of safety
reset.
l Number of State transitions (NUMTRANS) - Total number of state
transitions.
l No. of all PV transitions (NUMALLTRANS)- Accumulated number of
l (RESETFL) - Lets you reset all maintenance statistics to their default
values.
l Abnormal State Options - Lets you specify the action the function block
should take when the SCM is in an abnormal state.
selection is NONE.
l 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. The default selection is NONE.
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.
OP state. This alarm does not apply for momentary commanded states.
- 1026 -
Tab
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.
l Priority (BADPVALM.PR): Lets you select the priority level as NONE,
l Severity (BADPVALM.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.
alarm.
l 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 disables the alarm. The default setting is 0.
l 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
l Priority (CMDDISALM.PR): Lets you select the priority level as NONE,
l Severity (CMDDISALM.SV): Lets you set the relative severity of the alarm
fail alarm.
l 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
l 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
l Priority (CMDFALALM.PR): Lets you select the priority level as NONE,
l Severity (CMDFALALM.SV): Lets you set the relative severity of the alarm
alarm.
l Priority (UNCMDALM.PR): Lets you select the priority level as NONE,
l Severity (UNCMDALM.SV): Lets you set the relative severity of the alarm
0.

interlock conditions.
l Override Interlock (OIALM[0..1].FL): This alarm is generated when an
- 1027 -
Tab
override interlock (OI[0..1]) occurs, causing an OP state change.
l 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.
Safety Override Alarms - Lets you configure the following parameters for the
safety override interlock alarm
l Safety Override Interlock (SIALM.FL): This alarm is generated when the
safety override interlock (SI) occurs, and causes an OP state change.
l Option (SIALM.OPT): Lets you specify whether the safety override
l Priority (SIALM.PR): Lets you select the priority level as NONE, JOURNAL,
l Severity (SIALM.SV: Lets you set the relative severity of the alarm on a
Close Override Interlock Alarm - Lets you configure the following parameters
for this alarm.
l Option (OIALM[0].OPT): Lets you specify whether the Close override
Open Override Interlock Alarm - Lets you configure the following parameters
for this alarm.
l Option (OIALM[1].OPT): Lets you specify whether the Close override
alarm.
0.
- 1028 -
Tab
Defining
l Function-SOLENOID block
l Configuration examples-SOLENOID block
l Inputs-SOLENOID block
l Outputs-SOLENOID block
l Error handling-SOLENOID block
l States-SOLENOID block
l State parameters and descriptors-SOLENOID block
l Mode and mode attribute-SOLENOID block
l Safe output state-SOLENOID block
l Command dependency on switches and mode attribute-SOLENOID block
l Local manual-SOLENOID block
l Permissive interlocks-SOLENOID block
l Safety Override Interlock-SOLENOID block
l Override Interlocks-SOLENOID block
l Configurable Override/Permissive Interlock Bypass-SOLENOID block
l Alarms-SOLENOID block
l Seal-in option-SOLENOID block
l Initialization Manual condition-SOLENOID block
l OP initialization option-SOLENOID block
and OP Initialization-SOLENOID block
l Initialization request flags-SOLENOID block
l OP and DO initialization after load-SOLENOID block
l Maintenance statistics-SOLENOID block
l Output requests-SOLENOID block
l Output command-SOLENOID block
l SOLENOID parameters
29.7.1 Function-SOLENOID block
l The solenoid valve has two inputs, three states, and one output.
- 1029 -
l Allows PV source selection (PVSRC) as OPEN, CLOSE, INBET or faulty (BAD) state.
l Provides latched outputs.
l Provides BADPV, Command Disagree, SafetyInterlock , Uncommanded Change and Command
Fail, Override Interlock alarms.
l Allows PV change of state event.
l Provides Interlock trip alarms.
l Provides a Seal In option.
l Provides an explicitly configured safe state.
l Provides Initialization with OPFINAL based configuration.
l Provides Boolean command option
l Provides batch level 1 driver option.
l 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 DO or further connected to subsequent logic, if necessary.
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.
- 1030 -
- 1031 -
- 1032 -
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.
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.
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
Scenario 2:
Strategy with Safety, Override and permissive inputs and MCC inputs.
- 1033 -
- 1034 -
Callout Description
In the Solenoid Valve block, the MCC inputs (LTO, LTC) provide the feedback if the
(SI, OI[0], PI[1]) from the DICHANNEL block to the Solenoid Valve block.
Scenario 3:
Strategy with UCP Open/Close logic and MCC inputs.
- 1035 -
- 1036 -
Callout Description
In the Solenoid Valve block, the MCC inputs (LTO, LTC) provide the feedback if the
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.
l Hard Inputs: LTO, LTC, LOCALSWITCH, REMOTESWITCH, LOCALOPEN, LOCALCLOSE,
UCPREL, UCPOPEN, UCPCLOSE, SEQOPEN, SEQCLOSE, AUTOOPEN, AUTOCLOSE
l 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
l LOCALOPEN/LOCALCLOSE can be initiated only when 'Other FB' access lock, Operator mode
and Local/Remote selection switch is in local.
l AUTOOPEN/AUTOCLOSE can be initiated only when access lock in not 'Other FB' and
- 1037 -
local/remote switch is at remote.

l SEQOPEN/SEQCLOSE can be initiated only when the mode is in 'Program.'
l UCPOPEN/UCPCLOSE can be initiated only when access lock is not 'Other FB' and UCP release
is available.
l 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.
l 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
state of the Solenoid valve.
the field device to the associated state, such as OPEN or CLOSE. The OP parameter represents the
monitors the PV, and produces alarms based on the state assignment configurations, which
29.7.7 State parameters and descriptors-SOLENOID block

l State parameters
l PV
l PVAUTO
l OP
l OPFINAL
The State parameters are an enumeration with an assigned text name, which tracks the
names assigned to STATETEXT[0..6] parameter for use by an operator.
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:
l 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.
- 1038 -

l S0 -Represents settable output State 0 (CLOSE).
l S1 - Represents settable output State 1 (OPEN).
l S2 - Represents settable output State 2 .

labels unique to each state. The following table lists the default Solenoid name for a given
STATETEXT[0..6] and shows the corresponding generic states enumeration.
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
MANual.
l 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:
assumed.
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.
- 1039 -
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
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 AUTO position of the switch to a digital input. You can then have the state of the digital input
stored to the LOCALMAN pin added to the Solenoid Valve block through a DICHANNEL connection.
The control system cannot have control over the field device if the HAND/OFF/AUTO switch is not
in the AUTO position, the LOCALMAN parameter provides feedback of the switch position.
PV is in a non-settable state, OP is set to SAFEOP. This ensures that the last commanded state
agrees with the current value of the feedback state, when the LOCALMAN is turned OFF. You
cannot directly command the OP (GOP) while the LOCALMAN is ON.
You cannot access LOCALMAN, if the Solenoid Valve block does not have any inputs/outputs
connected. PV is illegal for no inputs and OP is illegal for no outputs, and therefore LOCALMAN
has no meaning for these conditions.
outputs CmdOpen/CmdClose will follow OPFINAL.
ATTENTION
LOCALMAN can be used for the above purpose, when the Solenoid Valve Commands are
Commanded by Local, controlled directly from MCC and not through DCS.
- 1040 -
29.7.12 Permissive interlocks-SOLENOID block

commanded output (OP) of the Solenoid Valve block to a specific state. Permissive Interlocks
themselves never cause OP to change.
l To change OP to the desired state, the corresponding Permissive Interlock parameter must be
set to ON.
l 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.
29.7.13 Safety Override Interlock-SOLENOID block

State (SAFEOP) when active. OP cannot be commanded to a different state when SI is active.
l SI may be connected to other blocks or can be directly set by an operator if the MODEATTR
l SI is OFF by default in case of Solenoid, it must be set to ON to force OP to go to SAFEOP.
l When SI turns OFF, OP = SAFEOP is maintained until changed by:
o the operator
o a user program
29.7.14 Override Interlocks-SOLENOID block

respective state regardless of the condition of the Permissive Interlocks. OP cannot be commanded
to a different state when an Override Interlock is active.
l 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.
Interlocks are determined by the state assigned to configurable SAFEOP:
o If SAFEOP is SO, the priority is SI, OI[0], OI[1].
o 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 parameter BYPPERM must be set to ON. The operator can then set or reset the
parameter BYPASS.
- 1041 -
l When BYPASS is ON, OP can be changed regardless of the state of the Override and
Permissive Interlocks.
l When BYPPERM is OFF, BYPASS is OFF by default in case of Solenoid and is read-only.
29.7.16 Alarms-SOLENOID block

l 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.
o 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
ATTENTION
been configured.
l Bad PV alarm - It is generated whenever the Current Active State (PV) is detected to be a NULL
(or bad) state.
l 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.
o 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
automatically disabled, if there are no inputs or no outputs. CMDDISALM.TM[0..1]
the OP state.
l 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
not Null.
- 1042 -
l Override Interlock alarms - When the alarm is enabled and the active override interlock causes
an OP state change, an alarm is generated.
l 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

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.
ATTENTION
configured.
29.7.18 Initialization Manual condition-SOLENOID block

l INITDOWN[1..2] - This is an input which can be connected to the DOC INITREQ output. When
29.7.19 OP initialization option-SOLENOID block

NORMALOPT, SAFEOPOPT or HOLDOPOPT. The default value for Solenoid is NORMALOPT.
- 1043 -

Override Interlocks, LocalMan, and OP Initialization-
SOLENOID block
l If the Safety Interlock is active, the OP is set to SAFEOP;
l 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;
l Otherwise, if OP Initialization is configured as HOLDOPOPT, OP remains on the last value;
l Otherwise, if OP Initialization is configured as SAFEOPOPT, OP is set to SafeOP;
configured, the stored OP value tracks the PV state if the PV state is settable ( CLOSE, OPEN);
l Otherwise, OP value is back-initialized from the output connections
l 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
29.7.22 OP and DO initialization after load-SOLENOID block

feature is 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.
- 1044 -

l NUMTRANS - Number of all PV transitions. This can be enabled provided TRKNUMTRANS is
enabled.
l NUMSIOVRD - accumulated number of safety interlock trips, which results in OP changing
state (after the last statistics reset). This can be enabled provided TRKSIOVRD is enabled.
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 request mechanism. The OP request (OPREQ/GOPREQ) differs from direct access an
store to OP. The OPREQ is always active unless it is NULL. This means the OPREQ continues to
29.7.25 Output command-SOLENOID block

OPEN/CLOSE, UCP OPEN/CLOSE, LOCAL OPEN/CLOSE, SEQ OPEN/CLOSE).
the given Boolean input command (AUTO OPEN/CLOSE, SEQ OPEN/CLOSE).
l Similarly, you can command the Solenoid Valve block through LOCAL OPEN/CLOSE, UCP
OPEN/CLOSE provided the following conditions are met:
o LOCAL OPEN/CLOSE depends on the LOCAL SWITCH which should be ON.
o UCP CLOSE ignores the LOCAL/REMOTE SWITCH condition provided SAFEOP is
configured to CLOSE.
o UCP OPEN ignores the LOCAL/REMOTE SWITCH condition provided SAFEOP is
configured to OPEN.
l Similarly, you can command the Solenoid Valve block through Console OPEN/CLOSE provided
the following conditions are met:
o Console CLOSE ignores the LOCAL/REMOTE SWITCH condition provided SAFEOP is
configured to CLOSE.
o Console OPEN ignores the LOCAL/REMOTE SWITCH condition provided SAFEOP is
configured to OPEN.
- 1045 -
If an SCM commands the Solenoid Valve block by sending a Null type of request to GOP and there
are active OPCMDs such as AUTO OPEN/CLOSE, UCP OPEN/CLOSE, LOCAL OPEN/CLOSE. (this
is possible when SCMOPT = NONE, MODEATTR = Program, and SCM OPTYPE = NULL), the OPCMD
has higher priority. An SCM store to GOP is rejected; if any of the OPCMD elements are active (one
or more OPCMD members are ON). An SCM can gain control, only when all OPCMD elements are
OFF.
The Solenoid Valve can also be commanded by SCM through SEQ OPEN/CLOSE when SCM
option is FIXED and MODEATTR is PROGRAM.
ATTENTION
l UCP OPEN/CLOSE, SEQ OPEN/CLOSE, LOCAL OPEN/CLOSE work on OFF to ON
l AUTO OPEN/CLOSE works on priority as per SAFEOP which is CLOSE since they are
latched.
l LOCAL OPEN/CLOSE, UCP OPEN/CLOSE commands change the MODEATTR to
Operator.
l AUTO OPEN/CLOSE, SEQ OPEN/CLOSE depends on REMOTESWITCH which
should be ON.
l AUTO OPEN/CLOSE, SEQ OPEN/CLOSE is not allowed when BYPASS is ON.
l 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.
l 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

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.
- 1046 -
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.
- 1047 -
Tab
l 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 l Init OP After Load (INITOPAFTLD) - Initialization values for OP and

CmdOpen\CmdClose after load. The selections are DEFAULT,
NOCOMMAND, OPEN, CLOSE.
l OP Initialization Option (INITOPOPT) - Lets you specify the state to which
NORMALOPT, HOLDOPT and SAFEOPOPT. . By default, the option is
NORMALOPT.
Selections are DISABLE and ENABLE. If ENABLE, the field output
l 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.
parameter.
l Torque Switch used for Tight-shutoff (TSENABLED) - When ON, the Close
Command cutoff is governed by TSC.
l Use Torque Switch for Protection (TSFORPROT) - When ON, the TSO and
TSC signals are used as protection for Open and Close commands
respectively.
- 1048 -
Tab
or 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
checked, 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.
l 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 RESETFL parameter to reset statistics anytime.
l No. of safety ovr. trips (NUMSIOVRD)- Accumulated number of safety
reset.
l Number of Transitions (NUMTRANS[0 -2]) - Accumulated time of PV in
each state, after the last statistics reset.
l Track Open Feedback Time (TRKOPENFEEDBKTIME) - When ON, the time
taken to receive Open feedback after the Open command is issued is
recorded.
l Track Close Feedback Time (TRKCLOSEFEEDBKTIME) - When ON, the
time taken to receive Close feedback after the Close command is issued is
recorded.
l Open Feedback Time (OPENFEEDBKTIME) - The time taken in seconds to
receive Open feedback after the Open command is issued.
l Close Feedback Time (CLOSEFEEDBKTIME) - The time taken to receive
Close feedback after the Close command is issued.
to take when the SCM is in an abnormal state.
selection is NONE.
NONE.
Alarms PV Alarming - The following alarms are configurable to represent
- 1049 -
Tab
disagreements between the commanded state (OP) and the feedback state
(PV). These alarms are disabled if there are no inputs or outputs.
l Command Disagree (CMDDISALM.FL) - This alarm is generated when the
OP state. This alarm does not apply for momentary commanded states.
l Command Fail (CMDFALALM.FL) - This alarm checks to see if the PV state
l Bad PV (BADPVALM.FL): This alarm is generated whenever both
feedbacks are ON.

interlock conditions.
l Safety Override Interlock (SIALM.FL) - This alarm may be generated
when the safety override interlock (SI) occurs, and has caused an OP
state change.
l 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
alarm.
l 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 the alarm. The default setting is 0.
l 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.
l Priority (CMDFALALM.PR): Lets you select the priority level of the
Command disagree alarm as NONE, JOURNAL, LOW, HIGH, or URGENT.
The default setting is LOW.
l Severity (CMDFALALM.SV): Lets you set the relative severity of the
Command disagree alarm on a scale of 0 to 15. Where 15 is the most
severe. The default setting is 0.
fail alarm.
l 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
- 1050 -
Tab
for CMDDISALM.TM [1].
l 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.
l 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.
l 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.
alarm.
l Priority (UNCMDALM.PR) - Lets you select the priority level as NONE,
l Severity (UNCMDALM.SV) - Lets you set the relative severity of the alarm
0.
Bad PV - Lets you configure the following parameters for this alarm.
l Priority (BADPVALM.PR) - Lets you select the priority level as NONE,
l Severity (BADPVALM.SV) - Lets you set the relative severity of the alarm
0.
Override Alarms - Lets you configure the following parameters for the safety
override interlock alarm.
l Option (SIALM.OPT) - Lets you specify whether the safety override
l Priority (SIALM.PR) - Lets you select the priority level as NONE, JOURNAL,
l Severity (SIALM.SV): Lets you set the relative severity of the alarm on a
NOCOMMAND Override Interlock Alarm - Lets you configure the following

l Option (OIALM[0].OPT): Lets you specify whether the NOCOMMAND
DISABLED.
OPEN Override Interlock Alarm - Lets you configure the following parameters
for this alarm.
l Option (OIALM[1].OPT): Lets you specify whether the OPEN override
- 1051 -
Tab
CLOSE Override Interlock Alarm - Lets you configure the following parameters
for this alarm.
l Option (OIALM[2].OPT): Lets you specify whether the CLOSE override
alarm.
0.
Torque Switch Open Alarm - Lets you configure the following parameters for
this alarm.
l Option (TSOALM.OPT): Lets you specify whether the OPEN override
l Priority (TSOALM.PR): Lets you select the priority level as NONE,
l 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.
l Option (TSCALM.OPT): Lets you specify whether the OPEN override
l Priority (TSCALM.PR): Lets you select the priority level as NONE,
l Severity (TSCALM.SV): Lets you set the relative severity of the alarm on a
Equipment safety alarm - Lets you configure the following alarms:

l Motor Trip alarm: Lets you configure the following parameters for the
alarm.
l Option (MOTORTRIPALM.OPT): Lets you specify whether the
motor trip alarm is enabled or not. The default setting is
DISABLED.
l Priority (MOTORTRIPALM.PR): Lets you select the priority level
as NONE, JOURNAL, LOW, HIGH, or URGENT. The default
setting is LOW.
l Severity (MOTORTRIPALM.SV): Lets you set the relative severity
- 1052 -
Tab
of the motor trip alarm on a scale of 0 to 15. Where 15 is the
l Winding Temperature Switch alarm: Lets you configure the following

parameters for the alarm.
l Option (WTSALM.OPT): Lets you specify whether the winding
temperature switch alarm is enabled or not. The default setting
is ENABLED.
l Priority (WTSALM.PR): Lets you select the priority level as
is LOW.
l 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. The default setting is 0.
Defining
l Function-VALVEDAMPER block
l Configuration examples-VALVEDAMPER block
l Inputs-VALVEDAMPER block
l Outputs-VALVEDAMPER block
l Limit Switches-VALVEDAMPER block
l Error handling-VALVEDAMPER block
l States-VALVEDAMPER block
l State parameters and descriptors-VALVEDAMPER block
l Mode and mode attribute-VALVEDAMPER block
l Safe output state-VALVEDAMPER block
l Command dependency on switches and Mode attribute-VALVEDAMPER block
l Local manual-VALVEDAMPER block
l Permissive interlocks-VALVEDAMPER block
l Safety Override Interlock-VALVEDAMPER block
l Override Interlocks-VALVEDAMPER block
l Configurable Override/Permissive Interlock Bypass-VALVEDAMPER block
- 1053 -
l Alarms-VALVEDAMPER block
l Seal-in option-VALVEDAMPER block
l Initialization Manual condition-VALVEDAMPER block
l OP initialization option-VALVEDAMPER block
and OP Initialization-VALVEDAMPER block
l Initialization request flags-VALVEDAMPER block
l OP and DO initialization after load-VALVEDAMPER block
l Maintenance statistics-VALVEDAMPER block
l Output requests-VALVEDAMPER block
l Output command-VALVEDAMPER block
l Logic override OPREQ-VALVEDAMPER block
l VALVEDAMPER parameters
29.8.1 Function-VALVEDAMPER block
l The Valve/Damper block has four inputs, three states, and two outputs.
l Allows PV source selection (PVSRC) as OPEN, CLOSE, INBET or faulty (BAD) state.
l Provides BADPV, Command Disagree, SafetyInterlock, Uncommanded Change and Command
Fail, Override Interlock alarms.
l Provides PV change of state event.
l Provides interlock trip alarms.
l Provides a seal-in option.
l Provides a Safety Interlock that enforces the defined safe state.
l Predefines Safe State as NoCommand.
l Initialization has OPFINAL based configuration.
l Provides Boolean command option.
l Provides batch level one driver option.
l Provides OFF NORMAL alarm associated with requested OP.
l Provides alarm when Torque switch Open or Torque switch Close are detected
l 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.
- 1054 -
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.
- 1055 -
- 1056 -
Callout Description
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.
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.
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
Scenario 2:
with safety, override and permissive inputs and MCC inputs.
- 1057 -
- 1058 -
Callout Description
(SI, OI[0], PI[1]) from the DICHANNEL block to the Valve/Damper block.
Scenario 3:
with UCP Open/Close logic and MCC inputs.
- 1059 -
- 1060 -
Callout Description
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.
l Hard Inputs: MTT, LTO, LTC, TSO, TSC, WTS, LOCALSWITCH, REMOTESWITCH, LOCALOPEN,
LOCALCLOSE, UCPREL, UCPOPEN, UCPCLOSE, SEQOPEN, SEQCLOSE, SEQNOCOMMAND
AUTOOPEN, AUTOCLOSE, AUTONOCOMMAND
l 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
- 1061 -
[0,1,2], NUMALLTRANS, NUMSIOVRD, OPENFEEDBKTIME, CLOSEFEEDBKTIME
29.8.5 Limit Switches-VALVEDAMPER block

The following are some of the behavior of Limit switches:
l The LTO switch feedback is used to withdraw the OPEN command irrespective of TSEnabled.
l An OPEN command cannot be issued if LTO is already ON.
l 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.
l 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.
l 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.
l If TSForProt is OFF and TSO acted, the OPEN command is not withdrawn.
l When TSForProt is ON and TSC is also ON, you cannot issue CLOSE command.
l If TSEnabled is OFF, the LTC feedback is used to withdraw the CLOSE command.
l If TSEnabled is ON, the TSC feedback in place of the LTC feedback is used to withdraw the
CLOSE command.
l 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.
l A CLOSE command cannot be issued if LTC is ON and TSEnabled is OFF.
l A CLOSE command cannot also be issued if TSC and TSEnabled are ON.
l If TSEnabled or TSForProt are ON and TSC is ON, you cannot issue a CLOSE command.
l 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).
l 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
l LOCALOPEN/LOCALCLOSE can be initiated only when access lock is ‘Other FB’, Operator
mode and Local/Remote selection switch is LOCAL.
l AUTOOPEN/AUTOCLOSE can be initiated only when access lock in not ‘Other FB’ and
local/remote switch is in REMOTE.
l SEQOPEN/SEQCLOSE can be initiated only when the mode is in PROGRAM.
l UCPOPEN/UCPCLOSE can be initiated only when access lock is not Other FB and UCP release
is available.
l OPENFEEDBKTIME, CLOSEFEEDBKTIME does not accept a value less than 0 or more than
96000.
l TRKOPENFEEDBKTIME, TRKCLOSEFEEDBKTIME requires AppDev Access lock.
l For Valve/Damper, both OFF status are valid state (In-between). oth ON is flagged and output is
not generated.
- 1062 -
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.
the field device to the associated state, such as OPEN, CLOSE, or NOCOMMAND. The OP
parameter represents the commanded state or the device state commanded by an operator. The
block transmits OP, monitors PV, and produces alarms based on the state assignment
configurations, which represent whether or not the process feedback has achieved the state
commanded in OP.
29.8.8 State parameters and descriptors-VALVEDAMPER block

l State parameters
l PV
l PVAUTO
l OP
l OPFINAL
l Generic state parameters
assigned to STATETEXT[0..6] parameter for an operator's use.
The generic state parameters are consistent data types, which can be compared with each other
l Active - Refers to momentary state settings for a two-state device.
l 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.
l S0 -Represents settable output State 0 (NOCOMMAND).
l S1 - Represents settable output State 1 (OPEN).
l S2 - Represents settable output State 2 (CLOSE)

and shows the corresponding generic state enumeration.
- 1063 -

STATETEXT[3] Safe(NOCOMMAND) Safe
STATETEXT[5] OPEN S1
STATETEXT[6] CLOSE S2
29.8.9 Mode and mode attribute-VALVEDAMPER block
MANual.
l 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:
assumed.
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.
l 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
- 1064 -
ValveDamper Local\Remote Switch ModeAttribute

UCPClose REMOTE
AutoClose REMOTE PROG
SeqClose REMOTE PROG
ConsoleClose REMOTE OPER
Ignore
Check
29.8.12 Local manual-VALVEDAMPER block

HAND/OFF/AUTO (also called HAND/OFF/REMOTE) switch on the field device. The AUTO position
of the switch can be hard wired to a digital input. The state of the digital input can then be
configured to store to the LOCALMAN pin added to the Valve/Damper block through a DICHANNEL
connection. The control system may not have control over the field device when the
HAND/OFF/AUTO switch is not in the AUTO position.
The LOCALMAN parameter provides feedback about the switch position. When the LOCALMAN
parameter is ON, the OP state tracks the PV state, if it is in a settable state. If PV is in a non-settable
state, OP is set to SAFEOP. This ensures that the last commanded state agrees with the current
value of the feedback state, when the LOCALMAN is turned OFF. The OP (GOP) cannot be
commanded directly when LOCALMAN is ON.
You cannot access LOCALMAN, if the Valve/Damper block does not have any inputs or outputs
connected. PV is illegal for no inputs and OP is illegal for no outputs, and therefore LOCALMAN is
of no consequence in such a condition.
outputs CmdOpen/CmdClose will follow OPFINAL.
ATTENTION
LOCALMAN can be used for the above purpose, when the Valve/Damper is Commanded by
Local, Controlled directly from MCC and not through DCS.
29.8.13 Permissive interlocks-VALVEDAMPER block

commanded output (OP) of the Valve/Damper block to a specific state. Permissive Interlocks
themselves never cause OP to change.
l To change the state of OP, the corresponding Permissive Interlock parameter should be set to
ON.
l 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

- 1065 -
State (NOCOMMAND) when active. OP cannot be commanded to a different state when SI is active.
l 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.
l 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.
l 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
l 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.
Interlocks are determined by the state assigned to a predefined SAFEOP that is NOCOMMAND
and the priority is SI, OI[0], OI[1], OI[2].
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 parameter BYPPERM must be set to ON. The operator can then set or
reset the parameter BYPASS.
l When BYPASS is ON, OP can be changed regardless of the state of the Override and
Permissive Interlocks.
l 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
l Command Disagree alarm - It is generated when the commanded output state (OP) changes
o 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
- 1066 -
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.
the OP state.
l Command Fail alarm - generated when the current active state (PV) fails to change from an
commanded.
o 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
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
been configured.
l Bad PV alarm - This alarm is generated whenever the current active state (PV) is detected as
NULL (or bad) state.
l 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.
not Null.
l Override Interlock alarms - When the alarm is enabled and the active override interlock causes
an OP state change, an alarm is generated.
l 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
29.8.18 Seal-in option-VALVEDAMPER block

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.
l The seal-in option is configured through the SEALOPT (Enable/Disable) parameter.
- 1067 -
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

l INITDOWN[1..2] - This is an input which is connected to the DOC INITREQ output. When
[i].STATUS is TRUE.
29.8.20 OP initialization option-VALVEDAMPER block

NORMALOPT, SAFEOPOPT or HOLDOPOPT. The default value for Valve/Damper is NORMALOPT.
l INITOPOPT = SAFEOPOPT, OP is set to NOCOMMAND

Override Interlocks, LocalMan, and OP Initialization-
VALVEDAMPER block
l If the Safety Interlock is active, the OP is set to NOCOMMAND;
l 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;
l Otherwise, if OP Initialization is configured as HOLDOPOPT, OP remains on the last value;
l Otherwise, if OP Initialization is configured as SAFEOPOPT, OP is set to NOCOMMAND;
- 1068 -
configured, the stored OP value tracks the PV state if the PV state is settable ( State0, State1);
l Otherwise, OP value is back-initialized from the output connections
l 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
29.8.23 OP and DO initialization after load-VALVEDAMPER block

feature is 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.
l NUMTRANS[0..2] - Number of transitions of PV to each state. This can be enabled provided
enabled.
l NUMSIOVRD - accumulated number of safety interlock trips, which results in OP changing
state (after the last statistics reset). This can be enabled provided TRKSIOVRD is enabled.
l 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.
l 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.
Valve/Damper block anytime irrespective of Redtagging, unlike the DEVCTL block.
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 request mechanism. The OP request (OPREQ/GOPREQ) differs from direct access an
- 1069 -
store to OP. The OPREQ is always active unless it is Null. This means the OPREQ continues to
29.8.26 Output command-VALVEDAMPER block

OPEN/CLOSE, AUTONOCMD, UCP OPEN/CLOSE, LOCAL OPEN/CLOSE, SEQ OPEN/CLOSE,
SEQNOCMD).
the given Boolean input command (AUTO OPEN/CLOSE, AUTONOCMD) provided REMOTE
SWITCH is ON.
l Similarly, you can command the Valve/Damper block through LOCAL OPEN/CLOSE, UCP
OPEN/CLOSE provided the following conditions are met:
o LOCAL OPEN/CLOSE depends on the LOCAL SWITCH which should be ON.
o UCP CLOSE/OPEN depends on REMOTE SWITCH which should be ON.
l Similarly, you can command the Valve/Damper block through Console OPEN/CLOSE provided
the following conditions are met:
o 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.
- 1070 -
ATTENTION
l UCP OPEN/CLOSE, SEQ OPEN/CLOSE, LOCAL OPEN/CLOSE work on OFF to ON
transitions. So, there is priority for them.
l AUTO OPEN/CLOSE work on priority as per SAFEOP which is NOCOMMAND since
they are latched.
l LOCAL OPEN/CLOSE, UCP OPEN/CLOSE commands change the MODEATTR to
Operator.
l AUTO OPEN/CLOSE, SEQ OPEN/CLOSE, UCP OPEN/CLOSE, CONSOLE
OPEN/CLOSE depends on REMOTESWITCH which should be ON.
l AUTO OPEN/CLOSE, SEQ OPEN/CLOSE is not allowed when BYPASS is ON.
l 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.
l 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.
l 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

- 1071 -
CHAPTER
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 Compute the Used for computing enthalpy, entropy, specific
Block thermodynamic quantities volume, pressure, and temperature of a
(STEAMPROP) of water and steam. thermodynamic system.
The following topics describe about thermodynamic utility function blocks.

l Steam Property Block (STEAMPROP)
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.
l SI in kJ/kg degree K
l Metric in kcal/kg degree C
l 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.
- 1072 -
Chapter 30 - Thermodynamic Utility Functions
l C300 Controller
l ACE Controller
l SIM-C300
ATTENTION
In this platform, the STEAMPROP block is useful for any process simulation and is
best for optimizing the process operation.
l SIM-ACE
The following figure is a graphical representation of the STEAMPROP block.
Figure 30.1 STEAMPROP block
30.1.1 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 30.2 STEAMPROP block usage in the industry
- 1073 -
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.
l Function
l Inputs/Outputs - STEAMPROP block
l Configuration parameters - STEAMPROP block
l Configuration example - STEAMPROP block
l Typical configuration of STEAMPROP block
l Error handling - STEAMPROP block
l STEAMPROP block parameters
30.1.2 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:
l Enthalpy (H)
l Entropy (S)
l Pressure (P)
l Temperature (T)
l Specific volume (V)
This function block supports one of the following selections.

l Water
l Steam
o Saturated
o 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/.
- 1074 -
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.
l Enthalpy (H)
l Entropy (S)
l Specific volume (V)
30.1.3 Inputs/Outputs - STEAMPROP block
Inputs
The STEAMPROP block accepts the following inputs.

l Pressure (P)
l Temperature (T)
l Entropy (S)
l 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:
l Pressure (P)
l Temperature (T)
l Entropy (S)
l Enthalpy (H)
l 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.
- 1075 -
Table 30.1 Supported STEAMPROP block inputs/outputs configuration

STEAM_WATER and STEAMTYPE configuration Supported inputs Supported
outputs
STEAM_WATER = WATER l Pressure (P) l Specific

Volume (V)
l Temperatur
e (T) l Enthalpy (H)
l Entropy (S)
STEAM_WATER = "STEAM" and STEAMTYPE = l Temperatur l Pressure (P)

"Saturated" e (T)
l Pressure (P) l Temperature

(T)
l Pressure (P) l Enthalpy (H)

l Entropy (S) l Specific
Volume (V)
l Temperature
(T)
l Pressure (P) l Specific

Volume (V)
l Steam
Quality (X) l Enthalpy (H)
l Entropy (S)
l Temperatur l Specific
e (T) Volume (V)
l Steam l Enthalpy (H)
Quality (X)
l Entropy (S)
STEAM_WATER = "STEAM" and STEAMTYPE = l Pressure (P) l Specific

"Superheated" Volume (V)
l Temperatur
e (T) l Enthalpy (H)
l Entropy (S)
l Pressure (P) l Enthalpy (H)

l Entropy (S) l Specific
Volume (V)
l Temperature
(T)
30.1.4 Configuration parameters - STEAMPROP block

The following table provides a summary of the STEAMPROP specific parameters that you can
access level of at least Engineer to enter or modify values for these parameters.
- 1076 -
NOTE
The table does not include descriptions of the common parameters such as block name and
description.
Table 30.2 Configurable parameters of STEAMPROP block

Steam Or STEAM_WATER Used for configuring the input (water or steam) for
Water 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 ENGUNITSYSTEM Used for configuring the engineering unit system for
Unit System 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 TEMPERATUREIO Used for configuring the temperature as input or output

(T) as applicable. By default, this parameter is configured as
"Not Configured."
Specific SPECIFICVOLUMEIO Used for configuring the specific volume as output. By

Volume (V) 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."
Steam STEAMQUALITYIO Used for configuring the steam quality as input. By

Quality (X) default, this parameter is configured as "Not Configured."
30.1.5 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."
- 1077 -
Finally, you have to configure the input/output parameters as mentioned in the Inputs/Outputs -
STEAMPROP block.
Computing the thermodynamic quantities of water
The following is an example illustration for computing the thermodynamic quantities of water.
Figure 30.3 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).
- 1078 -
Figure 30.4 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.5 STEAMPROP block configured for measuring thermodynamic quantities of steam
(superheated)
- 1079 -
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."
In addition, the STEAMPROP block is configured to accept the pressure and the entropy inputs
using the NUMERIC blocks.
30.1.6 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 30.6 Typical configuration of the STEAMPROP block
The following inputs of the Steam Turbine are provided to the AUXCALC to calculated the
mechanical efficiency.
l Superheated inlet steam flow
l Inlet steam temperature
l Exhaust steam pressure
l Exhaust steam quality
This typical configuration has been created using the typical usage explained in the Steam
Property Block (STEAMPROP).
- 1080 -
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 Provides the pressure as an input to the Superheated (STEAMPROP) block.
(NUMERIC)
Sup_Temp Provides the temperature as an input to the Superheated (STEAMPROP) block.
(NUMERIC)
Sat_pressure Provides the pressure as an input to the Saturated (STEAMPROP) block.
(NUMERIC)
Steam_quality Provides the steam quality (dryness of the steam) as an input to the Saturated
(NUMERIC) (STEAMPROP) block.
Gen_Output_ Provides the shaft power as an input to the AUXCALC block.
KW
(NUMERIC)
In_steam_flow Provides the steam flow rate as an input to the AUXCALC block.
(NUMERIC)
Superheated Accepts pressure and temperature as inputs and calculates the Enthalpy (H).
(STEAMPROP)
Saturated Accepts pressure and steam quality (dryness of steam) as inputs and calculates
(STEAMPROP) the Enthalpy (H).
AUXCALCA Accepts the Enthalpy (H) from the STEAMPROP (Superheated and Saturated)
(AUXCALC) 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.
30.1.7 Error handling - STEAMPROP block

The Control Module containing the STEAMPROP block cannot change the EXECSTATE status to
ACTIVE, if the following condition is satisfied:
l 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.
l 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.
30.1.8 STEAMPROP block parameters

the STEAMPROP block.
- 1081 -
CHAPTER
31 I/O REFERENCE BLOCKS
I/O Reference blocks are available as basic function blocks and provide a mechanism to the CM
for referencing
the Input/Output channel of supported I/O families or parameter values of any block.
A reference block allows a control strategy to be configured to access an independent object by

name. The referenced
object is a channel or IOPOINT that represents the field device that is being controlled or
monitored.
For example TT_101 represents a temperature transmitter. The strategy may be completed and
tested using
simulation features. The binding of the I/O is performed in the referenced independent object
and does not
require the strategy to be reconfigured or retested. The strategy requires reload when the binding
is changed.
The supported reference types are:
• Channels: Series C I/O and PM I/O
• IOPOINTs: CE900_IO, EtherNet I/P, IOPOINT_PARAM
• Parameter Values
When the REF block references an I/O channel, or I/O point it provides access to values
associated with the
referenced object. The Reference block supports configuration and monitoring, and simulation.
Attention: Exposing I/O type specific parameters may be useful in some applications, but may
restrict the ability
to change I/O types without re-configuration of the CM.
Whenever a reference is made from 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.
l The Reference block does not have to be re-configured or re-tested when the I/O assignment
is changed.
l The control strategies can be tested without building dummy I/O modules.
l Parameter connectors can be modified through Bulk Edit without having to open each chart
and modify the paremeter connectors.
- 1082 -
Chapter 31 - I/O Reference blocks
l A single typical can be created to reference a calculated value, or any of the I/O types
supported by the reference block. Bulk build/edit tools can be used to specify the reference of a
strategy created from the typical.
l A reference value of a referenced block may be modified without deleting the CM from the
Monitoring view.
l Load of a strategy does not affect the state of a channel.
l For Series C and PM I/O:
o When CM is deleted from the Monitoring view, the output channels hold the last good
value and do not go to fail-safe state
o 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.
l When CM is deleted from the Monitoring view, the output channels hold the last good value
and do not go to fail-safe state.
l 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.
l Load of a strategy does not affect the state of a channel.
31.1 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
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.
- 1083 -
Block Used for .... Block description

Referencing
an AI channel
AIREF (AI Acts as an interface between analog input I/O or the pulse input
block or an
Reference channels and the Control Module or between the parameters and the
analog
block) Control Module.
parameter
value.
Referencing
AOREF an AO channel
(AO block or an Acts as an interface between analog output I/O and the Control Module
Reference analog or between the parameters and the Control Module.
block) parameter
value.
Referencing a
DI channel
DIREF (DI
block or a Acts as an interface block between digital input I/O and the Control
Reference
digital Module or between the parameters and the Control Module.
block)
parameter
value.
Referencing a
Acts as an interface block between the digital output I/O and the
DOREF DO channel
Control Module to generates status output (0 or 1), pulsed output (ON
(DO block or a
or OFF) for specified pulse time based on origin of input and
Reference digital
parameters. Acts as a parameter connector between the parameters
block) parameter
and the Control Module.
value.
l Configuration of Reference block

l Behavior of Reference blocks when REFTYPE is configured as PARAMETER
l AIREF (AI Reference block)
l AOREF (AO Reference block)
l DIREF (DI Reference block)
l DOREF (DO Reference block)
l Copying Reference blocks
l Bulk Build of CM containing Reference blocks
l Navigating from Reference block faceplate to parameters or I/O channels
l UDT behavior of Reference blocks
31.2 Configuration of Reference block

The following table summarizes the common reference block 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, or
parameters specific to a reference block type. Additional parameters are described in the different
REF block type sections and also in the simulation section.
- 1084 -

Name
Reference REF Used for specifying the actual reference. Based on the REFTYPE
configuration, the reference can be a channel name, an IOPOINT
name or a parameter. In the case a name is entered that does not
exist, a new object is created automatically for the user, based on the
REFTYPE and CHANTYPE configuration:
l For REFTYPE of NONE, and IOPOINT is created with REFTYPE
of NONE
l For REFTYPE of SERIES_C_IO or PMIO anunassigned channel
is created
l For REFTYPE of IOPOINT_PARAM, CE900_IO or EtherNet I/P
an unassigned IOPPOINT is created and
o the REFTYPE parameter of the IOPOINT is set to match the
REF block
o the IOPTYPE parameter of the IOPOINT is set to match the
CHANTYPE from the REF block
Reference REFTYPE Indicates the type of interface. Enabled for edit only when the
Type Reference Type parameter is empty, and will be set automatically to
be compatible with the REF parameter. The reference type can be
one of the following:
• NONE
• SERIES_C_IO
• PMIO
• PARAMETER
• IOPOINT_PARAM
• CE900_IO
• EtherNet I/P
Note: Options for REFTYPE will be exposed
based on the Assigned controller platform of
the CM containing the REF block. Only types
supported for the platform will be exposed.
For unassigned CMs, all options are exposed
Channel CHANTYPE Enabled when the REF parameter is empty and REFTYPE is not
Type NONE, PARAMETER or IOPOINT_PARAM and will be set automatically
to be compatible with the REF parameter. Used to define the set of
parameters to be exposed on the REF block that are specific to the
reference. These parameters are accessed via
CMName.REFblock.parameter and may be exposed as pins to make
connections, or exposed on the faceplate of the block or accessed via
custom displays to supply I/O type specific information.
Note: Exposing I/O type specific parameters may be useful in some
applications, but may restrict the ability to change I/O types without
re-configuration of the CM.
Execution ORDERINCM Applies for cases when the REF block is loaded to the controller and
Order in executes. Recommendation is to configure the parameter correctly,
CM so can be applied when needed
- 1085 -

Name
IOPOINT REFCONN Read only parameter populated when the REF block has a REFTYPE
Reference of IOPOINT_PARAM. Identifies the parameter reference for the
IOPOINT.
The REF parameter displayed on the faceplate can only display the 24 characters of the REF value.
Hence, if the referenced 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.
Creation of Reference blocks

The Reference block is created by dragging and dropping a block into a CM. The following lists the
blocks that can be dragged into a CM:

• An existing Series C or PM I/O channel block or IOPOINT. In this case the Reference block will be
created
and automatically configured to reference the dragged block.
• A Reference block from the IOREFERENCES library. A Reference block will be created with no
reference.
31.2.1 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.
Mapping between Reference blocks

Reference Blocks PM I/O I/O channel types
AIREF l PMIO:AICHANNEL
l PMIO:HAICHANNEL
AOREF l PMIO:AOCHANNEL
l PMIO:HAOCHANNEL
DIREF PMIO:DICHANNEL
DOREF PMIO:DOCHANNEL
- 1086 -
31.2.2 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 31.1 Mapping between Reference blocks and Series C I/O channel types
Reference Blocks Series C I/O channel types
AIREF l SERIES_C_IO:AICHANNEL
l SERIES_C_IO:PICHANNEL
AOREF SERIES_C_IO:AOCHANNEL
DIREF SERIES_C_IO:DICHANNEL
DOREF SERIES_C_IO:DOCHANNEL
Mapping between IOPOINT 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 IOPOINTS:AI
AOREF IOPOINTS:AO
DIREF IOPOINTS:DI
DOREF IOPOINTS:DO
The behavior of the Reference block varies based on the configuration of the REFTYPE parameter.
The following figure is an example Main tab of the AIREF block where the REFTYPE is set as
"SERIES_
C_IO."
Illustration of Common Reference block parameters
- 1087 -
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.
l Block Pins
l Configuration Parameters
l Monitoring Parameters
The following figure displays an example of 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. Note that parameters added are specific to type of I/O
referenced.
- 1088 -
Parameters visible in the tabs when CHANTPE is defined
31.3 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.
- 1089 -
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.
l Point.Parameter
l Point.Block.Parameter
l @Substituteblockname.Parameter
l @Substitute Parameter
The following are the examples formats.

l CM.REGCTL.SP
l BIC_02.PIDA.PV
l AICHANNEL_01.PV
l @HT_LVL1.PV
l @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.
31.3.1 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.
l For the AO/DO Reference blocks, only push connections are allowed for OP/SO parameter.
l 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".
- 1090 -
Figure 31.1 Parameters visible in the tabs when REFTYPE is “PARAMETER”
AIREF (AI Reference block)The AIREF (AI Reference) block allows you toassociate a configured analog
I/O or a pulse input channel in a Control Module, orreference 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:
Function-AIREF blockConfiguration example-AIREF block
31.3.2 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.
- 1091 -
Table 31.2 Origin of the Input/output value for input Reference blocks
If REFTYPE is Then, the PV origin is...
configured as ...
Channel PV value of the referenced channel.
References:
PMIO or
SERIES_C_IO
IOPOINT I/O PV value resident on the AIREF block
References:
CE900_IO,
Ethernet
I/P
IOPOINT_ l For references where the datatype of the reference matches the type of the
PARAM REF block, the PV origin will be the reference configured for the IOPOINT.
l For references where type convert is required, PRIMARYVARORIGIN
parameter resident on the AIREF block
PARAMETER Values that are accessible by Control Builder. The values can be
l Point.Parameters, or
31.3.3 Configuration example-AIREF block

The following figure is an example of the AIREF block configuration when REFTYPE is set as
"SERIES_
C_IO."
Figure 31.2 Configuration of AIREF block
The following figure is an example of the AIREF block configuration when REFTYPE is set as
"IOPOINT_
PARAM."
Configuration of AIREF block when REFTYPE is IOPOINT_PARAM
- 1092 -
31.4 AOREF (AO Reference block)

The AOREF (AO Reference) block allows you to
l associate a configured analog I/O output channel in a Control Module, or
l reference a parameter value of any block.
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:
l Function-AOREF
l Configuration example-AOREF block
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
- 1093 -
Table 31.3 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.
IOPOINT I/O References: CE900_IO, OP value resident on the AOREF block

Ethernet I/P
PARAMETER values that are accessible in the Control Builder.

The values
can be
31.4.2 Configuration example-AOREF block
The following figure is an example of the AOREF block configuration when REFTYPE is set as
“SERIES_
C_IO.”
Figure 31.3 Configuration of AOREF block
The following figure is an example of the AOREF block configuration when REFTYPE is set as
“IOPOINT_PARAM.”
Configuration of AIREF block
- 1094 -
31.5 DIREF (DI Reference block)

The DIREF (DI Reference) block allows you to
l associate a configured digital I/O 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.
l Function-DIREF
l Configuration example-DIREF block
- 1095 -
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
Table 31.4 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.
IOPOINT I/O References: CE900_IO, PV value resident on the DIREF block

Ethernet I/P
IOPOINT_PARAM PRIMARYVARORIGIN parameter resident on the DIREF

block
PARAMETER values that are accessible in the Control Builder. The

values can be
31.5.2 Configuration example-DIREF block

The following figure is an example of the DIREF block configuration when REFTYPE is set as
"CE900_
IO."
Configuration of DIREF block When REFTYPE is CE900__IO
- 1096 -
The following figure is an example of the DIREF block configuration when REFTYPE is set as
"PARAMETER."
31.6 DOREF (DO Reference block)

The DOREF (DO Reference) block allows you to
l 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:
l Function-DOREF
l Configuration example-DOREF block
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
Table 31.5 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.
IOPOINT I/O References: CE900_IO, SO value resident on the DOREF block

Ethernet I/P
IOPOINT_PARAM PRIMARYVARORIGIN parameter resident on the

DOREF block
PARAMETER values that are accessible in the Control Builder. The

values can be
ATTENTION
The SO values are accepted only from the
PUSH blocks or PUSH connections.
- 1097 -
31.6.2 Configuration example-DOREF block

The following figure is an example of the DOREF block configuration when REFTYPE is set as
"CE900_IO."
Configuration of DOREF block when REFTYPE is CE900_IO
The following figure is an example of the DOREF block configuration when REFTYPE is set as
"PARAMETER."
Figure 31.4 Configuration of DOREF block When REFTYPE is PARAMETER
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.
- 1098 -
31.7.1 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.
l REF
- 1099 -
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.
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.
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.9.1 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.
31.9.2 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.
31.10.1 Configuration of Reference blocks in a UDT for I/O channels

and I/O Points
To configure the Reference blocks when the REFTYPE corresponds to a channel reference or
IOPOINT I/O referenceis or you must adhere to the following guidelines.
- 1100 -
l The value of Channel Type (CHANTYPE) and Reference (REF) parameters cannot be set in the
UDT.
l The REFTYPE, CHANTYPE, and the REF parameters cannot be made as template defining in
UDTs.
31.10.2 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.
l 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.
o @Substituteblockname.Parameter
o @Substitute Parameter
l The value of CHANTYPE parameters cannot be set in the UDT.

l The REFTYPE, CHANTYPE, and the REF parameters cannot be made as template defining in
UDTs.
31.10.3 Propagation of REFTYPE, CHANTYPE, and REF parameters

from parent UDTs
l 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.
l 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.
31.11 Limitations of Reference blocks

Following are some of the limitations of the Reference blocks.
l Reference blocks are supported in ACE only when the REFTYPE is set as "PARAMETER."
l 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.
l Reference blocks are not supported in C200/C200E Controller.
l Reference block simulation is only supported in UOC (R505)
- 1101 -
l Reference block to IOPOINTs is only supported in UOC (R505)

l AO/DO Reference block with REFTYPE of PARAMETER requires PUSH blocks to push to the
OP/SO parameters. NOTE: Use of Reference block with REFTYPE of PARAMETER is not
recommended. Use IOPOINT_PARAM instead.
- 1102 -
CHAPTER
32 UTILITY FUNCTIONS
l Utility Function Blocks

l ALMWINDOW (Alarm Window -Alarm Annunciator) Block
l ANNPANEL (Annunciator Panel) Block
l DIGACQ (Digital Acquisition) Block
l EXECTIMER Block
l FIRSTOUT (First Out Detection) Block
l FLAG Block
l FLAGARRAY Block
l MESSAGE Block
l NUMERIC Block
l NUMERICARRAY Block
l PUSH Block
l TEXTARRAY Block
l TEXTCOMMENT (Text Comment) Block
l TIMER Block
l TYPECONVERT Block
32.1 Utility Function Blocks

Utility function blocks provide a variety of configurable functions for storing and alarming selected
control data.
configuration of the 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.
- 1103 -
Chapter 32 - Utility Functions

Support alarm ALMWINDOW (Alarm Used to define configurable alarm inputs and
annunciator indication Window -Alarm annunciator outputs.
Annunciator) Block
Support alarm ANNPANEL Used in conjunction with the ALMWINDOW

annunciator indication (Annunciator Panel) block to provide configurable annunciator
Block panel operation.
Provide better use of DIGACQ (Digital Used to define PV source for associated DI
computing and memory Acquisition) Block channel input with PV alarm capability.
resources
Measure execution time EXECTIMER Block Used to measure the execution timing of CEE
of CEE blocks Blocks by creating two instances.
Provides first out logic FIRSTOUT (First Out Used to define configurable inputs to be
identification for digital Detection) Block scanned for first out function with alarm
input transition capability.
Store a single two-state FLAG Block Used to define two separate states (for
value example, Running/Stopped, Off/On) to
indicate the status of a particular input.
Store multiple two-state FLAGARRAY Block Used to define two separate states (Off/On) to
values indicate status of a particular input.
Provide client triggered MESSAGE Block Used to define up to 16 information only or

messages confirmation type messages that can be
triggered by a client of the block.
Store a floating point NUMERIC Block Used to store up to 8 bytes of a floating point
value value within defined upper and lower limits for
use in a control strategy.
Store multiple floating NUMERICARRAY Used to store up to 200 floating point values
point values Block for use in a control strategy.
Push the value of PUSH Block Used to push the value of different data types
various data types. to the output destination.
Store multiple text TEXTARRAY Block Used to store up to 120 text strings for use in
strings a control strategy.
Add comments into the TEXTCOMMENT (Text Used to add comments into the
strategies/templates Comment) Block strategies/templates.
Time process events or TIMER Block Used to keep track of elapsed time during a
create known delays. process and provides indication when elapsed
time reaches predefined limit.
Provide data type TYPECONVERT Block Used to convert one data type to another for
conversions connecting parameters of different data types.
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:
- 1104 -
delay time for the Off-Normal alarms.
l OFFNRMALM.TM
l OFFNRMALM.TMO
Each Alarm Window block supports the following user configurable attributes. The following table
lists the given name of the “Tab” in the parameter configuration form and then briefly describes
the attributes associated with that tab.
- 1105 -
Tab
l Number Of Inputs (NUMIN) - Lets you specify the number of digital inputs
to be used with the block. The default is 4.
l 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
l Off Normal Alarm Priority (OFFNRMALM.PR) - Indicates the relative
l Off Normal Alarm Severity (OFFNRMALM.SV) - Indicates the relative
l Deadband Time (OFFNRMALM.TM) -
condition occurs.
You can configure individual deadband time for OFFNRMALM. However, if
l Off-delay Time (OFFNRMALM.TMO) - With R410, this parameter is
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).
Defining
- 1106 -
l Function-ALMWINDOW block
l Inputs-ALMWINDOW block
l Outputs-ALMWINDOW block
l Alarms-ALMWINDOW block
l Error handling-ALMWINDOW block
l ALMWINDOW parameters
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).
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:
- 1107 -
Following is the state transition table of the Alarm window state machine
Lamp Events
State AckAlarm NewAlarm RtnAlarm RstAlarm
LampOff LampState No Action DoNothing No Action

= FastFlash
FastFlash No Action LampState = LampState = No Action

LampSteady SlowFlash
LampSteady LampState No Action LampState = No Action

= FastFlash SlowFlash
SlowFlash LampState No Action LampState = if(All alarms have rtn) then

= FastFlash LampSteady {LampState = LampOff} else
{LampState = LampSteady}
Manual reset sequence
The following is an illustration of the Alarm window state machine Manual Reset:
- 1108 -
Following is the state transition table of the Alarm window state machine Manual Reset:
LampState Events
NewAlarm AckAlarm RtnAlarm RstAlarm
LampOff LampState = NoAction NoAction NoAction
FastFlash
FastFlash NoAction LampState = NoAction NoAction

LampSteady
LampSteady LampState = NoAction NoAction If(All Alms RTN){LampState

FastFlash = LampOff}
Automatic Reset Sequence:
The following is an illustration of the Alarm window state machine Automatic Reset:
- 1109 -
Following is the state transition table of the Alarm window state machine Automatic Reset:
LampState Events
NewAlarm AckAlarm RtnAlarm RstAlarm
LampOff LampState = No Action No Action No Action
FastFlash
FastFlash No Action If(All Alarms RTN) No Action No Action

{LampState = LampOff}
Else
{LampState =
LampSteady}
LampSteady LampState = No Action LampState = No Action

FastFlash LampOff
32.2.5 Error handling-ALMWINDOW block
l The block displays an error when an invalid index or access lock is received during loading of
the block.
l If the user tries to store a value more than 16 for the NUMIN parameter, error “Invalid Value”
is displayed.
- 1110 -
l The parameter NUMIN cannot be changed from Monitoring side.

l Access level check is done at the time of loading the block as well during a parameter write.
l 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

the Alarm Annunciator-Alarm Window block.
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:
- 1111 -
Each Annunciator Panel block supports the following user configurable attributes. The following
table lists the given name of the “Tab”in the parameter configuration form and then briefly
describes the attributes associated with that tab.
- 1112 -
Configuration Tab Description

Main l Name - Block (Tag) name of up to 16 characters long. Must
be unique within the CM block containing it.
l 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 0
and 65535. The default value is 10.
l Number Of Inputs (NUMANNWIN) - Lets you specify the
number of alarm window blocks that can be connected to
the block. The default is 16.
l 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)
l 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.
l Alarm Window Text (ALMWINTXT) - This text specified in this
parameter appears on the detail display pages for the Alarm
panel.
Identification Lets you view information pertinent to the qualification and

version control system and enter block comments, if desired.
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 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.
Template Defining Lets you view and define parameters for associated templates.
l Function-ANNPANEL block
l Configuration Example-ANNPANEL block
l Inputs-ANNPANEL block
l Outputs-ANNPANEL block
l Error Handling-ANNPANEL block
l ANNPANEL parameters
- 1113 -
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.
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
- 1114 -
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
l The block displays an error when an invalid index or access lock is received during loading of
the block.
l If the user tries to store a value more than 32 for the NUMANNUNWIN parameter, than an
error “Invalid Value” appears.
l Access level check is done at the time of loading the block as well as during a parameter write.
32.3.6 ANNPANEL parameters

the Alarm Annunciator - Alarm Panel block.
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.
- 1115 -
delay time for Off-Normal and Bad PV alarms.
l OFFNRMALM.TM
l OFFNRMALM.TMO
l BADPVALM.TM
l BADPVALM.TMO
DIGACQ block provides a feature to configure change of state (COS) alarm with Delay option for
Digital Inputs (DI). The following parameters are introduced to enable/disable and to configure the
priority, severity and delay time of this alarm.
l ALMSELOPT
l CHGOFSTALM.PR
l CHGOFSTALM.SV
l CHGOFSTALM.TM
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
- 1116 -
Tab
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.
characters to identify the variable values associated with the block.
l Normal State - Defines the Normal State of the block, as selected by the
user.
l Actual State - Indicates the current state of the block as in PV
default selection is ONLYAUTO.
connection. Only applicable with PV Source Option selection of ALL. The
default selection is AUTO.
l Text for each state (STATETEXT) - Lets you select the text for each state.
l Display Configuration (DABLOCKSINCM) - Indicates the number of blocks
that will be displayed in system detail display.
Alarms l Off Normal Alarm Priority (OFFNRMALM.PR) - Indicates the relative

l Off Normal Alarm Severity (OFFNRMALM.SV) - Indicates the relative
l Bad PV Alarm Priority (BADPVALM.PR) - Lets you set the desired priority
l Bad PV Alarm Severity (BADPVALM.SV) - Lets you assign a relative
default value is 0.
l Deadband Time (xxxxALM.TM) -
condition occurs. You can configure individual deadband time for
OFFNRMALM. However, if you are migrating from pre-R410 to later
l 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 normal. The default time is 0; that is RTN is
reported as soon as the alarm condition returns to normal. However, if
- 1117 -
Tab
l The COS alarm is reported in the station with the priority defined in
priority column of the CHGOFSTALM.PR parameter. The possible
priorities are None, Journal, Low, High and Urgent.
l The COS alarm is reported in the station with given severity defined in the
Severity column of the CHGOFSTALM.SV parameter.
l The COS alarm is reported in the station whenever there is a state
change after a configured delay time defined in CHGOFSTALM.TM
parameter.
Defining
l Function-DIGACQ block
l Configuration Scenario-DIGACQ block
l Inputs-DIGACQ block
l Outputs-DIGACQ block
l Error handling-DIGACQ block
l DIGACQ parameters
32.4.1 Function-DIGACQ block
l Enables better utilization of processor computing and memory resources.

l Supports alarm generation when the current process variable state differs from the configured
NORMAL state.
Block configuration
l By default, the PVSRCOPT parameter is set to ONLYAUTO and PVSOURCE is set to AUTO.
l The PVSOURCE parameter is disabled when PVSRCOPT is set to 0 (ONLYAUTO). It can be
changed if PVSRCOPT is set to 1 (ALL).
Predecessor block
- 1118 -
l A predecessor block is not required if PVSOURCE is set to MAN.
l If PVSOURCE is set to AUTO, any block with a digital output can be a predecessor.
l 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.
The DIGACQ block is enhanced for you to configure the same for generation of COS alarms. A COS
To accomplish this, new parameters ALMSELOPT, CHGOFSTALM.PR, CHGOFSTALM.SV,
CHGOFSTALM.TM are introduced in the DIGACQ block.
l To configure CHGOFSTALM.PR, CHGOFSTALM.SV, CHGOFSTALM.TM parameters you need to
enable/disable the ALMSELOPT parameter.
Urgent.
- 1119 -
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
l IN - Input parameter
32.4.4 Outputs-DIGACQ block
l PV - Current selected input based on the PVSOURCE selection

l PVFL - Actual State Flag
l INVPVFL - Inverted State Flag
l 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
- 1120 -
l 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.
l 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.
32.4.5 Error handling-DIGACQ block
l The Digital Acquisition block reports errors when a parameter is accessed with a privilege lower
than the expected access level.
l The Digital Acquisition block provides PVSTATUS based on the PVOURCE.
If PVSOUCE is
o Manual - kManValSts.
o SCM - kUncertainValSts.
o Auto - kNormalValSts.
l If the CM is inactive or CEE is IDLE, the block holds the last legal value.
l 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

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
- 1121 -
Tab
Main l 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.
l Averaging Interval (TAU): TAU establishes the time interval over which
rolling averages are computed. Units are seconds.
l 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.
l 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.
l Offset (DTAOFFSET): Subtractive offset applied to DTIMEAVG in

computing DTIMEAVGCOMP.
Value is computed as follows.
DTIMEAVGCOMP = (DTIMEAVG - DTAOFFSET) * DTASCALE / DTANORM.
l Normalization (DTANORM): Denominator applied to DTIMEAVG in

computing DTIMEAVGCOMP.
l Scale Factor (DTASCALE): Numerator applied to DTIMEAVG in computing

DTIMEAVGCOMP.
l 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.
l 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:
l TIMEIN parameter of block instance is connected.
l TIMEIN parameter of block instance is receiving a good value.
l Block instance is enabled.
- 1122 -
Tab
l 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.
l 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.
l Minimum (DTIMEMIN): Minimum value of DTIME since RESET was last

set to On.
l 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.
l Maximum (DTIMEMAX): Maximum value of DTIME since RESET was last

set to On.
l 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.
l 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.
l Standard Deviation%: (DTIMESTDPRC): The value of DTIMESTD as

percent of DTIMEAVG.
DTIMESTDPRC is computed as follows.
DTIMESTDPRC = 100.0 * DTIMESTD / DTIMEAVG
l 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:
l Subtract out the small timing overhead not associated with the
block or module under measurement.
l Attempt to compensate for other factors by scaling up or down a
- 1123 -
Tab
measurement.
Defining
l Function-EXECTIMER block
l Input-EXECTIMER block
l Output-EXECTIMER block
l EXECTIMER Parameters
l EXECTIMER Example
l Limitations-EXECTIMER block
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.
l C300
l SIMC300
l C300-20ms
l C200E
l SIMC200E
l ACE
l SIMACE
ATTENTION
EXECTIMER is not supported on the C200 platform.
- 1124 -
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.
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

the 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.
- 1125 -
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.
l Measuring timing effects between EEs.
l Measuring timing effects between an EE and IO.
l 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.
- 1126 -
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 given name of the “Tab”in the parameter configuration form and then briefly
describes the attributes associated with that tab.
- 1127 -
Tab
l Number Of Inputs (NUMDINPUTS) - Lets you specify the number of
digital inputs to be used with the block. The default is 8.
Alarm l First Out Alarm Priority (FIRSTOUTALM.PR) - Indicates the relative priority
of the alarm. The default selection is LOW.
l First Out Alarm Severity (FIRSTOUTALM.SV) - Indicates the relative
Transition Lets you configure the transition monitoring status of the block.
Monitoring
Defining
l Function-FIRSTOUT block
l Inputs-FIRSTOUT block
l Outputs-FIRSTOUT block
l Error handling-FIRSTOUT block
l First out detection FB parameters
32.6.1 Function-FIRSTOUT block
l 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.
- 1128 -
l 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.
l 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).
l 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:
l IN[1] - IN[8] Inputs
l RESET Input
l 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.
l NUMDINPUTS
l INPUTACTED[1] - INPUTACTED[8]
l 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.
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.
- 1129 -
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.
- 1130 -
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
l The number of inputs can be restricted during configuration. By default, eight inputs are
allowed.
l 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.
o 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.
o If any of the inputs transition from the last cycle, the INPUTACTED is turned ON.
o The history inputs of the last cycle (equal to the values of current inputs in this cycle)
are updated.
o In the absence of a change, the control exits.
o 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”.
- 1131 -
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”.
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
l IN [1..24] - Boolean inputs whose transitions are monitored.

l 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
l FIRSTOUTACTED - This flag is set when there is an input transition from its configured
NORMAL state.
l INPUTACTED[1..24] - Indicates whether the corresponding input has transitioned causing a
First Out action.
l FIRSTOUTINPUT - This is an enumeration that indicates the input that triggered First Out.
l 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
l This block checks and reports for invalid input indexes while loading or accessing parameters.
l The SR parameter cannot be edited on the monitoring side. A string input to the SR parameter
- 1132 -
results in an error message being reported during configuration and the input string is
rejected.
l Parameter Access level is checked.
l 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

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.
delay time for the Off-Normal alarms.
l OFFNRMALM.TM
l OFFNRMALM.TMO
FLAG block provides a feature to configure change of state (COS) alarm with Delay option for
Digital Inputs (DI). The following parameters are introduced to enable/disable and to configure the
priority, severity and delay time of this alarm.
l ALMSELOPT
l CHGOFSTALM.PR
l CHGOFSTALM.SV
l CHGOFSTALM.TM
l Function-FLAG block
l Input/Output-FLAG block
l FLAG parameters
32.7.1 Function-FLAG block

Used to define two separate states (for example, Running/Stopped, Off/On) to indicate status of a
- 1133 -
particular input.
l There are 2 user-configurable state descriptors, STATETEXT[0] and STATETEXT[1] which are
used to describe STATE0 and STATE1 respectively.
l Current state of flag can be changed/read using PVFL (Boolean) or using PV (either
STATETEXT[0] or STATETEXT[1]).
l Block also supports:
o configurable access lock which determines who can write a value to the block (such as
operator, engineer, or other function block).
o 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.
o 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.
o 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
o 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).
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
l 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.
l When an alert is generated, the FLAG block's borders appear in red in the
Monitoring view.
l 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.
- 1134 -
The FLAG block is enhanced for you to configure the same for generation of COS alarms. A COS
To accomplish this, new parameters ALMSELOPT, CHGOFSTALM.PR, CHGOFSTALM.SV,
CHGOFSTALM.TM are introduced in the FLAG block.
l To configure CHGOFSTALM.PR, CHGOFSTALM.SV, and CHGOFSTALM.TM parameters you
need to select the Change Of State option from ALMSELOPT enumeration.
Urgent.
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

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:
l Function-FLAGARRAY block
l Input/Output-FLAGARRAY block
l FLAGARRAY parameters
32.8.1 Function-FLAGARRAY block

- 1135 -

l Current state of flags can be changed/read using flag value (PVFL[n]) (Boolean).
l 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
32.8.3 FLAGARRAY parameters

the FLAGARRAY function block.
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:
l Information,
l Confirmable,
l Single Signature, or
l Double Signature.
ATTENTION
You must have the Electronic Signature system license to use the Single Signature and
Double Signature message types.
l Function-MESSAGE block
l Configuration and Operation Considerations-MESSAGE block
l Input/Output-MESSAGE block
l MESSAGE parameters
32.9.1 Function-MESSAGE block

When a client triggers a given send flag (SENDFL[n]) input, the corresponding message
- 1136 -
(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.
l Select the message and press MSG CONFM on the IKB.
l Select the message and click Confirm Message on the menu bar.
l 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.
l Acknowledge the message twice.
l Select the message and click Confirm Message on the menu bar.
l Right-click the message and select Confirm.
- 1137 -
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.
l Each message has a maximum length of 132 characters.
l A new message cannot be sent when the message is awaiting/blocked on a confirmation
(CONFIRMED[n] parameter).
l 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).
l 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.
l 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.
32.9.4 MESSAGE parameters

the 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.
l Function-NUMERIC block
l Input/Output-NUMERIC block
l NUMERIC parameters
- 1138 -
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.
l Configurable high and low limits are also provided.
l 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
32.10.3 NUMERIC parameters

the NUMERIC function block.
32.11 NUMERICARRAY Block

The NUMERICARRAY block provides storage for up to 200 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:
l Function-NUMERICARRAY block
l Input/Output-NUMERICARRAY block
l NUMERICARRAY parameters
32.11.1 Function-NUMERICARRAY block

The NUMERICARRAY block outputs (PV[n]) can be used as source parameters to provide
predefined analog constants to other function blocks. A bad numeric output parameter typically
has the value NaN (Not-a-Number).
l A configurable Access Lock (ACCLOCK) which determines who can write a value to the block
(such as operator, engineer, or other function block).
l 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
- 1139 -
places (-XXX.XXX). The default selection is D1 for one decimal place.

l 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) configured. But, all block pin parameters are available to be exposed and connected
to using Control Builder graphical connections.
32.11.3 NUMERICARRAY parameters

the 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.
l Function-PUSH block
l Execution Status-PUSH block
l Store Status-PUSH block
l PUSH parameters
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:
l Overall Execution Status (EXECSTS)
The EXECSTS provide information on how successful the block is in fetching the input. EXECSTS
can have the following values:
- 1140 -
l OK - Successful i.e. when fetching of inputs as well as the conversion was done without any
error or clamping.
l 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.
l BADINPUT - This happens when the connection to input block is lost or it is simply bad data.
l 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:

l When the value exceeds the defined maximum limit for parameters.
l 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:
l Store status (STORESTS)
The STORESTS provide information on how successful the block is in storing the input. STORESTS
can have the following values:
l STOREOK - Successful i.e. the store to destination was successful
l 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
l 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
l 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

the PUSH function block.
32.13 TEXTARRAY Block

The TEXTARRAY block provides storage for up to 120 text strings 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:
- 1141 -
l Function-TEXTARRAY block
l Input/Output-TEXTARRAY block
l TEXTARRAY parameters
32.13.1 Function-TEXTARRAY block

The TEXTARRAY block outputs (STR[n]) can be used to provide predefined text strings to other
function blocks.
l 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

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
32.13.3 TEXTARRAY parameters

the TEXTARRAY function block.
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
- 1142 -
logic and hence does not participate in control execution. In addition, the Text Comment block does
not contain any pin connections.
l Benefits of using Text Comment block
l TEXTCOMMENT parameters
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:
l 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.
l 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.
l 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.
l 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.
l 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.
l 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.
l No restriction on the number of Text Comment blocks that can be introduced in a strategy.
l Maximum number of characters in the comments is limited to 1000.
l Special characters (!, @, #, $, %, ^, &, *, _, +, >, <, /, \, ], [, {, }, ~, `) are not allowed in the
comments.
l 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.
l Comments can be bulk built. Also, Text Comment block parameters can be bulk edited.
l Can be imported/exported like any other function block.
l User templates can be created using the Text Comment block.
l The comments font, color, size, and style can be modified.
l Since this block does not have logic, the block parameters do not appear in the Point Picker
dialog box.
32.14.2 TEXTCOMMENT parameters

- 1143 -
the 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.
l Function-TIMER block
l Input/Output-TIMER block
l Commands-TIMER block
l TIMER parameters
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
32.15.3 Commands-TIMER block

Commands are sent to the timer in one of two ways:
l By the operator, using the COMMAND parameter
l 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).
- 1144 -
When more than one of the Boolean command parameters is set at the same time, the following
priority is used:
l RESETFL - highest priority
l STOPFL
l RESTARTFL
l 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 given (through COMMAND), the Stop command is executed and all lower priority
command flags are automatically turned OFF
32.15.4 TIMER parameters

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.
l Boolean
l Integer (unsigned/signed 8/16/32-bit integers)
l Real (32-bit and 64-bit IEEE floating point numbers)
l Enumeration
It looks like this graphically:
l Function-TYPECONVERT block
l Execution status-TYPECONVERT block
l Input/Output-TYPECONVERT block
l TYPECONVERT parameters
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
- 1145 -
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.

l 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.
l 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.
l 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.
l 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
l An Enumeration to Boolean Map scroll box lets you configure a given enumeration
(ENUMBOOLMAP[n]) to OFF or ON.
l 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.
l OK - The fetching of inputs as well as the conversion was completed without any error or
clamping.
l 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.
- 1146 -
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.
l BadInput - The input connection exists but the data fetched is NaN (bad value). This is
applicable only for float input types.
l 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
32.16.4 TYPECONVERT parameters

the TYPECONVERT function block.
- 1147 -
CHAPTER
33 SEQUENTIAL CONTROL
l SCM (Sequential Control Module) Block
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.
- 1148 -
CHAPTER
34 APC
l PROFITCTL Block
l PROFITCTLIN Block
l PROFITCTLOUT Block
34.1 PROFITCTL Block

Refer to the Experion Profit Controller User's Guide for all information pertaining to the Experion
Profit Control function in an Experion system.
PROFITCTL l Responsible for interacting with the PC engine.
34.2 PROFITCTLIN Block

Block
PROFITCTLIN l Responsible for fetching and pre-processing of the measurements of CV

and DV, also contains Profit Controller tuning parameters associated with
CV and DV.
34.3 PROFITCTLOUT Block

- 1149 -
Chapter 34 - APC
PROFITCTLOUT l Responsible for post processing of the output calculation of MVs

computed by the Profit controller engine.
l Interacts with the supported Regulatory control blocks ( like PID, PID-PL)
to set their SP/ OP according to the configuration.
l Also takes care of shedding of downstream PID controllers when the
Profit Controller gets switched off.
- 1150 -
CHAPTER
35 MODE SELECTION FUNCTIONALITY
In the mode selection list, before R500, all Modes applicable/not applicable were listed
irrespective of whether a block supported a particular MODE or not. This enabled the Operator to
select an invalid mode from the MODE selection list. When an invalid MODE was selected a
system error would occur by which the Operator came to know that an invalid MODE was selected.
In addition, an Engineer had no provision of restricting the Operator from changing the
MODE/MODEATTR to a value which was inappropriate for a particular control strategy. Displaying
Mode selections that were not supported/ not applicable for a block was confusing to the Operator
and had the potential for the Operator to make an unsuitable selection.
In R500, the following features are implemented:
1. List only applicable modes in DEVCTL, POWERGEN. REGCTL blocks.
2. Mode Selection to filter out modes that are not applicable for an Operator to select during
control operations.
3. FORCEMODEATTR to prevent the Operator/Supervisor/Engineer from writing to MODE when
the MODEATTR is PROGRAM.
Access Locks
The following two users are impacted by the mode selection functionality:
l Project Engineer- Modifies the Mode Selection list to select the required Modes/Mode
Attribute either manually or through applications/control configurations. This restricts the
Operator from selecting a mode which is not applicable to a control strategy.
l Plant Operator- Will be able to view only the list of applicable modes configured by the project
engineer using mode selection.
l Applicable Modes for REGCTL, DEVCTL and POWERGEN blocks

l Mode and Mode Attribute Selection
l Force Mode Attribute (FORCEMODEATTR)
35.1 Applicable Modes for REGCTL, DEVCTL and POWERGEN

blocks
Displaying modes that are not supported by a particular block was confusing to the Operator. In
R500, the parameters MODE and NORMMODE display only applicable modes for a block. The
following table lists the applicable modes for the REGCTL, DEVCTL and POWERGEN blocks.
- 1151 -
Chapter 35 - Mode selection functionality
Block Applicable modes for Applicable modes for

MODE parameter NORMMODE parameter
PID, PIDER, PIDPL, PIDFF, POSPROP, MAN NONE

RATIOBIAS, RATIOCTL, ENHREGCALC
AUTO MAN
CAS AUTO
NORMAL CAS
REGCALC, REGSUMMER, SWITCH, MAN NONE

AUTOMAN, FANOUT, OVRDSEL
CAS MAN
NORMAL CAS
DEVCTL, HTMOTOR, LTMOTOR, MAN NONE

SOLENOID, VALVEDAMPER, MAINIBV
NORMAL MAN
REMCAS MAN NONE

CAS MAN
BCAS CAS
NORMAL BCAS
RAMPSOAK MAN NONE

AUTO MAN
NORMAL AUTO
NOTE
If you migrate from a release prior to R500 to R500 and if there are strategies configured
with invalid modes for MODE, MODEATTR and NORMMODE parameters, all the
configurations are set to the default value. Refer the error logs for the impacted control
strategies.
35.2 Mode and Mode Attribute Selection

The Mode and Mode Attribute Selection is used for configuring the Mode/Mode Attribute Selection.
It allows an engineer to remove the MODE/MODEATTR selections from the MODE selection lists
on the operator’s Standard-Display using the mode selection parameter. This prevents the
operator from selecting the wrong MODE/MODEATTR. By enabling/disabling MODE/MODEATTR
selections from the MODE selection list, the respective MODE/MODEATTR values are impacted on
line. The mode selection parameter can be modified with Engineer key level access from any of the
following:
l Project view
l Monitoring view
l Detail Displays
Mode selection list can also be configured using PIN connections where the Mode selection list
parameter receives inputs from the configured input PIN. This selection ensures that the
parameter MODE displays only the modes applicable to a particular block in the monitoring view.
- 1152 -
NOTE
NORMMODE and NORMMODEATTR are not impacted by the change you make to the mode
selection list. These parameters will always display the applicable modes and mode
attributes.
The following table lists the Mode and Mode Attribute Selection List for the REGCTL, DEVCTL and
POWERGEN blocks.
Block Mode/Mode Attribute

Selection
PID, PIDER, PIDPL, PIDFF, POSPROP, RATIOBIAS, RATIOCTL, MAN

ENHREGCALC
AUTO
CAS
PROGRAM
REGCALC, REGSUMMER, SWITCH, AUTOMAN, FANOUT, OVRDSEL MAN

CAS
PROGRAM
REMCAS, RAMPSOAK, DEVCTL, HTMOTOR, LTMOTOR, SOLENOID, PROGRAM

VALVEDAMPER, MAINIBV
Any change made to the mode selection parameter affects the value of MODE and the MODEATTR,
that is, if MODESEL is configured to disallow the AUTO mode, then the corresponding MODE
parameter does not list AUTO in the monitoring view/Station Display. However, programmatically
the MODE value can still be set to the AUTO.
For example, in the PID block, the allowable modes are MAN, AUTO and CAS. Any of these modes
can be configured for exclusion from the mode selection list. If PID is running in AUTO mode and
from the monitoring side the user deselects AUTO from the mode selection list, then the strategy
still continues to run in the AUTO mode. Later if you change MODE to MAN/CAS the AUTO mode
disappears from the MODE list.
NOTE
The default value for mode selection parameter is ON which means that all applicable modes
are available in the MODE/MODEATTR list. Ensure that you select the appropriate
mode/mode attribute in the mode selection list to prevent any error/warning. For more
information about the error message, see Control Builder Error Code Reference.
Special considerations for the following blocks

RAMPSOAK/REMCAS
These blocks contain the list of applicable modes and do not support the mode selection
functionality for the following reasons:
l RAMPSOAK supports modes MAN and AUTO only; disallowing either of these would render the
functionality of this block unusable.
l REMCAS block provides automatic switching between a remote cascade and a backup cascade
and thus it supports modes CAS, BCAS and MAN. Disallowing CAS or BCAS for this block would
hinder the basic purpose of the block.
DEVCTL/HTMOTOR/LTMOTOR/SOLENOID/VALVEDAMPER/MAINIBV
- 1153 -
Since these blocks do not contain mode as a modifiable parameter, hence the mode selection
functionality is provided only for MODEATTR parameter.
35.3 Force Mode Attribute (FORCEMODEATTR)
NOTE
This section is only applicable to the REGCTL blocks.
FORCEMODEATTR (Force Mode Attribute) prevents the Operator/Supervisor/Engineer from

changing the MODE when the MODEATTR is PROGRAM.
The following table demonstrates the change in behavior (highlighted) introduced as part of the
FORCEMODEATTR parameter.
Prior to R500 Starting R500
If MODEATTR=PROGRAM then the If FORCEMODEATTR is disabled and

Operator/Supervisor/Engineer can store MODEATTR=PROGRAM then the
to MODE and MODEATTR changes to Operator/Supervisor/Engineer can store to MODE
OPERATOR. and MODEATTR changes to OPERATOR.
If FORCEMODEATTR is enabled and
MODEATTR=PROGRAM then the
Operator/Supervisor/Engineer cannot store to
MODE and MODEATTR remains PROGRAM.
- 1154 -
Notices
Trademarks
Experion®, PlantScape®, SafeBrowse®, TotalPlant®, ControlEdge™, and TDC 3000® are registered
trademarks of Honeywell International, Inc.
OneWireless™ is a trademark of Honeywell International Sàrl
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:
l http://www.honeywellprocess.com/support
If you have comments about Honeywell Process Solutions documentation, send your feedback to:
l [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:
l Send an email to [email protected].
or
l Contact your local Honeywell Process Solutions Customer Contact Center (CCC) or Honeywell
Technical Assistance Center (TAC) listed in the “Support” section of this document.
- 1155 -
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.
- 1156 -

Control Builder Components Theory EPDOC XX16 en 501C

Uploaded by

Copyright:

Available Formats

Control Builder Components Theory EPDOC XX16 en 501C

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 EPDOC XX16 en 501C

Uploaded by

Copyright:

Available Formats

EXPERION PKS

Control Builder Components Theory

2.1.8 Parameter data types 47

2.2 Control Capacity and Performance 49

2.2.2 C200/C200E configuration options 51

2.3 I/O Capacity and Performance 65

2.4 Function Block Execution Schedules 70

2.5 Block Configuration Load Considerations 77

2.6 Memory Usage for CEE on C200/C200E, C300 or ACE 79

2.7 CPU Utilization for CEE on CPM 89

2.8 CEE Standard Control Blocks 90

3.3 CEE Architecture 100

3.4 Validation of Control Module Independence 105

4.3 Display options for relative references 110

4.4 Control Builder functions supporting relative references 112

4.7 Example of parameter connector using relative references 114

4.8 Example of other parameters using relative references 115

4.9 Bulk Builder and Bulk Editor support 116

5.2 Initiator Rate - Calculation 131

Chapter 6 - Time Support in Experion System 141

6.3 Time Configuration Considerations 142

6.4 Examples of Time Usage in CAB and SCM 146

Chapter 7 - Cold and Warm Restart Functionality 148

7.2 Planning 149

7.3 Configuration of Restart Behaviors 153

7.4 Warm and Cold Restart Behaviors of Cascades 161

7.5 Operations 168

Chapter 8 - External OPC Server Support 170

8.2 OPC Data References 171

8.3 OPC Data Type Conversions 173

8.4 ACE interface to TPS system as OPC server 177

9.3 Remote EEOUT (REEOUT) Function Block 183

Chapter 10 - Controller Redundancy Functionality 184

10.2 Implications for Control Builder Functions 188

10.2.2 RM configuration 188

10.2.9 Synchronization tab 195

Chapter 11 - Control Mode Shed on Loss of I/O Functionality 204

11.2 Option to specify a time delay for the REGCTL blocks to

11.3 Implications for Operation 212

11.4 Remote Cascade function between Controllers 213

12.2 MODESTARTMAN 217

Chapter 14 - SCM and CM Chart Visualization Functionality 220

14.2 Some SCM and CM Chart Operation Considerations 223

Chapter 15 - Enhancements to reporting of alarms in Station 224

Chapter 16 - I/O Link Interface 231

Chapter 17 - Process Manager Input/Output Functionality 235

17.2 Smart Transmitter Interface Point 241

17.2.8 STI IOP functions 246

17.3 Analog Output Point 249

17.4 Digital Input Point 251

17.5 Digital Output Point 258

Chapter 18 - Component Categories and Types 262

19.2 Clamping the output amperage to comply with the NAMUR

19.3 About Safety Interlock Function 285

19.5 AUTOMAN (Auto Manual) Block 288

19.5.11 Control Initialization-AUTOMAN 304

19.6 ENHREGCALC (Enhanced Regulatory Control Calculator)

19.7 FANOUT Block 341

19.7.8 Mode handling-FANOUT block 352