Custom Algorithm Block

Experion
Custom Algorithm Block and

Custom Data Block
User's Guide
EX25-210
R210
10/04
Notices and trademarks
Copyright 2004 by Honeywell International Inc.

Release 210 October 12, 2004
While this information is presented in good faith and believed to be accurate, Honeywell disclaims
the implied warranties of merchantability and fitness for a particular purpose and makes no express
warranties except as may be stated in its written agreement with and for its customers.
In no event is Honeywell liable to anyone for any indirect, special or consequential damages. The
information and specifications in this document are subject to change without notice.
Experion™ is a trademark of Honeywell International Inc.
Other brand or product names are trademarks of their respective owners.
Honeywell International
Process Solutions
2500 West Union Hills Drive
Phoenix, AZ 85027
1-800 343-0228
ii Custom Algorithm Block and Custom Data Block User's Guide R210
Honeywell 10/04
About this document
This document describes how to plan, develop, debug, deploy, and troubleshoot Custom
Algorithm Blocks and Custom Data Blocks.
Release information
Document name Document ID Release Publication
number date
Custom Algorithm Block and Custom Data Block EX25-210 210 10/04
User's Guide - EX25
References
The following list identifies all documents that may be sources of reference for material discussed
in this publication.
Document title
Parameter Definition Editor Reference
Application Control Environment User Guide
Simulation ACE User Guide
Control Building Guide
Control Builder Components Reference
Control Builder Components Theory
Control Builder Parameter Reference
iii Custom Algorithm Block and Custom Data Block User's Guide R210
Honeywell 10/04
Contacts
Contacts
World Wide Web
The following Honeywell web sites may be of interest to Industry Solution customers.
Honeywell organization WWW address (URL)
Corporate http://www.honeywell.com
Industry Solutions http://www.acs.honeywell.com
International http://content.honeywell.com/global/
Telephone
Contact us by telephone at the numbers listed below.
Organization Phone number
United States Honeywell International Inc. 1-800-343-0228 Sales

and Canada Industry Solutions 1-800-525-7439 Service
1-800-822-7673 Technical
Support
Asia Pacific Honeywell Asia Pacific Inc. (852) 23 31 9133

Hong Kong
Europe Honeywell PACE [32-2] 728-2711

Brussels, Belgium
Latin America Honeywell International Inc. (954) 845-2600

Sunrise, Florida U.S.A.
iv Custom Algorithm Block and Custom Data Block User's Guide R210
Honeywell 10/04
Symbol definitions
Symbol definitions
The following table lists those symbols used in this document to denote certain conditions.
Symbol Definition
ATTENTION: Identifies information that requires special

consideration.
TIP: Identifies advice or hints for the user, often in terms of

performing a task.
REFERENCE -EXTERNAL: Identifies an additional source of

information outside of the bookset.
REFERENCE - INTERNAL: Identifies an additional source of

information within the bookset.
R210 Custom Algorithm Block and Custom Data Block User's Guide v
10/04 Honeywell
6 Custom Algorithm Block and Custom Data Block User's Guide R210
Honeywell 10/04
Contents
INTRODUCTION ...................................................................................23
Overview ................................................................................................................... 23
Abstract ................................................................................................................................23
Who should use this guide ...................................................................................................23
Terms and acronyms ...........................................................................................................23
Prerequisite knowledge ........................................................................................................23
What are Custom Algorithm Blocks? .................................................................... 24
Overview ..............................................................................................................................24
CAB creation ........................................................................................................................24
CAB functionality..................................................................................................................24
What is a Custom Data Block? ............................................................................... 25
Overview ..............................................................................................................................25
Creating a CDB ....................................................................................................................25
Getting started tutorial ............................................................................................ 26
Overview of the tutorial ........................................................................................................26
System requirements ...........................................................................................................26
Description of the tutorial example .......................................................................................27
Create a CAB type ...............................................................................................................28
Instantiate the CAB type in a control strategy ......................................................................36
Create a CDB type ...............................................................................................................46
Instantiate the CDB type ......................................................................................................49
Additional examples .............................................................................................................54
CAB AND CDB PURPOSE ...................................................................55

Purpose, use, and value of the system.................................................................. 55
CAB overview.......................................................................................................................55
Why use CAB?.....................................................................................................................56
CDB overview ......................................................................................................................56
Why use CDB?.....................................................................................................................56
System functions that support CAB and CDB ......................................................................57
Relationships of subsystems................................................................................................57
Description of subsystems ...................................................................................................58
Platform hosting of block type categories.............................................................................60
Role of block types, instances, and templates .....................................................................61
CAB functional overview......................................................................................... 64
Overview ..............................................................................................................................64
How a CAB works ................................................................................................................64
Honeywell 10/04
Contents
CAB data characteristics ..................................................................................................... 72

CAB algorithm characteristics ............................................................................................. 73
CDB functional overview .........................................................................................74
Overview ............................................................................................................................. 74
How a CDB works ............................................................................................................... 74
CDB data definition characteristics...................................................................................... 78
CAB AND CDB SYSTEM PLANNING AND DESIGN .......................... 79

System architecture .................................................................................................79
Role of CAB and CDB in system architecture ..................................................................... 79
System requirements .......................................................................................................... 80
Computers and network infrastructure..................................................................82
Hardware requirements for CAB and CDB .......................................................................... 82
Software environment requirements for CAB and CDB....................................................... 83
Review the sizing of ERDB ................................................................................................. 84
Determine ACE processing requirements ........................................................................... 84
Determine ACE configuration limits for CAB types and instances....................................... 84
Summary of CAB configuration limits .................................................................................. 86
Determine ACE configuration limits for CDB types and instances....................................... 86
Determine ACE memory utilization...................................................................................... 87
Determine ACE shutdown horizon ...................................................................................... 88
Security policy ..........................................................................................................90
User access......................................................................................................................... 90
CDP Access Lock attribute.................................................................................................. 90
SIM-ACE and the MSVS debugger ..................................................................................... 90
CAB AND CDB TYPE PLANNING AND DESIGN ............................... 91

Control strategy........................................................................................................91
Determine that CAB and CDB are needed.......................................................................... 91
Develop strategies............................................................................................................... 91
Configuration planning ............................................................................................91
Configuration planning steps ............................................................................................... 91
Software development considerations................................................................................. 93
Requirements external to system ........................................................................................ 93
CAB configuration choices .....................................................................................94
Define the CAB naming strategy ......................................................................................... 94
Make CAB user interface decisions..................................................................................... 94
Determine the CAB algorithm and parameters.................................................................... 95
Determine Continuous Control access ................................................................................ 96
Data and algorithm characteristics of CAB.......................................................................... 96
Honeywell 10/04
Contents
CAB fixed definition parameters...........................................................................................97

CAB states ...........................................................................................................................98
CAB notifications..................................................................................................................98
CAB constraints ...................................................................................................................99
CAB API ...............................................................................................................................99
Design the Custom Algorithm Block ................................................................... 100
Design the usage of the CAB .............................................................................................100
Determine when to use CAB ..............................................................................................100
Develop a conceptual design .............................................................................................100
Organizing CAB programs for best performance ...............................................................101
Determine CAB memory usage..........................................................................................102
Determine CAB shutdown horizon .....................................................................................102
Determine the CAB distribution policy................................................................................102
CDB configuration choices................................................................................... 103
Define the CDB naming strategy........................................................................................103
Make CDB user interface decisions ...................................................................................103
Data characteristics of CDB ...............................................................................................104
CDB fixed definition parameters.........................................................................................104
CDB constraints .................................................................................................................104
Design the Custom Data Block............................................................................. 105
Design the usage of the CDB.............................................................................................105
Determine when to use CDB..............................................................................................105
Define the CDB distribution policy......................................................................................105
CAB AND CDB INSTALLATION AND UPGRADE.............................107

Hardware installation and upgrade ...................................................................... 107
Where to find information ...................................................................................................107
Software installation and upgrade ....................................................................... 107
Licensing considerations ....................................................................................................107
CAB Developer license ......................................................................................................107
ACE Base license ..............................................................................................................108
Possible licensing scenarios ..............................................................................................108
CAB CONFIGURATION......................................................................109
Create a new CAB type.......................................................................................... 109
CAB development environment overview...........................................................................109
Layout of the development environment ............................................................................109
Honeywell additions to MSVS ............................................................................................112
Honeywell files ...................................................................................................................112
MSVS .NET 2003 resources ..............................................................................................112
R210 Custom Algorithm Block and Custom Data Block User's Guide 9
10/04 Honeywell
Contents
CAB configuration procedures........................................................................................... 113

Open a new CAB block type for edit.................................................................................. 113
Define data and algorithm ................................................................................................. 114
Build the solution ............................................................................................................... 114
Save the solution............................................................................................................... 115
Save-Renew command ..................................................................................................... 117
Block type locking flags ..................................................................................................... 117
Interactions with the ERDB database lock feature ............................................................ 118
Close the development environment ................................................................................. 119
Define CAB type parameters .................................................................................120
Custom data parameter purpose....................................................................................... 120
CDP characteristics........................................................................................................... 120
Define custom data parameters ........................................................................................ 121
Validity checks based on CDP attributes........................................................................... 122
Access Lock attribute for CDPs......................................................................................... 123
Fixed definition parameter purpose ................................................................................... 125
Define values for fixed definition parameters .................................................................... 125
Define parameter references............................................................................................. 126
Assign parameter references ............................................................................................ 128
Specify symbol attributes .................................................................................................. 128
Specify form layout............................................................................................................ 129
Form entry steps ............................................................................................................... 130
Fixed definition parameters ............................................................................................... 131
FDPs common with native blocks...................................................................................... 131
FDPs specific to CAB ........................................................................................................ 131
Detailed description Of CAB specific FDPs ....................................................................... 137
Save parameter definitions................................................................................................ 137
Limitations on number of CAB parameters........................................................................ 138
Code CAB algorithm ..............................................................................................139
Overview ........................................................................................................................... 139
Define block scope variables............................................................................................. 140
Define local variables ........................................................................................................ 141
Algorithm definition – Execute()......................................................................................... 141
Execution mode of CAB programs .................................................................................... 142
PRef as data alias within CAB program ............................................................................ 144
Configuring parameter addresses on CAB instances........................................................ 144
Access level used In PRef writes ...................................................................................... 145
Data types for CDPs and parameter references................................................................ 146
CAB algorithm data definition...............................................................................150
Data initializations under Execute() ................................................................................... 150
Using the Restart property ................................................................................................ 151
CDP initializations associated with block load................................................................... 152
Data access integrity ......................................................................................................... 153
Local parameter access .................................................................................................... 153
Remote communication with no group integrity requirements ........................................... 154
Honeywell 10/04
Contents
Remote communication with group integrity requirements.................................................155

Read versus write ..............................................................................................................157
Structures and classes usage within CAB..........................................................................159
Array usage within CAB .....................................................................................................160
Floating point usage within CAB ........................................................................................160
TIME and TIMEOFDAY usage in CAB...............................................................................162
CAB algorithm parameter references .................................................................. 162
Implicit type conversion with CAB parameter references ...................................................162
Legend ...............................................................................................................................163
Parameter references used for read ..................................................................................164
Parameter references used for write ..................................................................................166
Parameter reference fail-safe values .................................................................................169
CAB writes with Continuous Control access level ..............................................................169
Create a CAB instance .......................................................................................... 171
Overview ............................................................................................................................171
Configure Value CDPs tab .................................................................................................172
Configure parameter references tab ..................................................................................173
Source and Alarms tabs .....................................................................................................175
Save the configuration .......................................................................................................175
Configure insertion points .................................................................................... 176
Overview ............................................................................................................................176
RegCtl insertion points .......................................................................................................176
DataAcq insertion points ....................................................................................................177
Configuration procedure.....................................................................................................177
Do not use graphical connections ......................................................................................178
Test and debug the CAB ....................................................................................... 179
Developmental debugging..................................................................................................179
Off-process debugging .......................................................................................................179
On-process debugging .......................................................................................................180
Troubleshooting information...............................................................................................180
Modify a CAB.......................................................................................................... 181
Modify/Edit CAB type with MSVS.......................................................................................181
Manage instances after modification of CAB type..............................................................182
User actions when saving modified CAB type....................................................................183
Behaviors when saving modified types to ERDB ...............................................................185
Convert instances to modified CAB type ............................................................................186
Manage CABs ......................................................................................................... 188
Verify match of CAB program in ERDB ..............................................................................188
View a CAB type as read only............................................................................................188
Delete a CAB type from ERDB...........................................................................................189
Rename a CAB ..................................................................................................................189
Recover a CAB with checkpoint restore.............................................................................189
Recover CAB source code .................................................................................................190
10/04 Honeywell
Contents
Export CAB ....................................................................................................................... 190

Import CAB........................................................................................................................ 191
Discover CAB dependency relationships .......................................................................... 192
Special considerations when using QVCS with CAB......................................................... 192
CDB CONFIGURATION ..................................................................... 195

Create a new CDB type ..........................................................................................195
CDB development environment......................................................................................... 195
Summary of configuration steps ........................................................................................ 195
Open a new CDB block type for edit ................................................................................. 195
Types of saves for CDB .................................................................................................... 197
Save As Renew command ................................................................................................ 198
Save CDB to ERDB........................................................................................................... 198
Define CDB type parameters .................................................................................199
Custom Data Parameter purpose...................................................................................... 199
CDP characteristics........................................................................................................... 199
Define CDB custom data parameters................................................................................ 200
Validity checks based on CDP attributes........................................................................... 201
Access lock attribute for CDPs .......................................................................................... 202
Fixed definition parameter purpose ................................................................................... 204
Fixed definition parameters in CDBs ................................................................................. 204
Detailed description of CDB FDPs .................................................................................... 205
Specify symbol attributes .................................................................................................. 205
Specify form layout............................................................................................................ 206
Form entry steps ............................................................................................................... 207
Save parameter definitions................................................................................................ 208
Limitations on number of CDB parameters ....................................................................... 208
Create a CDB instance ...........................................................................................209
Overview ........................................................................................................................... 209
Configure Value CDPs tab ................................................................................................ 209
Test the Custom Data Block..................................................................................211
Modify a Custom Data Block .................................................................................211
Manage instances after modification of CDB type............................................................. 211
User actions when saving modified CDB type................................................................... 213
Behaviors when saving modified types to ERDB............................................................... 215
Convert instances to modified CDB type........................................................................... 217
Verify match of CDB version in ERDB............................................................................... 219
View a CDB type as read only........................................................................................... 219
Delete a CDB type from ERDB.......................................................................................... 219
Rename a CDB ................................................................................................................. 220
Recover a CDB with checkpoint restore............................................................................ 220
Export CDB ....................................................................................................................... 220
Import CDB........................................................................................................................ 221
Honeywell 10/04
Contents
Discover CDB dependency relationships ...........................................................................222

Special considerations when using QVCS with CDB .........................................................222
CAB AND CDB EXAMPLE SCENARIOS ...........................................225

Summary of example scenarios ........................................................................... 225
Disclaimer ..........................................................................................................................225
Example scenarios included...............................................................................................225
CAB insertion algorithm........................................................................................ 226
Vapor-to-liquid ratio control ................................................................................................226
Creating empty block type VLR_CALC ..............................................................................228
Setting the access level for VLR_CALC .............................................................................228
Defining value CDPs for VLR_CALC .................................................................................229
Define parameter references for VLR_CALC .....................................................................230
Define the algorithm for VLR_CALC ..................................................................................231
Save VLR_CALC to ERDB.................................................................................................235
Block instances in the VLR_CALC application ...................................................................235
Configure VLR_CALC1 ......................................................................................................236
Configure VLR_CTL1 .........................................................................................................239
Control module chart for VLRATIO ....................................................................................239
Formulation of VLR_CALC without insertion point............................................ 241
Overview ............................................................................................................................241
CDP definitions for alternate formulation of VLR_CALC ....................................................241
Control module chart for alternate formulation of VLRATIO...............................................242
CDPs as Engineering Unit labels ......................................................................... 243
Example .............................................................................................................................243
A CDB to hold sensor data ................................................................................... 245
Temperature at position within PFR ...................................................................................245
Creating block type POSTEMPCDB ..................................................................................246
Block instances in temperature at position application .......................................................246
Configure POSTEMP1.DATA1...........................................................................................247
A CAB to calculate statistics over arrays............................................................ 248
Block type ZONESTATSCAB.............................................................................................248
Value CDPs for ZONESTATSCAB.....................................................................................248
Algorithm for ZONESTATSCAB .........................................................................................249
Bulk array connection on ZONESTATSCAB instance........................................................252
Array and scalar variables in CAB ....................................................................... 253
Overview ............................................................................................................................253
Example variables ..............................................................................................................253
PDE definitions...................................................................................................................254
Instance configuration ........................................................................................................256
Program .............................................................................................................................257
10/04 Honeywell
Contents
Two-dimensional array example........................................................................................ 258

Initializing in response to system events ............................................................259
Overview ........................................................................................................................... 259
Fast history block .............................................................................................................. 259
PDE definitions.................................................................................................................. 259
Program ............................................................................................................................ 260
Example using data type TIME..............................................................................261
Shift calculations ............................................................................................................... 261
Value CDP definition for SHIFTCALC ............................................................................... 262
Algorithm for SHIFTCALC ................................................................................................. 262
Example using data type TIMEOFDAY .................................................................263
Slow monitoring calculations ............................................................................................. 263
Value CDP definitions for MONCALC ............................................................................... 264
Algorithm for MONCALC ................................................................................................... 265
Example using data type DELTATIME..................................................................266
Time-out monitor ............................................................................................................... 266
Value CDP definitions for TIMEOUTMON......................................................................... 266
Algorithm for TIMEOUTMON............................................................................................. 267
Use of data access status in CAB ........................................................................269
Device monitor with Stop/Run command .......................................................................... 269
Value CDP for DEVMON................................................................................................... 269
Parameter references for DEVMON.................................................................................. 270
Algorithm for DEVMON ..................................................................................................... 271
Use of parameter reference variables in CAB .....................................................273
Setting control state for a group of CMs ............................................................................ 273
Value CDPs for SETMODE............................................................................................... 274
Parameter references for SETMODE................................................................................ 274
Algorithm for SETMODE ................................................................................................... 276
CAB AND CDB OPERATIONS .......................................................... 285

Startup and shutdown............................................................................................285
Custom Algorithm Blocks .................................................................................................. 285
Custom Data Blocks.......................................................................................................... 285
Process operations ................................................................................................285
Monitor CAB and CDB ...................................................................................................... 285
View CAB alarms .............................................................................................................. 285
View CAB and CDB from Station ..........................................................................286
Overview ........................................................................................................................... 286
Properties forms specific to CAB and CDB.........................................................286
Honeywell 10/04
Contents
Overview ............................................................................................................................286
Main tab of a CAB block property form ..............................................................................287
Main tab of a CDB block property form ..............................................................................288
Value CDPs tab for CAB and CDB.....................................................................................288
Parameter References tab .................................................................................................289
Source tab..........................................................................................................................289
Alarms tab ..........................................................................................................................291
CAB AND CDB SYSTEM ADMINISTRATION....................................293

CAB development environment administration ................................................. 293
Recovering from a Control Builder crash............................................................................293
User management .................................................................................................. 293
User management functions ..............................................................................................293
Setting user permissions ....................................................................................................293
Establishing a User account for SimACE ...........................................................................293
Resource management ......................................................................................... 294
Overview ............................................................................................................................294
Use performance monitoring FDPs ....................................................................................295
Use Task Manager .............................................................................................................296
Use Performance Monitor ..................................................................................................297
Backup and restore................................................................................................ 302
ACE shutdown procedure for reclaiming CAB memory......................................................302
CAB AND CDB TROUBLESHOOTING AND MAINTENANCE ..........303

Troubleshooting approach ................................................................................... 303
Overview ............................................................................................................................303
Troubleshooting approaches and tools ..............................................................................303
CAB instance states .............................................................................................. 304
Overview ............................................................................................................................304
State diagram.....................................................................................................................304
State descriptions...............................................................................................................306
Transition descriptions .......................................................................................................308
CAB alarms............................................................................................................. 309
Overview ............................................................................................................................309
CAB state Terminated ........................................................................................................309
CAB state Exception ..........................................................................................................309
Read error ..........................................................................................................................310
Write error ..........................................................................................................................310
10/04 Honeywell
Contents
FDPs that capture exception information .......................................................................... 311

Debug with SIM-ACE ..............................................................................................312
Overview ........................................................................................................................... 312
The MSVS debugger......................................................................................................... 312
Scope ................................................................................................................................ 312
Basic characteristics of SIM-ACE...................................................................................... 314
Setup procedure for CAB debugging on SIM-ACE............................................................ 314
Tips for using MSVS with SIM-ACE .................................................................................. 318
CAB fault handling .................................................................................................319
Principles........................................................................................................................... 319
Function limiter and supported namespaces ..................................................................... 319
Supported namespaces and classes................................................................................. 319
Summary of fault handling................................................................................................. 321
Parameter access faults.................................................................................................... 325
Divide-by-zero handling..................................................................................................... 325
Unbounded recursion ........................................................................................................ 326
Exception handling ............................................................................................................ 326
Overlong execution ........................................................................................................... 326
Loops In "Catch" Or "Finally" clauses................................................................................ 327
Site responsibilities in CAB fault handling ......................................................................... 327
CAB error reporting ........................................................................................................... 331
CAB and CDB error messages and codes ........................................................................ 339
Contacting TAC ......................................................................................................345
Overview ........................................................................................................................... 345
Information required for build-time problems ..................................................................... 345
Information required for run-time problems ....................................................................... 345
CAB API REFERENCE ...................................................................... 347

Overview..................................................................................................................347
The overall CAB map ........................................................................................................ 347
APIs supplied from CAB to system ......................................................................348
Class CAB ......................................................................................................................... 348
Subroutine Execute() of class CAB ................................................................................... 348
APIs supplied from system to CAB ......................................................................349
Enumeration RestartEnum ................................................................................................ 349
Enumeration CABAccStatusEnum .................................................................................... 350
Enumeration CABCommandEnum.................................................................................... 351
Enumeration CABStateEnum ............................................................................................ 352
CDP classes...................................................................................................................... 352
Parameter reference classes............................................................................................. 355
Read(), ReadStatus, and Value......................................................................................... 360
Write() ............................................................................................................................... 361
Honeywell 10/04
Contents
WriteStatus.........................................................................................................................363
Parameter reference list class............................................................................................364
CABMath class...................................................................................................................367
Examples of CABMath functions usage .............................................................................372
FDP classes .......................................................................................................................372
Base class..........................................................................................................................373
Predefined CDP variables ..................................................................................................373
Predefined parameter reference variables .........................................................................373
Predefined parameter reference list ...................................................................................373
Predefined FDPs and subroutines .....................................................................................374
Fixed definition parameter PROGSTSDESC .....................................................................374
Fixed definition parameter CABCOMMAND.......................................................................376
Fixed definition parameter CABSTATE ..............................................................................376
Restricted FDP PERIOD ....................................................................................................377
Restricted FDP PROCSPECEXEC ....................................................................................377
Subroutine Send() ..............................................................................................................378
Subroutine Abort()..............................................................................................................379
Property Restart()...............................................................................................................380
APIs supplied from VB.NET to CAB..................................................................... 381
Some constructs of interest................................................................................................381
Private and public access types In CAB programs.............................................................381
GLOSSARY OF TERMS AND ACRONYMS.......................................383

Introduction ............................................................................................................ 383
Overview ............................................................................................................................383
Special terms and acronyms ................................................................................ 383
10/04 Honeywell
Contents
Tables
Table 1 Relationship of subsystems that support CAB and CDB ..................................57
Table 2 Platform support for block types .......................................................................60
Table 3 Custom Algorithm Blocks in build-time environment ........................................65
Table 4 Custom Algorithm Blocks in run-time environment ...........................................66
Table 5 Agents supporting CABs in build-time and run-time environments ..................67
Table 6 Custom Data Blocks in build-time and run-time environments .........................75
Table 7 Agents supporting CDBs in build-time and run-time environments ..................76
Table 8 Comparisons of Experion and TPS architectures .............................................79
Table 9 Configuration limits for CAB types and instances .............................................85
Table 10 Configuration limits for CDB types and instances...........................................86
Table 11 Memory requirements for small, medium, and large CABs ............................87
Table 12 ACE memory usages after two years for medium-sized CABs ......................89
Table 13 Build Commands...........................................................................................114
Table 14 Types of saves for CAB ................................................................................116
Table 15 PDE Information links for Value CDPs..........................................................122
Table 16 Access levels in Experion .............................................................................124
Table 17 Access locks for CDPs..................................................................................125
Table 18 PDE information link for FDPs ......................................................................126
Table 19 PDE Information link for PRefs .....................................................................127
Table 20 PDE information link for symbol attributes ....................................................129
Table 21 PDE information link for form layout .............................................................129
Table 22 Summary of FDPs common with native blocks.............................................131
Table 23 Summary of CAB FDPs not common with native blocks ..............................132
Table 24 Configuration limits for CAB types and instances .........................................138
Table 25 Data types for CDPs and parameter references...........................................146
Table 26 Data type names in Experion and VB.NET...................................................150
Table 27 Custom Data Parameter initialization in Custom Algorithm Blocks ..............152
Table 28 Integrity considerations for read versus write ...............................................159
Table 29 Implicit data type conversion for PRef reads (part 1)....................................165
Table 30 Implicit data type conversion for PRef reads (part 2)....................................166
Table 31 Implicit data type conversion for PRef writes (part 1) ...................................167
Table 32 Implicit data type conversion for PRef writes (part 2) ...................................168
Table 33 Fail-safe values .............................................................................................169
Table 34 Insertion points for RegCtl points..................................................................176
Table 35 Insertion points for Data ACQ point ..............................................................177
Table 36 Insertion point configuration procedure.........................................................177
Table 37 Converting CAB instances ............................................................................187
Table 38 Verify CAB instance version .........................................................................188
Table 39 Types of saves for CDB ................................................................................197
Table 40 PDE information links for Value CDPs..........................................................200
Table 41 Access levels in Experion .............................................................................203
Honeywell 10/04
Contents
Table 42 Access locks for CDPs ................................................................................. 204

Table 43 CDB FDPs not common with native blocks.................................................. 205
Table 44 PDE information link for symbol attributes ................................................... 206
Table 45 PDE information link for form layout ............................................................. 207
Table 46 Converting CDB instances ........................................................................... 217
Table 47 Verify CDB instance version......................................................................... 219
Table 48 Block types in vapor-to-liquid ratio solution .................................................. 228
Table 49 Value CDP definitions for VLR_CALC.......................................................... 229
Table 50 Parameter reference definitions for VLR_CALC .......................................... 230
Table 51 Block instances for vapor-to-liquid ratio solution .......................................... 235
Table 52 Value CDPs for alternate formulation of VLR_CALC ................................... 241
Table 53 Value CDP definitions for VLR_CALC with "EU Label" CDPs ..................... 244
Table 54 Block types in PRF sensor data solution...................................................... 245
Table 55 Value CDP definitions in POSTEMPCDB .................................................... 246
Table 56 Block instances in PFR sensor data solution ............................................... 247
Table 57 Value CDP configuration in POSTEMP1.DARA1......................................... 247
Table 58 Value CDP definitions in ZONESTATSCAB................................................. 248
Table 59 Value CDP definitions................................................................................... 255
Table 60 Parameter reference definitions ................................................................... 256
Table 61 Value CDP configuration .............................................................................. 256
Table 62 Parameter reference configuration ............................................................... 257
Table 63 Value CDP definitions................................................................................... 259
Table 64 Value CDP definition for SHIFTCALC .......................................................... 262
Table 65 Value CDP definitions for MONCALC .......................................................... 264
Table 66 Value CDP definitions for TIMEOUTMON.................................................... 267
Table 67 Value CDP definition for DEVMON .............................................................. 269
Table 68 Parameter reference definitions for DEVMON ............................................. 270
Table 69 Value CDP definitions for SETMODE .......................................................... 274
Table 70 Parameter reference definitions for SETMODE ........................................... 275
Table 71 CAB instance states ..................................................................................... 306
Table 72 Transitions in CAB state ............................................................................... 308
Table 73 The Procedure to attach the MSVS debugger to ACE ................................. 314
Table 74 Summary of CAB fault handling ................................................................... 322
Table 75 Summary of site responsibilities for fault handling ....................................... 328
Table 76 .NET constructs appropriate to control mission............................................ 329
Table 77 Techniques for reporting CAB errors............................................................ 332
Table 78 CAB error type examples and recommended actions.................................. 333
Table 79 CAB/CDB error messages............................................................................ 339
Table 80 Members of enumeration RestartEnum ....................................................... 349
Table 81 Members of enumeration CABAccStatusEnum ........................................... 350
Table 82 Members of enumeration CABCommandEnum ........................................... 352
Table 83 Members of enumeration CABStateEnum ................................................... 352
10/04 Honeywell
Contents
Table 84 Custom data parameter classes ...................................................................353

Table 85 Declaration of members for class Float64CDP.............................................354
Table 86 Parameter reference classes ........................................................................356
Table 87 Declaration of members for class Float64PRef ............................................357
Table 88 Parameter reference list class ......................................................................365
Table 89 Description of members of class PrefListClass.............................................365
Table 90 Methods in the CABMath class.....................................................................368
Table 91 Fixed definition parameter classes ...............................................................372
Table 92 Declaration of members for class Float64FDP .............................................373
Table 93 Declaration of subroutine Send() ..................................................................378
Table 94 Declaration of subroutine Abort() ..................................................................380
Table 95 Declaration of property Restart()...................................................................380
Figures
Figure 1 Block types, block instances, and block templates..........................................62
Figure 2 The MSVS development environment for CAB .............................................110
Figure 3 Source code window......................................................................................110
Figure 4 Source code tab with GUID ...........................................................................112
Figure 5 Specify Library and CAB Names ...................................................................113
Figure 6 CAB Type Locking Flags ...............................................................................117
Figure 7 Value CDPs Tab ............................................................................................121
Figure 8 Value CDPs configuration form .....................................................................122
Figure 9 Fixed (FDP) tab..............................................................................................126
Figure 10 FDP configuration form ................................................................................126
Figure 11 Parameter references tab ............................................................................126
Figure 12 Parameter references configuration form ....................................................127
Figure 13 Parameter reference assignment ................................................................128
Figure 14 Access cut, copy, and paste options ...........................................................130
Figure 15 Value CDPs tab with descriptions showing .................................................172
Figure 16 Value CDPs tab with parameters showing ..................................................172
Figure 17 Parameter References tab...........................................................................174
Figure 18 Parameter Reference tab configured...........................................................175
Figure 19 Saving modified CAB types .........................................................................185
Figure 20 Specify library and CDB name.....................................................................196
Figure 21 The Parameter Definition Editor ..................................................................197
Figure 22 Value CDPs tab ...........................................................................................200
Figure 23 Value CDPs configuration form ...................................................................200
Figure 24 Access cut, copy, and paste options ...........................................................207
Figure 25 Value CDPs tab with descriptions showing .................................................210
Figure 26 Value CDPs tab with parameters showing ..................................................210
Honeywell 10/04
Contents
Figure 27 Saving Modified CDB Types ....................................................................... 216

Figure 28 Fractionation column ................................................................................... 226
Figure 29 Value CDP configuration for VLR_CALC1 .................................................. 236
Figure 30 Empty parameter reference properties form for VLR_CALC1 .................... 237
Figure 31 Completed parameter reference properties form ........................................ 238
Figure 32 VLRATIO Control Chart............................................................................... 240
Figure 33 VLRATIO alternate control chart ................................................................. 243
Figure 34 CAB-specific parts of CAB block property form Main tab ........................... 287
Figure 35 CDB-specific parts of CDB block properties form Main tab ........................ 288
Figure 36 Value CDPs tab of CAB and CDB block properties form ............................ 288
Figure 37 Parameter References tab of CAB block properties Form.......................... 289
Figure 38 Source code tab on CAB block properties form .......................................... 290
Figure 39 Alarms Tab on CAB Block Properties Form................................................ 291
Figure 40 Task Manager performance tab .................................................................. 296
Figure 41 Instance state diagram for FDP CABSTATE .............................................. 305
Figure 42 MSVS help contents.................................................................................... 313
Figure 43 .NET constructs allowed for CAB applications............................................ 319
Figure 44 Overall map of CAB API.............................................................................. 347
10/04 Honeywell
Contents
Honeywell 10/04
Introduction
Overview
Abstract
This document provides information on how you define, configure, deploy, and
troubleshoot Custom Algorithm Block (CAB) and Custom Data Block (CDB) control
blocks.
Who should use this guide

If your need is simply to familiarize yourself with the capabilities of CAB and CDB, this
guide contains introductory and tutorial information that will be helpful. The introductory
material is included in the section that you are reading.
If you are an engineer developing control strategies that use, or might use, CAB and/or
CDB, this guide also contains detailed reference material that you will require. Similarly,
if your activities include deploying and monitoring CABs and CDBs, this guide contains
detailed information about their behavior in the run-time environment.
Terms and acronyms

The section “Special terms and acronyms” contains a compilation of special terms and
acronyms that are commonly used in this guide. This list is an excellent introduction to
the concepts and “language” of CAB and CDB. If you are new to CAB and CDB, we
recommend that you read through this list prior to delving into the details of CAB and
CDB.
Prerequisite knowledge
• You should be familiar with the basic principles of control systems.
• You should be familiar with the architecture and functionality of Experion Process
Knowledge System (PKS).
• You should have a good working knowledge of Experion Control Builder.
• If you will be developing control algorithms for Custom Algorithm Blocks, you will
need to be adept at using the Microsoft Visual Basic .NET programming language.
Honeywell 10/04
Introduction
What are Custom Algorithm Blocks?
What are Custom Algorithm Blocks?

Overview
A CAB is similar in purpose and structure to the “native” function blocks that are
distributed with Experion Control Builder (CB). Examples of native blocks are REGCTL
blocks such as PID and RAMPSOAK. These blocks have a predefined algorithm and a
predefined data structure. By contrast, Custom Algorithm Blocks have user-defined
algorithms and data structures.
CAB creation
CABs are created within CB. You must purchase a CAB Developer license from
Honeywell in order to activate the CAB development features. These features include
Microsoft Visual Studio .NET 2003, which is combined with the Parameter Definition
Editor to provide the project development environment that is used to develop CAB types
and that allows implementation of custom parameters and algorithms.
The process of creating a CAB type requires fluency with a programming language
(VB.NET in the current release).
CAB functionality
With CAB Developer, you can define the block type itself, including the custom data
parameters, parameter references, and the control algorithm. With ACE R210 and later,
you can create instances of your custom block types. You can also create block
templates, which are an optional intermediate construct in between the type and the
instance. Templates might be useful to you in certain situations. Templates are covered in
the section “Role of block types, instances, and templates.”
A control strategy can include combinations of native blocks and custom blocks.
REFERENCE - INTERNAL
For more information on CAB functionality, refer to “CAB functional overview.”
Honeywell 10/04
Introduction
What is a Custom Data Block?
What is a Custom Data Block?

Overview
CDB types are similar to CAB types in that they allow the creation of a custom type that
can be instantiated multiple times. They differ in that they support the definition of
custom data parameters, but they do not support parameter references or a control
algorithm.
Creating a CDB
CDBs are created in CB. You do not need a license—CDB is a standard feature. You do
not require skill with VB.NET, as CDB does not support an algorithm.
REFERENCE - INTERNAL
For more information on CDB functionality, refer to “CDB functional overview.”
10/04 Honeywell
Introduction
Getting started tutorial

Overview of the tutorial
The tutorial illustrates the following steps:
• Creation of a CAB type, including a simple algorithm and a custom data parameter.
• Instantiation of the CAB type in a Control Module (CM).
• Assigning, loading, and activating the CM in the Control Execution Environment
(CEE).
• Monitoring the operation of the CAB instance.
• Creation of a CDB type including custom data parameters.
• Instantiation of the CDB type in a CM.
• Assigning, loading, and activating the CM in the CEE.
System requirements
Depending on your familiarity with the subject and your needs, you can skip the tutorial,
read it, or follow the steps and build the examples on your system. If you choose to build
the example, you should have an Experion system that includes a Server, a Station with
Control Builder (with CAB Developer support), and an Application Control Environment
(ACE) node. The ACE node must have a CEE configured. I/O is not required, as the
examples do not perform I/O. The tutorial assumes that ACE/CEE have already been
activated.
Honeywell 10/04
Introduction
Description of the tutorial example
ATTENTION
Control Builder familiarity is assumed.
The tutorial consists of a CAB example and a CDB example. In the CAB example, you
will perform the following tasks:
• Create a custom library called CABLIB and create a CAB type called CABDEMO in
the library.
• Configure a custom parameter called FLOW and write a simple, one-line VB.NET
program that adds a constant to the value of FLOW.
• Build and save the project.
• Create a new Control Module (CM) and create instances of your CAB and a
NUMERIC function block in the CM.
• Wire the output of the CAB to the input of the NUMERIC function block, and wire
the output of the NUMERIC to the input of the CAB, forming a simple loop.
• Load the CM to the CEE and activate it.
• Monitor execution of the strategy and observe the value of FLOW increasing.
In the CDB example, you will perform the following steps:
• Create a custom library called CDBLIB and create a CDB type called CDBDEMO in
the library.
• Configure Custom Data Parameters of various types.
• Save the type to the ERDB.
• Create a new CM and create an instance of your CDB in the CM.
• Load the CM to the CEE and activate it.
10/04 Honeywell
Introduction
The tutorial is separated into four parts:

1. Create a CAB type
2. Instantiate the CAB type in a control strategy
3. Create a CDB type
4. Instantiate the CDB type
Create a CAB type

In this section of the CAB tutorial, you will create a custom library, and within the
library you will create a custom CAB type, including:
• A custom data parameter. Custom data parameters are called value CDPs within the
CB development environment because the value of the parameter is stored within the
block as opposed to being a reference to a variable located outside the block.
• A custom algorithm—a very simple one in this case, for demonstration only.
The tutorial example does not include the configuration of parameter references,
although this functionality is available in CAB.
Honeywell 10/04
Introduction
Step Action
1 Open Control Builder with the two tree views open, upper displaying the
project view and lower displaying the library view.
10/04 Honeywell
Introduction
Step Action
2 Create a new CAB type by choosing File > New > Type > Custom Algorithm
Block.
3 Enter CABLIB as the new Custom Library Name and enter CABDEMO as the
name of the new CAB type.
Click OK.
Honeywell 10/04
Introduction
Step Action
4 The CAB Development Environment opens. The Custom Algorithm Block
splash screen appears briefly.
10/04 Honeywell
Introduction
Step Action
5 The Parameter Definition Editor (PDE) opens with the Value CDPs tab
exposed. This is where custom data parameters (value CDPs) are defined.
Enter the following data as shown.
Parameter name: FLOW
Parameter description: Demo custom parameter
Data type: FLOAT64
Access lock: OPERATOR
Configuration load: LOAD
Default value: 2.2
Save the PDE data by clicking the indicated button.
Honeywell 10/04
Introduction
Step Action
7 Click the CABlock.vb* tab to expose the VB source code window. Note that
several lines of code already exist. Add your line of code after the comment
line that begins “TODO:…” as shown. Note that Microsoft IntelliSense provides
dropdown lists to assist you as you code. Your line of code is:
Me.FLOW.Value += 3.1
8 Click the Build Solution button to compile and link your code.
10/04 Honeywell
Introduction
Step Action
9 Verify that there were no errors.
10 Click the indicated button to save the CAB type to the ERDB.
11 Click the “X” in the upper right corner to close the Microsoft Development
Environment window.
A confirmation message appears briefly.
Honeywell 10/04
Introduction
Step Action
12 The Custom Library and CAB appear in the CB Library window.
10/04 Honeywell
Introduction
Instantiate the CAB type in a control strategy

In this section of the CAB tutorial, you will create a new Control Module. You will drag-
and-drop your CAB type and a NUMERIC function block into the Control Module chart
creating instances of the CAB and NUMERIC types. You will wire the CAB and
NUMERIC forming a control strategy. You will load and activate the CM and observe
the results.
Step Action
1 In CB, select the Project view and create a new Control Module by choosing:
File > New > Control Module.
Honeywell 10/04
Introduction
Step Action
2 From the Library tree view, drag and drop your CAB type (CABDEMO) and a
NUMERIC (under UTILITY) function block into the Project chart.
This process creates an instance of your CAB type and an instance of the
NUMERIC type.
3 Double-click on your CAB instance to bring up its properties form. Click on the
Value CDPs tab and your custom parameter will be displayed. If you had
other custom parameters, they would be displayed in a list.
10/04 Honeywell
Introduction
Step Action
4 Select the Block Pins tab. In the Parameters list, select FLOW, your custom
parameter.
5 Using the CB pin addition functionality, add an input pin on the left side of the
CAB and an output pin on the bottom of the CAB. Adding the input pin is
illustrated below.
Honeywell 10/04
Introduction
Step Action
6 The completed block is shown below.
Click OK to save the configuration and close the properties form.
7 Double-click the NUMERIC block to bring up its properties form.
Change the Actual Value from NaN to 2.2 and click OK.
10/04 Honeywell
Introduction
Step Action
8 Select the Block Pins tab. In the same manner as Steps 4-6 above, select the
PV parameter, and add an input pin to the left side of the block. When you
have finished and closed the NUMERIC property form, the CM Project chart
appears as shown below.
Honeywell 10/04
Introduction
Step Action
9 Click the Wire tool button shown below.
Click once on the NUMERIC PV input pin and then click again on the CAB
FLOW output pin, wiring them together. See the illustration below.
10 In the same manner, wire the PV output pin of the NUMERIC to the FLOW
input pin of the CAB. The result appears as follows:
10/04 Honeywell
Introduction
Step Action
11 Click the “X” button in the upper right corner of the Project chart to close the
window. Click Yes when asked if you want to save changes to the Project.
12 Now assign the Control Module to the CEE.
Select your Control Module. It will be under the Unassigned node in the
Project tree view.
Honeywell 10/04
Introduction
Step Action
13 Click the Assign button on the CB toolbar.
14 When the Assignment screen appears, be sure that your new CM is selected
in the Available Modules list and that the ACE CEE that you want to load it to
is selected in the Assign To list, and then click Assign.
10/04 Honeywell
Introduction
Step Action
15 Click Close. Your CM now appears under the CEE node in the Project tree.
.
16 Click the Load button to load the CM.
Click OK to close the Load Dialog screen that appears.
17 Click the Monitor tab.
Honeywell 10/04
Introduction
Step Action
18 Double-click the CM to open the chart window.
19 Choose Controller > Activate > Selected Item(s).
20 Click Yes to confirm.
Note that the value of your FLOW parameter is increasing.
10/04 Honeywell
Introduction
Create a CDB type

In this section of the CDB tutorial, you will create a custom library, and within the
library you will create a custom CDB type, including five custom data parameters. This
CDB is used in the example “A CDB to hold sensor data” in the example scenarios
section later in this document.
Step Action
1 Open Control Builder with the two tree views open, upper displaying the
Project view and lower displaying the Library view.
Honeywell 10/04
Introduction
Step Action
2 Create a new CDB type by choosing File > New > Type > Custom Data
Block.
3 Enter CDBLIB as the new Custom Library Name and enter CDBDEMO as the
name of the new CDB type.
Click OK.
10/04 Honeywell
Introduction
Step Action
4 Enter the values as shown in the figure below. These values are also listed in
Table 55 Value CDP definitions in POSTEMPCDB, which may be easier to
read.
5 Click the “X” in the right upper corner to close the PDE.
Click Yes when prompted to save data.
6 The Custom Library and CDB type appear in the CB Library window.
Honeywell 10/04
Introduction
Instantiate the CDB type

In this section of the CDB tutorial, you will create a new Control Module and will drag
and drop your CDB type from the Library tree window into the Control Module chart.
You will load and activate the Control Module.
Note that this is an incomplete example. It is intended only to illustrate the instantiation
of a CDB, which is the same as for a CAB or native block. The CDB will not serve a
useful purpose until it is incorporated into a strategy with other blocks. For an example of
how this CDB might be used in a control application, refer to the example scenario “A
CDB to hold sensor data.”
Step Action
1 In CB, select the project view and create a new Control Module by choosing:
File > New > Control Module.
10/04 Honeywell
Introduction
Step Action
2 From the Library tree view, drag and drop your CDB type (CDBDEMO) into the
Project chart.
3 Double-click on the CDB instance to open its properties form. Select the Value
CDPs tab. Your custom data parameters will be displayed in a list.
4 Click OK to close the form.
Honeywell 10/04
Introduction
Step Action
5 Click the “X” button in the upper right corner of the Project chart to close the
window. Click Yes when prompted to save data.
6 Now assign the Control Module to the CEE.
Select the Control Module. It will be under the Unassigned node in the Project
tree.
10/04 Honeywell
Introduction
Step Action
7 Click the Assign button on the CB toolbar.
8 When the Assignment screen appears, be sure that your new CM is selected
in the Available Modules list and the CEE that you want to assign it to is
selected in the Assign To list, and then click Assign.
Honeywell 10/04
Introduction
Step Action
9 Click Close. Your CM now appears under the CEE node in the Project tree.
10 Click the Load button to load the CM.
Click OK to close the Load Dialog screen that appears.
11 Click the Monitor tab. Select the CDB in the tree view.
10/04 Honeywell
Introduction
Step Action
12 Choose Controller > Activate > Selected Item(s).
13 Click Yes to confirm. The CDB values are now available for other blocks and
can be viewed.
Additional examples
There are more advanced examples of CAB and CDB usage in the example scenarios
section of this guide.
Honeywell 10/04
CAB and CDB purpose
Purpose, use, and value of the system
CAB overview
One of your options for implementing a control strategy is to use instances of “native”
blocks. These are block types that are built in, or predefined, in Experion Control Builder
(CB). You can “customize” these native blocks by values you assign to certain
configuration parameters, but you cannot alter the basic structure of the block—the data
elements and the control algorithm.
Creating control strategies this way is efficient, as it requires only the work of creating
instances, configuring parameter values, binding the instances to other blocks, to an
execution environment, and to I/O. Many control strategies can be implemented very
efficiently with these native blocks. In some cases, however, you might find that you
cannot easily solve a control problem using native block types. When these cases arise,
you can use CAB functionality to create a new custom block type with a custom
algorithm, custom data parameters, and parameter references.
The process of creating a CAB type requires an understanding of system capabilities and
tools beyond those used for block instance creation and editing. Not least of these is the
understanding of a programming language.
After a CAB type has been created and saved within the Experion ERDB, it has a look
and feel equivalent to that of a native block type. It shows up within the library view of
CB under the name of a user assigned library. It can be instantiated on the project side of
CB by dragging from the library view to a control module chart. Once instantiated, the
instances can be configured through a parameter driven properties form. They can be
assigned and loaded as components of their parent control module. They can be
monitored from the monitor side of CB.
The fully qualified name for a CAB type consists of the concatenation of the library
name with the block type name. This means that different CAB types can be given the
same name within different libraries.
User interaction to create CAB templates is analogous to that of native block types. Thus,
an engineer can start with a CAB type and make a template directly from it. CAB
parameters can be declared "template-defining" in the same fashion as native block
parameters.
Honeywell 10/04
CAB and CDB purpose
Why use CAB?

As stated above, an important reason to use CAB is to solve new control strategies that
can be implemented most effectively by the use of a custom algorithm and custom data
parameters. There is another reason why you might wish to consider CAB. That
situation is where you have an investment in custom control programs on another
platform and wish to migrate to Experion. CAB provides the support for custom
algorithms and custom data. Existing programs can be recoded in VB.NET, which is a
powerful, yet user-friendly programming language.
CDB overview
A CDB is a control block that stores data whose type and structure are defined by the
user. CDB types are similar to CAB types in that they allow the creation of a custom type
that can be instantiated multiple times. They differ in that while they support the
definition of custom data parameters, they do not support the definition of parameter
references and they do not support the definition of an algorithm.
CDB types are simpler to create than CAB types, as they are created in the PDE and do
not require programming tools or the use of MSVS. They appear within the CB in a
library view and are dragged into control modules to create instances.
In all other respects, CDBs are analogous to CABs. They support associated properties
forms and can be designed to support loadable configuration parameters. They can be
used to create templates. Once instantiated, CDBs are configured, assigned, loaded, and
monitored in a fashion completely analogous to that of CABs and native blocks.
As with CAB types, the fully qualified name for a CDB type consists of the
concatenation of the library name with the block type name. This means that different
CDB types can be given the same name within different libraries.
Why use CDB?

CDBs are somewhat analogous to Custom Data Segments in the TPS world. A typical
use would be to pass data from one application (strategy) to another. For more
information, see “Custom Data Parameter purpose.”
Anything that you can do with a CDB, you can also do with a CAB. Why would you
choose to use a CDB rather than a CAB? Some examples are:
• You have not purchased a CAB developer license. CDB is a standard feature of CB
and is therefore available to you without a CAB license.
• You encounter a situation where CDB is supported on a given platform and CAB is
not.
Honeywell 10/04
CAB and CDB purpose
• CAB has a certain amount of .NET overhead because of its capability to support an
algorithm, and you do not need the algorithm feature.
System functions that support CAB and CDB

As with native blocks, the user view of CABs and CDBs is composed of elements
provided by different subsystems. These subsystems are summarized in the following
table.
Relationships of subsystems
The following table indicates the relationships of the major subsystems that support CAB
and CDB. In this table, read a row from left to right. For example, "Microsoft Visual
Studio .NET presents data content of ERDB" and "Engineering Repository Database
hosts Block Type, Block Template, and Block Instance."
Table 1 Relationship of subsystems that support CAB and CDB
Subsystem Relationship Subsystem
Engineering Repository Hosts Block Type, Block Template, and

Database (ERDB) Block Instance
Control Builder (CB) Edits Block Type, Block Template, and

Block Instance
Presents data content of ERDB and CEE
Provides definition to Experion Server
Control Execution Hosts Block Type and Block Instance

Environment (CEE)
Uses Microsoft .NET Run-Time Enablers
Microsoft Visual Studio .NET Edits CAB Block Type

(MSVS)
Uses Microsoft .NET Compile-Time
(CAB only) Enablers
Presents data content ERDB

(including source code) of
Experion Server Transports data content to CEE
Experion Station Presents data content of CEE and Experion Server
10/04 Honeywell
CAB and CDB purpose
Description of subsystems
The relevance of each subsystem is as follows.
• Engineering Repository Database—ERDB forms the persistent storage for all non-
run-time information related to blocks.
• Block Type—Native block types are formed from parameter definitions and
associated information. This is true for CAB and CDB types as well but the
definitions can be created and edited. The information that comprises the full
definition of a block type is somewhat distributed, with parts residing in both the
build-time and run-time environments. Within the user view, an abstraction is
presented that makes block types appear as a unified entity.
• Block Instance—Block instances are data sets. In the build environment (held by
ERDB), instances consist largely of configuration data. In the run-time environment
(held by CEE), they consist of both configuration and run-time data. Block instances
always rely on an associated block type. Block instances, like block types, are
presented to users as an abstraction that unifies the distributed parts that make up the
complete entity.
• Block Template—Block templates are data sets holding configuration data. They
are used to reduce engineering effort in the maintenance of block instances and have
similarities to both block types and block instances. Block templates exist only in the
build-time environment. Like block instances, block templates always rely on an
associated block type. Templates are supported for CAB and CDB types as well as
standard block types.
• CEE—CEE is the repository for most information of the run-time environment. This
includes both instance information and type information. For native blocks, CEE
holds the type information in an unchangeable form. For CDBs and CABs, both
instance and type information are loadable. For CABs, the type information includes
both parameter definitions and algorithm (program) definition. Block templates play
no role within CEE.
• Control Builder—Control Builder presents block instance data that is resident in

both ERDB (the "project side" of CB) and CEE (the "monitor side" of CB). CB
supports the visual editing of both block instances and block templates. CB also
supports the editing of CDB types.
Honeywell 10/04
CAB and CDB purpose
• MS Visual Studio .Net 2003—CAB types are edited with MS Visual Studio .Net
2003. This applies to both the parameter definitions of the block and the algorithm.
• Experion Server—The Experion PKS Server plays a vital role in presenting blocks
within the operational view. It holds large portions of run-time data including alarm
and history databases. It also uses system communication services to transport run-
time data from CEE block instances to operator displays. CB provides block
definition information to Experion PKS Server to enable display of operational
information.
• Experion Station—The Experion Station presents the final operator view of run-
time data. This includes alarm summary display, event journal display, detailed
displays, group display, and graphical displays. Experion Station relies on
communication with Experion Server, and, in some cases, with CEE to access run-
time data.
Within Experion Station and Experion Server, blocks are treated equivalently,
regardless of whether they are native blocks, CABs, or CDBs.
This guide does not give particular attention to CABs and CDBs within Station and
Server, as their behavior is equivalent to that of native blocks.
• MS .NET Compile-Time Enablers—CAB types are highly dependent on Microsoft

.NET software technology. One dependency is on the .NET compile-time tools
incorporated within MS Visual Studio .Net 2003. These tools are used to build source
code into modules that can be loaded to the run-time environment. CDB types do not
depend on .NET compile-time enablers.
• MS. NET Run-Time Enablers—CEE depends on Microsoft .NET software

technology to load and execute CAB types. .NET run-time enablers include the .NET
Common Language Run-time and class namespaces. CDB types do not depend on
.NET run-time enablers.
10/04 Honeywell
CAB and CDB purpose
Platform hosting of block type categories

CEE can execute on multiple platforms. However, not all categories of block types are
supported on each platform. The table below shows the categories of block types that are
supported on each platform at the time of this release.
Table 2 Platform support for block types
Block type category
Platform Native CAB CDB
C200 Yes No No
ACE Yes Yes Yes
SCE-C200 Yes No No
SIM-ACE Yes Yes (See Note 1) Yes
Note 1— The first release of SIM-ACE supports most CAB functionality. However, this
excludes bulk data access for dynamic simulation data. Dynamic simulation data is used
for freeze, backup, and replay in dynamic simulation applications.
Honeywell 10/04
CAB and CDB purpose
Role of block types, instances, and templates

Within the Experion system, control algorithms are housed in blocks. These include both
"block types" and "block instances."
A block type is a general-purpose algorithm together with a set of data definitions. Block
types are not bound to particular execution environments, particular equipment sets or
particular data values. Examples of "native" Experion block types are: CM, SCM, PID,
DataAcq, AND, and AICHANNEL.
A block instance is a rendering of a block type in application-specific form. A given
block instance is always associated with a particular block type. For any given block
type, there can be a single block instance or there can be multiple block instances. Each
instance has specific values for each datum defined for its type.
The Experion system also supports templates. Templates are distinct from types and
instances yet bear some resemblance to each. The differences between types, templates
and instances can sometimes be a point of confusion for Experion users.
For brevity, the term "type" is used to mean "block type" in the remainder of this section.
Similarly, "instance" refers to "block instance" and "template" refers to "block template."
When an instance is to be loaded and used, it must be associated with a particular
execution environment. Instances can have references to particular blocks, particular I/O,
and particular equipment sets. Instances always have names that distinguish them from
their associated types. For example, an instance of a CM might be called FC101, while
an instance of PID might be called FC101.PID1.
Like types, templates can have multiple corresponding instances. Each instance (or
"child") that descends from a template carries forward some of the characteristics
exemplified by its parent. Yet, unlike types, templates do not define the data or algorithm
they represent. Instead, they refer back to a type that maintains all data and algorithm
definitions.
Like instances, templates can establish particular values for their parameters. They can
establish particular address values for data references. Yet, unlike instances, templates
cannot be loaded to execution environments. They never maintain a correspondence with
specific field equipment.
Within Experion, it is entirely possible for engineers to build and maintain control
strategies without the use of templates. Types and instances are all that are required.
Templates add capabilities for maintaining and modifying control configurations with
reduced engineering effort. By creating a template as a modification layer between a type
and one or more instances, engineers can declare particular data values and data
references to be the same across all those instances. If common data values or references
10/04 Honeywell
CAB and CDB purpose
must change, the change can be introduced at the parent template and automatically
propagated to the off-process child instances within the project side of the ERDB.
To clarify the distinction between block types, block instances, and block templates, refer
to the figure below.
Figure 1 Block types, block instances, and block templates
In the diagram, a single type is shown called "Type." Type has instances and templates
that descend from it. The direct descendants are Instance 1 and Template 1. Instance 2
and Instance 3 are indirect descendants of Type through Template 1. In general, it is
possible to have no templates between an instance and its type or to have multiple
templates between an instance and its type. To further illustrate consider the following
examples.
• Instance Creation From Type—An engineer decides to create a CM instance for

purposes of flow control. The engineer calls it "FC101." Within FC101, the engineer
creates a PID and calls it "PID1." Its fully qualified name is "FC101.PID1."
In this example, FC101.PID1 is analogous to Instance 1 with PID in the role of Type.
Honeywell 10/04
CAB and CDB purpose
• Template Creation From Type—Later, the engineer decides that something similar
to FC101 would serve as a good starting point for other flow controllers. The
engineer creates a template CM and gives it the name "FC." The engineer inserts a
PID into FC and calls it "PID1." The engineer assigns some of the parameters of
FC.PID1 to be "template defining."
In this example, FC is analogous to Template1 with CM in the role of Type.

Similarly, FC.PID1 is analogous to Template1 with PID in the role of Type.
• Instance Creation From Template—Later still, the engineer decides to create some
new flow controller instances. To save work, the engineer doesn't start from the types,
CM and PID. Instead, the engineer starts from the template, FC. The engineer creates
an instance of FC called FC102. By so doing, the engineer implicitly creates the
instance FC102.PID1. The engineer also creates an instance of FC called FC103. By
so doing, the engineer implicitly creates the block instance FC103.PID1. FC102 and
FC103 acquire their structure from the parent template FC. FC102.PID1 and
FC103.PID1 acquire template-defining data from the parent template from FC.PID1.
In this scenario, FC102.PID1 is analogous to Instance 2 while FC103.PID1 is

analogous to Instance 3.
Types, instances, and templates are each distinct. But templates are closer to being
instances than they are to being types. Instances and templates each depend on an
association with a known type to have their identity fully defined. The main difference
between an instance and a template is that the template has particular parameters, or
particular structural characteristics, fixed over the category of instances that they govern.
It is important to understand that while templates can be created from types, and instance
can be created from either types or templates, types must be created through a completely
independent mechanism as described in “Create a new CAB type.”
10/04 Honeywell
CAB and CDB purpose
CAB functional overview

Overview
A CAB type represents the same concept as a “class” in modern object-oriented software
terminology. Instances made from CAB types can be thought of as “objects.” A class can
be thought of as a library model or template, a “master” from which specific usable
instances can be created and deployed. Within the concepts of Experion and CEE, the
user-visible entities tend to be called “block types” and “block instances” rather than
“classes” and “objects.”
As with any class, a CAB type is fundamentally characterized by the following two parts:
• A set of data definitions
• An algorithm definition
Also, as with any class, a CAB type is defined by a program. However, due to its
integration with the PKS name space, the program of a CAB type does not express the
complete definition. In particular, you must define much of the data of a CAB outside the
source code you write for the program.
How a CAB works

The user's experience of CABs is generated through a combination of various services
and subsystems. Each subsystem can be thought of as an "agent" that adds capabilities to
the overall function set. The two tables below summarize the complete set of agents.
The first table, Table 3 Custom Algorithm Blocks in build-time environment,"
emphasizes agents that play a vital role in the creation and editing of block types and
block instances. This includes the ERDB as the central off-process database. It includes
various displays, as well as subsystems that are not directly visible within the user view.
The diagram also shows some agents that play a role in both build-time and run-time
operations.
The second table, Table 4 Custom Algorithm Blocks in run-time environment," shows
subsystems that play a vital role in the run-time operations of CABs. For context, it also
shows some agents whose purpose primarily serves the build-time environment.
In these tables, read rows from left to right to determine the relationships. For example,
"Control Builder (CB) presents data content of ERDB.”
Following the tables, each agent is described in detail.
Honeywell 10/04
CAB and CDB purpose
Table 3 Custom Algorithm Blocks in build-time environment
Agent Function Agent
Control Builder (CB) Presents data content of ERDB
Opens MSVS
Hosts Library Tree, Project Tree, Monitor

Tree, CM Project Chart, CM Monitor
Chart, and CAB Properties Form
Microsoft Visual Studio Hosts PDE Window and Source Code Window
.NET (MSVS)
Presents data contents of ERDB
Parameter Definition Edits Parameter Definitions

Editor (PDE) Window
Source Code window Edits Algorithm Definition
Library Tree Shows symbol of Custom Library
Project Tree Shows symbol of CAB Instance – Project
Monitor Tree Shows symbol of CAB Instance – Monitor
CM Chart – Project Shows symbol and data of CAB Instance – Project
CM Chart - Monitor Shows symbol and data of CAB Instance – Monitor
Custom Library Groups CAB Types
CAB Type Consists of Parameter Definitions and Algorithm

Definition
Defines CAB Properties Form
CAB Instance - Project Is one of CAB Type
CAB Instance - Monitor Is one of CAB Type
CAB Properties Form Edits data of CAB Instance – Project and CAB
Instance – Monitor
Views data of CAB Type – Library
Development Folder Caches Parameter definitions and Algorithm

definitions
10/04 Honeywell
CAB and CDB purpose
Table 4 Custom Algorithm Blocks in run-time environment
Hosts Control Module Chart –

Monitor, CAB Properties Form,
and CEE Block Properties Form
Control Module Chart – Shows symbol and data of CAB Instance - Monitor
Monitor
Shows Control Module - EE
CAB Properties Form Edits data of CAB Instance – Monitor
CEE Block Properties Form Shows system data of CEE
Has tab CAB Library Directory Form
CAB Library Directory Form Shows Custom Library
ACE Platform Hosts CEE
CEE Hosts Custom Library and Control

Module – EE
Custom Library Hosts CAB Type
CAB Instance – Monitor Is one of CAB Type
Shows CAB Instance - EE
CAB Instance – EE Is one of CAB Type
Control Module – EE Hosts CAB Instance – EE
CAB Type Defines CAB Properties Form
Honeywell 10/04
CAB and CDB purpose
Table 5 Agents supporting CABs in build-time and run-time environments
Agent Operating Description

environment
Engineering Build-time Provides persistent storage for all block types and
Repository DB block instances.
This applies to native blocks, CABs, and CDBs. Holds

CAB programs across edit sessions. Holds CAB
programs after they are complete and ready for load
to an EE.
Control Builder Build-time and Central agent that manages view and edit of block
run-time instances.
This applies to native blocks, CABs, and CDBs. CB

and its underlying services present data content of the
ERDB. CB hosts various different views and displays.
These include the Library Tree, the Project Tree, the
project side CM chart, the Monitor Tree, the monitor
side CM chart and the CAB Properties Form. CB
supports the opening of MS Visual Studio .Net 2003
for purposes of CAB type editing.
MS Visual Studio Build-time Integrated Development Environment that plays

.Net 2003 central role in the viewing and editing of CAB types.
MSVS and associated CAB services present data

content of the ERDB. To support block type editing,
MSVS hosts two main types of windows: the
Parameter Definition Editor Window and the Source
Code Window.
Parameter Build-time Window through which user defines and edits

Definition Editor parameter definitions of a block type.
Window
Also edits parameter references. Also allows
specification of attributes of block properties form and
block faceplate symbol.
10/04 Honeywell
CAB and CDB purpose

environment
Parameter Build-time Descriptions of public and custom data of the block.

definitions
Parameter definitions associated with CAB types are
different from those of native block types in that they
are under the control of the user. They are called
custom data parameters (CDPs, or value CDPs).
Parameter definitions establish the name, data type
and other attributes of parameters.
Algorithm definition Build-time The CAB program.
Source code Build-time Edit window through which Control Engineer (CE)
window creates and edits the source code program that is the
CAB algorithm.
CEs can use one or several source code windows to

create and maintain CAB source code.
Development folder Build-time Cache area used to hold block type definitions during
edit sessions.
The Development folder is located on the PC where

CB and MSVS run. Ordinary "Save" operations
commanded at MSVS write the algorithm and
parameter definitions to this location. Ordinary Save
must be distinguished from "Save To ERDB," which
transfers the block type definition from the
Development Folder to ERDB. The Development
folder holds block types while MSVS is open. Block
types must be transferred to ERDB before MSVS is
closed (MSVS prompts for Save To ERDB before
closing). CAB services do not preserve the contents of
the Development folder across MSVS shutdown or
across PC shutdown and startup.
CAB Type Build-time and Logical union of the parameters and algorithm that
run-time define the CAB.
Also defines the CAB Properties Form. The user view

of the CAB Type comes from a combination of system
enablers, some in the build-time and some in the run-
time. The complete type definition is comprised of
data and program stored within ERDB and (after load
of at least one instance) the EE.
Honeywell 10/04
CAB and CDB purpose

environment
Library Tree Build-time View hosted by CB that shows libraries and the block
type they hold.
Native block types are held in system libraries while

CAB and CDB types are held in custom libraries.
Custom Library Build-time and A logical grouping of user-created block types.

run-time
Whereas native block types are held within system
libraries, CAB and CDB types are held within custom
libraries. Custom libraries provide an additional layer
of naming for block types that can help with resolution
of name collisions that might occur during import to a
new ERDB. Within the Library Tree, custom and
system libraries are distinguished by different icons.
Within a custom library, CAB and CDB types are
distinguished by different icons.
Project Tree Build-time View hosted by CB that shows block instances held
on the project side of ERDB.
The project tree is a hierarchical view that shows

SCMs, CMs and the function blocks they contain. This
includes native block instances, CAB instances, and
CDB instances. CB and ERDB maintain a distinction
between "project side" data and "monitor side" data.
Project side data correspond to instances that are
under edit and have not been deployed within the
runtime system. Monitor side instances map directly to
runtime instances within EEs.
CM Chart – Project Build-time A graphical display showing the internal

representation of a project-side CM.
It shows symbols and data of the blocks as stored in

ERDB as well as graphical connections. CM chart –
Project shows both native and CAB instances.
CAB Instance – Build-time Instance of a CAB held in ERDB for configuration

Project activities.
This is to be distinguished from the monitor-side

instance. When shown within a CM chart, the ERDB
data is presented rather than the run-time data.
10/04 Honeywell
CAB and CDB purpose

environment
Monitor Tree Build-time and View hosted by CB that shows block instances held
run-time on the monitor side of ERDB.
State data and other data shown within the monitor

tree correspond to the loaded run-time instances of
the blocks depicted.
CM Chart – Monitor Build-time and A graphical display showing the internal

run time representation of a monitor-side CM.
Shows symbols and data of the EE resident blocks as

well as graphical connections. CM chart – Monitor
shows both native and CAB instances.
CAB instance – Build-time and Monitor-side instantiation of a CAB type.

Monitor run-time
Is created from the project-side instance at the time of
parent CM load. It is viewed from within the parent
CM's chart using CB or using chart visualization in
Station. Data read or written from CAB Instance –
Monitor corresponds to run-time data within the EE.
CAB Properties Build-time and One of the chief displays used to view and
Form run-time manipulates CAB data.
There is a different form for each block type. The form

can be used to edit and view both project-side and
monitor-side data, and view CAB type data in the
Library. When viewed from the project side, writes go
to the ERDB. When viewed from the monitor side,
writes go to the EE block instance. The form is
frequently used for assigning configuration data before
load. It can be used exclusively for monitoring if the
block has no loadable parameters. The form can be
viewed from within Control Builder. It can also be
viewed from Station displays via chart visualization.
Honeywell 10/04
CAB and CDB purpose

environment
CEE Block Run-time Form showing data associated with the CEE as a
Properties Form whole.
This form is logically associated with the CEE function

block which hosts CEE-wide parameters. CEE Block
Properties Form plays a role in the configuration of the
CEE. For CAB however, it is only used in connection
with the run-time environment.
CAB Library Run-time CAB Types Info tab on CEE Block Properties Form
Directory Form that shows CAB instances loaded to a CEE.
The form displays (1) the label “Instantiated CAB

Types” followed by the number of CAB types that
have a least one instantiation, (2) the label “Max
Instantiated CAB Types” followed by the maximum
number of CAB types that can be instantiated at any
one time, and (3) a grid box showing the friendly name
of each instantiated CAB type and the number of
instances of each instantiated type.
ACE platform Run-time Platform that hosts CEEs capable of supporting CABs.
In the first release, there are no other platforms

capable of hosting CABs.
CEE Run-time A logical operating environment providing execution

services to both native blocks, CABs, and CDBs.
Control Module – Run-time Runtime resident module block hosting continuous

EE type function blocks.
EE-resident control modules (called "Control Module –

EE” in the table) host CAB instances, CDB instances,
and all native block instances except those of the
SCM library. CABs run within Control Modules but not
within Sequence Control Modules.
10/04 Honeywell
CAB and CDB purpose

environment
CAB Instance – EE Run-time Run-time instantiation of the CAB type.
EE-resident CAB instances (called "CAB Instance –

EE” within the table") actually hold the run-time data
and do the run-time execution of CABs. CAB
instances are always associated with generic
programs. All references that bind the block to specific
equipment and specific external function blocks are
contained within the instances.
CAB data characteristics

There are different categories of data that can be used within a CAB. They differ
according to persistence, visibility, and where they are stored.
• Fixed definition parameters—Parameters that are defined by the system. Some
FDPs are for internal use only and are of no concern to users. Others are known to
users and are used either at the time of block type creation, block instantiation or
both. Some of these parameters appear on the fixed tab of the Parameter Definition
Editor in the MSVS Development Environment within Control Builder, where you
are able to specify a default value. Specific FDPs supported by CAB types are
described in the section “Fixed definition parameters.”
• Parameter references—These are traditional process control data elements that
exist external to the CAB but whose values can be used within the CAB. Parameter
references are configured on the Parameter References tab of the Parameter
Definition Editor in the MSVS Development Environment within Control Builder.
• Custom data parameters—These parameters are also known as value CDPs, and
are configured by the user on the Value CDPs tab of the Parameter Definition Editor
in the MSVS Development Environment within Control Builder. CDPs are variables
visible within the program and within the PKS as a whole. They are "public" in that
any agent that has access to the PKS name space can read them. Similarly, CDPs can
be written by any PKS agent subject to store access checks specified by the block
designer. For more information on CDPs, see the section “Define CAB type
parameters.”
• Block scope variables— Block scope variables are like CDPs in that they are
persistent and are retained across block executions. They differ in that they are not
visible within the namespace of the PKS. Thus, they never "appear" on the "surface"
Honeywell 10/04
CAB and CDB purpose
of the block. Since block scope variables are visible only within the CAB program,
their use is a matter private to the CE who creates the CAB type. For more
information on block scope variables, see the section “Define block scope variables.”
• Local variables—These variables are declared within the Execute() subroutine that
is included in the skeleton code framework supplied by Honeywell. The Execute()
subroutine is where you insert your custom algorithm code. Values of local variables
are not persistent from one block execution to the next. For more information on
Local Variables, see the section “Define local variables.”
CAB algorithm characteristics

Algorithms are defined in the CABlock.vb tab of the MSVS Development Environment
within Control Builder. On this page, Honeywell provides a skeleton application that
includes an Execute() subroutine. You insert your application code under this subroutine.
The Execute() subroutine can be configured to execute under control of the host CM, or
it can be used as an insertion point algorithm for another component block such as a PID.
For more information on CAB algorithm definition, see the section “Algorithm definition
– Execute().”
10/04 Honeywell
CAB and CDB purpose
CDB functional overview

Overview
A CDB is basically a CAB without an algorithm and without parameter references. CDB
types are useful in a wide variety of applications. They can be used to hold data that is
shared by multiple block instances within a CM or across multiple CMs. They can be
used in conjunction with both native blocks and CABs. They can be used as a more self-
documenting alternative to flags, flag arrays, numerics and numeric arrays.
How a CDB works

As with CABs, the CE interacts with various agents when creating and using CDBs.
Build-time and run-time agents important to CDBs are shown in the following table. In
this table, read a row from left to right. For example, “Control Builder (CB) Presents data
content of ERDB.”
Honeywell 10/04
CAB and CDB purpose
Table 6 Custom Data Blocks in build-time and run-time environments
Hosts Library Tree, Project Tree, Monitor Tree,

CM Project Chart, CM Monitor Chart,
CDB Properties Form, and the
Parameter Definition Editor Window
Parameter Definition Edits Parameter Definitions

Editor (PDE) Window
Library Tree Shows symbol of Custom Library
Project Tree Shows symbol of CDB Instance – Project
Monitor Tree Shows symbol of CDB Instance – Monitor
CM Chart – Project Shows symbol and data of CDB Instance – Project
CM Chart - Monitor Shows symbol and data of CDB Instance – Monitor
Shows Control Module - EE
Cxxx and ACE Platforms Host CEE
CEE Hosts Control Module - EE
Custom Library Groups CDB Types
CDB Type Consists of Parameter Definitions
Defines CDB Properties Form
CDB Instance - Project Is one of CDB Type
CDB Instance - Monitor Is one of CDB Type
Represents CDB Instance - EE
CDB Properties Form Edits data of CDB Instance – Project and CDB
Instance – Monitor
Views data of CDB Type – Library
Control Module - EE Hosts CDB Instance - EE
10/04 Honeywell
CAB and CDB purpose
System agents relevant to CDBs are generally a subset of those relevant to CABs. Agents
common to the two categories generally have the same meaning and usage in each case.
However, there are some differences that are highlighted in the table below.
Table 7 Agents supporting CDBs in build-time and run-time environments
Agent Description
Control Builder CB hosts all services for creation and edit of CDB types.
Control Builder plays largely the same role for CDBs that it does for
CABs. One difference is that MSVS plays no role in the creation
and edit of CDB types. Thus, Control Builder does not open MSVS
in order to start edit sessions for CDB types.
Parameter For CDB types, the Parameter Definition Editor window is hosted
Definition Editor directly within Control Builder.
Window
For CAB types there is an advantage to hosting the Parameter
Definition Editor window within MSVS. This allows an integrated
application to be the seat of both the data complement and
algorithm complement that make up a CAB type. Since there is no
algorithm in CDB types, it is most natural for the CE to edit the type
in the same application where the CE edits the instance.
CDB Type CDB types consist of parameter definitions with no algorithm

definition.
Custom Library CDB Types are grouped by custom libraries in the same fashion as
CAB types.
Custom libraries are useful in that they provide an additional layer

of naming that can help when resolving name collisions upon
import to a new ERDB. One way in which CDBs and CABs differ is
that for CDBs, custom libraries have no role to play in the run-time
environment. The type definition of CDBs is held within each
instance in the run-time environment. Thus, there is no
dependence on a library for hosting of CDB types or unloading of
CDB types.
CDB Instance - As with CABs, CDB instances are held on the project side of the
Project ERDB when they are being created or edited.
CDB Instance – CDB Instances are held on the monitor side of the ERDB after they
Monitor have been loaded and reside in an EE.
Honeywell 10/04
CAB and CDB purpose
Agent Description
CDB Properties As with CABs, there is a CDB properties form that is defined by the
Form CDB type.
This form can be used to edit the project side instance or the
monitor side instance. It can be used to view CDB type data in the
Library. It can be used to display view-only parameters as well as
configuration parameters. It can be viewed from within CB or from
within Station displays via Experion chart visualization.
CDB Instance – CDB instances within an EE form the repositories for actual run-
EE time data.
Note that CDB Instance – Monitor, though it is logically considered

part of the run-time environment, is not used in any fashion by
control algorithms at runtime. It holds ERDB data that must be
preserved to represent CDB Instance – EE. The instances can be
used by control algorithms of CABs through connections or
parameter references. They can also be part of control strategies
with other native blocks involving connections.
CDB Library CDB Types Info tab on CEE Block Properties Form that shows
Directory Form CDB instances loaded to a CEE.
The forms displays (1) the label “Instantiated CDB Types” followed
by the number of CDB types that have a least one instantiation, (2)
the label “Max Instantiated CDB Types” followed by the maximum
number of CDB types that can be instantiated at any one time, and
(3) a grid box showing the friendly name of each instantiated CDB
type and the number of instances of each instantiated type.
10/04 Honeywell
CAB and CDB purpose
CDB data definition characteristics

• Fixed definition parameters—Parameters that are defined by the system. Unlike
CABs, CDBs do not have FDPs for which the user can define default values when the
CDB type is defined in CB. Therefore when the PDE is open for CDB definition, it
does not have the Fixed tab that is present for CAB definition.
• Custom data parameters—These parameters are also known as value CDPs, and
are configured by the user on the Value CDPs tab of the Parameter Definition Editor
within Control Builder. CDPs are variables visible within the PKS as a whole. They
are "public" in that they can be read by any agent that has access to the PKS name
space. Similarly, CDPs can be written by any PKS agent subject to store access
checks specified by the block designer. For more information on CDPs, see “Define
CDB custom data parameters.”
Honeywell 10/04
CAB and CDB system planning and design
System architecture

System architecture
Role of CAB and CDB in system architecture
CAB and CDB are elements of the Experion system. They adhere to the architecture of
the Experion system, which involves:
• Building control strategies within Control Modules, using the Control Builder
development tool.
• Executing the strategies in a Control Execution Environment.
CAB and CDB provide the ability to build custom applications that are tightly integrated
with the Experion system.
CAB and CDB have similarities to components of the TPS system, as shown in the
following table:
Table 8 Comparisons of Experion and TPS architectures
Experion component TPS component Function
Control Builder (CB) DEB or TPS Builder Tools for building control
strategies.
Custom Algorithm Block Control Language (CL) Allows development of

(CAB) custom control algorithms.
Custom Data Block (CDB) Custom Data Segments Provides custom data
(CDS) storage.
Application Control Application Module (AM) Host’s execution of

Environment (ACE) applications.
10/04 Honeywell
System architecture
System requirements
• Minimum CAB Developer Requirements—The CAB product requires the
following to allow users to develop CABs:
− Control Builder
− Experion Server
− CAB Developer license and components
− Microsoft's Visual Studio .Net 2003 (included within the CAB-Developer
package)
• Highly Recommended—SIM-ACE node for off-process CAB debug in conjunction
with MSVS debugger (see “Off-process debugging”)
• Minimum CAB User Requirements—The CAB product requires the following to
allow a CAB to be loaded to an ACE CEE and executed within an ACE CEE:
− Control Builder
− ACE (hardware and software with latest ACE CEE version that supports the
CDB and CAB function)
− Experion Server
− CAB runtime components (included with the ACE Base licensing)
• Minimum TPS Interoperability Requirements
− The most current TPN Release (currently R65x)
− Control Builder
− ACE (with latest ACE CEE version that supports the CAB and CDB function)
− Experion Server
− CAB runtime components (included with the ACE Base licensing)
Honeywell 10/04
System architecture
• Minimum CDB Developer Requirements—The CDB product requires the

following to allow users to develop CDBs:
− Control Builder
− Experion Server
• Minimum CDB User Requirements—The CDB product requires the following to
allow a CDB to be loaded to an ACE CEE and executed within an ACE CEE:
− Control Builder
− ACE (hardware and software with latest ACE CEE version that supports the
CDB and CAB function)
− Experion Server
• Minimum TPS Interoperability Requirements
− The most current TPN Release (currently R65x)
− Control Builder
− ACE (with latest ACE CEE version that supports the CAB and CDB function)
− Experion Server
10/04 Honeywell
Computers and network infrastructure

Hardware requirements for CAB and CDB
For hardware information, refer to the SCN and/or Spec and Tech that is applicable to the
release.
ATTENTION
ACE hardware must have at least two gigabytes of memory.
An important part of your hardware planning is to determine:

• The number of ACE nodes that you will need.
• The number of CB clients that you will need for CAB and other strategy
development.
• The number of CAB Developer licenses that you will need.
Clearly, these choices will depend on the level of your CAB, CDB, and native block
development and use. If you subcontract your CAB development, or are at a location
where you import your CAB instances, you only need to be concerned with ACE issues.
Honeywell recommends SIM-ACE node(s) for off-process CAB debug. SIM-ACE is
ACE in the simulation mode. SIM-ACE can have the MSVS debugger attached for
source code debug, whereas ACE cannot. A separate SIM-ACE node allows you to
develop and debug CAB programs independent of your on-process operations. Refer to
“Debug with SIM-ACE” for SIM-ACE information. For your planning purposes, note
that a dual-processor node will support up to four SIM-ACEs, while a single-processor
node will support up to two SIM-ACEs.
To determine your ACE node requirements, try to estimate your anticipated CAB usage.
Refer to “Determine ACE processing requirements,” “Determine ACE memory
utilization,” and “Determine ACE shutdown horizon” topics that follow for guidance on
ACE loading considerations.
To determine the number of CB nodes that you will require, try to estimate your
anticipated CB development activity, especially the total number of developers who will
be doing concurrent development work. At this time, a server will support a maximum of
eight concurrent CB connections. In addition, you must have enough CAB Developer
licenses to support the maximum number of developers who will be doing concurrent
CAB development activity on some or all of these CBs. These licenses are “floating” in
the sense that they are not associated with a particular CB node, but the total number of
Honeywell 10/04
CBs that have the integrated MSVS application open for CAB development cannot
exceed the number of licenses.
Software environment requirements for CAB and CDB

• CAB Build Time—For the build-time environment, CABs require the following
software.
− Experion Server—Hosts the ERDB where CAB type definitions are stored.
− Experion Control Builder—Experion CB incorporates a wide array of build-
time services. These include enablers for compile and build of CAB types and
instances, for parameter definition editing and others. CAB build-time enablers
are independently licensable but are installed as part of CB.
− Microsoft Visual Studio .Net 2003—MSVS is distributed by Honeywell to its
customers as part of the overall CAB build-time solution.
− Microsoft Windows OS— For specific OS requirements, refer to the SCN
and/or Spec and Tech that is applicable to the release.
• CAB Run Time—For the run-time environment, CABs require the following
software.
− Experion ACE—Experion PKS ACE provides a wide array of run-time
services. This includes enablers for the load and execution of CAB types and
instances. CAB run-time enablers are included with the ACE Base license and
are installed as part of ACE.
and/or Spec and Tech that is applicable to the release. Microsoft .NET
Framework 1.1 which includes .NET CLR is one of the required enablers for
CAB run-time services.
• CDB Build Time—For the build-time environment, CDBs require the following
software.
− Experion Server—Hosts the ERDB where CDB type definitions are stored.
− Experion Control Builder—CB includes enablers for the definition and build
of CDB types and block instances. CDBs are not a separately licensable option,
and therefore build-time enablers are included with every CB.
10/04 Honeywell
• CDB Run Time—For the run-time environment, CDBs require the following
software or firmware
− Experion ACE—ACE includes enablers for the load and execution of CDB
types and CDB instances. CDBs are not a separately licensable option, and
therefore run-time enablers are included with every ACE.
Review the sizing of ERDB

The ERDB uses SQL Server, and sizing is not a concern for CAB.
Determine ACE processing requirements

Preliminary measurements by the CAB development team indicate that an ACE can run
approximately 300 medium-sized CAB instances (see Table 11) with a 0.5 second
execution interval at a 60% load.
TIP
Refer to “Resource management” in this guide for methods of monitoring CPU
utilization.
Determine ACE configuration limits for CAB types and instances

The following table gives the limits on the number of types and instances that can be
configured on an ACE with two gigabytes of memory. It also includes the maximum
number of off-node peer-to-peer parameter reference stores.
Honeywell 10/04
Table 9 Configuration limits for CAB types and instances
Item Typical Maximum Comment

count count
Loaded 200 400 This limit is enforced. CAB infrastructure (ACE

1
instantiated loader) prevents the number of instantiated block
3
CAB types types from growing beyond 400 .
The maximum count of instantiated CAB types is

enforced because it corresponds to the count of
programs actually in use. Each must be physically
resident within PC memory.
CAB 5 100 This limit is not enforced; it is a Honeywell

2
instances per recommended limit.
type
The maximum count of CAB instances is not
enforced because CAB instances can be deleted
and their memory recovered without shut down of
the ACE.
Total CAB 1000 2000 This limit is enforced. CAB infrastructure (ACE
instances loader) prevents the total number of CAB
across all instances from exceeding 2000.
types
Off-node 20 101 Enforced limit of 101 off-node peer-to-peer

peer-to-peer parameter reference stores for an ACE.
parameter
reference
stores
Notes:
1. An instantiated CAB type is one that has one or more instances defined against it within
the CEE.
2. This policy allows users to trade off available memory so that the instance count for
specific types can go somewhat in excess of 100.
3. You can have 400 CAB instantiated types and 400 CDB instantiated types. These limits
are independent of each other and these limits are both enforced.
10/04 Honeywell
Summary of CAB configuration limits

• There are no enforced limits for how many CAB types can be stored in the ERDB.
• There are no enforced limits for how many CAB instances can be stored in the
ERDB.
• There is an enforced limit of 400 CAB types loaded to any single ACE CEE.
• There is an enforced limit of 2000 CAB instances loaded to any single ACE CEE.
Although these numeric limitations are important, they are usually overshadowed by
subsequent memory capacity, execution performance, or shutdown horizon
considerations.
Determine ACE configuration limits for CDB types and instances

The following table gives the limits on the number of types and instances that can be
configured on an ACE with two gigabytes of memory.
Table 10 Configuration limits for CDB types and instances
Item Typical Maximum Comment

count count
Loaded 200 400 This limit is enforced. CDB infrastructure (ACE

1
instantiated loader) prevents the number of instantiated block
2
CDB types types from growing beyond 400 .
CDB - - CDB does not have an enforced instance limit.

instances per The CDB instance limit is determined by the ACE
type user memory pool (32 MB total for the ACE
memory pool).
Notes:
1. An instantiated CDB type is one that has one or more instances defined against it within
the CEE.
2. You can have 400 CAB instantiated types and 400 CDB instantiated types. These limits
are independent of each other and these limits are both enforced.
Honeywell 10/04
Determine ACE memory utilization

Memory utilization for CAB and CDB is a more complex topic than it is for native
blocks. For this discussion we need some simple definitions. These definitions are not
precise .NET definitions, but are suitable for this discussion and for planning purposes.
OS Memory: This memory is a part of the memory managed by the Operating

System. A typical size for this memory for an ACE is 2GB.
CEE Memory Pool: This memory is a part of the CEE executable, and is managed
by the CEE. The size of this memory in current CEEs is 32MB.
Recoverable: Memory labeled as recoverable can be returned for later use,

when it is no longer needed for type or instance storage.
Unrecoverable: The opposite of recoverable. Memory labeled as unrecoverable

cannot be returned for later use. An ACE node reboot is
required to “recover” unrecoverable memory.
CAB applications use these types of memory:

• Unrecoverable OS Memory
• Recoverable OS Memory
• Recoverable CEE Memory Pool
The following table compares typical memory usage for some arbitrary typical CAB
application size categories:
Table 11 Memory requirements for small, medium, and large CABs
CAB size Lines of Number of Number of CAB type CAB

category code CDPs PRefs size (KB) instance size
(KB)
Small 20 1 10 73 31
Medium 100 15 50 74 61
Large 200 30 100 84 103
CAB type memory comes from unrecoverable OS memory. We will discuss the use of
unrecoverable OS memory in the topic “Determine ACE shutdown horizon.” From the
table above, we can see that CAB type memory size does not vary dramatically between
small and large CAB types. Much of the size of a CAB type is taken up by the built-in
CAB functionality, rather than the user-developed code or parameter definitions.
10/04 Honeywell
CAB instance memory comes from recoverable OS memory. From the table, we can see
that the CAB instance memory size is tied to both the number of lines of code, and the
number of parameters.
In addition to the OS memory, each CAB instance also consumes about 3KB of
recoverable CEE memory pool memory. The exact size of this consumed memory is
variable, but is usually close enough to 3KB that 3KB is a good rule of thumb for
planning purposes. With 32MB of CEE memory pool memory available for CAB and
native block instance memory, this is rarely the driver for planning decisions.
CDBs use recoverable CEE memory pool memory. A medium size CDB will consume
approximately 1.5KB of this memory. A medium size CDB is defined as containing 15
CDPs, of which two are arrays, as follows:
• Five 32 character STRING
• Four scalar FLOAT64
• Four scalar BOOLEAN
• One 20-element FLOAT64 array
• One 20-element BOOLEAN array
Determine ACE shutdown horizon

CAB instance memory is reclaimed when the instance is deleted, for both the recoverable
OS memory and the CEE memory pool memory associated with the instance.
Each time a CAB type is modified and the instance is loaded into the CEE, unrecoverable
OS memory is used. The unrecoverable OS memory used for the old CAB type cannot
be reclaimed until the ACE node is shut down and restarted. Thus, unrecoverable OS
memory gets used up as new CAB types are added and loaded, and when existing types
are modified and reloaded. Eventually, the ACE will need to be shut down and restarted
to reclaim the memory used by obsolete CAB types.
The system is designed such that under normal to heavy CAB engineering activities,
shutdown and restart will not be required for at least two years. The following table
shows a calculation of estimated memory usage at the end of two years for medium sized
blocks.
Honeywell 10/04
Table 12 ACE memory usages after two years for medium-sized CABs
Item Maximum count Maximum memory

required (KB)
Total instantiated CAB Types reloaded in ACE 400 types x 30 reloads 12000 x 74 = 888,000
during debug sessions. = 12000 (See Note 1)
Total instantiated CAB Types reloaded in ACE 400 types x 3 reloads 2400 x 74 = 177,600
during maintenance cycle. x 2 years = 2400
Total CAB instances allowed to be loaded at 2000 2000 x 61 = 122,000

one time
ACE + .Net Runtime + CAB runtime Loaded once 12,000
Total memory 1,187,600 (1.13 GB)

(See Note 1)
Note 1—If you are using SIM-ACE for debug, the memory consumed during reloads of types is
reclaimed when you shut down the SIM-ACE and therefore should not be included in the total
memory figure.
TIP
Refer to “Resource management” in this guide for methods of monitoring
memory utilization.
ATTENTION
Refer to “ACE shutdown procedure for reclaiming CAB memory” for the
procedure to reclaim memory.
ATTENTION
Honeywell strongly advocates the use of SIM-ACE for debug because of the
security advantage and the ability to use the MSVS debugger. However, if you
do choose to debug on ACE and then use the same ACE for production, you
should do a shutdown before going on line, thereby reclaiming memory.
10/04 Honeywell
Security policy
Security policy
User access
User access to build tools for creating CAB and CDB types is controlled by the same
security policies that govern access to CB. Basic access to CB is controlled by logon
password. A developer license is required to access CAB development tools within CB.
Refer to “CAB Developer license” for additional information.
User access to CAB instances and CDB instances is controlled by the same security
policies that govern access to native blocks.
CDP Access Lock attribute

Like native block parameters, custom data parameters have an additional level of access
control, the Access Lock attribute. This attribute is configured when the CAB or CDB is
created and cannot be changed thereafter except by editing the block type and reloading
instances. See “Access Lock attribute for CDPs” for details.
SIM-ACE and the MSVS debugger

The MSVS source level debugger should never be attached to an on-process ACE because of the
possibility of debugger activity freezing control processing. The best way to prevent this
possibility occurs at ACE installation time. You will be given a choice of whether or not to
install the remote debugger. You can choose to install this option only on nodes that will be
running SIM-ACE but not ACE. If the debugger is installed on a node that is configured as ACE
and the Machine Debug Manager (MDM) remote debug service runs, an ACE alarm is generated
stating that the MDM service is running, If this occurs, the MDM service should be stopped and
disabled from Control Panel > Administrative Tools > Services to prevent any possibility of a
CAB remote debug session attaching to an on-process ACE.
When using the MSVS debugger, you create a debug version of the CAB program by building
to the “debug target” in MSVS. You debug the CAB program in the SIM-ACE environment,
which is an off-process environment, and therefore isolates the debug activity and safeguards
against disruption of on-process functions. When debug is complete, you create a release
version of the CAB program by building to the “release target” in MSVS. You should do a final
test on SIM-ACE using the release version to ensure that the program still works as intended.
Then, you deploy the release version to the on-process environment. For more information, see
“Off-process debugging.”
Some CAB programs can be debugged without using the MSVS debugger. But in other
cases the debugger will be a useful tool for CAB development. In order to use the
debugger, CAB programs must be loaded to an ACE that is configured to be in the
simulation mode, called SIM-ACE. SIM-ACE is never used for on-process control. For
more information about SIM-ACE, see “Debug with SIM-ACE.”
Honeywell 10/04
CAB and CDB type planning and design
Control strategy
Determine that CAB and CDB are needed
You must determine if CAB and/or CDB are appropriate for your control requirements.
The topics in the section “Purpose, use, and value of the system” will be helpful in
making these decisions.
Develop strategies
Assuming you determine that CAB and/or CDB represent the most effective architecture
to solve some of your control requirements, you must develop, at least at a conceptual
level, the strategies that you will use to implement the solutions. We suggest that you
review the example scenarios section of this guide. The example scenarios section
presents a number of examples of the application of CAB and CDB to typical control
scenarios.
At an early stage, you will begin to formulate your strategies, including the CMs, CABs,
CDBs, CDPs, PRefs, and native blocks that you will be using in each strategy. Consider
organizing your CDPs and Prefs in Excel spreadsheets using the same format as the PDE
forms. Then you can cut and paste your parameters from the spreadsheets directly into
the PDE when you are ready to create your CABs or CDBs.
The material in this type planning and design section should be viewed as an outline, or
checklist, of the planning steps and design decisions that you should make prior to actual
implementation of strategies involving CAB and CDB. You undoubtedly have site
practices in place that address many of these items; however, CAB, CDB, and CDPs
present some new features that require special consideration.
Configuration planning
Configuration planning steps
The following are some configuration planning considerations:
• Configuration planning for CAB and CDB is similar to planning for native blocks.
Because of the added functionality, however, CAB and CDB have some special
planning needs.
• Plan the roles and responsibilities of users. This should address the issue of multiple
developers working on the same or multiple parts of a CAB application. It should also
address the responsibilities of individuals involved in deployment and monitoring of
strategies that involve CABs.
Honeywell 10/04
• You should review your security practices with CAB in mind. See “Security policy”
for information on security issues.
• Determine if templates can be used to reduce development effort, especially if you
have multiple equipments that are similar. See “Role of block types, instances, and
templates” for information about templates.
• With CAB, custom data and algorithm are user-defined. This increases the likelihood
of “tweaking” to improve performance or reliability, or to add features. The problem
of revision control of instances is therefore magnified. You will need to develop and
adopt an appropriate strategy for managing types and instances. (Note that version
control (QVCS) is not supported for CAB or CDB types.)
• Your strategy for managing types and instances can take advantage of the Search
tool (formerly known as the Relationship Browser) that is included in Experion. The
tool is accessed from Configuration Studio. For more information, see “
Honeywell 10/04
Discover CAB dependency relationships.”
Software development considerations

If you anticipate extensive software development for CAB algorithms, you may wish to
consider some of the following standards and procedures:
• Software functional specifications
• Standards for program internal documentation (comments)
• Code peer review process
• Software revision tracking using library/block names for version control
• Standards and procedures for test
You will need enough detailed documentation so that the CAB can be maintained and
perhaps modified or enhanced throughout its deployment life, even if there are personnel
changes.
Requirements external to system

There are no special third-party software requirements. All necessary software is
provided as part of Honeywell install packages. There are no physical switch settings
required. You will require a license to develop CABs, and an R210 ACE to run CABs.
You will also require that the appropriate software development expertise is available to
the project.
10/04 Honeywell
CAB configuration choices

Define the CAB naming strategy
Determine a naming strategy that includes:
• Library names
• Type names
• CDP names
• Parameter reference alias names (the names defined in the type definitions)
• Parameter reference values (the block.param assigned to alias names in instances)
• Instance names
• CM names
Consider using separate libraries for test types and deployed types, and include “test” as
part of the test library names so as to avoid inadvertently instantiating a type that is still
under test.
Choose type names that include serialization or other means of supporting your
versioning strategy.
Use meaningful names that reflect the purpose. Use meaningful descriptions in the
parameter definition “Description” fields. See the example scenarios in this guide for
examples of naming.
Make CAB user interface decisions

Your CAB application planning and design should include the definition of the
techniques that you will use to enable developers and operators to control and monitor
the application. To the extent that it is feasible, it is appropriate to make as many of these
decisions as possible early in the design so as to avoid extra edits and instance updates
later in the project.
Some items to consider are:
• Determine the parameters that will be exposed on the faceplate. Configuring
parameters on the faceplate is easy to do in the PDE when the type is initially defined,
but is more complex to do after instances have been created. See “Specify symbol
attributes” for more information.
Honeywell 10/04
TIP
In order to display parameter reference values, you must assign the parameter
reference values to a CDP value that can be displayed on the faceplate or as
a pin.
• Make decisions about when to use custom data parameters and when to use
parameter references. Parameter references are recommended if the CAB is to be
used as an insertion point algorithm (see “Do not use graphical connections”).
Parameter references do not support whole array access whereas CDPs do. When
using parameter references, user code should check status after the read or write
operation. Parameter reference functionality supports PRef lists. This is a programmer
convenience, and its use does not affect performance. Parameter references are
defined as aliases in the type definition, and actual reference target names are
assigned in the property forms of the instances. CDPs are connected by graphical
connections (wires and parameter connectors). You can define the pins that are
exposed on the block symbols when you define the type in the PDE. (There is one
caveat, however. If you later edit a CAB type and change symbol attributes, these
changes will not automatically propagate to instances.) You can also define these
exposed pins for each instance in the block properties form.
• Consider how you will make configuration changes in the run-time environment.
This is done through the block properties forms. See “Properties forms specific to
CAB and CDB” for information on the relevant forms. Be aware that you can
customize these forms in the PDE when you define the block type. You can rename
tabs, define custom tabs, and organize how information is displayed on the tabs. For
example, you could set up separate tabs for references to parameters in different
controllers, or you could separate reads and writes on different tabs. See “Specify
form layout” for information including a link to detailed information in the
Parameter Definition Editor Reference.
• Consider how you will monitor the operation of your CAB by itself and in the
overall control strategy. This could involve exposing certain critical parameters on the
faceplate. It could involve displaying certain parameters on a custom schematic. In
the latter case, your planning would include the resources and schedule impact of
creating the schematic.
Determine the CAB algorithm and parameters

This step encompasses defining the calculations and control functions that will be
implemented in the CAB program. This should include a definition of the PRef reads and
writes that will be required, the CDPs that will be used by the CAB program, and the
graphical connections that will be used to interface parameters on other blocks. This
10/04 Honeywell
analysis could result in a specification for coding the CAB. This specification could, in
turn, be part of an overall specification for the strategy of which the CAB is a part.
As part of the planning of the CAB program, consider any special provisions that will
help during the debug process. For example, perhaps you could use local variables that
capture interim calculations or status values or other internal data so that they can be
easily viewed in the debugger. Similarly, you can define CDPs that could be used to
display internal data on the faceplate or in the debugger. Also consider using the Send()
subroutine to forward information to the message display of Experion Station (see “On-
process debugging”). Consider using SIM-ACE for debugging to take advantage of the
powerful MSVS debugging functionality. For more information on using SIM-ACE, see
“Debug with SIM-ACE.”
Determine Continuous Control access

You must determine whether to use Program or Continuous Control access level for each
CAB. If a CAB is to be used as an insertion point algorithm, it should be configured for
Continuous Control. Continuous Control is also used with legacy Honeywell control
systems. For further information, see the following topics:
“Access Lock attribute for CDPs”
“Access level used In PRef writes”
“CAB writes with Continuous Control access level”
Data and algorithm characteristics of CAB

A CAB type represents the same concept as a "class" in modern object-oriented software
terminology. Instances made from CAB types can be thought of as "objects." Within the
context of Experion and CEE, the user-visible entities tend to be called "block types" and
"block instances" rather than "classes" and "objects."
Like any class, the following two parts fundamentally characterize a CAB type:
• A set of data definitions
• An algorithm definition
Also, like any class, a program defines a CAB type. However, due to its integration with
the PKS name space, the program of a CAB type does not express the complete
definition. In particular, you must define much of the data of a CAB type outside the
source code you write for the program.
There are different categories of data used within CAB types. They vary according to
persistence and visibility.
Honeywell 10/04
• Fixed definition parameters (FDPs)

• Custom data parameters (CDPs)
• Block scope variables
• Local variables
For more detailed information on FDPs and CDPs, see “Define CAB type parameters.”
For more information on block scope variables and local variables, see “Define block
scope variables” and “Define local variables.”
Parameter references are a special case. They differ from the types listed above in that
their values are not stored within the CAB. The CAB stores Assign parameter references,
or pointers, to the actual data, which exists external to the CAB. For information on
parameter references, see “Define parameter references” and “Assign parameter
references Assign parameter references.”
CAB fixed definition parameters

As with native blocks, CAB includes a number of predefined parameters. These FDPs are
part of the infrastructure of the CAB. In some cases, you can supply default values when
you create the type (for example, ACCESSLEVEL). In other cases, you can enter values
at run time (for example, CABCOMMAND). At this time, the planning phase, review the
section “Fixed definition parameters” and familiarize yourself with these parameters. If
possible, try to determine the default values that you will assign to:
• ACCESSLEVEL—plays a part in the security of writes to parameter references
• READEROPT—allows you to configure event reporting on parameter read errors
• WRITEERROPT— allows you to configure event reporting on parameter write
errors
The following FDPs can have values assigned at run time under certain conditions. If
possible, plan how you will use these parameters.
• CABCOMMMAND—allows you to enter commands to alter the CAB state
• EXCPTALM.PR—allows you to set alarm notification priority for a CAB exception
• EXCPTALM.SV—allows you to set alarm notification severity for a CAB exception
• RDERRALM.PR— allows you to set alarm notification priority for a read error
• RDERRALM.SV— allows you to set alarm notification severity for a read error
10/04 Honeywell
• TRMNTALM.PR— allows you to set alarm notification priority for a CAB

terminated alarm
• TRMNTALM.SV— allows you to set alarm notification severity for a CAB
terminated alarm
• WRTERRALM.PR— allows you to set alarm notification priority for a write error
• WRTERRALM.SV— allows you to set alarm notification severity for a write error
CAB states
A CAB instance can be in one of five states at any given time (see “CAB instance
states”). The CAB transitions from one state to another in response to system events,
program actions, or manual commands. The state is reflected in the CABSTATE
parameter. See “Fixed definition parameter CABSTATE” for an example of how to use
the CABSTATE FDP in a your program. See “Fixed definition parameter
CABCOMMAND” for an example of how you can use the CABCOMMAND FDP to
alter the CAB state.
For other related information, review the sections “Startup and shutdown” and
“Enumeration RestartEnum.”
CAB notifications
There are four CAB-specific notifications. All are alarms. A brief summary follows. For
more detailed information, refer to “CAB alarms.”
• CAB State Terminated—Indicates that CAB execution was terminated because
execution exceeded the time allowed. This alarm can have its priority and severity
configured independently for each instance. You could determine these options in
advance as part of your planning activity.
• CAB State Exception—This alarm can have its priority and severity configured
independently for each instance. You could determine these options in advance as
part of your planning activity.
• Read Error—This alarm is associated with parameter reference reads. This alarm
can have its priority and severity configured independently for each instance. In
addition, you must enable this alarm in the PDE when you define the type. It cannot
be enabled in the instance. Your advanced planning should consider these options.
• Write Error— This alarm is associated with parameter reference writes. This alarm
can have its priority and severity configured independently for each instance. In
addition, you must enable this alarm in the PDE when you define the type. It cannot
be enabled in the instance. Your advanced planning should consider these options.
Honeywell 10/04
CAB constraints
The following are constraints in the initial release (R210):
• CABs cannot access Experion history, PHD history, or general OPC history data
access servers.
• CAB execution is constrained to 250 milliseconds. Background (distributed)
execution is not available. CAB infrastructure provides an FDP (CABEXECTIMER)
that can be used to determine CAB execution time. It also provides two FDPs
(CABPRFRDTIM and CABPRFWRTIM) that can be used to monitor the time
outside of CAB user code consumed by processing PRef reads and writes. See “Use
performance monitoring FDPs.”
• CABs cannot use the file access features of Visual Basic. There are other VB
functions that are not allowed. The function limiter in CAB will catch code that is not
allowed and display an error message. See “Summary of fault handling.”
• Parameter references do not support whole array access.
• CABs do not support dynamic indirection or dynamic re-referencing (a configuration
reference is fixed in this instance).
• Other CABs cannot share subroutines and functions without copying and pasting
into each program.
• CAB does not have a data type for enumerations. You have two choices with respect
to enumerations:
− You can use the TYPECONVERT function block to convert parameters of type
enumeration to parameters of type integer and work with the ordinal values
within the CAB program. For information about the TYPECONVERT function
block, see "TYPECONVERT Block" in the Control Builder Components
Theory.
− You can use parameter references, which will do an implicit type conversion.
See “Implicit type conversion with CAB parameter references.”
CAB API
The CAB Application Programming Interface (API) is a collection of interface elements
provided by Honeywell that allows the CAB developer to access and use the functions
and features of the CAB infrastructure. This interface includes classes, class members,
data types, enumerations, subroutines, properties, and functions in support of FDPs,
CDPs, PRefs, and custom math features. It also includes features in support of
controlling and monitoring CAB initialization and execution.
10/04 Honeywell
Design the Custom Algorithm Block
Your application programmers need to become familiar with this functionality prior to
beginning implementation of CABs. The CAB API is covered in the section “reference”
of this guide, which includes examples of usage. Other examples are found throughout
this guide, including the section that contains example scenarios.

Design the usage of the CAB
CAB usage is the same as native block usage. CABs are contained in CMs and execute in
a CEE in an ACE node. See “CAB overview” for more information.
Determine how your CAB will be deployed. Will it be instantiated multiple times? At the
same site or different sites? Will the usage be identical in each case? Will it be similar
but not identical? These criteria could influence the CAB design in terms of generality.
Will you design it for one specific usage, or will you design it such that it can be adapted
(configured) so as to be applicable to different equipment or process variations? Will it
run as an insertion algorithm in a DataAcq or RegCtrl block, or as a standalone CAB, or
as a process special?
Determine when to use CAB

CABs are intended for use in situations where native function blocks do not satisfy your
control requirements. This could include scenarios for developing new applications,
functional enhancements to existing applications, or migration of legacy applications to
Experion.
Develop a conceptual design

Your site practices will determine your methodology for this step. The following are
suggestions.
Develop a solid design concept, including the data content, algorithm, processing flow,
and interaction with other blocks. Document the concept in sufficient detail that it can be
reviewed by team members and used as a design specification. Include items such as:
• Identify data that needs to be persistent and data that can be temporary. See “CDP
characteristics,” “Define block scope variables,” and “Define local variables” for
additional information.
• Determine when to use CDPs and when to use PRefs. See “Make CAB user interface
decisions” for a discussion of this topic.
• List CDPs.
Honeywell 10/04
• List PRefs.
• Define default values for FDPs where applicable.
• Define values for symbol attributes (see “Specify symbol attributes”).
• Define form layout (see “Specify form layout”).
• Define the control algorithm(s) and outline the code that will be used for
implementation. Consider using pseudo code and/or prototyping selected routines in
order to verify design concept. Refer to “Code CAB algorithm” for more information.
• Develop a strategy for debug. See “Test and debug the CAB.” Develop test
specifications as appropriate.
• Develop a security policy. Refer to “Security policy” for information. The following
are some suggestions for items to consider in your security policy:
− Determine the individuals who will have access to the CAB development tools
(administrators and developers) and assign passwords as appropriate.
− Similarly, determine the individuals who will have run-time access at the
Engineer, Supervisor, and Operator access levels, and assign passwords as
appropriate.
− Plan ahead of time the access lock and access level attribute values that you will
assign to individual CDPs as your CAB types are defined.
− Develop a policy with regard to debug activity, especially on-process
debugging.
− Develop a policy for managing types and instances including requirements for
testing and distributing new or modified block types and instances.
Organizing CAB programs for best performance

There are no specific guidelines for optimizing performance other than the obvious ones:
• There is no significant performance issue when deciding whether to use CDPs or
PRefs.
• Avoid loops that can cause CAB execution to time out.
• Use on-node references in preference to off-node references wherever possible.
• Use whole array access instead of individual element access (CDPs only) unless you
only need a small number of elements.
10/04 Honeywell
• If you have a memory-intensive or processor-intensive routine and you wish to split

its execution across multiple execution cycles, you must do this programmatically,
because distributed execution (allowing execution to span multiple cycles
automatically) is not supported in this release.
• Assign the order of execution of CMs, and blocks within CMs, keeping in mind the
logical flow of data within your control application.
• You can use standard Windows performance monitoring tools to monitor
performance and memory utilization. See “Resource management” for more
information.
Determine CAB memory usage

CAB instances require memory from the block of memory reserved within ACE for
instances. In addition, unlike native blocks, they also require memory that is taken from
the general .NET memory pool. If you anticipate significant CAB and native block
utilization, you should do an ACE memory analysis. Refer to “Determine ACE memory
utilization” for details about how to perform this analysis.
Determine CAB shutdown horizon

As CAB types and instances is created, modified, and deleted, ACE memory that is
required for type definition storage grows. This memory is not reclaimed even when all
instances of a type are deleted. Eventually, it may be necessary do an ACE shutdown and
restart in order to claim this unused memory. Refer to “Determine ACE shutdown
horizon” for information about this potential requirement.
Determine the CAB distribution policy

This policy will depend on the characteristics of your plant or company, including such
items as the number of sites and their geographical distribution, and your in-house MSVS
development expertise.
You can choose to have your CAB applications developed by Honeywell or a third party,
and use the import and export features for distribution of instances. In this case, you
would not require a developer license unless you wanted the ability to make
modifications to the programs. If you have in-house development capability, you can
develop your CAB applications at a central location and use the import and export
features for distribution.
Your distribution policy should include a strategy for managing versions of types and
instances. Take advantage of the ability to name libraries, types, and instances. Consider
using serialization as part of names.
Honeywell 10/04
CDB configuration choices

Define the CDB naming strategy
Determine a naming strategy that includes:
• Library names
• Type names
• CDP names
• Instance names
• CM names
Consider using separate libraries for test types and deployed types, and include “test” as
part of the test library names so as to avoid inadvertently instantiating a type that is still
under test.
Choose type names that include serialization or other means of supporting your
versioning strategy.
Use meaningful names that reflect the purpose. Use meaningful descriptions in the
parameter definition “Description” fields. See the example scenarios in this guide for
examples of naming.
Make CDB user interface decisions

Your CDB application planning and design should include the definition of the
techniques that you will use to enable developers and operators to control and monitor
the application. To the extent that it is feasible, it is appropriate to make as many of these
decisions as possible early in the design so as to avoid extra edits and instance updates
later in the project.
Some items to consider are:
• Define the CDPs that will be configured in your CDB before you begin definition of
the type.
• Determine the parameters that will be exposed on the faceplate. Configuring
parameters on the faceplate is easy to do in the PDE when the type is initially defined,
but is more complex to do after instances have been created. See “Specify symbol
attributes” for more information.
• CDPs are connected by graphical connections (wires and parameter connectors). It is
convenient to define the pins that are exposed on the block symbols when the type is
10/04 Honeywell
created in the PDE. Otherwise, you will need to do this in the property form for each
instance. (There is one caveat, however. If you later edit a CDB type and change
symbol attributes, these changes will not automatically propagate to instances.)
• Consider how you will make configuration changes in the run-time environment.
This is done through the block properties forms. See “Properties forms specific to
CAB and CDB” for information on the relevant forms. Be aware that you can
customize these forms in the PDE when you define the block type. You can rename
tabs, define custom tabs, and organize how information is displayed on the tabs. See
“Specify form layout” for information including a link to detailed information in the
Parameter Definition Editor Reference.
Data characteristics of CDB

There are two categories of data used within CDB types:
• Fixed definition parameters (FDPs)
• Custom data parameters (CDPs)
For more detailed information on FDPs and CDPs, see “Define CDB type parameters.”
CDB fixed definition parameters

As with native blocks and CABs, CDB includes a number of predefined parameters.
These FDPs are part of the infrastructure of the CDB. None of these CDB FDPs can be
configured with default values. Therefore, there is no Fixed tab in the PDE (where
default values are normally configured), and therefore a preliminary planning step is not
needed to determine default values.
For information on these FDPs, refer to “Fixed definition parameters in CDBs.”
CDB constraints
CDBs have the following constraints:
• CDBs do not support parameter references.
• CDBs do not support a control algorithm.
• CDB does not have a data type for enumerations. You can use the TYPECONVERT
function block to convert parameters of type enumeration to parameters of type
integer and work with the ordinal values.
Honeywell 10/04
Design the Custom Data Block

Design the usage of the CDB
CDB usage is the same as native block usage. CDBs are contained in CMs and execute in
a CEE in an ACE node. See “CDB overview” for more information.
Determine how your CDB will be deployed. Will it be instantiated multiple times? At the
same site or different sites? Will the usage be identical in each case? Will it be similar
but not identical? These criteria could influence the CDB design in terms of generality.
Will you design it for one specific usage, or will you design it such that it can be adapted
(configured) so as to be applicable to different equipment or process variations.
Determine when to use CDB

CDBs are intended for use in situations where native function blocks do not satisfy your
control requirements. This could include scenarios for developing new applications,
functional enhancements to existing applications, or migration of legacy applications to
Experion. You do not require the CAB development license for CDB development.
While CDBs will often be used in conjunction with CABs, this is not a requirement.
CDBs can be used for generic data storage in applications that do not involve CABs. See
the example “A CDB to hold sensor data.”
See “Why use CDB?” for more information about CDB usage.
Define the CDB distribution policy

This policy will depend on the characteristics of your plant or company, including such
items as the number of sites and their geographical distribution.
Your distribution policy should include a strategy for managing versions of types and
instances. Take advantage of the ability to name libraries, types, and instances. Consider
using serialization as part of names.
10/04 Honeywell
Honeywell 10/04
CAB and CDB installation and upgrade
Hardware installation and upgrade
Where to find information
For hardware requirements, refer to the Software Change Notice (SCN) and/or the
Specifications and Technical Data (Spec and Tech) that is applicable to the release.
Software installation and upgrade

For detailed information about installation and upgrade, refer to the System Installation
and Upgrade Guide (SIUG) and the Software Change Notice (SCN).
Licensing considerations
CAB has a two-tiered licensing scheme that is based on the Client/Developer style of
licensing. The two licenses that make up CAB licensing are CAB Developer and ACE
Base. The CAB Developer license allows users to build programs using Microsoft
Visual Studio .NET 2003 and Control Builder integrated with CAB tools. The users will
create custom programs using Microsoft Visual Basic .Net.
The developed CAB types can be run on ACE CEEs throughout a site and even in other
plants without the necessity of purchasing a special license. The ACE Base licensing is
included with ACE. To edit a CAB that is developed by another plant site, a CAB
Developer license is required to edit and recompile the code.
CAB Developer license

The CAB Developer license allows users to develop and compile Visual Basic programs
for use with the ACE CEE via CAB tools, Control Builder, and Visual Studio .NET
2003. The user can add CAB function blocks to projects and attach programs to them.
The CAB Developer license does not allow users to load CAB function blocks to the
CEE Monitor environment. ACE Base and Control Builder allow users to add CAB
function blocks to the CEE Monitor environment.
Honeywell 10/04
CAB and CDB installation and upgrade
Software installation and upgrade
ACE Base license

The ACE Base license and package, which is included with ACE, allows users to load
CAB instances to ACE environments, but they cannot edit CAB types or create new
CAB types without a CAB Developer license. The ACE Base allows a user to import
CAB types/libraries and CMs containing CAB function blocks.
Possible licensing scenarios

• Purchase at least one CAB Developer license per major unit of a plant along with as
many ACE nodes that are required for systems to run programs.
• Purchase one CAB Developer license per site with as many ACE nodes required to
run the CAB programs.
• Purchase only ACE nodes and subcontract CAB development work to Honeywell or
third parties.
Honeywell 10/04
CAB configuration
Create a new CAB type
CAB development environment overview
The CAB development environment is launched from the Control Builder application. The
development environment provided by Honeywell for CAB creation is called the
Integrated Development Environment (IDE). This environment integrates the following
features into CB:
• Support for creation of new types for CABs, and for adding these new types to the CB
library.
• Support for instantiating the new types into CMs, and for loading them into the CEE.
• A customized version of Microsoft Visual Studio .NET 2003 (MSVS .NET) for
creating CAB algorithms.
• The Honeywell Parameter Definition Editor (PDE) for configuring custom data
parameters for CABs and CDBs and parameter references for CABs. For CABs, this
application opens within MSVS as a tab-selectable option.
ATTENTION
When you open the CAB development environment, a splash screen appears
briefly. You can minimize this screen, but if you close it, the development
environment will not open.
Layout of the development environment

When you open the IDE from Control Builder for the purpose of creating a new CAB type,
you specify the library and block names and then the Microsoft Development Environment
launches with the Honeywell Parameter Definition Editor tab selected, as shown in the
following figure.
Honeywell 10/04
CAB configuration
Figure 2 The MSVS development environment for CAB
Note that in the IDE there are two tab-selected options available:
• Parameter Definition Editor—Where the parameters for your CAB are configured.
This window is selected in the figure above. When you open the IDE for creation of a
new CAB type, the PDE tab is active by default.
• CABlock.vb—Where the algorithm for your CAB is configured. When you open the
IDE for edit of an existing CAB type, the CABlock.vb tab is active by default.
When you select the CABlock.vb tab, or if you are opening an existing CAB type for edit,
the Source Code window appears as shown in the next figure.
Figure 3 Source code window
Honeywell 10/04
CAB configuration
The source code window contains a framework of Honeywell-supplied code with no

executable statements if you are creating a new CAB. It is in this framework that you will
insert the code for your algorithm. This figure shows how the source code window appears
when you open it for creation of a new CAB type. If you were editing an existing CAB
type, the window would contain your previously entered code.
The CABlock.vb tab is shown in Figure 3 as it appears when opening the window for
creation of a new CAB. After the each build, a Globally Unique Identifier (GUID) is
appended to the label as shown in the following figure:
10/04 Honeywell
CAB configuration
Figure 4 Source code tab with GUID
The GUID is used to ensure that each CAB and CDB type is globally unique across the
system, independent of the library and type name. The GUID from the type is propagated
to each instance and therefore ensures that an instance can be matched to its type, even if it
is exported to another system where another CAB exists with the same library/type name
but different algorithm.
Honeywell additions to MSVS

In order to support CAB development, Honeywell has provided customized features within
MSVS. Some of these are:
• The PDE is integrated into MSVS.
• MSVS starts in a mode in which certain advanced features are not displayed. These
are features that are not required for CAB development. This makes the environment
friendlier for developers who are not power users of MSVS.
• Special classes were added to support CDPs and parameter references. The use of
Microsoft IntelliSense will aid in typing CDP and PRef names and supporting
properties.
• Reliability features were added such as code validation checks.
• Code was added to support saving data to the ERDB.
Honeywell files
CAB infrastructure includes many critical files provided by Honeywell. Do not modify or
delete any files under: C:\Documents and Settings\All Users or under C:\Documents and
Settings\<login userid>.
MSVS .NET 2003 resources

Many of the standard features of MSVS .NET 2003 and VB.NET are available to you in
the Development Environment. These include certain libraries, objects, properties,
methods, debugging tools, and the IntelliSense coding aid. Honeywell includes the features
that are appropriate for the creation and editing of CABs that will run in the current ACE
runtime environment. Features that are not required are not included.
Honeywell 10/04
CAB configuration
CAB configuration procedures

The following topics cover the steps involved in configuring a CAB type. The topics that
will be covered are:
• Open a new CAB block type for edit
• Define data and algorithm
• Build the solution
• Save the solution
• Save-Renew command
• Block type locking flags
• Interactions with the ERDB database lock feature
• Close the development environment
Open a new CAB block type for edit

To create a new CAB type, choose File > New > Type > Custom Algorithm Block in the
Control Builder application to open the Integrated Development Environment. A dialog
box appears in which you specify the Custom Library Name, either by entering the name
of a new custom library, or by selecting an existing library name from a drop-down list. In
this dialog box, which is shown in the following figure, you also enter the name of the new
block (CAB) type.
Figure 5 Specify Library and CAB Names
Rules for library names are as follows:
10/04 Honeywell
CAB configuration
• Maximum character count for library name is 50, minimum 1.

• All characters except * | \ : < > ? / ” and tab are legal.
Rules for block type names are as follows:
• Maximum character count for block name is 50, minimum 1.
• Name must include an underscore or an alpha character.
After specifying the Custom Library Name and the Block Type Name, you click OK. The
data entered is checked to ensure that only valid characters were entered and that the
maximum character count was not exceeded. If the data is valid, the IDE opens with the
Parameter Definition Editor window selected as previously shown in “Layout of the
development environment.”
Define data and algorithm

You enter your custom data parameters and parameter references in the PDE window. For
more information, see the section “Define CAB type parameters.”
You enter your code for your control algorithm in the Source Code window, previously
shown in Figure 3. For more information, see the section “Code CAB algorithm.”
Build the solution

After data and code have been entered, you build the block type. You may need to invoke
build multiple times until all build errors have been eliminated.
After all build errors have been eliminated, you save the block type to the ERDB. You do
this by invoking the "Save To ERDB" command that is made available within MSVS.
Save operations are covered in the topic “Save the solution.”
You are not required to eliminate all build errors before saving to ERDB. ERDB serves as
the permanent storage for all CAB types, whether they are complete and ready for use or
whether they are under a prolonged period of edit. If a block type is saved to ERDB before
it has been successfully built, it can still be used to make instances. However, before a
CAB type is successfully built, its Incomplete Lock parameter is set. Instances of such a
type cannot be loaded to a CEE. CB will report an error on any attempt to do so. For more
information on the Incomplete Lock parameter, see “Block type locking flags.”
Table 13 Build Commands
Honeywell 10/04
CAB configuration
File menu Toolbar Action

option button
Build Solution Saves all project files to local storage, and then builds
(compiles) the project.
N/A Cancels a build option that is in progress. The button is

inactive (Grayed) when a build is not in progress.
Save the solution

With regard to storage of project files, developing a CAB in MSVS under CB is different
than you are probably used to if you have developed other projects under MSVS in the
past. With CAB, project files are kept in the ERDB, which is advantageous for several
reasons. ERDB storage takes advantage of redundancy (if present), and the SQL Server
backup and restores operations in effect for ERDB. It also avoids any confusion that might
occur if multiple copies of a project exist. Local storage is used during a CAB edit session,
but when the session is complete and you close MSVS without saving to the ERDB, you
will be prompted to save changes (if you have made any). This save operation is to the
ERDB. If you decline, all changes made will be lost, because all local project files are
deleted when MSVS closes.
Note that the fully qualified name for a CAB type consists of the concatenation of the
library name and the block type name. This means that different types that are assigned
different library names can use the same block type name. As an example, suppose a CAB
type called "VLR_CALC" is assigned to a library called "USER_UTILS." There is nothing
to prevent a new block type called "VLR_CALC" from being assigned to a library called
"USER_ALGOS."
The following table covers the types of saves that are available.
10/04 Honeywell
CAB configuration
Table 14 Types of saves for CAB
File menu Toolbar Action

option button
Save PDE Saves the PDE data to local storage. This option is only
Data available if you have made changes to PDE data. Note:
You must save any PDE changes prior to developing
code in order to have the changes recognized in
IntelliSense.
Save-Renew N/A Do not use this command unless prompted to do so. See
PDE Data “Save-Renew command” below.
Save All N/A Saves all project files to local storage.
Save to Saves all project files to the ERDB.

ERDB
IMPORTANT: If you are using the QVCS versioning
system, refer to the topic “Special considerations when
using QVCS with CAB” for important information.
Save to N/A Allows you to save another copy of the current block. You
ERDB As will be prompted for the desired Library and Block names.
If you keep the same Library name, you must enter a
different Block name. If you choose a new Library name,
the Block name can be the same as, or different from, the
name of the original block. After the save operation, the
block under edit in MSVS will be the new version.
Save N/A Saves only the code to local storage.

CABlock-
<GUID>.vb
Save N/A This function is not supported in the current release.

CABlock-
<GUID>.vb
As
Note: “GUID” stands for Globally Unique Identifier.
Honeywell 10/04
CAB configuration
Save-Renew command
Both CDPs and the PRefs parameters are identified within the system by the parameter
identification numbers that are invisible to users. Under certain unusual conditions, it may
become necessary for the system to regenerate these identification numbers in order to
continue with the current operation. If this should occur, you will be notified by an error
message that indicates that you need to execute the Save-Renew command. This command
requires that you select a new name for the block that you are saving. If you execute the
Save-Renew command, the parameter identification numbers within the system are
regenerated.
ATTENTION
A consequence of the Save-Renew command is that you will have to reload all
instances of the block. Alternatively, you can elect to cancel the operation that
you were doing when you received the error message indicating the need for
Save-Renew.
Block type locking flags

CAB types include two fixed definition parameters (FDPs) that are used internally to
prevent certain potential errors from occurring during the CAB development process (edit
phase). These parameters can be viewed on the Main tab of the block properties form.
They are the Edit Lock flag and the Incomplete Lock flag (the parameter names are
EDITLOCK and INCOMPLETE). The following figure shows a partial view of the
properties form where the flags appear.
Figure 6 CAB Type Locking Flags
EDITLOCK— The Edit Lock flag is supported by all CAB types. When blank, it
indicates that the type is available for edit. When not blank, it contains the machine name
and user name of the person who is editing the type. Edit Lock prevents a type from
becoming corrupted by simultaneous edits. It is automatically set when the type is opened
for edit, and is automatically cleared when the edit session ends.
10/04 Honeywell
CAB configuration
When Edit Lock is set, the type can still be opened view-only by using the "View"
command. Attempts to save to the ERDB will not work when the type has been opened
view-only. Block instances can be created or loaded regardless of the state of Edit Lock.
Edit Lock gives no indication of the edit state between edit sessions. In order to prevent
others from modifying your type when it is not open for edit, there must be a site practice
for honoring reservations. To handle coordination of CAB types under development, a
recommended procedure is to include a term such as “development” or “test” as a part of
the name of a Custom Library to differentiate it from deployed libraries.
ATTENTION
In the unlikely occurrence that a PC crashes while an edit session is in
progress, the Edit Lock will be set. If this happens, the ERDB administration
tool, DBAdmin, must be used to clear Edit Lock. For information, see “Using
DBADMIN” in the Control Hardware Troubleshooting and Maintenance Guide.
INCOMPLETE— The Incomplete Lock flag is supported by all CAB types. When True
(checked), it indicates an inconsistency between the parameter definitions established
within PDE and the algorithm definition established within VB.NET source files.
Parameter definitions have been added or changed since the last successful build. To clear
the lock, you must successfully rebuild.
CAB types can be instantiated when Incomplete Lock is set (although there is no reason to
do so), but they cannot be loaded.
You can view the value of Incomplete Lock, as shown in Figure 6 above, by opening the
block properties form and selecting the Main tab.
Interactions with the ERDB database lock feature

Database locks are a standard feature in most databases. They are used in the ERDB. Their
purpose is to lock a database item when it is opened so that another user cannot attempt to
edit the same item. Any attempt to modify a database item when it is locked will generate
an error. There is a potential for this to occur any time that you open a CAB or CDB type
for creation or editing, or save a CAB or CDB to ERDB. These operations cause a change
in the value of the Edit Lock flag, a database resident parameter. The system performs a
check prior to setting or resetting the Edit Lock flag to ensure that the database is not
locked. For example, assume that you have a project chart open containing an instance of a
CAB type. A database lock is set for that CAB type (and for every other block type
instantiated in the chart). If you attempt to open the CAB type for edit, or save it if it is
already open, a warning will appear stating that the chart must be closed before the CAB or
CDB can be opened or saved, because the open or save operation attempts to change the
Edit Lock flag. Another potential conflict is the case where you are editing a CAB or CDB
Honeywell 10/04
CAB configuration
type, and someone else opens a chart that contains an instance of that CAB or CDB type. If
you try to save the CAB or CDB type, you will get an error because the database record for
that CAB or CDB type is locked. The error message will indicate who has it locked and
will give you the option to cancel, or to continue the operation, which will leave the Edit
Lock set.
Close the development environment

After the block type has been saved to ERDB, you can close MSVS if you believe that
block type editing is complete. Alternatively, you can leave MSVS open for debugging. In
most cases, you will probably leave MSVS open after first creating a new block type to
support a cycle of instantiation, test and modification. Remember to save the PDE any time
that you change its data so that IntelliSense will recognize the changes.
If you attempt to close MSVS and you have a CAB type open for edit, you will get the
following dialog:
If you select Discard, your changes will be lost. It is important to emphasize that source
files saved within the development folder (local storage) are used as a temporary cache in
support of edit and build sessions. They are not maintained after an edit session has ended.
When an edit session is complete and MSVS is closed, ERDB is the only storage resource
for all data related to block types. "Save To ERDB" can be done at any time during the
MSVS edit session to preserve work done so far.
If you attempt to close Control Builder when you have a CAB type open for edit, you will
get the following error message:
10/04 Honeywell
CAB configuration
Define CAB type parameters

Custom data parameter purpose
As the name implies, CAB types support custom data parameters (CDPs). CDPs as
supported within CAB types are equivalent to the CDPs supported on CDB types.
CDPs are parameters (variables) that you define. They are part of the overall definition, or
configuration, of your CAB. CDPs are visible within the CAB program and within the
PKS as a whole. They are "public" in that any agent that has access to the PKS name space
can read them. Similarly, CDPs can be written by any PKS agent subject to store access
checks specified by you when you design the block. Thus, they represent an effective
vehicle for exchanging custom data throughout the PKS.
Globally defined variables in a CAB program retain their values across CM execution
cycles as do CDPs, but they are not visible to the PKS.
CDP characteristics
Some characteristics of CDPs are:
• CDPs are directly analogous to the parameters of native CEE block types. However,
the name, data type, access lock, and other properties, are not predefined. You specify
them during the process of defining the block type. Attributes that can be specified for
CDPs are described in "Reviewing custom parameters tab (Value CDPs)" in the
Parameter Definition Editor Reference. Data types are described in this guide in the
section “Data types for CDPs and parameter references.”
• CDP values are persistent in the sense that they are maintained from creation until
deletion of the block instance. Their values are retained from one execution of the
block to the next.
Honeywell 10/04
CAB configuration
• The data types available for the CAB CDPs are the same as those available for CDB
CDPs.
• CDP values can be changed by writes from within the block or from external blocks or
other agents within the PKS.
• CDPs can be viewed from several different displays within the PKS. CDP values can
be configured in the CAB properties form using the CB project side instance if their
Configuration load attributes were configured as LOAD in the PDE. CDP values can
be read and written on process from the CAB properties form using the CB monitor
side instance. Values can be read and written using chart visualization from the
Experion Station. They can also be read and written from custom displays.
One difference between native block parameters and CDPs is that the native block
parameters are only visible from outside of the block while the CDPs are visible from both
inside of and outside of the block. To illustrate this, suppose that you decide to create a
CDP called "FLOW" on a block type called "CONTROLLER." Then you make an
instance of CONTROLLER called "CONTROLLER1" within a CM instance called
"CM1." Then, the CDP called "FLOW" can be accessed externally under the name
"CM1.CONTROLLER1.FLOW." In addition, it can be accessed internally by the CAB
program under the name "FLOW.Value."
Define custom data parameters

CDP definitions are entered in the Value CDPs tab of the PDE. This form is selected by
clicking the Value CDPs tab of the PDE.
Figure 7 Value CDPs Tab
A portion of he Value CDPs configuration form (tab) is shown in the following figure.
10/04 Honeywell
CAB configuration
Figure 8 Value CDPs configuration form
Operations that you perform in the PDE are covered in the Parameter Definition Editor
Reference. The following table includes useful links for Value CDP information:
Table 15 PDE Information links for Value CDPs
For information on… In the PDE Reference see…
Customizing the Value CDPs view (set of Reviewing PDE views for CAB and CDB
attributes that are displayed),
Specifying CDP attributes Reviewing custom parameters tab (Value

CDPs)
ATTENTION
It is strongly recommended that you avoid using VB reserved names in
parameter definitions. You can search VB on-line help for “Visual Basic
keywords.”
Validity checks based on CDP attributes

Some of the CDP attributes that you configure are used to condition whether or not the
CAB instance will accept writes from external agents. This is true for the following
attributes.
• Access Lock
• Minimum Value
• Maximum Value
• Dimension 1 Array Element Count
• Dimension 1 Array Lower Bound
Honeywell 10/04
CAB configuration

It is important to understand that these validity checks are done in accordance with the
Data Owner Principle. Thus, the CAB instance is considered the owner of all its CDP data.
Writes to its CDPs from external agents (blocks, displays, etc.) are accepted only if they do
not violate the validity checks.
In contrast, writes that a CAB program makes to its own CDPs are not subject to validity
checks at all. If such checks are needed, they must be built into the CAB program
explicitly.
As one example, a CDP defined with access lock ViewOnly cannot be written to by any
external agents. But it can be written to by the CAB program itself.
For validity checks of Maximum Value and Minimum Value, special behavior is supported
for CDPs of floating point type. This is as follows:
• Writes of NaN are always accepted.
• Writes of non-NaN values are compared to the limits. Out of range values are never
rejected but are clamped instead.
• A write of +INF or –INF will be accepted unless a limit is set, in which case the value
that is stored is clamped at the limit.
A store to any parameter type other than floating point will be rejected if the value is
outside the Maximum Value and Minimum Value limits. A store to a parameter of type
floating point will clamp the value at the upper/lower limit and allow the store.
Note that the attributes specified for CDPs at type creation time guide built-in behavior of
the type at instance configuration time and at run time. However, most are not available to
user-written code. The only attribute available to user code is "<CDP-name>.Value". The
Value attribute is further described in “CDP classes.”
Access Lock attribute for CDPs

Attributes that can be specified as part of a CDP definition are described in the previous
topic. One of these is Access Lock. The access lock of a CDP determines which external
agents can initiate stores to the parameter. External agents are identified by an Access
Level identifier that is sent with every write request.
The following table lists external agents that can attempt stores to CDPs and the access
level that identifies them. An “X” in a cell indicates that the operation is allowed. Note that
for some external agents, the access level can be one of several values, depending on
10/04 Honeywell
CAB configuration
circumstances. In the case of CAB instances, the access level will be either Program or
Continuous Control depending on the value of fixed definition parameter
ACCESSLEVEL which is configured on the Fixed tab in PDE. In the case of human
initiated stores from CB monitoring displays or Station displays, the access level will be
Engineer, Supervisor or Operator depending on privileges associated with the user id.
Table 16 Access levels in Experion
External agent Access level

attempting
store Application Program Continuous Engineer Supervisor Operator
developer control
Control Builder X
during load of
CM or SCM
Supervisory X
batch
application
SCM X
CAB instance X X
Supervisory X
control
application
Algorithm X
function block
Human being X X X
storing from
CB monitoring
display
Human being X X X
storing from
Station display
Access Locks are configured for each CDP on the Value CDPs tab in the PDE when the
block is created.
The following table lists possible values for CDP Access Lock and their meanings. Each
cell indicates whether stores with the indicated Access Level will be accepted by a CDP
that has been assigned the indicated Access Lock.
Honeywell 10/04
CAB configuration
Table 17 Access locks for CDPs
Access Level
Access lock Application Program Continuous Engineer Supervisor Operator

developer control
View Only No No No No No No
AppDevOnly Yes No No No No No
Program Yes Yes Yes No No No
Engineer Yes Yes Yes Yes No No
Supervisor Yes Yes Yes Yes Yes No
Operator Yes Yes Yes Yes Yes Yes
As an example of how to interpret the above tables, consider a CDP defined with Access
Lock = Engineer. Suppose a human being with engineering privileges is logged on and
using a Station display. This user can store to the CDP. Users logged with only Supervisor
or Operator privileges and using the same display cannot store to the CDP. Supervisory
Batch or Continuous Control applications can store to the CDP, as can any CEE function
blocks that have the capability to initiate stores.
Fixed definition parameter purpose

CAB types support fixed definition parameters (FDPs). These are parameters that are
defined by the system in order to provide services essential to every CAB. Some FDPs are
for internal use only and are of no concern to users. Others are known to users and are used
either at the time of block type creation, block instantiation, or both.
Define values for fixed definition parameters

FDP configuration values (default values only) are entered in the Fixed configuration form
of the PDE. This form is selected by clicking the Fixed tab of the PDE.
10/04 Honeywell
CAB configuration
Figure 9 Fixed (FDP) tab
A portion of he FDP configuration form is shown in the following figure.

Figure 10 FDP configuration form
Reference. The following link leads to information on FDPs:
Table 18 PDE information link for FDPs
Configuring the default values for FDPs Reviewing Fixed Parameters tab
Define parameter references
ATTENTION
Parameters that reside in the System Repository (SR) cannot be accessed
from CAB programs. CB will allow a parameter reference to refer to an SR-
resident parameter, but the runtime will not allow access to the parameter.
If you are in doubt about a given parameter, you can check its residency as
follows:
For CAB specific parameters, see “Detailed description Of CAB specific
FDPs” in this guide.
For other parameters, see the Control Builder Parameter Reference.
Parameter references are configured on the Parameter References configuration form of

the PDE, which is selected by clicking the Parameter References tab.
Figure 11 Parameter references tab
Honeywell 10/04
CAB configuration
A portion of the parameter references configuration form is shown below.
Figure 12 Parameter references configuration form
Reference. The following link leads to information on parameter references:
Table 19 PDE Information link for PRefs
Configuring parameter references Reviewing Parameter References tab
10/04 Honeywell
CAB configuration
The attributes specified for parameter references at type creation time guide built-in
behavior of the type at instance configuration time and at run time. They are not available
to user-written code. Attributes available to user code include "<PRef-name>.Value",
"<PRef-name>.ReadStatus", "<PRef-name>.WriteStatus" and others. For more
information, see the section “Parameter reference classes.”
Assign parameter references

Specific external references are assigned to the block instance on the block properties form
with the Parameter Reference tab selected. You can access this form in the project or
monitor tree view by double-clicking on the function block. You can assign values on the
project side but you must do a load to reflect them on the monitor side. You can view
parameter reference assigned values on the monitor side, but you cannot change them.
Figure 13 Parameter reference assignment
Specify symbol attributes

As part of the CAB type definition, the Symbol Attributes tab on the PDE allows you to
define attributes for the block symbol that appears within project and monitor control
charts. By default, the symbol exposes CABSTATE and CABCOMMAND, which, if left
as the default, would display on the monitor faceplate along with the block instance name
and the block template or type name.
As part of the type definition, you can elect do the following:
• Expose any CDP as a connectable pin.
• Expose any CDP value on the face of the symbol.
Reference. The following link leads to information on symbol attributes:
Honeywell 10/04
CAB configuration
Table 20 PDE information link for symbol attributes
Configuring symbol attributes Reviewing Symbol Attributes tab
ATTENTION
Any modifications you later make to symbol attributes will not propagate to
existing CAB instances if you choose a Save and answer Yes when prompted
to update instances. There are two ways to change Symbol Attributes in
existing instances. Symbol Attribute changes must be done for each instance
by deleting and re-adding the block to the CM, or making the change in the
block properties form on the project side and then loading to update the
monitor side.
Specify form layout

As part of the CAB type definition, the Form Layout tab of the PDE allows you to specify
aspects of the layout of the block properties form. In most cases this is unnecessary as the
default form layout will be adequate. In some cases, you might wish to change the way the
form appears during instance building or during chart visualization in on-process displays.
Reference. The following link leads to information on form layout:
Table 21 PDE information link for form layout
Defining the layout of the properties form Reviewing Form Layout tab
10/04 Honeywell
CAB configuration
Form entry steps

CAB parameters and attributes are configured in the PDE forms. Descriptions and
reference material for these parameters and attributes are covered in this guide.
Information on how to use the PDE is covered in the Parameter Definition Editor
Reference.
One of the features of the PDE that you might find especially useful is the ability to cut,
copy, and paste parameters. These options are available by right clicking on a line in the
PDE.
Figure 14 Access cut, copy, and paste options
If your block contains multiple parameters that are similar, you can copy a parameter and
paste it into multiple lines. The PDE will rename each parameter when you paste it, so that
you will probably want to change the names to suit your naming convention.
You can also copy one or more parameters and paste them into a separate block that is
open for edit. In this case, the PDE will not change the names.
Honeywell 10/04
CAB configuration
Fixed definition parameters

Each CAB type supports an identical set of FDPs. FDPs of interest to the end user are
described in this section. FDPs that are only relevant for internal system implementation
are not covered. The FDPs that are covered here are grouped into two categories:
• FDPs that are common with native blocks
• FDPs that are specific to CAB (and in some cases, CDB)
FDPs common with native blocks

The following table summarizes CAB and CDB FDPs that are common with native block
types. The definitions of these parameters cannot be modified as part of CAB or CDB type
definition.
Table 22 Summary of FDPs common with native blocks
Parameter name Description
BLCKCOMMENT1 Holds descriptive information that can be entered by the user.
CREATEDBY Identifies the user who did the first save of the instance or
template.
DATECREATED Gives the date of the first save of the instance or template.
DESC Descriptive text appearing within configuration form and on

alarm summary display.
EUDESC Descriptive text typically used to describe engineering units of

the block.
MODIFIEDBY Identifies the user who did the most recent save of the instance
or template.
ORDERINCM Integer value that determines execution order of CAB instance

within parent CM.
FDPs specific to CAB

The following table summarizes CAB FDPs that are not common with native blocks. Note
that for most of these parameters, the definitions are entirely fixed. There are some for
10/04 Honeywell
CAB configuration
which the instance default can be changed at type creation time. The following FDPs are
not accessible from within a CAB program except for the BlockBase FDPs
CABCOMMAND, CABSTATE, PROGSTSDESC, PERIOD, and PROCSPECEXEC (see
“Predefined FDPs and subroutines”). These parameters that are accessible from within a
CAB program are marked with an asterisk in the following table.
Table 23 Summary of CAB FDPs not common with native blocks
Parameter name Summary description Modification of User Write access

definition for instance
ACCESSLEVEL Specifies access level CE can assign View only.

with which CAB instance default
programs store to at type creation
parameter references. time.
BLOCKTYPEID Holds an identifier Definition fixed. View only

unique to each CAB or
CDB type.
CABCOMMAND* Command parameter Definition fixed. Operator can assign certain

for CABSTATE. values under certain
circumstances.
CABEXECTIMER Contains the time in Definition fixed. View Only

microseconds
required during the
last execute cycle to
run the user’s CAB
code.
CABPREFRDTIM Contains the total Definition fixed. View Only
time in microseconds
spent outside of CAB
user code processing
PRef read requests
during the current
execute cycle.
Honeywell 10/04
CAB configuration

CABPREFWRTIM Contains the total Definition fixed. View Only

time in microseconds
spent outside of CAB
user code processing
PRef write requests
during the current
execute cycle.
CABSOFTVER Contains the version of Definition fixed. View only.
the CAB software that
was used to build the
user’s CAB program.
CABSTATE* Operating state of CAB Definition fixed. View only.

instance.
DOTNETVER[ ] A one or two element Definition fixed. View only.

array that contains the
version of .NET
framework that was
used to build the user’s
CAB program.
EDITLOCK Prevents simultaneous Definition fixed. View only.

type edits by holding
identifier of CE and
machine doing current
edit.
EDITLOCK also
pertains to CDB.
EXCPTALM.PR Sets the alarm Definition fixed Engineer can assign

notification priority for a values.
CAB exception.
EXCPTALM.SV Sets the alarm Definition fixed Engineer can assign

notification severity for values.
a CAB exception.
10/04 Honeywell
CAB configuration

EXCPTNLINENM Publishes the source Definition fixed. View only.

file name and source
line number of the
function executing on
the last exception
incurred by CAB
program.
NOTE – The source file

and line number are
only available when the
CAB block is built using
the Debug
Configuration of Visual
Studio. If the Release
Configuration is used,
only the function name
is shown.
EXCPTNMODULE Publishes the name of Definition fixed. View Only.

the function executing
on the last exception
incurred by CAB
program.
EXCPTNMSG Publishes descriptive Definition fixed. View only.

information on the last
exception incurred by
CAB program.
EXCPTNTYPE Publishes type of last Definition fixed. View only.

exception incurred by
CAB program.
INCOMPLETE Indicates whether type Definition fixed. View only.

is in consistent build
state.
INSMASTER Indicates whether or not Definition fixed. View only. The value is set
this block is being used to the name of the master
for insertion point block when the block is
processing. configured for insertion
point processing.
Honeywell 10/04
CAB configuration

OSVER Contains the version of Definition fixed. View only.

the operating system
that was executing
when the user’s CAB
program was created.
PERIOD* Provides the value of Definition fixed. View only.

the PERIOD parameter
of the parent CM of the
CAB instance. Units are
in seconds.
NOTE – PERIOD
appears in a CAB
program like an FDP
even though it is not a
fixed definition
parameter in the truest
sense of an FDP
definition. It is only
available to the user
code.
PROCSPECEXEC* Provides the current Definition fixed. Engineers can read/write

value of the BPS from a CAB program even
parameter of the CAB though writing this
instance's parent CM. It parameter has no effect on
is intended only to the block execution.
provide information to
the block about how it
was started.
NOTE –
PROCSPECEXEC
appears in a CAB
program like an FDP
even though it is not a
fixed definition
parameter in the truest
sense of an FDP
definition. It is only
available to the user
code.
10/04 Honeywell
CAB configuration

PROGSTSDESC* Optionally publishes Definition fixed. View only.

last error identified by
CAB program.
RDERRALM.PR Sets the alarm Definition fixed. Engineer can assign

read error.
RDERRALM.SV Sets the alarm Definition fixed. Engineer can assign

a read error.
READERROPT Allows for design of CE can assign View only.

CAB types that report instance default
an event in response to at type creation
read errors. time.
READSTATUS Shows whether error Definition fixed. View only.

occurred during read of
inputs on last execution
cycle.
SRCDATA[0] Parameter that holds a Definition fixed. View only

copy of the CAB source
code.
TRMNTALM.PR Sets the alarm Definition fixed. Engineer can assign

CAB terminated alarm.
TRMNTALM.SV Sets the alarm Definition fixed. Engineer can assign

a CAB terminated
alarm.
WRITEERROPT Allows for design of CE can assign View only.

CAB types that report instance default
an event in response to at type creation
write errors. time.
WRITESTATUS Shows whether error Definition fixed. View only.

occurred during write of
outputs on previous
execution cycle.
Honeywell 10/04
CAB configuration

WRTERRALM.PR Sets the alarm Definition fixed. Engineer can assign

write error.
WRTERRALM.SV Sets the alarm Definition fixed. Engineer can assign

a write error.
* Indicates a parameter that can be accessed by a CAB program.
Detailed description Of CAB specific FDPs

Detailed descriptions are found in the Control Builder Parameter Reference. You can
access them by clicking on the parameter name in Table 23. The following comments
apply to the descriptions in the Control Builder Parameter Reference.
• Default refers to the default value assigned to the instance when it is first configured.
• When an FDP has Access Lock "ViewOnly" it means that the parameter value cannot
be written at type creation time, at instance configuration time, or at any other occasion
when working with an instance.
• When an FDP has Access Lock "Type Definition Only" it means that PDE can be
used to modify the instance default of the parameter at the time the type is created. The
parameter value cannot be written at instance configuration time or at any other
occasion when working with an instance.
Save parameter definitions

After completing configuration steps in the PDE, you must terminate the edit session with
the "Save PDE" or "Save All" command so that the algorithm source code window will
reflect the information that you configured. You can return to the PDE to add or change
configuration at a later time. For more information about Save operations, refer to “Save
the solution.”
10/04 Honeywell
CAB configuration
Limitations on number of CAB parameters

There is a limit to how many CDPs a CAB can have. CDPs, FDPs, and parameter
references all contribute to a total that is constrained. The following table indicates these
constraints.
Table 24 Configuration limits for CAB types and instances
Parameter Max Comment

type limit
FDPs 200 FDPs are defined by Honeywell and are not available for
definition by users, although users can read them and write
to some of them. Approximately 50 are currently used and
150 more are reserved for future use.
User-defined 799* • CDPs count as one user-defined parameter.

parameters
• Prefs count as two user-defined parameters
*Note: Array parameters count as one parameter no matter how many elements they
have.
Honeywell 10/04
CAB configuration
Code CAB algorithm
Code CAB algorithm

Overview
When the source code window opens, it contains a code frame with no executable
statements. The empty frame is shown below.
'Imports for the standard Honeywell supplied namespaces

Imports Honeywell.CAB.SysCommon
Imports Honeywell.CAB.SysBase
Imports Honeywell.CAB.BlockBase
Imports Honeywell.CAB.Math
'Imports for the Math namespace

Imports System.Math
Imports System.Double
Public Class CABlock

Inherits BlockBase
Public Overrides Sub Execute()

'TODO: User should insert their Execute code here
End Sub
End Class
You enter your code statements into the code frame. The following kinds of statements can
be entered:
• Declarations of block scope variables are entered below declaration of class CAB and
above the line "Public Overrides Sub Execute()".
• Declarations of local variables are entered within subroutine Execute().
• Executable statements are entered within subroutine Execute() where the “TODO”
comment is.
• Private subroutines and functions are entered within the CAB class declaration, above
or below the declaration of Execute(). Subroutines can be added outside the class
definition, but if you do, you will not have access to all of the data that is inherited
from the original class. Depending on the subroutine, this might not be a problem.
10/04 Honeywell
CAB configuration
Code CAB algorithm
Although parameter definitions and executable code are entered into different windows,
there is interplay between the two. The PDE definitions ultimately yield support code that
allows parameters to be used as variables within the Execute() subroutine. You do not need
to provide definitions other than those entered within PDE. However, you must save
parameter definitions before parameter names will be recognized within executable code.
Entering a complete type definition is typically an iterative process in which you shift back
and forth between PDE and the algorithm source window.
TIP
In your code, you must remember to add .Value to a CDP or parameter
reference when accessing its value—for example, accessing Me.FLOW.Value.
If you forget the .Value, you will get a build error similar to the following (this
example is for a CDP that is Float64).
<cdpname>.Value: Value of type ‘Double’ cannot be converted to

Honeywell.CAB.BlockMap.Float64CDP
For a parameter reference, the error message would be similar to the following
(this example is for a PRef that is Float64).
<prefname>.Value: Value of type ‘Double’ cannot be converted to

Honeywell.CAB.BlockMap.Float64PRef’
Define block scope variables

Block scope variables are like CDPs in that they are persistent and are retained across
block executions. They differ in that they are not visible within the namespace of the PKS.
Thus, they never "appear" on the "surface" of the block. Since block scope variables are
visible only within the CAB program, you determine their use when you create the CAB
type.
You might decide never to use block scope variables. Or, you might use them for holding
internal state, for doing pre-computations that render several CDP values into a single
value, or for other reasons.
Microsoft VB.NET establishes the rules for definition and manipulation of block scope
variables. Generally, these variables are defined within the CAB program at the scope of
the VB.NET class that defines the block type.
Block scope variables can be declared as either private or public. Either way, they cannot
be accessed through the standard data access methods of the PKS.
Honeywell 10/04
CAB configuration
Code CAB algorithm
In the terminology of VB.NET, block scope variables are "instance variables" of the class
that defines the block. For an example of block scope variables, see “Define the algorithm
for VLR_CALC.”
Define local variables

Local variables are similar to block scope variables in that they are visible only within the
context of the CAB program. They differ in that their values are not retained from one
block execution to the next. Their values are retained only during of execution of the
subroutine or function where they are declared.
Local variables are declared within Execute(), which is described in the next topic. They
can also be declared within custom subroutines and functions created by the CE.
Microsoft VB.NET establishes the rules for definition and manipulation of local variables.
For examples of local variables see “Define the algorithm for VLR_CALC.”
Algorithm definition – Execute()

There is a single subroutine, Execute() that forms the user-supplied interface for all CABs.
It is known to the wider CEE environment. It is called whenever the containing CEE is in
Run and the parent CM is Active.
All algorithmic content of the block consists of VB.NET statements that are either
explicitly contained within Execute() or that are contained within custom subprograms
called by Execute(). Execute() handles code that is intended to run continuously as well as
initialization code that is intended to run only under special conditions.
Execute() can read and write CDPs, block scope variables, and local variables as needed. It
can make reference to parameters owned by other block instances through the use of CAB
parameter references. It can send messages and make use of other CEE-specific APIs. It
can make use of a wide variety of built-in functions supported by VB.NET.
Execute() can call programmer-defined functions and subroutines as appropriate. However,
functions and subroutines are always local to the CAB type. CAB does not support
functions and subroutines that are shared across CAB types.
Execute() can have its execution triggered by the parent CM in the same manner as any
other component block within the CM. In this scenario, the CAB's order of execution with
respect to other component blocks is determined by its ORDERINCM parameter.
Alternatively, CABs can have their execution controlled by one of the other component
blocks within the parent CM. This would be the treatment used when a CAB is to serve as
an insertion point algorithm. In this case, the partner component block, a PID for instance,
would be configured to call the CAB at an appropriate point in its execution, while the
CAB’s parent CM would be configured to not call the CAB at all.
10/04 Honeywell
CAB configuration
Code CAB algorithm
Execute() runs periodically when the CAB is instantiated within a CM configured to run
under process special scheduling. CM process special is a configuration option that allows
a trigger parameter to be set at runtime on the CM, causing any pre-fetch requests to be
issued and the subsequent execution to be scheduled.
Execution mode of CAB programs

The execution mode of CAB programs can be characterized as "atomic." They do not
support "distributed" execution. What this means is that after the Execute() function of a
CAB program starts, it runs to completion. It is never interrupted by data access requests
from outside the block.
A CAB can be thought of as an "atom" in the sense that it's execution is indivisible by
requests to access the data it owns. This feature means that programmers who write CAB
programs can do so without concern that data (CDPs) might be read while their values are
under computation and not ready for use.
In contrast, distributed execution would mean that the processing of the CAB Execute()
subroutine could be interrupted by requests to access CDP data owned by the block. Under
this paradigm, the complete execution of a CAB is "distributed" in time, across one or
multiple requests to read data from the block. Distributed execution is extremely useful for
support of long running, iterative calculations. But it requires careful management of
computing resources so that "foreground" computations are never delayed and so that data
that is under modification by the algorithm is never read until it is ready and whole.
Distributed execution is not supported in this release.
Long-running iterative calculations can, in principle, be supported within an atomic
execution paradigm. This could be done by carefully tracking state data and by using
counters or explicit state variables to direct looping activity. State variables could be used
to determine when loops must be exited to avoid overruns, and how to reenter loops once
the computation resumed. But this sort of approach is difficult and is rarely used.
CAB programs are not used as sequence programs in the sense of SCMs or in the sense of
prior Honeywell offerings such as SOPL/MFC, CL/MFC or CL/PM. Sequence block types
or sequence programs are designed with built-in preemption mechanisms that
accommodate the wait operations prevalent in sequence control. CAB programs offer no
such inherent support.
In principle, a CAB program could be used to affect some level of sequence control. This
could be done by explicitly managing state within the program design so that "steps" could
be exited and re-entered with each call to Execute(). In general though, this would be a
time consuming design so CAB would not generally be used to drive sequence control
within CEE. SCMs would be used instead.
Honeywell 10/04
CAB configuration
Code CAB algorithm
However, SCMs can work with CAB instances to augment their own function. There
several different ways that this can be accomplished:
• A CM containing a CAB could be triggered to do a process special execution by an
SCM.
• A CAB could be written to alter its execution pattern in response to one or more
values of its own CDPs. A partner SCM could be implemented to write the CAB CDPs
to trigger different kinds of processing.
• A CAB program could be written to alter its execution pattern in response to one or
more PRef values read from a partner SCM.
• A CAB instance could be configured to operate as an insertion program triggered by a
native block (the call master). Any changes of state an SCM might apply to the call
master would likely impact execution of the CAB program. For example, if the call
master were a PID, SCM writes to MODE would stop or start execution of the insertion
program.
It is also true that CAB instances can initiate communications that impact execution of
other CAB instances or SCMs.
• In general, any affect that an SCM can have on a CAB instance can also be triggered
by a different CAB instance. Thus, a CAB could trigger the process special function for
a CAB contained in a different CM, it could use CDPs and PRefs to affect the
execution pattern of another CAB, or it could write to parameters like MODE that
would impact the execution of a CAB insertion program.
• CAB instances can also impact the execution of SCMs in the same manner that SCMs
impact the execution of other SCMs. This is through writes to the SCM COMMAND
parameter.
• A CAB can control the execution of another CAB in a different CM There is a
Boolean parameter called Block Process Special (BPS) on a CM that a CAB can use to
cause the CM to run one time as a process special. Refer to CB documentation for more
information.
• Another technique whereby a CAB can control the execution of another CAB is by
activating and inactivating the host CM of the CAB to be controlled. This can be done
by writing a zero (inactivate) or one (activate) to the CM’s EXECSTATE parameter.
As an example, a CAB (CAB1) can monitor an event and activate the CM in which
another CAB (CAB2) resides. CAB2 can do the processing for the event, and can then
inactivate its own CM at the end of the special processing.
10/04 Honeywell
CAB configuration
Code CAB algorithm
PRef as data alias within CAB program

CAB programs can read and write data on other blocks through parameter references
(PRefs). Each PRef addresses exactly one scalar parameter or one element of an indexed
parameter. Referenced parameters can be on blocks within the same CEE or a different
CEE, or on a remote OPC server referenced through an OPC Server FB. For information
on configuration and use of OPC Server FBs, see the Application Control Environment
User Guide.
You specify the number and kinds of references used by a given program at the time you
design the block type. Limits on reference count come from the ERDB total memory size
and from the ERDB parameter count limit per block type. See “Limitations on number of
CAB parameters” for comments on ERDB limits that affect both CDPs and PRefs.
When creating PRefs, CAB programmers can assign the attributes of name, data type,
description, and data flow direction. Data types supported for PRefs are described in “Data
types for CDPs and parameter references.”
The name of a PRef is used within the CAB program to refer to the external parameter.
This name can be thought of as an alias for the external data. It can be the same or different
from the name of the parameter to be referenced. Often, PRef names are chosen so that
they reflect what the data means within the program. For example, suppose a CE is
designing a block type that receives a temperature input from a boiler. It would be natural
to call the reference to this parameter BOILERTEMP.
Configuring parameter addresses on CAB instances

CAB PRefs are generic and static. This means that the block parameters they refer to are
not bound at the time the block type is defined. The binding occurs later, at the time the
block instance is configured. Each instance can use its references uniquely, pointing to
different blocks and parameters. Only one copy of the CAB program (type definition) is
needed within the execution environment no matter how many instances are created.
The binding of CAB PRefs is not so late that it can be considered "dynamic." Binding
occurs before block load at the time of block instance configuration. After the block has
been loaded, reference binding cannot be changed without reload.
Within CAB programs, PRefs are typically used as constant-valued pointers. But it is also
possible to define PRef variables internal to the program. This would be done to allow the
use of more flexible programming constructs such as looping over an array of references or
passing references to a subroutine. For an example of the use of PRef variables see “Use of
parameter reference variables in CAB.”
Honeywell 10/04
CAB configuration
Code CAB algorithm
When addresses are assigned to PRefs at configuration time, it is not required that an entry
be supplied for every reference defined by the block. Undefined or null valued PRefs are
accepted without error at time of load. However, if READERROPT and WRITEERROPT
are specified as Event (see “FDPs specific to CAB” for a description of READERROPT
and WRITEERROPT), an event is reported if a null reference is used at run time. Allowing
null PRefs enables greater flexibility in the creation of generic block types.
PRefs allow CAB programs to read and write external data but do not allow that external
data to be displayed as though it were a parameter on the block. When debugging, you
must view external data on the externally referenced block or you must create value CDPs
within the CAB and set their values to the parameter reference values to show the data
locally.
Access level used In PRef writes

When PRefs are used for writes, CAB sends an identifier along with the data to indicate
the type of agent originating the write. This identifier is called the Access Level. It has two
possible values as follows:
• Program
• Continuous Control
When a CAB type is designed, you choose one of these values by specifying the instance
default for FDP ACCESSLEVEL (described in “FDPs specific to CAB”). After the CAB
type is operational, it uses one or the other access level value exclusively.
When a CAB program interacts with CEE native blocks, writes are treated equivalently
regardless of whether the access level is Program or Continuous Control. Typically,
parameters like the SP of regulatory control blocks are not written from CAB. Instead, if a
CAB is to serve as supervisory controller in a regulatory cascade, the downstream block
pulls the SP from a CAB CDP.
If you explicitly wish a CAB type to write to SP, then MODE at the target regulatory block
must be Auto. This is equivalent to the MODE protocol that applies to sequences. In
addition, MODEATTR must be set to Program at the target in order for writes to any of the
parameters SP, MODE, OP, RATIO, or BIAS to be accepted.
10/04 Honeywell
CAB configuration
Code CAB algorithm
In most cases, there is no reason for a CAB design to use Continuous Control instead of
Program access level. Thus, when a CAB type is first created, the instance default for FDP
ACCESSLEVEL is automatically set to Program by PDE and left unchanged by you. You
would change ACCESSLEVEL to Continuous Control if the CAB type were designed for
use with legacy Honeywell control systems. You would also change ACCESSLEVEL to
Continuous Control if the CAB were to be used as an insertion point algorithm. For
comments on interfacing to legacy systems, see “Determine Continuous Control access.”
Data types for CDPs and parameter references

Data types supported for CDPs within CABs and CDBs, and for parameter references
within CABs, are shown in the following table. Note that the set of types supported for
data that exists within the PKS name space is more restricted than the set supported within
the confines of a CAB program. Within a CAB program, the only limitations are the
capabilities of VB.NET.
Table 25 Data types for CDPs and parameter references
Data type Supported Supported Comment

for CDPs for
parameter
references
BOOLEAN Yes Yes BOOLEAN CDPs as used within CABs and CDBs
have a representation equivalent to that of CEE
parameters of flag type. False (Off) has value 0
while True (On) has value 1. The same is true for
BOOLEAN parameter references in CABs. Note
that for consistency with past characteristics of
MS VB 6.0, VB.NET represents True as –1 when
converted to integer. Despite this, all BOOLEAN
type parameters in Experion, including those of
CABs, represent True as 1.
INT16 No No 16 bit integers can be used within VB.NET if

desired. But for parameters and parameter
Note 1 references visible within the PKS name space;
CABs and CDBs support INT32 as the general-
purpose integer.
Honeywell 10/04
CAB configuration
Code CAB algorithm

for CDPs for
parameter
references
INT32 Yes Yes There is a single integer type supported for CDPs
and parameter references within both CABs and
CDBs. For CAB parameter references, implicit
conversion operations are supported between
INT32 and most other scalar types. Specific
properties of these conversions are described in
“Implicit type conversion with CAB parameter
references.”
<Standard No No Defining value CDPs or parameter references to

System be one of the standard system enumeration types
Enumeration> (for example, MODE enumeration or MODEATTR
enumeration) is not supported. Within CAB
programs, you can use the equivalent numerical
values when dealing with system enumerations.
You can also define program-local enumerations
that match the system enumerations. When
storing to external parameters, CAB parameter
references support implicit conversion so that the
store will be accepted by the destination
parameter. This is described further in “Implicit
type conversion with CAB parameter references.”
<Self-Defining No No Defining value CDPs or parameter references to

Enumeration> be of type self-defining enumeration (for example,
PV state of Device Control, OP state of Device
Control, or PV state of Digital Input) is not
supported. Within CAB programs, users can use
equivalent numerical values when dealing with
system enumerations. They can also define
program local enumerations that match the self-
defining enumerations. When storing to external
parameters, CAB parameter references support
implicit conversion so that the store will be
accepted by the destination parameter. This is
described further in “Implicit type conversion with
CAB parameter references.”
10/04 Honeywell
CAB configuration
Code CAB algorithm

for CDPs for
parameter
references
FLOAT32 No No 32-bit floating-point numbers can be used within

VB.NET if desired. But for parameters and
parameter references visible within the PKS name
space; CABs and CDBs support FLOAT64 as the
general purpose floating point type.
FLOAT64 Yes Yes There is a single floating-point type supported for

CDPs and parameter references. For CAB
parameter references, implicit conversion
operations are supported between FLOAT64 and
most other scalar types. Specific properties of
these conversions are described in “Implicit type
conversion with CAB parameter references.”
Within CAB programs, FLOAT64 CDPs and
PRefs are of the VB.NET data type Double.
TIME Yes Yes Parameters of type TIME indicate a point in time

(social time). Within CAB programs, TIME is
represented by the .NET structure DateTime.
Conversion between TIME and the internal
representation of DateTime is always done
implicitly for CABs. This applies to both parameter
references and CDPs. See “TIME and
TIMEOFDAY usage in CAB” for information.
DELTATIME Yes Yes Parameters of type DELTATIME indicate a time

span (time duration). Internal to CAB programs,
DELTATIME is represented by the VB.NET
structure called TimeSpan. Conversion between
DELTATIME and the internal representation of
TimeSpan is always done implicitly for CABs. This
applies to both parameter references and CDPs.
Honeywell 10/04
CAB configuration
Code CAB algorithm

for CDPs for
parameter
references
TIMEOFDAY Yes Yes Parameters of type TIMEOFDAY (Time Of Day)

indicate the time elapsed since midnight. CDPs of
type TIMEOFDAY are supported by both CABs
and CDBs. Parameter references of type
TIMEOFDAY are supported by CABs. Within CAB
programs, TIMEOFDAY is represented as the
VB.NET type TimeSpan. It is thus internally
equivalent to DELTATIME and will, in many
cases, provide no added value over that data
type. In some cases, however, it may be
convenient for the design of custom displays to
define CDPs of time TIMEOFDAY. See “TIME and
TIMEOFDAY usage in CAB” for information.
STRING Yes Yes String type CDPs are supported for both CDBs
and CABs. String type parameter references are
supported for CABs. String types can be up to 255
characters in length.
Structure No No Structure types can be used internal to CAB

programs, but CDPs and parameter references
cannot have structure type.
Class No No Class types can be used internal to CAB

programs but CDPs and parameter references
cannot have class type.
Note 1—There are several other integer data types beyond INT16 and INT32 supported
within the PKS. These are not explicitly listed here. INT32 is unique in being the only
integer data type supported for CDPs and parameter references.
CDPs can be indexed parameters (logical arrays) of dimension up to 2. When configuring
array parameter definitions within the PDE window, the data type is selected from one of
the scalar types listed above. That a CDP is indexed is specified by parameter attributes
distinct from the data type.
Parameter references cannot be indexed (logical arrays of references are not supported).
However, they can be used to refer to scalar elements of array parameters at fixed index.
10/04 Honeywell
CAB configuration
CAB algorithm data definition
In the table above, it is important to understand that typing of CAB CDPs and CAB
parameter references is described in terms of the Experion type names. It is necessary to do
so as CDPs are part of the PKS namespace and parameter references point to parameters
that are part of that namespace. However, there is a one to one mapping between each of
the supported data types listed above and the VB.NET data type used within a program.
This is shown in the following table.
Table 26 Data type names in Experion and VB.NET
Data type of parameter Data type of alias

as viewed externally as viewed internally
in PKS namespace within VB.NET program
BOOLEAN Boolean
INT32 Int32
FLOAT64 Double
TIME DateTime
DELTATIME TimeSpan
TIMEOFDAY TimeSpan
STRING String

Data initializations under Execute()
CAB instances can own data that are persistent but that are not computed every execution
cycle. These might be internal constants derived from externally stored configuration
parameters. They might be status values that are typically constant but that can change in
response to process or system failures. There are many other possibilities. All such data are
initialized under the calling tree of subroutine Execute().
When the condition that triggers initialization derives from a process or communication
occurrence, the initialization code is typically integrated directly into the periodic control
algorithm. A typical example would be initialization of a PV in response to an I/O error
status.
Honeywell 10/04
CAB configuration
Using the Restart property

Another kind of initialization is one that needs to be done in response to changes in the
operating environment that hosts the CAB block. To enable this, CAB supports an API
called Restart. Restart is a VB property that can be accessed within Execute() to identify
when special initializations are needed. The use of Restart is optional. In many algorithms,
there is no need to use it at all.
Restart returns values of type RestartEnum. Possible values are described below.
• None— No system event has occurred since the llast execution of the CAB
instance.There has not been a system event since the last execution of the CAB
instance.
• BlockLoad—The block is about to execute for the first time since creation within the
EE, or for the first time since reload.
• BlockActivate—The block had been inactive but is now about to execute for the first
time since going active. No load occurred while the block was inactive but the user
may have changed configuration data within the block through on-process displays.
• CABToNormal—The block has returned to Normal state from Dormant or
Terminated state.
• CEEColdStart—The CEE as a whole is about to restart execution from a data state

left after a previous execution. The time elapsed since last execution was judged by the
operator to be long.
• CEEWarmStart—The CEE as a whole is about to restart execution from a data state

left after a previous execution. The time elapsed since last execution was judged by the
operator to be moderately short.
If it happens that more than a single system event occurs while a CAB block is not
running, CAB infrastructure uses a priority scheme to decide which value to return when
Restart is accessed. This scheme insures that the CAB block is informed of the most severe
initialization condition. The priority is as follows.
BlockLoad > BlockActivate > CEEColdStart > CEEWarmStart > CABToNormal > None
10/04 Honeywell
CAB configuration
For an example of using Restart to select different initializations see “Initializing in

response to system events.”
It is important to understand that initializations that are conditioned by Restart only occur
in response to events that impact execution of the instance. If instance execution is not
impacted, then the value returned by Restart remains at None. As an example, consider
conditions that cause a PV input to become unavailable or bad. This might be caused by
communication failure, node failure or some kind of process condition. A condition such
as this would never cause Restart to deviate from None. Instead, the CAB algorithm must
detect this condition explicitly and respond as appropriate.
CDP initializations associated with block load

For CDPs, CAB infrastructure can support data initialization as part of block instance load.
When this is done, there are actually three stages of CDP initialization of which the
processing done within Execute() is the last. These are shown in the following table.
Table 27 Custom Data Parameter initialization in Custom Algorithm Blocks
Type of CDP Order Value Comment

initialization returned by
Restart
Default 1 Not When you design a block type, you can define the
Applicable instance default for the CDP. You can also declare
the CDP to be loadable. When an instance is created
within CB, the CDP will be initialized with the default
value.
Configuration 2 Not After an instance is created within CB, the default of

Applicable all loadable CDPs can be left unchanged or they can
be modified. After loadable CDPs are configured, the
instance is loaded to CEE. This causes all loadable
CDPs to be initialized to the configured value within
CEE. If a CDP is defined to be non-loadable, then it is
initialized to the fail-safe value that goes with its data
type. Fail-safe values are described in “Parameter
reference fail-safe values.”
Execute() 3 BlockLoad When the CM parent of a CAB is activated for the first
processing time following load, access to Restart within
Execute() will result in return of the value BlockLoad.
In response to this, code within Execute() can choose
to leave the loaded values of CDPs unchanged or it
can modify them.
Honeywell 10/04
CAB configuration
Data access integrity

The topic “Execution mode of CAB programs” discussed how CAB instances execute
atomically. This form of execution generally insures that data integrity is preserved.
However, integrity issues can still occasionally arise. This discussion provides further
information on integrity of parameter access.
Characteristics of parameter transfer vary depending on the nature of the application being
developed. Three major variants are listed below.
• Local Parameter Access—CAB type is intended to communicate only with local
blocks.
• Remote Communication With No Group Integrity Requirements—CAB type
must communicate with remote blocks but data transfer involves only scalar parameters
or whole array parameters which pose no issues of consistency or timing across groups
of different parameters.
• Remote Communication With Group Integrity Requirements—CAB type must
communicate with remote blocks and the application design imposes consistency or
timing requirements across a group of two or more parameters.
Each of the variants is discussed in the following topics.
Local parameter access

In applications where a block reads parameters only from other blocks within the same
CEE, no data integrity issues arise. The same can be said for cases where a block writes
only to blocks within the same CEE. In these cases, the property of atomic execution is
sufficient to insure data integrity.
To see this, consider the code segment below. Here it is assumed that a program must
generate a sum over a scaled input parameter that is indexed. Also assume the following.
• The input array, called INPUT, is a custom parameter that can be written by other
blocks.
• The scale factor, SCALE, is a CDP that can be written by other blocks or by displays.
• The sum parameter, OUTPUT, is an output CDP which can be read by other blocks or
by displays.
10/04 Honeywell
CAB configuration
OUTPUT.Value = 0.0
For I = 0 To 9
OUTPUT.Value = OUTPUT.Value + SCALE.Value * INPUT(I).Value
Next I
While the syntax of CDP usage may appear unfamiliar at first (this is discussed in “CDP
classes”), it should be clear what the above code is doing. In the context of data access, the
following questions might arise.
• Suppose that another local block, CAB or native, tries to read parameter OUTPUT.
Could it get a value taken from the middle of the loop computation?
No. If a request to read OUTPUT arrives while the above code is executing, access to
the parameter is locked until the code finishes executing.
• Suppose another local block writes to each of the elements of INPUT. Could it happen
that the sum would get computed using values from two different execution cycles of
the block that writes to INPUT?
No. The loop above can never execute at the same time as another local block that
stores to the INPUT array. As long as the writing block writes all elements of INPUT
within one execution, the values are received as a consistent set.
• Suppose SCALE is written by another block. Could a new value of SCALE start to be
used in the middle of the loop?
No. If a write to SCALE occurs while the above code is executing, it does not take
effect until the code finishes executing the current cycle.
Remote communication with no group integrity requirements

In some applications, it may be essential to access remote data, either for some or all
instances of the CAB type. Ensuring that data obtained remotely is consistent and useable
requires deliberate consideration on the part of the CAB program designer. But in many
cases, special measures need not be taken because of the nature of the data itself.
To see this, consider the single line of code below. Here it is assumed that a program must
produce a PV that cannot be directly measured. Instead, the PV must be mathematically
inferred from three other process measurements. To start with, assume the following:
Honeywell 10/04
CAB configuration
• Three measured inputs, MEASIN1, MEASIN2, MEASIN3, must be obtained from

one or more remote CEEs.
• A single output, called PV, must be computed from the three inputs by a proprietary
algorithm.
• Each of the three inputs is accessed via a parameter reference.
Consider the following line of code:
PV.Value = Compute(MEASIN1.Value, MEASIN2.Value, MEASIN3.Value)
While the syntax of PRef usage may appear unfamiliar at first (this is discussed in
“Parameter reference classes”) it should be clear what the above code is doing.
In this example, data integrity issues can be reduced to considerations of whether each
input value is good and useable. There are multiple techniques for identifying the usability
of remote input data. These are discussed in “Parameter reference classes.”
The important point is that this example presents no issues of consistency across the group
of inputs. MEASIN1 through MEASIN3 are continuous process readings. So while you,
the CAB type designer, would need to consider the general timing properties of the remote
data access in this example, you would not need to be concerned about the order of data
retrieval. Nor would you need to be concerned about whether input values came from the
same execution of a remote block. With continuous process values, there is no inherent
ordering and, depending on the application, a fairly broad time interval can be considered
close enough to simultaneous.
Now, if the example is changed slightly to imagine that MEASIN1 through MEASIN3
were CDPs being pushed from one or more remote CEEs, then the same reasoning applies.
No consistency requirements apply to the set of inputs, so the only integrity consideration
is whether each value is good or bad.
Remote communication with group integrity requirements

The majority of CAB applications will fall into one of the two cases discussed above.
However, it might occasionally arise that a CAB program must involve itself with remote
parameter access in which two or more parameters in a group have consistency
requirements. The means for addressing this will depend strongly on the particular
application. Some examples are discussed below to give a feel for the issues.
First, reconsider the example in the topic “Local parameter access,” changing the
assumptions such that the input array, INPUT, is coming from a single remote block, not a
local block. The example is reproduced here, with the new assumption:
10/04 Honeywell
CAB configuration
It is assumed that a program must generate a sum over a scaled input parameter that is
indexed. Also assume the following.
• The input array, called INPUT, is a custom parameter that is written by a single
remote block.
• The scale factor, SCALE, is a CDP that can be written by other blocks or by displays.
• The sum parameter, OUTPUT, is an output CDP that can be read by other blocks or
by displays.
OUTPUT.Value = 0.0
For I = 0 To 9
OUTPUT.Value = OUTPUT.Value + SCALE.Value * INPUT(I).Value
Next I
In this case, consistency issues might arise. It is possible that the array data would need to
be sampled from a single execution of the originating block. But, if each array element
were pushed individually, transport services could not be guaranteed to preserve order or
even to insure that the entire set of elements were received as a set between executions of
the consuming CAB instance. The array might be received in parts across multiple
executions of the consuming block.
A way to resolve this problem would be to implement the CM containing the receiving
CAB instance so that it receives the array INPUT through bulk array transport. Bulk array
transport is guaranteed to read the entire set of elements and to write them with no
intervening block executions. Also, since the array is transported as a unit, no issues arise
with respect to order.
This principle can be used fairly flexibly. For example, suppose that in the above example,
the INPUT array together with the scale factor, SCALE, had consistency requirements.
Then SCALE could be transported with the INPUT array by creating an array of 11
elements at the originating end and transporting that in bulk.
Bulk array transport could also be used to transport process value along with a quality
indicator. Generally, the data status or quality needs to come from the same execution of
the source block as the data value. If not, the quality indicator could say the data was good
when it was bad or vice versa. While quality indicators would generally be thought of as
being integer valued, there is nothing to prevent a floating-point number from being used
to represent quality. Thus, quality and value could be placed into a single array at the
originating end and transported as a unit.
Honeywell 10/04
CAB configuration
Now consider a different example. Parameters MODE and SP of the PID block are related
and can be considered to have a consistency requirement. In general, MODE must have a
particular value in order for store of SP to be accepted by the target block.
When CAB writes MODE and SP to a local block, no particular design issues arise. As
long as MODE is written with the appropriate value first, SP will be accepted. However, if
the target block is remote, the write sequence will usually work but is not guaranteed to
always work. Peer-to-peer communication services are not guaranteed to maintain order of
delivery. Also, depending on the remote device which hosts the block, it may be necessary
for the receipt of MODE and the receipt of SP to be separated by an execution cycle at the
target.
A standard technique for addressing this problem is to write MODE and read it back before
writing SP. Once MODE goes to the target value, the SP write may proceed. This is shown
in the following example where WriteSP is assumed to be a local Boolean state variable
and SPTargetValue is the desired value for SP. Both MODE and SP are assumed to be
PRefs.
If WriteSP Then
If MODE.Value <> 1 Then
MODE.Value = 1
Else
SP.Value = SPTargetValue
WriteSP = False
End If
End If
Read versus write

Another consideration when designing applications that use CAB is whether a particular
data transfer should be done with Read or Write. CAB supports both. Target blocks or
devices may require one or the other. In some applications, you might have the option to
choose whether a CAB design uses Read or Write.
There is no hard and fast rule as to which should be used if the choice is available. Here are
some general considerations:
• If CAB is to receive data and the chosen design has an external block push to the CDP
of a CAB instance, then it is not possible for CAB to check status information on the
data transfer. The last value pushed will always hold if the transfer operation fails. This
is true regardless of whether the transfer operation is peer-to-peer or is confined to a
single CEE.
10/04 Honeywell
CAB configuration
• If CAB is to receive data and the chosen design has CAB pull from an external block
via a PRef, then the CAB instance can always check status to see whether the data
transfer was successful. This is true regardless of whether the transfer operation is peer-
to-peer or is confined to a single CEE.
• If CAB is to send data and the chosen design has an external block pull from the CDP
of a CAB instance, then depending on its design, the external block might be able to
check status information on the data transfer. This is true regardless of whether the
transfer operation is peer-to-peer or is confined to a single CEE.
• If CAB is to send data and the chosen design has CAB push to an external block via a
PRef, then the CAB program can always be implemented to check the status of the
write operation. However, the program implementation depends on whether the
destination block is always in the same CEE as the CAB instance, or whether there will
be at least one case when the two will be in different CEEs. Response of the external
block to transfer failure depends on its design. In most cases it would hold last value.
• If CAB pushes to a local block, status is always available in the same execution cycle
where the push was performed. The program design to use the status is quite simple.
• If CAB pushes to a remote block, status is not available until an execution cycle
subsequent to the cycle where the push was performed. The program design to use the
status is more involved and requires the use of one or more state variables.
Honeywell 10/04
CAB configuration
These observations are summarized in the following table.

Table 28 Integrity considerations for read versus write
Data flow initiator
Data flow direction
External block Cab instance

• External block pushes to • CAB pulls through PRef.
CAB CDP.
External block to • CAB can see transfer
CAB instance • CDP holds on transfer status.
failure.
• CAB cannot see transfer
status.
• External block pulls. • CAB pushes through PRef.
CAB instance to • Depending on design, • If target is local, CAB can

external block pulling block may check see transfer status on
transfer status. same execution.
• If target is remote, CAB
can see transfer status on
subsequent execution.
• Depending on design,
target generally holds in
response to transfer
failure.
Structures and classes usage within CAB

Variables of structure type and variables of class type can be used within CAB programs as
consistent with the syntax and semantics of the underlying .NET language. CDPs that are
visible to the PKS outside the CAB program cannot be defined to have structure or class
type. Parameter references that access data on function blocks outside of the CAB program
cannot be defined to reference parameters of structure or class type.
10/04 Honeywell
CAB configuration
Array usage within CAB

Arrays can be used within CAB programs as consistent with the syntax and semantics of
the underlying .NET language. For arrays that are only used internally to CAB programs
(block scope variables or local variables), the full indexing capabilities of the VB.NET
language are supported.
CAB CDPs can be defined to be of one- or two-dimensional array type. The element type
of CDP arrays is always a simple type and is restricted to the set supported by scalar CDPs.
The CAB that owns the array CDP can do index computations at run time in order to
access elements of the array.
CAB parameter references are always scalar. Thus, the block designer cannot create an
array of parameter references. Scalar parameter references can point to scalar parameters
or to individual elements of array parameters. References to external parameter arrays
always use fixed indices and are thus equivalent to ordinary scalar references.
Several options are available for the space-efficient display of array-valued CDPs within
operating displays:
• Custom displays can be designed to show selected elements of arrays.
• Chart visualization can be used to show CAB forms within the operational view.
Under chart visualization and monitoring, array CDPs can be displayed in the following
ways:
• Individual array elements can be displayed as parameter values on the CAB faceplate
symbol.
• Individual array elements can be displayed as pins on the CAB faceplate symbol.
• The CAB form can be opened to view a scrollable form for the entire array.
For an illustration of the differences between internal array variables, CDP arrays, and
scalar parameter references to array elements, see “Array and scalar variables in CAB.”
Floating point usage within CAB

Floating-point data within CAB programs are represented according to the IEEE 754
floating-point standard. The following functions are provided.
• Floating-point divide of a finite value by zero produces +INF or –INF with no
exception being thrown.
• Assigning an INF value from one floating-point variable does not cause an exception.
Honeywell 10/04
CAB configuration
• INF values are ordinal. Use of INF in any floating-point comparison produces results
consistent with comparison of finite values.
• INF values propagate through subsequent calculations. Thus, a finite value divided by
+INF or –INF will yield zero. A positive finite value multiplied by –INF will yield –
INF. +INF subtracted from any finite number will yield –INF.
• INF values can be identified through use of the IsInfinity() method and related
methods.
• Floating-point divide of zero by zero produces NaN with no exception being thrown.
• Assigning a NaN value from one floating-point variable to another does not cause an
exception.
• NaN values are non-ordinal. Use of NaN in any floating-point comparison produces
the value False. For example, the following comparisons will all return False:
(1.0 = NaN); (1.0 <> NaN); (1.0 > NaN); (1.0 < NaN); (NaN = NaN).
• NaN values propagate through subsequent calculations. Any calculation done with one
or more NaN values as input yields NaN as output.
• NaN values can be identified through use of the IsNan() method.
A NaN constant is available within the language implementation to allow variables to be
initialized to NaN.
When INF or NaN values are stored to external block parameters through parameter
references, the resulting behavior is determined by the design of the receiving block. Some
blocks might be designed to allow write of these values to specific parameters. Others
might be designed to reject such writes. If a CAB program attempts to write a NaN or INF
and the write is rejected, the program can learn of this from the returned data access status.
CAB infrastructure never throws exceptions when programs attempt to write floating-point
values to internal or external variables. If you wish to prevent NaN or INF values from
going out, you must write the program to test before storing.
10/04 Honeywell
CAB configuration
CAB algorithm parameter references
TIME and TIMEOFDAY usage in CAB

The following rules summarize how to use data types TIME and TIMEOFDAY in CAB:
1. All parameters of type TIME and TIMEOFDAY are stored internally (in ERDB) in
UTC time format.
2. If you enter a TIME or TIMEOFDAY CDP default value in PDE, it should be entered
in regional (local) time. The value will be converted automatically to UTC time when
stored in the ERDB.
3. CB will display TIME and TIMEOFDAY parameters in PC regional time.
4. Displays will display TIME and TIMEOFDAY parameters in regional time.
5. CAB programs that convert TIME and TIMEOFDAY parameters to a string format
are responsible for converting TIME and TIMEOFDAY to regional time using the
VB.NET conversions that are available.

Implicit type conversion with CAB parameter references
Although CAB parameter references can only be defined with one of the types listed in
“Data types for CDPs and parameter references,” a particular parameter reference can
actually address a wider set of parameter types. For example, a FLOAT64 reference can be
configured to address parameters of type INT16, INT32, FLOAT32, one of the standard
system enumerations, and others.
To support this functionality, implicit data type conversions are performed for read and
write operations associated with parameter references. Implicit conversions are supported
for CAB parameter references but not for stores to value CDPs. Stores to value CDPs from
native blocks or from displays must always come with matching data type.
Depending on the nature of the source data type, the nature of the destination data type,
and the nature of the value to be converted, direct conversion may not always be possible.
The following tables show how CAB handles conversions involving non-commensurate
data. Symbols used within the table are explained by the following legend.
Honeywell 10/04
CAB configuration
Legend
• "→" indicates "transferred to" or "converted to".
• The term "commensurate" indicates a data transfer in which range, precision and data
semantics are preserved.
• Terms "ordinal 0 or "ordinal 1" indicate the numeric value of an enumeration as
distinct from the name value of an enumeration.
• MINI32 = -2147483648. This is the minimum value that can be represented by an
INT32.
• MAXI32 = 2147483647. This is the maximum value that can be represented by an
INT32.
• MINI16 = -32768. This is the minimum value that can be represented by an INT16.
• MAXI16 = 32767. This is the maximum value that can be represented by an INT16.
• MINF32 = -2.86E38. This is roughly the minimum value that can be represented by a
FLOAT32.
• MAXF32 = 2.86E38. This is roughly the maximum value that can be represented by a
FLOAT32.
• MAXP32 = 16777215. This is the maximum integer value that can be represented
with full precision by a FLOAT32.
• "~x" indicates that the pre-existing value of x is preserved with some loss in precision.
In cases of floating point to integer conversion the fractional part is always handled by
rounding.
• .NETTO = .NET Time Origin. This is a 0 within the 64-bit .NET representation of
time. It corresponds to January 1, 0001, 12:00 AM.
• ExpTO = Experion Time Origin. This is 0 within the 64 bit Experion representation of
time. It corresponds to January 1, 1972, 12:00 AM.
In cases where the data read is out of range for the destination data type and must be
clamped, the parameter reference status property will indicate a range error. In cases where
the data read results in real or potential loss of precision there is no indication by the status
property. In cases where the data flow is outgoing (write via CAB parameter reference)
and data must be clamped, there is no indication by the status property.
10/04 Honeywell
CAB configuration
Parameter references used for read

The following two tables show how CAB handles implicit type conversions for reads
through parameter references. "Source Data Type" is the data type of the external
parameter being read. "Destination Data Type" is the data type of the CAB parameter
reference itself. The destination data type maps directly to a VB.NET type as described in
“Data types for CDPs and parameter references.” In the following tables, rows correspond
to source while columns correspond to destination. The table is broken into two parts for
readability.
Honeywell 10/04
CAB configuration
Table 29 Implicit data type conversion for PRef reads (part 1)
Destination data type
Source data BOOLEAN INT32 FLOAT64

type
BOOLEAN commensurate FALSE → 0 FALSE → 0.0

TRUE → 1 TRUE → 1.0
INT16 Note 1 x == 0 → FALSE commensurate commensurate

x != 0 → TRUE
INT32 x == 0 → FALSE commensurate commensurate

x != 0 → TRUE
<Standard x == ordinal 0 → ordinal 0 → 0 ordinal 0 → 0.0

System FALSE ordinal 1 → 1 ordinal 1 → 1.0
Enumeration> x != ordinal 0 → TRUE etc. etc.
<Self Defining x == ordinal 0 → ordinal 0 → 0 ordinal 0 → 0.0

Enumeration> FALSE ordinal 1 → 1 ordinal 1 → 1.0
x != ordinal 0 → TRUE etc. etc.
FLOAT32 x is NaN → FALSE x is NaN → 0 commensurate

x == 0.0 → FALSE x < MINI32 → MINI32
x != 0.0 → TRUE MAXI32 < x → MAXI32
other x → x
FLOAT64 x is NaN → FALSE x is NaN → 0 commensurate

x == 0.0 → FALSE x < MINI32 → MINI32
x != 0.0 → TRUE MAXI32 < x → MAXI32
other x → ~x
TIME FALSE 0 NaN
DELTATIME FALSE 0 NaN
TIMEOFDAY FALSE 0 NaN
STRING FALSE 0 NaN
Note 1
There are several other integer data types beyond INT16 and INT32 supported within the
PKS. These are not explicitly listed here. INT32 is unique in being the only integer data
type supported for CDPs and parameter references. However, like INT16, implicit
conversion to and from INT32 is supported for other integer types.
10/04 Honeywell
CAB configuration
Table 30 Implicit data type conversion for PRef reads (part 2)
Source data TIME DELTATIME TIMEOFDAY STRING

type
BOOLEAN .EXPTO 0 12:00 AM ""
INT16 Note 1 .EXPTO 0 12:00 AM ""
INT32 .EXPTO 0 12:00 AM ""
<Standard .EXPTO 0 12:00 AM ""

System
Enumeration>
<Self Defining .EXPTO 0 12:00 AM ""

Enumeration>
FLOAT32 .EXPTO 0 12:00 AM ""
FLOAT64 .EXPTO Converts to days Converts ""

fractional part to
TIMEOFDAY
TIME commensurate 0 12:00 AM ""
DELTATIME .EXPTO commensurate 12:00 AM ""
TIMEOFDAY .EXPTO 0 commensurate ""
STRING .EXPTO 0 12:00 AM commensurate
Parameter references used for write

The two tables below show how CAB handles implicit type conversions for writes through
parameter references. "Destination Data Type" is the data type of the external parameter
being written. "Source Data Type" is the data type of the CAB parameter reference itself.
The source data type maps directly to a VB.NET type as described in “Data types for
CDPs and parameter references.” In these tables, columns correspond to source while rows
correspond to destination. The table is broken into two parts for readability
Honeywell 10/04
CAB configuration
Table 31 Implicit data type conversion for PRef writes (part 1)
Source data type BOOLEAN INT32 FLOAT64
BOOLEAN commensurate same as read same as read
INT16 Note 1 FALSE → 0 x < MINI16 → MINI16 x is NaN → 0

TRUE → 1 MAXI16 < x → MAXI16 x < MINI16 → MINI16
other x → x MAXI16 < x → MAXI16
other x → x
INT32 same as read commensurate same as read
<Standard FALSE → ordinal 0 x <= 0 → ordinal 0 x is NaN → ordinal 0

System TRUE → ordinal 1 x == 1 → ordinal 1 x < 1 → ordinal 0
Enumeration> etc. 1 <= x < 2 → ordinal 1
etc.
<Self Defining FALSE → ordinal 0 x <= 0 → ordinal 0 x is NaN → ordinal 0

Enumeration> TRUE → ordinal 1 x == 1 → ordinal 1 x < 1 → ordinal 0
etc. 1 <= x < 2 → ordinal 1
etc.
FLOAT32 FALSE → 0.0 x < -MAXP32 → ~x x is NaN → NaN

TRUE → 1.0 MAXP32 < x → ~x x < MINF32 → -INF
other x → x MAXF32 < x → INF
other x → ~x
FLOAT64 same as read commensurate commensurate
TIME ExpTO ExpTO ExpTO
DELTATIME same as read same as read same as read
TIMEOFDAY same as read same as read same as read
STRING same as read same as read same as read
Note 1
There are several other integer data types beyond INT16 and INT32 supported within the
PKS. These are not explicitly listed here. INT32 is unique in being the only integer data
type supported for CDPs and parameter references. However, like INT16, implicit
conversion to and from INT32 is supported for other integer types.
10/04 Honeywell
CAB configuration
Table 32 Implicit data type conversion for PRef writes (part 2)
Source data type TIME DELTATIME TIMEOFDAY STRING
BOOLEAN same as read same as read same as read same as read
INT16 Note 1 0 0 0 0
INT32 same as read same as read same as read same as read
<Standard ordinal 0 ordinal 0 ordinal 0 ordinal 0

System
Enumeration>
<Self Defining ordinal 0 ordinal 0 ordinal 0 ordinal 0

Enumeration>
FLOAT32 NaN NaN NaN NaN
same as read same as read same as read same as read

FLOAT64
TIME commensurate ExpTO ExpTO ExpTO
DELTATIME same as read commensurate same as read same as read
TIMEOFDAY same as read same as read commensurate same as read
STRING same as read same as read same as read commensurate
Honeywell 10/04
CAB configuration
Parameter reference fail-safe values

CAB infrastructure returns a fail-safe value for any parameter reference that incurs a read
error. The value returned depends on the data type as shown in the table below.
Table 33 Fail-safe values
Data type Fail-safe value
BOOLEAN False
INT32 0
FLOAT64 Nan
TIME EXPTO - 1/1/1972 12:00AM
DELTATIME 0
TIMEOFDAY 12:00 AM
STRING ""
CAB writes with Continuous Control access level

Assume that a CAB type was designed to support supervisory control to a UCN resident
PM, APM or HPM controller. There are several different ACE configurations that could be
used.
• CAB instance serves as insertion algorithm for Regulatory Control FB in ACE.
UCNOUT FB pulls from regulatory FB. UCNOUT FB pushes to Regulatory Control
point or to AO point in PM through an OPC Server FB.
• CAB instance executes stand-alone in ACE. CAB instance computes SP or OP
command as CDP value. UCNOUT FB pulls from CAB instance. UCNOUT FB pushes
to Regulatory Control point or AO point in PM through an OPC Server FB.
• CAB instance executes stand-alone. CAB instance uses PRefs to write parameters of
PM points through an OPC Server FB, independent of any regulatory or UCNOUT FBs
in ACE.
In the first case listed above, the CAB instance directs PRef writes to an ACE regulatory
FB. In this case, the CAB should be configured with an access level of Continuous
Control.
10/04 Honeywell
CAB configuration
In the second case above, the CAB instance does not issue PRef writes. Therefore access
level does not enter the picture.
In the third case above, use of Program or Continuous Control access level in the CAB
design will have different effects. When Program is used, PM points receiving the write
react as though the CAB program is part of a sequence. The following applies:
• Regulatory points must have MODE = Auto for SP writes to be accepted.
• Regulatory points must have MODE = Man for OP writes to be accepted.
• AO points must have MODE = Man for OP writes to be accepted.
• Parameter MODEATTR at the target point must be Program in order for writes to
parameters SP, OP, MODE, RATIO or BIAS to be accepted.
When Continuous Control access level is used, PM points receiving the write react as
though the CAB program is supervisory continuous controller. The following applies:
• Regulatory points must have RCASOPT set to SPC or RSP and MODE set to Cas in
order for SP writes to be accepted.
• Regulatory points must have RCASOPT set to DDC or DDC RSP and MODE set to
Cas in order for OP writes to be accepted.
• AO points must have RCASOPT set to DDC and MODE set to Cas for OP writes to
be accepted.
• MODATTR does not condition acceptance of writes to parameters SP, OP or MODE.
Honeywell 10/04
CAB configuration
Create a CAB instance

Overview
The process of configuring CAB instances is the same as for native block instances, and
only the differences are covered here. For more information on creating instances, refer to
the Control Building Guide. You can also review the “Getting started tutorial” in this
document, which demonstrates many of the basic Control Builder steps that are used in
creating a CAB type and creating a CAB instance.
Double-clicking on the block symbol within the project or monitor control chart accesses
the block’s properties form, which has several tabs. (There are other ways to open the
form, which are standard CB functionality.) The form can be used to specify and load
configuration parameters, and can also be used to display view only parameters when
monitoring. When the block is a CAB, the properties form has four additional tabs that are
not present on the forms for native blocks. They are:
• Value CDPs tab
• Parameter References tab
• Source tab
• Alarms tab
These are the default tabs. Other custom tabs can be configured in the PDE using the form
layout feature.
TIP
The Value CDPs tab is present only if you configured value CDPs when you
defined the type. Similarly, the Parameter References tab is present only if
you configured parameter references when you defined the type.
TIP
You can create custom tabs and do other special properties form editing tasks
in the PDE. For more information, see "Reviewing general block type
functions" in the Parameter Definition Editor Reference.
10/04 Honeywell
CAB configuration
Configure Value CDPs tab

The Value CDPs tab on the properties form has two viewing options, depending on
whether the Show Parameter Names option at the bottom of the form is checked or
unchecked.
Figure 15 below shows the Value CDPs tab as it appears when the Show Parameter
Names option is unchecked. In this view, the Parameter description that you entered
when you created the type is listed for each CDP, along with its default value. Figure 16
shows the Value CDPs tab when the Show Parameter Names tab is checked. In this case,
the parameter name is listed rather than the parameter description.
Figure 15 Value CDPs tab with descriptions showing
Figure 16 Value CDPs tab with parameters showing
Honeywell 10/04
CAB configuration
The parameters that are listed on the form are the parameters that you configured when you
defined the CAB type in the IDE. The corresponding values shown for each parameter are
the default values that you assigned at that time (unless you subsequently changed the
default value for the instance, as described in the next paragraph).
If you were in the Project tree view when you opened the properties form, you can change
a default value on the form and new value will be saved to the ERDB when the form is
saved. It will then be saved to the CEE when the block is loaded, provided that the
parameter’s Configuration load attribute was set to LOAD when you created the type.
This change of a default value will apply only to the specific block instance, and will not
be reflected in other instances of the type, nor will it change the value in the type
definition.
If you opened the properties form from the Monitoring view, you can change a parameter
value, and when you click OK on the form, you will be prompted as to whether or not you
want to save the online value:
If you click Yes, the new value will be loaded to the CEE immediately. The change will
not be reflected in the ERDB, and the next time the block is loaded, the default value
stored in the ERDB will be loaded.
See also “Value CDPs tab for CAB and CDB.”
Configure parameter references tab

To configure parameter references, you must open the properties form when you are in the
Project view. You cannot configure or modify parameter references in the Monitoring
view. When you select the Parameter References tab on the block properties form for the
first time, the list of parameters is displayed, but the values are empty, as shown in Figure
17.
10/04 Honeywell
CAB configuration
Figure 17 Parameter References tab
As in the case of the Value CDPs tab, you have the option of viewing the parameter
names, or descriptions, depending on whether the Show Parameter Names option at the
bottom of the form is checked or unchecked (see “Configure Value CDPs tab” above). In
Figure 17 and Figure 18, the parameter names are displayed. These parameter names are
the alias names that you entered when you defined the block type in the IDE.
On this form, you configure the parameter references that will be used for this instance of
the CAB. Use the browse button at the right of each entry box to select the reference. You
can also enter the parameter reference directly, but it must be valid reference that is
configured on the system and saved in the database. Figure 18 shows a Parameter
Reference tab that is configured with parameter references.
Honeywell 10/04
CAB configuration
Figure 18 Parameter Reference tab configured
See also “Parameter References tab.”
Source and Alarms tabs

The Source tab displays the algorithm code. This can be helpful in verifying the version of
code that is actually running in the instance. See “Source tab.”
The Alarms tab allows you to view and configure the values for alarm priority and
severity for CAB-specific alarms. See “Alarms tab.”
Save the configuration

When you have completed the configuration of value CDPs, parameter references, and the
other standard configuration items, click OK to close the form. The configuration
information will be saved to the ERDB when you save the project chart using one of the
standard CB methods.
10/04 Honeywell
CAB configuration
Configure insertion points

Overview
In this discussion, “insertion point” refers to a place in the normal processing sequence of a
block where a CAB algorithm can be inserted, and is not to be confused with the usage of
“point” as tagged entity.
CAB instances can be configured to execute in the “normal” way that blocks are processed
in a CM. Alternatively, a CAB instance can be configured to execute at an insertion point
in the processing sequence of certain other block types. In this case, the CAB instance will
not execute independently. When inserted into a native block instance, the CAB will
execute whenever the host native block is scheduled to run, and will execute when the
appropriate point in the processing of the native block is reached (the configured insertion
point). The host native block instance and the CAB instance being inserted must be in the
same CM. When used as an insertion point algorithm, a CAB can replace the standard
algorithm, or it can be used to enhance other aspects of the native block’s function. This
depends on where it is inserted.
The ACE Data Acquisition block type and all of the Regulatory Control block types can be
configured to accept a CAB instance as an insertion point algorithm. Refer to Control
Builder documentation for specific information about the use of these various insertion
points.
RegCtl insertion points

The following insertion points are available for regulatory control type block instances:
Table 34 Insertion points for RegCtl points
Insertion Description
Post-Input CAB instance inserted after input processing
Pre-Alg CAB instance inserted prior to algorithm processing
Ctl-Alg CAB instance inserted in place of the built in algorithm
Post-Alg CAB instance inserted after algorithm processing
Post-CtlOut CAB instance inserted after control output processing
Honeywell 10/04
CAB configuration
DataAcq insertion points

The following insertion points are available for the data acquisition point:
Table 35 Insertion points for Data ACQ point
Insertion Description
PV-Alg Custom PV algorithm
Post-PVchar CAB instance inserted after PV characterization
Post-Clampfilt CAB instance inserted after PV filtering and clamping
Post-PVsrc CAB instance inserted after PV source selection
Post-Alarmproc CAB instance inserted after alarm processing
Configuration procedure
The following procedure is a summary of the general steps to configure an insertion point.
Refer to Control Builder documentation for additional information.
Table 36 Insertion point configuration procedure
Step Action
1 When you are defining the CAB type in the development environment, be sure
to configure the Access Level as Continuous Control. This is important.
2 Configure the RegCtl or DataAck instance and the insertion CAB instance in
the same CM and do a Save.
3 Open the properties form for the RegCtl or DataAck instance and select the
Insertion tab.
10/04 Honeywell
CAB configuration
Step Action
4 Configure the number of insertions (NUMINSERT), the Insert Type, and the
name of the CAB (you can use the browser button to select the name, but do
not pick a parameter even though they are listed). The result will be similar to
the figure below:
5 Open the CAB properties form and configure values for any parameter
references that you have defined.
6 Verify that the insertion is configured correctly. Either of these methods will
work.
• With the CAB properties form open, select either the Configuration
Parameters or the Monitoring Parameters tab, select INSMASTER, and
click Add.
• With the RegCtl or DataAck properties form open, select the
Configuration Parameters tab, select INSBLOCK, and click Add.
7 Save, load, and activate the CM.
Do not use graphical connections

When using a CAB as an insertion algorithm, do not use graphical connections (wire or
parameter connections). CAB insertion programs usually share data only with their
insertion master (the block that is using the CAB as an insertion program). When this is the
case, PRefs must be used to accomplish data flow into or out of the CAB instance. This is
because PRefs are the only data flow mechanism that will insure that data flow occurs in
the proper sequence with respect to execution of the insertion master and the CAB
program.
Honeywell 10/04
CAB configuration
Test and debug the CAB

Developmental debugging
There are several steps that you can take before you incorporate your CAB into a strategy
that is ready for debugging in a CEE. With Control Builder, you can create libraries and
define CAB and CDB types. You can define CDPs for your CAB and CDB types. You can
develop control algorithms for your CAB types, and ensure that the code compiles without
errors. You can save your types to the ERDB. However, in order to test your types as part
of a strategy, you will need to configure them in CMs and load them into a CEE. You will
undoubtedly want to debug your CAB in the context of the overall strategy, but in an off-
process environment.
Off-process debugging
You can debug CAB programs in an off-process mode. By doing so, you can utilize the
source level debug capabilities of the MSVS IDE. These capabilities include single step
execution, break points that can be set and viewed directly within the source code, and the
ability to examine internal variables during break.
To do source level debugging, start by creating a debug build of the CAB program. To do
this, build to the "debug target" within MSVS. This produces a build of the program that is
different from the normal "release target" build in that it contains additional information to
be used by the source level debugger.
The CAB infrastructure supports four parameters (EXCPTNLINENM,
EXCPTNMODULE, EXCPTNMSG, and EXCPTNTYPE) that can assist in debugging
code that is causing an exception. For information about these parameters, see “FDPs that
capture exception information.”
After building, save the debug build to ERDB and load an instance of the block to a SIM-
ACE. With the block instance loaded, attach the MSVS debugger to the SIM-ACE OS
process that is running the block instance. With the debugger attached, you can then set
break points and use other MSVS debugger capabilities. The MSVS online documentation
set includes information on the use of the MSVS debugger.
10/04 Honeywell
CAB configuration
You can iterate through as many variations of the block type as needed to eliminate
defects, using the source level debugger to identify defects at each stage. When all defects
have been removed and off-process debug is considered complete, you should do a final
test of your CAB with a build to the "release target" and do a test run of the “release” built
CAB. Then save this final build to the ERDB.
To insure safety, source level debugging should only be used with an off-process SIM-
ACE. An alarm is generated if MDM service is running on an ACE node. This is the
service that allows breakpoints to be set, so it should be disabled on on-process ACE
nodes. For more information, see “Security policy.”
For further information on the use of SIM-ACE, see “Debug with SIM-ACE.”
On-process debugging
You can choose to use on-process debugging in addition to or instead of off-process
debugging. In some cases this may be convenient because it avoids the need to create
simulation strategies to support off-process debug.
The facilities available for on-process debugging are equivalent to the facilities available
for debugging instances of native block types like SCM, AUXCALC and REGCALC. You
use the monitoring capabilities of CB to view runtime values of CAB parameters and draw
conclusions about the correctness of the underlying code.
With CAB types, the definition of visible parameters is under your control. This means
that you can define parameters to make internal data visible, either permanently to form
characteristic attributes of the block, or temporarily to support debug. You can also use the
Send() subroutine to forward information to the message display of Experion Station. This
technique can be used to construct a trace of specific block data across successive
executions. Refer to “Subroutine Send()” for more information.
Troubleshooting information
The section on CAB and CDB troubleshooting and maintenance has information that will
help you troubleshoot CAB problems. Refer to the following topics:
• Troubleshooting approach
• CAB instance states
• CAB alarms
• Debug with SIM-ACE
• CAB fault handling
Honeywell 10/04
CAB configuration
Modify a CAB
Modify a CAB
Modify/Edit CAB type with MSVS
ATTENTION
When you open the CAB development environment, a splash screen appears
briefly. You can minimize this screen, but if you close it, the development
environment will not open.
You will frequently need to modify CAB types. Required changes might include algorithm
defect fixes, algorithm functional enhancement, addition of CDPs, modification to
attributes of existing CDPs, or deletion of CDPs. Whatever the reason, changes will
happen most often while the type is in development. Less frequently they will also happen
after a type has been deployed.
If you have already started an edit session and MSVS is open, you can immediately make
modifications. If you wish to open an existing type for edit, you must consider the lock
status as described in ”Block type locking flags.” If Edit Lock is set (that is, the type is
currently under edit by another engineer), you will see a message indicating that the block
cannot be edited.
To open the type, right-click on the block symbol within the library tree and choose Edit
Type. Alternatively, double-click on the CAB type, or choose the CAB type in the library,
then go to the Edit menu, and choose Type. When MSVS opens, the algorithm code
window will show the executable code for this type. To see the parameter definitions for
the type, go to the Parameter Definition Editor tab/window.
With MSVS open, edit the type as required, changing or adding parameter definitions and
executable statements as desired. When your editing session is complete, save PDE
changes, and build. Repeat edit, save, and build operations until all build errors are
eliminated.
After you have a clean build, you are ready to save to ERDB. When modifying a type, the
procedure of saving to ERDB can be different than it is when saving a newly created type.
This depends on the following:
• Whether instances already exist for the block type
• What kinds of changes have been made to the type
These issues are discussed in the next topic.
10/04 Honeywell
CAB configuration
Modify a CAB
Manage instances after modification of CAB type

When saving a modified block type to ERDB, you must make decisions about how to
handle any preexisting instances. There are two options. Which one you use depends on
whether you are in the process of debugging the block type or whether you are maintaining
a block type that is already being used on process. The two options are:
1. Save the modified block type under the preexisting name. This will immediately
convert the project side instance. The actual operation of the block, if active, is not
affected, because it will continue to use the old block until a load operation updates it
with the new instance. If you have made changes such as new pins or parameters that
are configured to show on the faceplate, there are special considerations. If you made
these changes in the Symbol Attributes tab in the PDE, you need to delete and re-
add the instance on the project side and then load to update the monitor side. If you
made these changes from the project side properties form, the changes will not appear
on the monitor side until you load.
2. Save the modified block type under a new name, and convert the project and monitor
side instances later.
The first option is used in debug scenarios. During debug, you typically go through
multiple cycles of changing code and testing instances. It would be very inconvenient to
manually reassign type names at every pass through the cycle. To avoid this, CB and CAB
infrastructure allow modified types to be saved without name changes. Existing instances
are converted automatically on the project side subject to constraints on the nature of
changes that can be made.
When using the first option, a save overwrites the source code in ERDB, and if you choose to
update instances, the original code is eliminated entirely from the project side. However, if you
have not loaded the new code to the monitor side instances, the old code still exists there. If you
want to recover the old code, you can open the source code tab on the monitor side property
form, copy the old source code that is displayed there, and paste it back into MSVS.
When on-process CAB blocks must be modified, the second option is recommended. In
this case, you save the modified CAB type under a new name so that none of the on-
process blocks need be disturbed. Then you can inactivate the running blocks one at time,
convert them to the new type, and reload them. The process of converting blocks can be
carried on over an extended period of time without risk.
When you use the second option, the CAB type (program) used by the CEE instances is
not overwritten within ERDB. Both the old and new types remain until you have converted
all instances. After there are no remaining instances of the old type, you can delete it if
desired. You cannot delete it while there are remaining instances. As long as there is an
instance of the old CAB type within CEE or within ERDB, the old CAB type cannot be
deleted from ERDB.
Honeywell 10/04
CAB configuration
Modify a CAB
Note that a procedure exists whereby you can verify that the version of a CAB program
running in CEE is the same as the version stored in ERDB. This is described in ”Verify
match of CAB program in ERDB.”
User actions when saving modified CAB type

There are several conditions that can affect the save operation. To make this clear, consider
the following scenario.
1. You create a block type called CONTROLLER.
2. You instantiate CONTROLLER under the name CONTROLLER1 within control
module CM1.
3. You assign and load CM1.CONTROLLER1 to a CEE so that both project and
monitor copies exist.
4. You now open type CONTROLLER once again and make changes.
5. You successfully build type CONTROLLER.
Now you attempt to save block type CONTROLLER to ERDB.
The first relevant condition to affect the save operation is whether instances of the type
exist within ERDB. In this case there is an instance so you will be given a warning
message that says the following:
"Overwrite type and convert all ERDB instances?"
ATTENTION
If you are using the QVCS versioning system, refer to the topic “Special
considerations when using QVCS with CAB” for important information.
If you were saving a modified CAB type that was already on process, you would normally
select Cancel (Cancel is the default) because you would not wish to overwrite an on-
process CAB with one that is untested. Similarly, if you were debugging a new type but
wished to leave the old version in ERDB for a while longer, you would select Cancel. But
suppose that you are debugging and don't need to keep the old version of the type. You
select OK.
At this time, another condition comes into play. This condition is the nature of the changes
that have been made to the block type. For most changes, CB automatically converts all
existing instances to match the new block type. This is what would happen, for example, if
CDPs had been added to the type, parameter references had been added, or if any
algorithm changes had been made. However, under a specific set of conditions such as
10/04 Honeywell
CAB configuration
Modify a CAB
deletion of a preexisting CDP, or changing the data type of a CDP, CB does not support
automatic conversion.
Suppose that you had modified CONTROLLER in such a way that a CDP was deleted. CB
would then respond to the save command as follows:
A "Save-As" dialog appears that gives the option of changing the name of the block type or
of canceling the save operation.
Faced with this dialog, you must now save the CONTROLLER to ERDB under a new
library or block name.
The fully qualified name for a CAB type consists of the library name concatenated with the
block type name. Thus, at this stage in the scenario, it is sufficient to change one or the
other. If the library name is left unchanged then the modified type goes into the preexisting
library under a new block type name. If the block type name is left unchanged then the new
block type goes into a different library under the old block type name.
To complete the scenario, suppose that you choose to leave the library name unchanged
and change the block type name to “CONTROLLERB.” You have now succeeded in
saving the modified version of "CONTROLLER" to the original library in ERDB, under
the new name "CONTROLLERB." What remains is to convert the preexisting instance,
CONTROLLER1, from an instance of CONTROLLER to an instance of
CONTROLLERB. The following section describes how to use the CB "Convert"
command.
Note that when save under a new name is done, the edit lock on the old type is
automatically cleared and a new lock is opened for the newly named type. The lock
remains active until you close MSVS for the new block type.
Figure 19 Saving modified CAB types” is a flow diagram that shows how various
conditions affect the save operation. This diagram covers the most usual scenarios but does
not necessarily cover every special case that might arise.
Honeywell 10/04
CAB configuration
Modify a CAB
Behaviors when saving modified types to ERDB

Whereas there is only one condition that impacts Convert of block instances from one type
to another, there are several conditions that impact the save operation. These are shown in
the figure below.
Figure 19 Saving modified CAB types
10/04 Honeywell
CAB configuration
Modify a CAB
Convert instances to modified CAB type

CB provides the ability to change a block instance from one type to another type. This is
called converting a block instance.
A typical use of this feature is to allow you to modify an existing type, save it as a new
type, and then update the existing instances of the old type. This technique avoids the need
to delete the old instances and create new instances of the new type. Other scenarios are
possible. When conversion is done, the ERDB type definition data is updated in both the
project side and monitor side instances. Instances must be converted one at a time, and a
subsequent load operation is required to update the CEE.
Changes that you can make to the type that are allowed by the conversion function are:
• You can add CDPs or change their data types.
• You can delete CDPs unless they have connections to other blocks. If a parameter with
an external connection needs to be deleted, the connection must be removed first.
• You can delete PRefs.
• You can add PRefs or change data types, but you will have run-time errors until you
configure the references in the instances.
• You can change the control algorithm
Honeywell 10/04
CAB configuration
Modify a CAB
Steps involved are as follows:

Table 37 Converting CAB instances
Step Action
1 Identify an in-service CAB instance that needs to be converted.
2 Decide whether the run-time instance contains any data that is not up to date in the
monitor side ERDB instance. If so, use the "Upload" command for the CM that contains
the CAB instance (right-click on the CM in the Monitor tree view and choose Upload).
3 Select the block instance to be converted in the project side chart view.
4 Right-click on the instance and choose Function Block Convert.
5 From the list that appears, select the new block type that should be assigned to the
instance.
6 Click Convert.
7 After the existing instance has been converted, you can inactivate, load and reactivate
the CM that contains the CAB instance.
Note that the convert function has fewer constraints than the Save to ERDB operation. For
example, you cannot Save to ERDB a block that has parameter deletions or data type changes if
there are existing instances of the block. These operations are permitted in the convert operation.
When a block instance is converted, the new type might have fewer parameters than the old
type, have more parameters than the original type, or have parameters with the same name but
different data type. These situations are handled as follows:
Parameters that have the same name and data type receive the value from the original instance.
• Parameters that have the same name but different data type are initialized to their
default values.
• Parameters present on the new block type but absent from the old are initialized to
their default values.
• Parameters absent from the new block type but present on the old are eliminated from
the new instance.
When converting instances, you might need to identify all instances of a block. See
“Discover CAB dependency relationships” for comments on locating instances of a type
using the Search functionality of Configuration Studio.k type.
10/04 Honeywell
CAB configuration
Manage CABs
Manage CABs
Verify match of CAB program in ERDB
You can compare the values of parameter BLOCKTYPEID to verify that the version of a
CAB program running in a CEE is the same as the version stored within ERDB. Use the
following procedure:
Table 38 Verify CAB instance version
Step Action
1 Open the properties form for the CAB type defined within ERDB. This can be
done in one of two ways. Either open the form directly from the library tree, or
open the form for an instance of the CAB type within the project tree.
2 Read the value of BLOCKTYPEID from the form. This is a 36-character
numerical value.
3 Open the properties form for an instance of the CAB type within the monitoring
tree.
4 Read the value of BLOCKTYPEID from the form.
5 Compare the two values.
TIP
If you are interested in determining whether or not a specific code change is
loaded into a monitor side instance, you can compare the code displayed on
the Source tab of the monitor and project property forms.
View a CAB type as read only

You can use the View > Type menu option when the Library tree has focus to open, as
read only, a CAB type that is under edit by another engineer. You can also use this
command to open the type without setting the Edit Lock flag.
If a type is under edit and you try to open it without using the View Type command, you
will be prompted to open as read only or to cancel.
Honeywell 10/04
CAB configuration
Manage CABs
Delete a CAB type from ERDB

You can delete CAB types from the ERDB if they are no longer needed or if they have
been superseded by later versions. CB will not allow you to delete block types if there are
corresponding instances on the project side or monitor side of ERDB. Similarly, CB will
not allow you to delete block types if there are templates on the project side that depend on
the type you are attempting to delete. If such instances or templates exist, CB will return an
error message on the delete attempt.
Deletion of a CAB type is not allowed when it is open for edit.
Custom libraries that contain custom block types or user templates can also be deleted.
System security policies allow anyone with engineering access to delete CAB types.
Rename a CAB
You can rename a CAB type except under the following conditions:
• You cannot rename a CAB type that is open for edit.
• You cannot rename a CAB type, or change the library name, if the type has an
instance loaded to the monitor side.
There are no restrictions on renaming CAB instances.
Recover a CAB with checkpoint restore

The system is designed to insure that all data and program associated with a CAB are
recovered by using the checkpoint restore command. Using a checkpoint containing CABs
is no different than using a checkpoint that contains only native blocks. You select the
ACE of interest and command a restore or save.
The action of checkpoint restore is destructive rather than additive. Thus, if checkpoint
restore is commanded to an ACE with a preexisting database, any preexisting CAB
programs are wiped out and new ones are added. Also, CAB infrastructure ensures that the
data restored with checkpoint restore is a unified set. If it matters to the application, CAB
programmers can rely on the fact that the restored data was captured at one instant in time
between block executions.
REFERENCE - EXTERNAL
For more information about checkpoint and restore, see the section titled
“Using Checkpoint to Save and Restore Data” in the Control Building Guide.
10/04 Honeywell
CAB configuration
Manage CABs
Recover CAB source code

If you have a CAB loaded and running in the CEE, but have overwritten (saved over) the
source code in the ERDB, there is a way to recover the source. The Source tab on the CAB
properties form on the monitor side reflects the source for the code that is actually running
in the CEE. You can copy the source code from this form, paste it into MSVS, rebuild, and
do a Save As. Then you can convert existing instances or create new instances as needed.
Export CAB
CABs can be exported from ERDB into a specified directory in the same manner that
native blocks are exported through the File > Export menu option. The procedures and the
user interface for doing so are covered in the Control Building Guide and are not
duplicated here. However, some important differences are highlighted here.
When you export native blocks, it is only the instance data that is extracted from ERDB. In
general, there is no need to extract native block types because they will already be defined
within the ERDB that is to receive the instances upon import. CAB types, however, are
different. When you export a CM that contains a CAB instance, you must also explicitly
export the CAB type into the same directory. This is because, in all likelihood, the
receiving ERDB will not already have a definition of the CAB type.
System services for export and import provide special handling for name collisions in CAB
types. A type name collision would occur if two engineers working with different ERDBs
had coincidentally chosen the same block name and the same library name for the type
they had created. Such a collision would not matter and would never be discovered unless
one engineer tried to import the block type into the ERDB used by the other. But if this did
happen, services associated with import would resolve the conflict by renaming the library.
To insure name collisions can be properly handled, export processing anticipates the
possibility of name change by supplying an internal identifier for associated types and
instances. This internal identifier is always unique and never changes. On import the
identifier can be used to properly match associated types and instances even when a type
name must change.
When you export a CAB, you must explicitly indicate both the requisite block types and
any requisite module instances. Types must always be selected explicitly. If instances are
exported without the associated types, any subsequent import operation will fail. CAB
types can be selected for export without any accompanying instances if the objective is
simply to transfer a program or toolkit from one ERDB to another.
When CAB types are exported, they always bring their library name with them. You may
choose whether to export the entire type content of the library or only a subset of the types.
Only those block types that have been explicitly selected are exported. To export an entire
library, you select all types contained within.
Honeywell 10/04
CAB configuration
Manage CABs
When a CAB type is exported, a directory structure is created. This directory structure is
used when importing. For more information on importing, see the next topic “Import
CAB.”
Import CAB
CABs can be imported from ERDB through the File > Import menu option. Block types
are imported first. Each fully qualified type name (library name with block type name) is
checked to determine if a duplicate exists within ERDB. If a duplicate is found, a
numerical suffix is automatically appended to the library name. After the name conflict is
resolved, the type is imported.
Status messages are reported during import to inform you if and when a library name
change occurs. Import messages are recorded in a log file called "IXP_log.txt" within the
directory:
"c:\Documents and Settings\All Users\Application Data\Honeywell\Experion PKS".
Following import, you have the opportunity to change the automatically generated names
if you desire.
When you import a CAB type, you must select the entire directory that the CAB type was
exported to. When CAB instances are imported, system services use both the type name
and the internal identifier to properly associate the instances with their types. If it is
discovered that the type associated with an instance has gone through a name change, the
instance's type name is changed to match and a status message is reported in file
IXP_log.txt.
ATTENTION
When a custom block type (CAB or CDB) is exported from one ERDB and
imported to another, the system that the type is imported to must be at an
Experion release level that is the same as or later than the release level of the
system that is being exported from.
10/04 Honeywell
CAB configuration
Manage CABs
Discover CAB dependency relationships

Experion supports services for tracing relationships between CABs and other named
entities within the PKS. These services are part of the Search functionality of
Configuration Studio.
All forms of dependency identification supported for native block instances and templates
are also supported for CAB block instances and templates. In addition, the Search tool
supports identification of certain dependencies that are unique to custom block types.
These are as follows.
• CAB instances that derive from a given CAB type.
• CAB type from which a given CAB instance is derived.
• CAB templates that derive from a given CAB type.
• CAB type from which a given CAB template is derived.
Special considerations when using QVCS with CAB

QVCS does not support versioning of CAB types or instances. QVCS does, however,
support versioning of CMs that contain CAB instances. Unlike native block types, CAB
types can be modified. Therefore it is important to understand the scenarios that can occur
when you modify a CAB type that has instances in CMs that are versioned in QVCS.
Assume that you wish to modify a CAB type that has instances in CMs that are versioned
in QVCS. If you first check out all of the CMs that have the current instance of the type
you wish to modify, and then modify the type and save to ERDB (with option to overwrite
instances if prompted), and then check the CMs back into QVCS, there are no special
QVCS considerations. All instances will be overwritten and the QVCS database will
contain the latest instances. If, however, you modify a CAB type that has instances in CMs
that are checked into QVCS, and then overwrite instances when saving the modified CAB
type to ERDB, all instances of the type will be overwritten, except that the QVCS database
will NOT be updated for those instances that are checked in. Therefore, if you
subsequently attempt to check out a CM from QVCS that contains one of these instances
whose type has changed, a special condition exists. The internal BLOCKTYPEID
associated with the CAB type of the instance to be checked out will not match the
BLOCKTYPEID of the new type stored in ERDB. In this case, you will encounter one of
the following situations:
Honeywell 10/04
CAB configuration
Manage CABs
1. If the system finds a library type whose library name and block name matches the
library name and block name associated with the type of the instance to be checked
out, the checkout (import) will be accepted with a warning message similar to the
following: “Import Warning for CM1.CAB1. BLOCKTYPEID checks for CAB
Block Type bypassed.” In this case, the BLOCKTYPEID of the checked out instance
will be changed to the BLOCKTYPEID of the type whose library and block names
match.
2. If the system cannot find a library type whose library name and block name matches
the library name and block name associated with the type of the instance to be
checked out, QVCS will display an error message and will reject the checkout
(import).
10/04 Honeywell
CAB configuration
Manage CABs
Honeywell 10/04
CDB configuration
Create a new CDB type
CDB configuration
CDB development environment
The CDB development environment is launched from the Control Builder application. The
development environment provided by Honeywell for CDB creation integrates the
following features into CB:
• Support for creation of new types for CDBs, and for adding these new types to the CB
library.
• Support for instantiating the new types into CMs, and for loading the type definitions
into the CEE.
• The Honeywell Parameter Definition Editor (PDE)—for configuration of custom data
parameters for CDBs.
Summary of configuration steps

The following steps are involved in the creation of a new CDB type:
• Open a new block type for edit
• Define custom parameters
• Save the type
Open a new CDB block type for edit

Creating a new CAB type begins from the Control Builder application. You choose File >
New > Type > Custom Data Block from the CB menu bar. A dialog box appears in which
you specify the Custom Library Name, either by entering the name of a new custom
library, or by selecting an existing library name from a drop-down list. In this dialog box,
which is shown in the following figure, you also enter the name of the new block (CDB)
type.
10/04 Honeywell
CDB configuration
Figure 20 Specify library and CDB name
Rules for library names are as follows:

• Maximum character count for library name is 50, minimum 1.
Rules for block type names are as follows:
• Maximum character count for block name is 50, minimum 1.
• Name must include an underscore or an alpha character.
After you specify the library and block names and click OK, the Honeywell Parameter
Definition Editor launches, as shown in the following figure.
Honeywell 10/04
CDB configuration
Figure 21 The Parameter Definition Editor
In this window, you enter your custom parameters (value CDPs). See “Define CDB custom
data parameters” for details on defining custom parameters.
Types of saves for CDB

The following table shows the types of save operations that are available for CDB.
Table 39 Types of saves for CDB
File menu Action

option
Save Saves the PDE data to local storage and to the ERDB. This option is
only available if you have made changes.
IMPORTANT: If you are using the QVCS versioning system, refer to

“Special considerations when using QVCS with CDB” for important
information.
Save As Do not use this command unless prompted to do so. See “Save As
Renew Renew command” below.
Save As Allows you to save another copy of the current block. You will be
prompted for the desired Library and Block names. If you keep the
same Library name, you must enter a different Block name. If you
choose a new Library name, the Block name can be the same as, or
different from, the name of the original block. After the save operation,
the block under edit in the PDE will be the new version.
10/04 Honeywell
CDB configuration
TIP
CDB types are different from CAB types in that there is not a separate
command to save to ERDB. The save commands in the table above save data
all the way through to the ERDB.
Save As Renew command

CDPs are identified within the system by parameter identification numbers that are
invisible to users. Under certain unusual conditions, it may become necessary for the
system to regenerate these identification numbers in order to continue with the current
operation. If this should occur, you will be notified by an error message that indicates that
you need to execute the Save As Renew command. This command requires that you select
a new name for the block that you are saving. If you execute the Save As Renew
command, the parameter identification numbers within the system are regenerated.
ATTENTION
A consequence of the Save As Renew command is that you will have to
reload all instances of the block. Alternatively, you may elect to cancel the
operation that you were doing when you received the error message indicating
the need for Save As Renew.
Save CDB to ERDB

After you have finished parameter definitions, you save them by choosing File > Save or
one of the other save options shown in Table 39 above.
After the type has been saved, instances can be created.
Honeywell 10/04
CDB configuration
Define CDB type parameters

Custom Data Parameter purpose
As the name implies, CDB types support custom data parameters. CDPs as supported
within CDB types are equivalent to the CDPs supported on CAB types.
Custom data parameters (CDPs) are parameters (variables) that you define. They are part
of the overall definition, or configuration, of your CDB. CDPs are visible within the PKS
as a whole. They are "public" in that any agent that has access to the PKS name space can
read them. Similarly, CDPs can be written by any PKS agent subject to store access checks
specified by you when you design the block. Thus, they represent an effective vehicle for
exchanging custom data throughout the PKS.
CDB types are useful in a wide variety of applications. They can be used to hold data that
is shared by multiple block instances within a CM or across multiple CMs. They can be
used in conjunction with both native blocks and CABs. They can be used as a more self-
documenting alternative to flags, flag arrays, numerics and numeric arrays.
CDP characteristics
Some characteristics of CDPs are:
• CDPs are directly analogous to the parameters of native block types. However, the
name, data type, access lock, and other properties, are not predefined. You specify
them during the process of defining the block type. Attributes that can be specified for
CDPs are described in "Reviewing custom parameters tab (Value CDPs)" in the
Parameter Definition Editor Reference. Data types are described in the section “Data
types for CDPs and parameter references” in this guide.
• Their values are persistent in the sense that they are maintained from creation until
deletion of the block instance. Their values are retained from one execution of the
block to the next.
• The data types available for the CDB CDPs are equivalent to those available for CAB CDPs.
• CDP values can be changed by writes from external blocks or other agents within the PKS.
However, since there is no program associated with a CDB, values are never changed as a
result of internal processing. Also, CDBs do not support parameter references.
10/04 Honeywell
CDB configuration
• CDPs can be viewed from several different displays within the PKS. CDP values can
be configured in the CDB form using the CB project side instance. CDP values can be
read and written on process from the CDB form using the CB monitor side instance.
Values can be read and written using chart visualization from the Experion Station.
They can also be read and written from custom displays.
Define CDB custom data parameters

CDP definitions are entered in the Value CDPs configuration form of the PDE. This form
is selected by clicking the Value CDPs tab of the PDE.
Figure 22 Value CDPs tab
A portion of he Value CDPs form is shown in the following figure.

Figure 23 Value CDPs configuration form
Reference. The following table includes useful links for Value CDP information:
Table 40 PDE information links for Value CDPs
Customizing the Value CDPs view (set of Reviewing PDE views for CAB and CDB
attributes that are displayed),
Specifying CDP attributes Reviewing custom parameters tab (Value

CDPs)
Honeywell 10/04
CDB configuration
Validity checks based on CDP attributes

Some of the CDP attributes that you configure are used to condition whether or not the
CDB instance will accept writes from external agents. This is true for the following
attributes.
• Access Lock
• Minimum Value
• Maximum Value
It is important to understand that these validity checks are done in accordance with the
Data Owner Principle. Thus, the CDB instance is considered the owner of all its CDP data.
Writes to its CDPs from external agents (blocks, displays, etc.) are accepted only if they do
not violate the validity checks.
For validity checks of Maximum Value and Minimum Value, special behavior is supported
for CDPs of floating point type. This is as follows:
• Writes of NaN are always accepted.
• Writes of non-NaN values are compared to the limits. Out of range values are never
rejected but are clamped instead.
• A write of +INF or –INF will be accepted unless a limit is set, in which case the value
that is stored is clamped at the limit.
A store to any parameter type other than floating point will be rejected if the value is
outside the Maximum Value and Minimum Value limits. A store to a parameter of type
floating point will clamp the value at the upper/lower limit and allow the store.
10/04 Honeywell
CDB configuration
Access lock attribute for CDPs

Attributes that can be specified as part of a CDP definition are described in the previous
topic. One of these is Access Lock. The access lock of a CDP determines which external
agents can initiate stores to the parameter. External agents are identified by an Access
Level identifier that is sent with every write request.
Table 41 below lists external agents that can attempt stores to CDPs and the access level
that identifies them. An “X” in a cell indicates that the operation is allowed. Note that for
some external agents, the access level can be one of several values, depending on
circumstances. In the case of CAB instances, the access level will be either Program or
Continuous Control depending on the value of fixed definition parameter
ACCESSLEVEL. In the case of human initiated stores from CB Monitoring Displays or
Station Displays, the access level will be Engineer, Supervisor or Operator depending
on privileges associated with the user id.
Honeywell 10/04
CDB configuration
Table 41 Access levels in Experion
External agent Access level

attempting
store Application Program Continuous Engineer Supervisor Operator
developer control
Control Builder X
during load of
CM or SCM
Supervisory X
batch
application
SCM X
CAB instance X X
Supervisory X
control
application
Algorithm X
function block
Human being X X X
storing from
CB monitoring
display
Human being X X X
storing from
Station display
Table 42 lists possible values for CDP Access Lock and their meanings. Each cell indicates
whether stores with the indicated Access Level will be accepted by a CDP that has been
assigned the indicated Access Lock.
10/04 Honeywell
CDB configuration
Table 42 Access locks for CDPs
Access level
Access lock Application Program Continuous Engineer Supervisor Operator

developer control
View Only No No No No No No
Yes No No No No No
AppDevOnly
Program Yes Yes Yes No No No
Engineer Yes Yes Yes Yes No No
Supervisor Yes Yes Yes Yes Yes No
Operator Yes Yes Yes Yes Yes Yes
As an example of how to interpret the above tables, consider a CDP defined with Access
Lock = Engineer. Suppose a human being with engineering privileges is logged on and
using a Station display. This user can store to the CDP. Users logged with only Supervisor
or Operator privileges and using the same display cannot store to the CDP. Supervisory
Batch or Continuous Control applications can store to the CDP, as can any CEE function
blocks that have the capability to initiate stores.
Fixed definition parameter purpose

CDB types support fixed definition parameters (FDPs). These are parameters that are
defined by the system in order to provide services essential to every CDB. Some FDPs are
for internal use only and are of no concern to users. Others are known to users and are used
either at the time of block type creation, block instantiation or both.
Fixed definition parameters in CDBs

CDBs and CABs support certain FDPs that are common to native blocks. These FDPs are
shown in Table 22. There are no CDB FDPs whose default values are configurable by the
user when the CDB is defined in CB. Hence the PDE does not have the Fixed tab that is
present for CABs.
The following table lists CDB FDPs that are not common with native blocks. Note that the
EDITLOCK and BLOCKTYPEID parameters are also present in CAB.
Honeywell 10/04
CDB configuration
Table 43 CDB FDPs not common with native blocks

BLOCKTYPEID Holds an identifier Definition fixed. View only

unique to each CAB or
CDB type.
CDBSOFTVER Contains the version of Definition fixed. View only.

the software that was
used to build the user’s
CDB type.
EDITLOCK Prevents simultaneous Definition fixed. View only.

type edits by holding
identifier of CE and
machine doing current
edit.
EDITLOCK also pertains

to CAB.
LOADSTATE Operating state of CDB Definition fixed. View only.

instance (Unloaded,
Loading, or Loaded)
Detailed description of CDB FDPs

Detailed descriptions of these parameters are located in the Control Builder Parameter
Reference. You can access these parameter descriptions by clicking on the name in Table
43.
Specify symbol attributes

As part of the CDB type definition, the Symbol Attributes tab on the PDE allows you to
define attributes for the block symbol that appears within project and monitor control
charts.
As part of the type definition, you can elect do the following:
• Expose any CDP as a connectable pin.
• Expose any CDP value on the face of the symbol.
Reference. The following link leads to information on symbol attributes:
10/04 Honeywell
CDB configuration
Table 44 PDE information link for symbol attributes
Configuring symbol attributes Reviewing Symbol Attributes tab
ATTENTION
Any modifications you later make to symbol attributes will not propagate to
existing CDB instances if you choose a Save and answer Yes when prompted
to update instances. There are two ways to change Symbol Attributes in
existing instances. Symbol Attribute changes must be done for each instance
by deleting and re-adding the block to the CM, or making the change in the
block properties form on the project side.
Specify form layout

As part of the CDB type definition, the Form Layout tab of the PDE allows you to specify
aspects of the layout of the block properties form. In most cases this is unnecessary as the
default form layout will be adequate. In some cases, you might wish to change the way the
form appears during instance building or during chart visualization in on-process displays.
Reference. The following link leads to information on form layout:
Honeywell 10/04
CDB configuration
Table 45 PDE information link for form layout
Defining the layout of the properties form Reviewing Form Layout tab
Form entry steps

CDB parameters and attributes are configured in the PDE forms. Descriptions and
reference material for these parameters and attributes are covered in this guide.
Information on how to use the PDE is covered in the Parameter Definition Editor
Reference.
One of the features of the PDE that you might find especially useful is the ability to cut,
copy, and paste parameters. These options are available by right clicking on a line in the
PDE.
Figure 24 Access cut, copy, and paste options
If your block contains multiple parameters that are similar, you can copy a parameter and
paste it into multiple lines. The PDE will rename each parameter when you paste it, so that
you will probably want to change the names to suit your naming convention.
You can also copy one or more parameters and paste them into a separate block that is
open for edit. In this case, the PDE will not change the names.
10/04 Honeywell
CDB configuration
Save parameter definitions

After completing configuration steps in the PDE, you must save the parameter definitions
with the Save command. The PDE will remain open after the Save operation. You must
close the PDE to end the edit session. For more information about Save operations, refer to
“Types of saves for CDB.”
Limitations on number of CDB parameters

There is a limit to how many CDPs a CDB can have. CDPs and FDPs both contribute to a
total that is constrained. This is shown by the inequality below:
Number of FDPs + number of CDPs < 1000
In this inequality it is important to note that array parameters count as one parameter
no matter how many elements they have. Also, use 200 for the number of FDPs, as this
is the number of FDPs that are reserved for each CDB.
Honeywell 10/04
CDB configuration
Create a CDB instance

Overview
Instance handling for CDBs is equivalent to that of CABs and to that of native blocks that
are instantiated within CMs. CDBs cannot be instantiated within SCMs. Project side and
monitor side instances have the same meaning and usage for CDB types as they do for
CAB and native block types. For more information about creating, loading, and deleting
instances, refers to the Control Building Guide.
CDB properties forms have the same meaning for CDB types as they do for CAB and
native block types. The look and feel of the form is determined by the parameters that
make up the block. The forms can be used for configuring the instance before load. The
form can be used for viewing and changing CEE-resident data from the monitoring side of
CB or from on-process Station displays using Experion chart visualization.
CDB types are analogous to CAB types in that the existence of run-time instances poses
restrictions on the user’s ability to change the block type. This is discussed further in
“Manage instances after modification of CDB type.”
Configure Value CDPs tab

Double-clicking on the block symbol within the project or monitor control chart accesses
the block’s properties form, which has several tabs. (There are other ways to open the form
that are standard CB functionality.) The form can be used to specify and load configuration
parameters, and can also be used to display view only parameters when monitoring. When
the block is a CDB, the properties form has one additional tab that is not present on the
forms for native blocks. It is:
• Value CDPs tab
The Value CDPs tab on the properties form has two viewing options, depending on
whether the Show Parameter Names option at the bottom of the form is checked or
unchecked.
Figure 25 below shows the Value CDPs tab as it appears when the Show Parameter
Names option is unchecked. In this view, the Parameter description that you entered
when you created the type is listed for each CDP, along with its default value. Figure 26
shows the Value CDPs tab when the Show Parameter Names tab is checked. In this case,
the parameter name is listed rather than the parameter description.
10/04 Honeywell
CDB configuration
Figure 25 Value CDPs tab with descriptions showing
Figure 26 Value CDPs tab with parameters showing
The parameters that are listed on the form are the parameters that you configured when you
defined the CDB type in the PDE. The corresponding values shown for each parameter are
the default values that you assigned at that time (unless you subsequently changed the
default value for the instance, as described in the next paragraph).
If you were in the project tree view when you opened the properties form, you can change a
default value on the form and new value will be saved to the ERDB when the form is saved. It
will then be saved to the CEE when the block is loaded, provided that the parameter’s
Configuration load attribute was set to LOAD when you created the type. This change of a
default value will apply only to the specific block instance, and will not be reflected in other
instances of the type, nor will it change the value in the type definition.
If you opened the properties form from the monitor tree, you can change a parameter
value, and when you click OK on the form, you will be prompted as to whether or not you
want to save the online value:
Honeywell 10/04
CDB configuration
Test the Custom Data Block
If you click Yes, the new value will be loaded to the CEE immediately. The change will
not be reflected in the ERDB, and the next time the block is loaded, the default value
stored in the ERDB will be loaded.
Test the Custom Data Block

Since CDBs do not have an algorithm, there is no debug stage as there is with CAB. A
CDB will be tested in the context of the control strategy in which it is located. Testing
involves verifying that the parameters are properly defined and that values are written and
read as intended.
Modify a Custom Data Block

Manage instances after modification of CDB type
When saving a modified block type to ERDB, you must make decisions about how to
handle any preexisting instances. There are two options. Which one you use depends on
whether you are in the process of developing the block type or whether you are
maintaining a block type that is already being used on process. The two options are:
1. Save the modified block type under the preexisting name. This will immediately
convert the project side instance. The actual operation of the block, if active, is not
affected, because it will continue to use the old block until a load operation updates it
with the new instance. If you have made changes such as new pins or parameters that
are configured to show on the faceplate, there are special considerations. If you made
these changes in the Symbol Attributes tab in the PDE, you need to delete and re-
add the instance on the project side and then load to update the monitor side. If you
made these changes from the project side properties form, the changes will not appear
on the monitor side until you load.
2. Save the modified block type under a new name. Later, convert the project side
instance and reload to reflect the changes in the monitor side.
10/04 Honeywell
CDB configuration
The first option is used in development scenarios. During development, you are likely to
go through multiple cycles of changing CDB CDPs while debugging a strategy. It would
be very inconvenient to manually reassign type names at every pass through the cycle. To
avoid this, CB and CDB infrastructure allow modified types to be saved without name
changes. Existing instances are converted automatically on the project side subject to
constraints on the nature of changes that can be made.
When on-process CDB blocks must be modified, the second option is recommended. In
this case, you save the modified CDB type under a new name so that none of the on-
process blocks need be disturbed. Then you can convert the blocks one at time to the new
type, inactivate them, and reload them. The process of converting blocks can be carried on
over an extended period of time without risk.
When you use the second option, the CDB type used by the CEE instances is not
overwritten within ERDB. Both the old and new types remain until you have converted all
instances. After there are no remaining instances of the old type, you can delete it if
desired. You cannot delete it while there are remaining instances. As long as there is an
instance of the old CDB type within CEE or within ERDB, the old CDB type cannot be
deleted from ERDB.
Note that a procedure exists whereby you can verify that the version of a CDB running in
CEE is the same as the version stored in ERDB. This is described in “Verify match of
CDB version in ERDB.””
Honeywell 10/04
CDB configuration
User actions when saving modified CDB type

There are several conditions that can affect the save operation. To make this clear, consider
the following scenario.
1. You create a block type called MYCDB.
2. You instantiate CONTRCDB under the name MYCDB1 within control module CM1.
3. You assign and load CM1. MYCDB1 to a CEE so that both project and monitor
copies exist.
4. You now open type MYCDB once again and make changes.
Now you attempt to save block type MYCDB to ERDB.
The first relevant condition to affect the save operation is whether instances of the type
exist within ERDB. In this case there is an instance so you will be given a warning
message that says the following:
"Overwrite type and convert all ERDB instances?"
10/04 Honeywell
CDB configuration
ATTENTION
If you are using the QVCS versioning system, refer to “Special considerations
when using QVCS with CDB” for important information.
If you were saving a modified CDB type that was already on process, you would normally
choose Cancel (Cancel is the default) because you would not wish to overwrite an on-
process CDB with one that is untested. Similarly, if you were developing a new type but
wished to leave the old version in ERDB for a while longer, you would choose Cancel.
But suppose that you are still developing and don't need to keep the old version of the type.
You choose OK.
At this time, another condition comes into play. This condition is the nature of the changes
that have been made to the block type. For most changes, CB automatically converts all
existing instances to match the new block type. This is what would happen if CDPs had
been added to the type. However, under a specific set of conditions, such as deletion of a
preexisting CDP, or changing the data type of a CDP, CB does not support automatic
conversion.
Suppose that you had modified MYCDB in such a way that a CDP was deleted. CB would
then respond to the save command as follows:
A "Save-As" dialog appears that gives the option of changing the name of the block type or
of canceling the save operation.
Faced with this dialog, you must now save the MYCDB to ERDB under a new library or
block name.
The fully qualified name for a CDB type consists of the library name concatenated with the
block type name. Thus, at this stage in the scenario, it is sufficient to change one or the
other. If the library name is left unchanged then the modified type goes into the preexisting
library under a new block type name. If the block type name is left unchanged then the new
block type goes into a different library under the old block type name.
Honeywell 10/04
CDB configuration
To complete the scenario, suppose that you choose to leave the library name unchanged
and change the block type name to “MYCDBA.” You have now succeeded in saving the
modified version of "MYCDB " to the original library in ERDB, under the new name "
MYCDBA." What remains is to convert the preexisting instance, MYCDB1, from an
instance of MYCDB to an instance of MYCDBA. The section “Convert instances to
modified CDB type” describes how to use the CB "Convert" command.
Note that when save under a new name is done, the edit lock on the old type is
automatically cleared and a new lock is opened for the newly named type. The lock
remains active until you close the PDE for the new block type.
Figure 27 Saving Modified CDB Types” is a flow diagram that shows how various
conditions affect the save operation. This diagram covers the most usual scenarios but does
not necessarily cover every special case that might arise.
Behaviors when saving modified types to ERDB

Whereas there is only one condition that impacts Convert of block instances from one type
to another, there are several conditions that impact the save operation. These are shown in
the figure below.
10/04 Honeywell
CDB configuration
Figure 27 Saving Modified CDB Types
Honeywell 10/04
CDB configuration
Convert instances to modified CDB type

CB provides the ability to change a block instance from one type to another type. This is
called converting a block instance.
A typical use of this feature is to allow you to modify an existing type, save it as a new
type, and then update the existing instances of the old type. This technique avoids the need
to delete the old instances and create new instances of the new type. Other scenarios are
possible. When conversion is done, the ERDB type definition data is updated in both the
project side and monitor side instances. Instances must be converted one at a time, and a
subsequent load operation is required to update the CEE.
Changes that you can make to the type that are allowed by the conversion function are:
• You can add CDPs or change their data types.
• You can delete CDPs unless they have connections to other blocks. If a parameter with
an external connection needs to be deleted, the connection must be removed first.
Steps involved are as follows:
Table 46 Converting CDB instances
Step Action
1 Identify an in-service CDB instance that needs to be converted.
2 Decide whether the run-time instance contains any data that is not up to date
in the monitor side ERDB instance. If so, use the "Upload" command for the
CM that contains the CDB instance (right-click on the CM in the Monitor tree
view and choose Upload).
3 Select the block instance to be converted in the project side chart view.
4 Right-click on the instance and choose Function Block Convert.
5 From the list that appears, select the new block type that should be assigned
to the instance.
6 Click Convert.
7 After the existing instance has been converted, you can inactivate, load and
reactivate the CM that contains the CDB instance.
10/04 Honeywell
CDB configuration
Note that the convert function has fewer constraints than the Save to ERDB operation. For
example, you cannot Save to ERDB a block that has parameter deletions or data type
changes if there are existing instances of the block. These operations are permitted in the
convert operation.
When a block instance is converted, the new type might have fewer parameters than the
old type, have more parameters than the original type, or have parameters with the same
name but different data type. These situations are handled as follows:
• Parameters that have the same name and data type receive the value from the original
instance.
• Parameters that have the same name but different data type are initialized to their
default values.
• Parameters present on the new block type but absent from the old are initialized to
their default values.
• Parameters absent from the new block type but present on the old are eliminated from
the new instance.
When converting instances, you might need to identify all instances of a block type. See
“Discover CDB dependency relationships” for comments on locating instances of a type
using the Search tool in Configuration Studio.
Honeywell 10/04
CDB configuration
Verify match of CDB version in ERDB

You can compare the values of parameter BLOCKTYPEID to verify that the version of a CDB
in a CEE is the same as the version stored within ERDB. Use the following procedure:
Table 47 Verify CDB instance version
Step Action
1 Open the properties form for the CDB type defined within ERDB. This may be
done in one of two ways. Either open the form directly from the library tree, or
open the form for an instance of the CDB type within the project tree.
2 Read the value of BLOCKTYPEID from the form. This is a 36-character
numerical value.
3 Open the properties form for an instance of the CDB type within the monitoring
tree.
4 Read the value of BLOCKTYPEID from the form.
5 Compare the two values.
View a CDB type as read only

You can use the "View Type" menu option to open as read only a CDB type that is under
edit by another engineer. You can also use this command to open the type without setting
the Edit Lock flag.
If a type is under edit and you try to open it without using the View Type command, you
will be prompted to open as read only or to cancel.
Delete a CDB type from ERDB

You can delete CDB types from the ERDB if they are no longer needed or if they have
been superseded by later versions. CB will not allow you to delete block types if there are
corresponding instances on the project side or monitor side of ERDB. Similarly, CB will
not allow you to delete block types if there are templates on the project side that depend on
the type you are attempting to delete. If such instances or templates exist, CB will return an
error message on the delete attempt.
Deletion of a CDB type is not allowed when it is open for edit.
Custom libraries that contain custom block types or user templates can also be deleted.
System security policies allow anyone with engineering access to delete CDB types.
10/04 Honeywell
CDB configuration
Rename a CDB
You can rename a CDB type except under the following conditions:
• You cannot rename a CDB type that is open for edit.
• You cannot rename a CDB type or change the library name if the type has an instance
loaded to the monitor side.
There are no restrictions on renaming CDB instances.
Recover a CDB with checkpoint restore

The system is designed to insure that all data associated with a CDB is recovered by using
the checkpoint restore command. Using a checkpoint containing CDBs is no different from
using a checkpoint that contains only native blocks. You select the ACE of interest and
command a restore or save.
The action of checkpoint restore is destructive rather than additive. Thus, if checkpoint
restore is commanded to an ACE with a preexisting database, any preexisting CDBs are
wiped out and new ones are added.
REFERENCE - EXTERNAL
For more information about checkpoint and restore, see the section titled
“Using Checkpoint to Save and Restore Data” in the Control Building Guide.
Export CDB
CDBs can be exported from ERDB into a specified directory in the same manner that
native blocks are exported through the File > Export menu option. The procedures and the
user interface for doing so covered in the Control Building Guide and are not duplicated
here. However, some important differences are highlighted here.
When you export native blocks, it is only the instance data that is extracted from ERDB. In
general, there is no need to extract native block types because they will already be defined
within the ERDB that is to receive the instances upon import. CDB types, however, are
different. When you export a CM that contains a CDB instance, you must also explicitly
export the CDB type into the same directory. This is because, in all likelihood, the
receiving ERDB will not already have a definition of the CDB type.
System services for export and import provide special handling for name collisions in CDB
types. A type name collision would occur if two engineers working with different ERDBs
had coincidentally chosen the same block name and the same library name for the type
they had created. Such a collision would not matter and would never be discovered unless
Honeywell 10/04
CDB configuration
one engineer tried to import the block type into the ERDB used by the other. But if this did
happen, services associated with import would resolve the conflict by renaming the library.
To insure name collisions can be properly handled, export processing anticipates the possibility of
name change by supplying an internal identifier for associated types and instances. This internal
identifier is always unique and never changes. On import the identifier can be used to properly
match associated types and instances even when a type name must change.
When you export a CDB, you must explicitly indicate both the requisite block types and
any requisite module instances. Types must always be selected explicitly. If instances are
exported without the associated types, any subsequent import operation will fail. CDB
types can be selected for export without any accompanying instances if the objective is
simply to transfer a program or toolkit from one ERDB to another.
When CDB types are exported, they always bring their library name with them. You can
choose whether to export the entire type content of the library or only a subset of the types.
Only those block types that have been explicitly selected are exported. To export an entire
library, you select all types contained within.
When a CDB type is exported, a directory structure is created. This directory structure is used
when importing. For more information on importing, see the next topic “Import CDB.”
Import CDB
CDBs can be imported from ERDB through the File > Import menu option. You must
select the strategies and block types for import. Block types are imported first. Each fully
qualified type name (library name with block type name) is checked to determine if a
duplicate exists within ERDB. If a duplicate is found, a numerical suffix is automatically
appended to the library name. After the name conflict is resolved, the type is imported.
Status messages are reported during import to inform you if and when a library name
change occurs. Import messages are recorded in a log file called "IXP_log.txt" within the
directory:
"c:\Documents and Settings\All Users\Application Data\Honeywell\Experion PKS".
Following import, you have the opportunity to change the automatically generated names
if you desire.
When you import a CDB type, you must select the entire directory that the CDB type was
exported to. When CDB instances are imported, system services use both the type name and the
internal identifier to properly associate the instances with their types. If it is discovered that the
type associated with an instance has gone through a name change, the instance's type name is
changed to match and a status message is reported in file IXP_log.txt.
10/04 Honeywell
CDB configuration
Discover CDB dependency relationships

CB supports services for tracing relationships between CDBs and other named entities within
the PKS. These services are part of the Search functionality of Configuration Studio.
All forms of dependency identification supported for native block instances and templates
are also supported for CDB block instances and templates. In addition, the Search tool
supports identification of certain dependencies that are unique to custom block types.
These are as follows.
• CDB instances that derive from a given CDB type.
• CDB type from which a given CDB instance is derived.
• CDB templates that derive from a given CDB type.
• CDB type from which a given CDB template is derived.
Special considerations when using QVCS with CDB

QVCS does not support versioning of CDB types or instances. QVCS does, however,
support versioning of CMs that contain CDB instances. Unlike native block types, CDB
types can be modified. Therefore it is important to understand the scenarios that can occur
when you modify a CDB type that has instances in CMs that are versioned in QVCS.
Assume that you wish to modify a CDB type that has instances in CMs that are versioned
in QVCS. If you first check out all of the CMs that have the current instance of the type
you wish to modify, and then modify the type and save to ERDB (with option to overwrite
instances if prompted), and then check the CMs back into QVCS, there are no special
QVCS considerations. All instances will be overwritten and the QVCS database will
contain the latest instances. If, however, you modify a CDB type that has instances in CMs
that are checked into QVCS, and then overwrite instances when saving the modified CDB
type to ERDB, all instances of the type will be overwritten, except that the QVCS database
will NOT be updated for those instances that are checked in. Therefore, if you
subsequently attempt to check out a CM from QVCS that contains one of these instances
whose type has changed, a special condition exists. The internal BLOCKTYPEID
associated with the CDB type of the instance to be checked out will not match the
BLOCKTYPEID of the new type stored in ERDB. In this case, you will encounter one of
the following situations:
Honeywell 10/04
CDB configuration
1. If the system finds a library type whose library name and block name matches the
library name and block name associated with the type of the instance to be checked
out, the checkout (import) will be accepted with a warning message similar to the
following: “Import Warning for CM1.CDB1. BLOCKTYPEID checks for CDB
Block Type bypassed.” In this case, the BLOCKTYPEID of the checked out instance
will be changed to the BLOCKTYPEID of the type whose library and block names
match.
2. If the system cannot find a library type whose library name and block name matches
the library name and block name associated with the type of the instance to be
checked out, QVCS will display an error message and will reject the checkout
(import).
10/04 Honeywell
CDB configuration
Honeywell 10/04
CAB and CDB Example Scenarios
Summary of example scenarios
Disclaimer
ATTENTION
The examples in this user guide are included solely for the purpose of
illustrating CAB and CDB functionality. They are not to be considered, in whole
or in part, as suitable for use in your control systems. Honeywell International
Inc. makes no representations or warranties, either expressed or implied, of
merchantability or fitness of these examples for any particular purpose. Under
no circumstances will Honeywell International Inc. be liable to any person or
business entity for any damages resulting from the use of any portion of the
material in these examples.
Example scenarios included

The following example scenarios are included in this section:
• CAB insertion algorithm
• Formulation of VLR_CALC without insertion point
• CDPs as Engineering Unit labels
• A CDB to hold sensor data
• Array and scalar variables in CAB
• Initializing in response to system events
• Example using data type TIME
• Example using data type TIMEOFDAY
• Example using data type DELTATIME
• Use of data access status in CAB
• Use of parameter reference variables in CAB
Honeywell 10/04
CAB insertion algorithm

Vapor-to-liquid ratio control
In this example, you wish to control vapor-to-liquid ratio (VLR) within a fractionation
column. VLR is to be used as the PV in a PID loop. It is not available as a direct
measurement and must be inferred from other measurements. There is a simple algebraic
formula for computing the VLR.
The following diagram shows the relevant variables.
Figure 28 Fractionation column
Honeywell 10/04
Equations are as follows:

WL = [ CP/lambda (TT - TR ) + 1 ] WR + CP / lambda (TT - TI) WPWV = WP + WL
R = WV / WL
where:
WL = weight-flow rate of liquid through tray 5
WV = vapor flow rate through tray 5
R = vapor – liquid ratio
WR = external reflux-flow rate
WP = product-draw-flow rate
CP = heat capacity of liquid
lambda = heat of vaporization
TT = top vapor temperature
TR = external reflux temperature
TI = temperature on tray 5
10/04 Honeywell
To address this application, you will use the following block types.
Table 48 Block types in vapor-to-liquid ratio solution
Name Description
AICHANNEL Native block type. Has algorithm and data for one channel of
analog input.
PID Native block type. Does control loop computation and triggers
execution of the insertion point program at the right point in its
sequence.
VLR_CALC CAB type. Defines custom data and custom algorithm. Serves as
the insertion point program.
Control Module Native block type. One module serves as container for PID and
VLR_CALC instances. Other modules serve as containers for
AICHANNEL instances.
All except one of these block types is available as a standard algorithm (native block
type) within CB libraries. VLR_CALC is a CAB type that you create.
Creating empty block type VLR_CALC

In CB, command File > New > Type > Custom Algorithm Block. A dialog box comes
up asking for the library name and block type name. Supply the name "FRACT" for the
library and "VLR_CALC" for the block type.
After you close the dialog, MSVS opens up. The two main windows for block type
creation, the parameter edit window and the source code window, are available as tab
selections. At this point, the PDE window does not contain any CDP definitions. The
source code window contains framing statements and comments to help you start the
algorithm definition.
Setting the access level for VLR_CALC

This CAB will be configured as an insertion algorithm hosted by a PID block. Honeywell
recommends that CABs that are used as insertion point algorithms have their access level
set to Continuous Control. Select the Fixed tab in the PDE and set the default value of
the ACCESSLEVEL parameter to CONTCONTROL.
Honeywell 10/04
Defining value CDPs for VLR_CALC

Although you can choose to work in any order, assume you decide to start by entering
definitions for value CDPs. Select the Value CDPs tab in the PDE to display the PDE
definition window. This exposes the default definition view. A more detailed CDP
definition view is also available but in most cases the default view, similar in content to
the table below, is sufficient.
Make the following entries:
Table 49 Value CDP definitions for VLR_CALC
Parameter Parameter Data type First Access lock Config Default

name description dimension load value
array size
CP Heat FLOAT 64 0 ENGINEER LOAD 0.75

capacity of
liquid
LAMBDA Heat of FLOAT 64 0 ENGINEER LOAD 650.0

vaporization
Note that by defining a parameter called "CP," you set up two kinds of name usage. One
usage is the external name references. These are always qualified by the independent
block name and dependent block name of the VLR_CALC instance as in
"VLRATIO.VLR_CALC1.CP". The other usage is the internal name references. These
are always qualified by a property name as in "CP.Value."
After definition of the value CDPs is complete, choose File > Save PDE Data (or click
the appropriate icon) in MSVS. This causes the definitions of CP and LAMBDA to be
saved in the development area. These definitions are now available for any algorithm
development to be done.
You can return to add or change value CDP definitions later. Each edit session must be
terminated with "Save PDE Data" or "Save All" before the algorithm source code
window can become aware of changes.
10/04 Honeywell
Define parameter references for VLR_CALC

Although you can choose to work in any order, assume that you now decide to enter
definitions for parameter references. Go to the PDE window and select the tab for
defining references. Make the following entries:
Table 50 Parameter reference definitions for VLR_CALC
Parameter name Reference data type Parameter description Data flow
TOPT FLOAT 64 Top Vapor Temperature INPUT
TRAYT FLOAT 64 Temperature on Tray 5 INPUT
RFXT FLOAT 64 External Reflux Temperature INPUT
RFXFLOW FLOAT 64 Reflux Flow Rate INPUT
DRAWFLOW FLOAT 64 Draw Flow Rate INPUT
PVCALC FLOAT 64 Computed PV to PID VLR_CTL1 OUTPUT
The meaning of each attribute in the above table is described in “Define parameter
references.”
In VLR_CALC, all references except PVCALC are used for reading input values. The
PVCALC reference is used for writing the computed PV to the associated PID block
After parameter reference definitions are complete, command File > Save PDE Data or
File > Save All at MSVS. This causes the definitions of TOPT through PVCALC to be
saved in the development area. These definitions are now available for algorithm
development.
Honeywell 10/04
Define the algorithm for VLR_CALC

Although you can choose to work in any order, assume you now decide to enter source
code for the algorithm. Start with an empty code frame as described in “Code CAB
algorithm.” After entering statements for VLR_CALC, you end up with the following:

Imports System.Math

Inherits BlockBase
Private K As Double
' Calculate internal vapor/liquid ratio for any column

Dim W1, WV, Ratio As Double
' Make value and status available for all input

' parameter references
PRefList.Read()
' Calculate constant used to compute flow rate

K = CP.Value / LAMBDA.Value
' Calculate internal liquid flow rate from

' heat and material balance
W1 = ((TOPT.Value - RFXT.Value) * K + 1) * _
RFXFLOW.Value + (TOPT.Value - TRAYT.Value) * _
DRAWFLOW.Value * K
' Calculate internal vapor flow rate from material balance
10/04 Honeywell
WV = DRAWFLOW.Value + W1
' Calculate vapor/liquid ratio and store as PV

Ratio = WV / W1
PVCALC.Value = Ratio
' Store values to destination for any output references

' whose values were written
PRefList.Write()
End Sub
End Class
There are several points worth noting about this program.
• Imports Statements
This section of the automatically generated code consists of several Imports

statements at the start of the program. These statements make available classes and
support utilities that are typically needed in control programs or which needed for
integration with CEE.
• Public Class CABlock
Block types are declared as classes within VB.NET. The name of the class shown
here is "CABlock" and is the same for all CAB types. Within CB and CEE, different
CAB types are distinguished by their filenames and by internal identifiers rather than
by their class names. The name you declared at the time of File > New > Type >
Custom Algorithm Block is visible under the library tree in CB after the save to
ERDB.
• Inherits BlockBase
The Inherits statement indicates that the CAB type acquires attributes and
behaviors from the parent class called "BlockBase." BlockBase is automatically
generated by the CAB build-time software to capture the specifications of value
CDPs and parameter references that you entered in the PDE.
Honeywell 10/04
• Private K As Double
The program computes a persistent constant called K for use within the program. K is
a block scope variable as described in “Define block scope variables.” K is declared at
the scope of the class and is thus visible to any subroutine or function defined within
the class. K is not visible outside the VLR_CALC program.
• CP.Value, LAMBDA.Value, TOPT.Value, TRAYT.Value, ... ,

PVCALC.Value
CP and LAMBDA are predefined CDPs. Their values are accessed via the Value
property as indicated in “CDP classes.” TOPT, TRAYT, through PVCALC are
predefined PRefs. Their values are also accessed through the Value property as
described in “Parameter reference classes.”
• Public Overrides Sub Execute()
The keyword "Overrides" indicates that Execute() has been defined within
BlockBase but the CE is providing her/his own definition here.
• Dim W1, WV, Ratio As Double
The program includes three variables, W1, WV, and Ratio, for use only within
subroutine Execute(). These are local variables of the subroutine. Their values last
only for the duration of subroutine processing. They are not visible outside the
VLR_CALC program.
• PRefList.Read()
Since PRefs are used in the Execute() subroutine CAB infrastructure needs to be told
to fetch the referenced data so that it will be available via the Value properties. This is
accomplished for all PRefs in Execute() with the single PRefList.Read() statement.
Alternatively, you could have issued a Read() call for each individual PRef. Using a
single statement for all is more convenient.
10/04 Honeywell
• K = CP.Value / LAMBDA.Value
References to CP.Value and LAMBDA.Value fetch values local to the

VLR_CALC block that correspond to the value CDPs CP and LAMBDA. This is
different from the behavior for parameter references as discussed below.
• WV = DRAWFLOW.Value + W1
Variables defined within the program differ from names defined within the PDE
window in that they are not used with a ".Value" property. Thus, the appearance of
WV and W1 in this expression. Unlike CP, DRAWFLOW is a parameter reference.
This means that using "DRAWFLOW.Value" in an expression actually references
data that has been fetched from a block outside the VLR_CALC block.
• PVCALC.Value = Ratio
After the desired ratio is calculated, it is stored to the PVCALC parameter reference.
In this example, PVCALC points to a PID block that serves as the insertion point call
driver. In general, PRefs can point to any block.
• PRefList.Write()
In order to transfer the data out through the output PRefs, the Write() subroutine must
be invoked, either once for each output PRef or once for all output PRefs using
PRefList.Write(). In this case there is only one output PRef so either method would
have been equally convenient. This program is written according to the prevailing
style using a single statement that handles any number of output references.
Note that the VLR_CALC block type is very simple and does not require user-defined
subroutines. In general, you can use whatever user-defined subroutines or functions you
need. However, they must be included directly within the main source file or they must
be included as separate source files within the same Visual Studio project. Also, any files
added to the project must be placed within the CAB source directory. If they are
preexisting files, they must be copied into the CAB source directory.
After you enter the program into the source code window, you save it into the
development area. To do this, invoke File > Save Selected Items or File > Save All.
After the source code has been saved, you can compile and link. To do this, invoke File
> Build > Build Solution. If the build operation generates compile errors, correct the
source code and repeat the build until all errors are eliminated.
Honeywell 10/04
Save VLR_CALC to ERDB

After a block type, in this case VLR_CALC, is complete and you get a successful build,
you save the type to ERDB.
Saving to ERDB is an essential step in preparing a block type for use. Until VLR_CALC
is saved, instances of it cannot be used within a CEE. The copy of VLR_CALC that
resides in the development area while it is being created or modified is only a temporary
copy of which ERDB is unaware. Any work that is not saved to ERDB will be lost when
MSVS is closed.
To save VLR_CALC to ERDB, you invoke the "Save To ERDB" command in MSVS.
It is possible to save an incomplete block type to ERDB. For example, if you had
attempted to build VLR_CALC but had not yet eliminated all build errors, you could still
save the type into ERDB with the intent of resuming work later. Block types saved in
such an incomplete state can be instantiated, but cannot be loaded.
Block instances in the VLR_CALC application

After you have completed the CAB type VLR_CALC, you are ready to build a control
strategy for vapor-to-liquid ratio control. A set of control modules and block instances
are required to complete the strategy. They are shown in the following table.
Table 51 Block instances for vapor-to-liquid ratio solution
Name Description
VLRATIO.VLR_CTL1 PID instance contained within control module VLRATIO.

Stimulates execution of VLR_CALC1 as an insertion point
program.
VLRATIO.VLR_CALC1 VLR_CALC instance contained within control module

VLRATIO. Hosts CDPs and the custom PV computation
algorithm.
TI201.AI1 An AI channel block within control module TI201. Provides

the PV for top temperature (TT, TOPT).

the PV for reflux temperature (TR, RFXT).

the PV for tray temperature (TI, TRAYT).
FI202.AI1 An AI channel block within control module FI202. Provides

the PV for reflux flow rate, (WR, RFXFLOW).
10/04 Honeywell
Name Description
FI203.AI1 An AI channel block within control module FI203. Provides

the PV for product draw flow rate, (WP, DRAWFLOW).
Configure VLR_CALC1
The process of configuring CAB instances is basically the same as configuring native
block instances. Double-clicking on the block symbol within the control chart accesses
the properties form. When the form comes up, values can be entered. The form can be
used to specify and load properties parameters but can also be used to display view only
parameters when monitoring.
The figure below shows the Value CDPs properties form for VLR_CALC1.
Figure 29 Value CDP configuration for VLR_CALC1
One behavior is worthy of note here. When type VLR_CALC was defined, both value
CDPs were declared to have Configuration Load attribute = LOAD. Because of this, they
would not be grayed out in the configuration VLR_CALC1 form. If either had been
declared with Configuration Load = NOLOAD, it would have been grayed out and would
not be alterable on the form.
The default values for CP and LAMBDA that were defined when VLR_CALC was
created can be changed now. Or, they can be left unchanged. The values that result from
configuration will be sent to CEE when VLR_CALC1 is loaded.
Type VLR_CALC also had parameter references defined when it was created. Because
of this, the configuration form has a Parameter Reference tab, which is shown in the next
figure. Note that in this figure, the parameter names are shown, as opposed to the
parameter descriptions. This is achieved by checking the Show Parameter Names option
on the form as shown below.
Honeywell 10/04
Figure 30 Empty parameter reference properties form for VLR_CALC1
When the form first appears the Reference Address column is blank as shown above.
Each parameter reference that you declared within the definition of VLR_CALC now
requires an address to be entered. A pick list is used to generate each parameter address.
You can also type in the parameter address. After you have completed all entries, the
form would be as shown in the next figure.
10/04 Honeywell
Figure 31 Completed parameter reference properties form
Based on this configuration, when a value is read from "TOPT.Value" within the
program of VLR_CALC1, the value of TI201.AI1.PV will be read. Similarly, when
"PVCALC.Value" is written to, parameter VLRATIO.VLR_CTL1.PV will be written.
VLR_CALC1 is used within VLRATIO as a block whose execution is stimulated by a
partner block that calls the Execute() subroutine at an appropriate step in its own
execution sequence. In this application, the partner block is VLR_CTL1. Since
VLR_CTL1 is to act as execution master, VLRATIO, the parent CM, must not trigger the
execution of VLR_CALC1. To arrange this, the system sets the INSERTION parameter
on VLR_CALC1 to indicate no execution by the parent CM. This happens when you
configure VLR_CALC1 as an insertion point algorithm on the execution master, PID
VLR_CTL1 (see the next topic). At the same time, the ORDERINCM parameter on the
inserted CAB block is changed to match the ORDERINCM setting of the calling master.
Note, however, that although a CAB configured as an insertion point adopts the
ORDERINCM of its master, if the configuration is changed such that the CAB is no
longer configured as an insertion point, its ORDERINCM value does not revert back to
the value that it was before the CAB was configured as an insertion point.
Honeywell 10/04
Configure VLR_CTL1
VLR_CTL1 is a PID instance and is configured like any other. However, the manner in
which insertion points are configured is functionality that is special for CAB.
PID supports multiple different points in its execution flow where a call-out to another
block can be inserted. These points are:
• Post-Input—CAB instance inserted after input processing
• Pre-Alg—CAB instance inserted prior to algorithm processing
• Ctl-Alg—CAB instance replaces built-in algorithm
• Post-Alg—CAB instance inserted after algorithm processing
• Post-CtlOut—CAB instance inserted after control output processing
For this example, assume that you choose to configure the PID instance so that the CAB
VLR_CALC1 is inserted into the PID VLR_CTL1 at the Post-Input insertion point.
The method for doing this is covered in Control Builder documentation, but the general
procedure is as follows. On the properties form for VLR_CTL1, you select the tab that
allows you to configure the insertion point. On this tab, there is a drop-down list box that
allows you to select the insertion point. You select “Post-Input.” There is also a text box
with a browser button that you use to browse to and select the CAB instance that you
wish to use for the insertion point algorithm. For more information on insertion point
configuration, see “Configure insertion points.”
Control module chart for VLRATIO

Figure 32 below shows project side instances created for the VLR application as they
might appear within CB. The project tree is shown on the left. It lists each control
module (FI202 through VLRATIO) and within each control module, each basic block.
The VLRATIO control module has been opened for chart view. It shows the symbols for
the two basic blocks it contains, VLR_CALC1 and VLR_CTL1.
10/04 Honeywell
Figure 32 VLRATIO Control Chart
Honeywell 10/04
Formulation of VLR_CALC without insertion point

Overview
Insertion points are used when the CAB block must execute somewhere in the middle of
a PID or Data Acquisition algorithm. But with PV computation, the CAB algorithm runs
before the start of the subsequent block algorithm. In this particular case, it is possible
and perhaps even desirable, to implement the CAB instance as a normal component
block of the parent CM.
This section briefly reformulates the pervious example, the insertion point solution, along
these lines. A summary of the changes in this alternate formulation is as follows.
• Since the instance VLR_CALC1 will not be used as an insertion algorithm it can be
implemented as a client of CM graphical connections. Thus, although the use of
PRefs shown in “Define parameter references for VLR_CALC” would still work, a
simpler design using only CDPs is presented in this example.
• Since the VLR_CALC1 will execute under the command of the parent CM there is
no need for an insertion point configuration on VLR_CTL1.
As a variation commonly encountered in the use of PV computation algorithms, this new
formulation assumes that the computed PV is supplied to a Data Acquisition block rather
than directly to a PID.
CDP definitions for alternate formulation of VLR_CALC

There are no PRefs in the new formulation. Each of the data names previously
represented as a PRef is now represented as a CDP. This is shown in the table below.
Table 52 Value CDPs for alternate formulation of VLR_CALC
Parameter Parameter Data First Access lock Config Default

name description type dimension load value
array size
CP Heat capacity FLOAT 0 ENGINEER LOAD 0.75

of liquid 64
LAMBDA Heat of FLOAT 0 ENGINEER LOAD 650.0

vaporization 64
TOPT Top vapor FLOAT 0 ENGINEER NOLOAD Nan

Temperature 64
TRAYT Temperature FLOAT 0 ENGINEER NOLOAD Nan

on Tray 5 64
10/04 Honeywell
Parameter Parameter Data First Access lock Config Default

name description type dimension load value
array size
RFXT External FLOAT 0 ENGINEER NOLOAD Nan

Reflux 64
Temperature
RFXFLOW Reflux Flow FLOAT 0 ENGINEER NOLOAD Nan

Rate 64
DRAWFLOW Draw Flow FLOAT 0 ENGINEER NOLOAD Nan

Rate 64
PVCALC Computed PV FLOAT 0 VIEWONLY NOLOAD Nan

64
Control module chart for alternate formulation of VLRATIO

In the alternate formulation, VLRATIO contains three basic blocks: VLR_CTL1,
VLR_CALC1 and a Data Acquisition instance called VLR_DACQ1. Parameter
ORDERINCM for each of these blocks is assigned to achieve the desired execution
order. One alternative is as follows.
VLR_DACQ1.ORDERINCM = 10
VLR_CALC1.ORDERINCM = 20
VLR_CTL1.ORDERINCM = 30
Since VLR_CALC1 is to be executed by the parent CM it is not configured to disable

execution by the parent. This is different from the insertion point formulation in which
execution by the parent CM was disabled because the parameter INSERTION was set by
the system when VLR_CALC1 was configured as an insertion point algorithm in
VLR_CTRL1.
Honeywell 10/04
CDPs as Engineering Unit labels
Figure 33 VLRATIO alternate control chart

Example
CDPs do not support an Engineering Unit (EU) attribute that can be specified as part of
their definition. Instead, you can specify string valued CDPs to hold EU descriptors for
other CDPs. This can be done equivalently for CAB types and CDB types. One
advantage of this approach is that it can be applied to any of the following situations.
• You wish to create a custom block type that will only be instantiated once. Each
CDP will never have more than one EU assigned to it.
• You wish to create a custom block type that will be instantiated multiple times. Each
CDP will use the same EUs in every instantiation.
10/04 Honeywell
• You wish to create a custom block type that will be instantiated multiple times and
used in different ways. Each CDP can have different EUs depending on how the
block is instantiated.
As an example, consider the CAB type VLR_CALC described in “CAB insertion
algorithm.” Suppose you wish VLR_CALC to work with a fixed set of EUs for CP and
LAMBDA. To accomplish this, you can define CDPs as shown in the following table.
Table 53 Value CDP definitions for VLR_CALC with "EU Label" CDPs
Parameter Parameter Data First dim Access lock Config Default

name description type array size load value
CP Heat capacity FLOAT 0 ENGINEER LOAD 0.75

of liquid 64
CPEU Heat capacity STRING 0 VIEWONLY LOAD “Joules /

of liquid Liter”
LAMBDA Heat of FLOAT 0 ENGINEER LOAD 650.0

vaporization 64
LAMBDAEU Heat of STRING 0 VIEWONLY LOAD “Joules”

vaporization
In this example, you specified CPEU and LAMBDAEU to have ViewOnly access lock.
This means that the units are fixed with the type and every instance must specify CP and
LAMBDA values with those units. In other applications you might wish to specify an
Access Lock of Engineer. This would allow CPEU and LAMBDAEU to be specified as
part of instance configuration. However, in that case, it would also be necessary to design
the CAB algorithm to handle the appropriate EU scaling.
With CP, CPEU, LAMBDA and LAMBDAEU defined as shown in the table above, all
four parameters would be shown in properties form for a VLR_CALC instance, making
it clear which units are required. This same form would be visible as an operations
display through the chart visualization capability of CB and EPKS Server. If a custom
display was created to support VLR_CALC, the EU values for CP and LAMBDA could
be presented on the display along with the data values.
Honeywell 10/04
A CDB to hold sensor data

Temperature at position within PFR
Assume that a control strategy is needed for use with a Plug Flow Reactor (PFR)
application. PFRs are tube shaped vessels in which a chemical reaction takes place. They
can vary in size from small lab units to very large capital equipment deployed within
petrochemical plants. Large units can be up to a mile long.
PFRs are typically broken down into zones. Each zone consists of an injection point at
the head end of the flow followed by a length of tube in which the reaction takes place.
Reactants are injected at the injection point. Thermocouples are arranged below the
injection point to monitor temperature as the reaction evolves.
The number of thermocouples used within a zone can vary depending upon the overall
size of the PFR. It can be as few as five or as many as twenty or more. The number of
zones can vary from as few as five to twenty or more.
A CM that accepts a temperature input, conditions it, and holds associated data can be
formulated as one component of an overall PFR control solution. For this example,
assume that you wish to create a CM that takes in a temperature input and provides as
output a data set that characterizes the temperature at one position within the PFR zone.
The PFR is assumed to be small.
To create POSTEMP1, you use the following block types.
Table 54 Block types in PRF sensor data solution
Name Description
AICHANNEL Native block type. Has algorithm and data for one channel of
analog input
DATAACQ Native block type. Does signal conditioning and alarming for one
analog input or other numeric value.
POSTEMPCDB Custom data block type. Holds data that characterizes temperature
at one position within one PFR zone.
Control Module Native block type. Serves as container for AICHANNEL,

DATAACQ and POSTEMPCDB instances.
10/04 Honeywell
Creating block type POSTEMPCDB

Start at CB by commanding File > New > Type > Custom Data Block. Enter the name
"PFR" for the library and "POSTEMPCDB" for the block type in the dialog box that
appears. After the “New” operation completes, block type POSTEMPCDB is visible
within the CB library tree and a PDE window is open within CB. The name
"POSTEMPCDB" shows up in the heading for the PDE window.
Select the Value CDPs tab of the PDE window and make the following definitions:
Table 55 Value CDP definitions in POSTEMPCDB

name description dim load value
array
size
ZONE Zone number FLOAT64 0 APPDEVONLY LOAD -----
POSITION Position in FLOAT64 0 APPDEVONLY LOAD -----

zone
TEMP Temperature FLOAT64 0 PROGRAM NOLOAD -----

at position
BAD Error flag BOOLEAN 0 PROGRAM NOLOAD ON
DESCR Description of STRING 0 APPDEVONLY LOAD

sensor
After CDP definition is complete, execute the Save command at CB. This causes block
type POSTEMPCDB and its parameter definitions to be saved in ERDB.
POSTEMPCDB is now available for use. You can return to add, change or delete CDP
definitions later.
Block instances in temperature at position application

After POSTEMPCDB is created, you have all the block types you need to build control
strategy POSTEMP1. Create CM instance POSTEMP1 so that it holds the following
basic block instances:
Honeywell 10/04
Table 56 Block instances in PFR sensor data solution
Name Description
POSTEMP1.AI1 An AI channel block within control module POSTEMP1.

Provides the raw temperature reading at one position
within a PFR zone.
POSTEMP1.DATAACQ1 A DATAACQ block within control module POSTEMP1.

Conditions the temperature value and does alarming as
needed.
POSTEMP1.DATA1 POSTEMPCDB instance contained within control module

POSTEMP1. Hosts CDPs that describe temperature and
position within a PFR zone.
Configure POSTEMP1.DATA1
The process of configuring CDB instances is the same as that of native or CAB instances.
Double-click on the block symbol in the control chart to open the properties form.
Block type POSTEMPCDB has five CDPs defined on it. Thus, when the form for
POSTEMP1.DATA1 opens, five parameters appear. This is shown below where it is
assumed that you have already made data entries for the fields that allow it.
Table 57 Value CDP configuration in POSTEMP1.DARA1
Name Value Description
ZONE 3.0 Zone number
POSITION 25.7 Position in zone
TEMP ----- Temperature at position
BAD ON Error flag
DESCR “K Type, Bottom of Tube” Description of sensor
On the form, only the value CDP entries for ZONE, POSITION, and DESCR can be
modified. The description field that goes with each parameter indicates the meaning of
the parameter and is fixed at block type creation time.
The value CDP fields for TEMP and BAD cannot be modified because these parameters
were declared not configurable. This is indicated above with italics.
10/04 Honeywell
A CAB to calculate statistics over arrays
The DESCR parameter is a string parameter. This value can and should be defined at
instance configuration time. Note how it differs from the description field of CDPs.
When viewed from the monitor side at runtime, all five parameters show data read
directly from the CEE.

Block type ZONESTATSCAB
Assume that you wish to calculate statistics on zone temperatures as another component
in an overall PFR application. The statistics are to summarize the overall temperature
state of the zone. They can then be presented within a graphical schematic display that
allows the operator to monitor the reaction over the entire length of the PFR without
being overwhelmed by many individual readings.
Assume that you create a CAB type called ZONESTATSCAB to compute zone statistics.
You design ZONESTATSCAB so that it can receive as input whole array parameters that
hold temperature and position data. ZONESTATSCAB will then use this data to compute
scalar values that characterize the zone as a whole.
Value CDPs for ZONESTATSCAB

ZONESTATSCAB has the following Value CDP definitions:
Table 58 Value CDP definitions in ZONESTATSCAB

array
size
POSITION Position in FLOAT64 5 PROGRAM NOLOAD -----

zone
TEMP Temperature FLOAT64 5 PROGRAM NOLOAD -----

at position
MAXTEMP Maxi temp in FLOAT64 0 VIEWONLY NOLOAD -----

zone
MAXPOS Position of FLOAT64 0 VIEWONLY NOLOAD -----

max temp
MINTEMP Min temp in FLOAT64 0 VIEWONLY NOLOAD -----

zone
Honeywell 10/04

array
size
MINPOS Position of FLOAT64 0 VIEWONLY NOLOAD -----

min temp
AVGTEMP Average temp FLOAT64 0 VIEWONLY NOLOAD -----

in zone
POSITION and TEMP are both array parameters. They are designed to connect directly
with parameters of the same name on an instance of block type ZONETEMPCDB, called
ZONETEMP1.
MAXTEMP, MAXPOS, MINTEMP, MINPOS and AVGTEMP are real valued statistics
parameters computed by looping over the TEMP array. The access lock of these
parameters is declared to be VIEWONLY. This means that external agents cannot write
to these parameters, but program ZONESTATSCAB can.
MAXPOS and MINPOS give, respectively, the position of maximum and minimum
temperature within the zone. They are computed by looping over data received in
POSITION and TEMP.
Block type ZONESTATSCAB has value CDP definitions but no parameter reference
definitions. The output parameters provided by ZONESTATSCAB (MAXTEMP,
MAXPOS, MINTEMP, MINPOS, AVGTEMP) are collected asynchronously by
displays. Thus, they can only be supported by value CDPs.
The inputs needed by ZONESTATSCAB require bulk array transport from the source.
This is not supported by CAB parameter references. Thus, value CDPs POSITION and
TEMP are used to bring in array data from a process-connected controller. The
connectivity to source data is accomplished through the use of CM graphical connections
rather than CAB parameter references.
Algorithm for ZONESTATSCAB

The program for ZONESTATSCAB is as follows:
10/04 Honeywell

Imports System.Math

Inherits BlockBase

Dim I As Integer
If Restart <> None Then DoInitialize()
SetOutputsToBad()
AVGTEMP.Value = 0.0
For I = 0 To 4
If IsNaN(TEMP(I).Value) Or IsNaN(POSITION(I).Value) Then
SetOutputsToBad()
Exit For
Else
AVGTEMP.Value = AVGTEMP.Value + TEMP(I).Value
If IsNaN(MAXTEMP.Value) Or MAXTEMP.Value < _
TEMP(I).Value Then
MAXTEMP.Value = TEMP(I).Value
MAXPOS.Value = POSITION(I).Value
End If
If Not (MINTEMP.Value <= TEMP(I).Value) Then
MINTEMP.Value = TEMP(I).Value
MINPOS.Value = POSITION(I).Value
End If
End If
Next I
AVGTEMP.Value = AVGTEMP.Value / 5
End Sub
Private Sub DoInitialize()
Dim I As Integer
Honeywell 10/04
For I = 0 To 4
POSITION(I).Value = NaN
TEMP(I).Value = NaN
Next I
End Sub
Sub SetOutputsToBad()
MAXTEMP.Value = NaN : MAXPOS.Value = NaN
MINTEMP.Value = NaN : MINPOS.Value = NaN
AVGTEMP.Value = NaN
End Sub
End Class
Some things to note about the program above are:

• The TEMP and POSITION CDP arrays use the default base index of 0. Thus, all
loops range from 0 to 4 in this program.
• The programmer has chosen to isolate initializations within a private subroutine
called DoInitialize().
• The programmer is following the convention that all initialized CDPs show the value
NaN after the program is activated. TEMP and POSITION are intended to serve as
input arrays. In case they are not initialized by the time of the first execution,
DoInitialize() was written to set them to NaN.
• The output CDPs are initialized to NaN in subroutine SetOutputsToBad(). Output
CDPs do not need to be initialized because SetOutputsToBad() is called at the start of
Execute().
• The VB.NET line separator has been used in SetOutputsToBad(). For example,
"MAXTEMP.Value = NaN : MAXPOS.Value = NaN", could have been
written with each assignment statement on a different line.
• For assignment of MAXTEMP and MAXPOS within the loop, TEMP(I) is explicitly
tested for NaN before doing any compare. This insures that nothing unexpected will
happen if a NaN value is passed into the comparison. For assignment of MINTEMP
and MINPOS the programmer has written the program to handle NaN correctly, but
in a more subtle way. The programmer has not used IsNan(), but instead has written
the comparison operation as a negative so that the correct outcome will occur
10/04 Honeywell
regardless of whether MINTEMP.Value is NaN or ordered. The more transparent

approach of using explicit IsNan() calls is the recommended style.
• The final assignment, "AVGTEMP.Value = AVGTEMP.Value / 5" can
happen with a NaN value on the right hand side if inputs are bad. If so, the division
operation results in a NaN output.
• Subroutine Execute() is declared with VB.NET access type of Public. In contrast,
subroutines Initialize() and SetOutputsToBad() are declared with an access type of
Private. Execute() must be declared Public in order for CEE services to access them.
It is an interface subroutine whose declaration should not be changed to vary from the
declaration automatically generated when the block type was first created.
• SetOutputsToBad() and Initialize() are different in that these are subroutines used as
utilities by type ZONESTATSCAB alone. Thus, they are declared to be Private. In
point of fact, they would still be private even if the access type declaration were left
out or if it was declared to be Public. CAB does not support utility functions that can
be shared across block types. The recommended style is to declare all internal utility
functions as Private since this documents the true behavior.
Bulk array connection on ZONESTATSCAB instance

Assume that after creating the block type, you create a CM instance called
"ZONESTATS1" and instantiate ZONESTATSCAB within it as "ALG1". You create
graphical connections within ZONESTATS1 that accomplish the following whole-array
data flow:
• ZONESTATS1.ALG1.TEMP[ ] ← ZONETEMP1.DATA1.TEMP[ ]
• ZONESTATS1.ALG1.POSITION[ ] ← ZONETEMP1.DATA1.POSITION[ ]
At runtime, the values of TEMP and POSITION are used internally within
ZONESTATS1.ALG1 for computing the statistics parameters as indicated in the
algorithm above.
Note that CM hierarchies are well suited to the logical representation of a PFR control
application such as described in this and preceding sections. For example, a top level CM
could be used to model the entire PFR. It could hold multiple CMs each representing a
zone. The zone CMs could hold each of the temperature–position CMs. However, the use
of CM hierarchies in control applications is not specific to CAB or CDB functionality
and is not described in detail within this document.
Honeywell 10/04
Array and scalar variables in CAB

Overview
Preceding sections illustrate the various ways in which scalar and array data can be used
in CAB programs. This next example uses scalar and array value CDPs and parameter
references in various contexts of scope to demonstrate, in a single example, their
similarities and differences.
This section also includes sample code illustrating how to initialize a two-dimensional
array: “Two-dimensional array example.”
Example variables
The variables used in this example are as follows. These names were chosen to signify
the type of variable rather than the meaning of the variable within an application.
• LclSclrVar - Local Scalar Variable
Declared explicitly within the Execute() subroutine of the user's source code.
• LclArrVar - Local Array Variable
Declared explicitly within the Execute() subroutine of the user's source code.
• BlkScpSclrVar - Block Scope Scalar Variable
Declared explicitly within the CAB class outside the scope of any subroutine.
• BlkScpArrVar - Block Scope Array Variable.
Declared explicitly within the CAB class outside the scope of any subroutine.
• SCLRCDP - SCaLar value CDP
Declared through PDE CDP definition. Defined in program context by automatically

generated declaration within BlockBase.
• ARRCDP - ARRay value CDP
Declared through PDE CDP definition. Defined in program context by automatically

generated declaration within BlockBase.
10/04 Honeywell
• SCLRPREFSCLR - SCaLar Parameter REFerence To SCaLar Parameter
Declared through PDE Par. Ref. definition. Defined in program context by

automatically generated declaration within BlockBase.
• SCLRPREFFXD - SCaLar Parameter REFerence To FiXeD Element Of Array
Parameter
Declared through PDE Par. Ref. definition. Defined in program context by

automatically generated declaration within BlockBase.
PDE definitions
PDE definitions for the value CDPs and parameter references could be as shown below.
In this example, it is assumed that you wish to create parameter ARRCDP as a one-
dimensional array with a base index different from the default. To do so, you must
expose more attributes than are presented within the default view of PDE (refer to the
Parameter Definition Editor Reference for information). The table below shows all
supported CDP attributes. This table is displayed in a vertical format rather than the
normal horizontal format so that it fits on the page.
Honeywell 10/04
Table 59 Value CDP definitions
Parameter name
Attribute SCLRCDP value ARRCDP value
Data Type FLOAT64 FLOAT64
First Dimension Array Size 0 10
First Dimension Array Lower 0 1

Bound
Second Dimension Array 0 0

Size
Second Dimension Array 0 0

Lower Bound
Default Value 100.0 0.0
Minimum Value -1.78E308 -1.78E308
Maximum Value 1.78E308 1.78E308
Configuration Load LOAD LOAD
Access Lock ENGINEER ENGINEER
Description Scalar value Ten-element array value
The minimum and maximum values for SCLRCDP and ARRCDP correspond to the
maximum finite magnitudes for a FLOAT64. These values are defaulted by PDE. You
can narrow the range if you desire. In accordance with the Data Owner Principle, range
limits are checked whenever an external agent makes a store into a CAB instance. They
are not checked for writes by the CAB program itself.
10/04 Honeywell
PDE definitions for the parameter references could be as follows:

Table 60 Parameter reference definitions
Name Data type Data flow Description
SCLRPREFSCLR FLOAT64 INPUT Scalar parameter reference to

scalar parameter
SCLRPREFFXD FLOAT64 INPUT Scalar parameter reference to

element of array parameter
Instance configuration
Instance configuration for the value CDPs could be as follows. Note that although the
table shows all elements of ARRCDP(), the properties form would show the array in
scrollable form.
Table 61 Value CDP configuration
Name Index Value Description
SCLRCDP ----- 175.0 Scalar value
ARRCDP 1 1000.0 Ten-element array value
Honeywell 10/04
Instance configuration for the parameter references could be as follows:

Table 62 Parameter reference configuration
Reference alias Reference address Description
SCLRPREFSCLR TI100.PID1.PV Scalar parameter reference to scalar

parameter
SCLRPREFFXD FC100.NN1.PV(7) Scalar parameter reference to element

of array parameter
Program
The following program uses the variables defined above. The algorithm is not intended to
be useful— it is intended to demonstrate the variable syntax. Note that whereas the
indices for BlkScpArrVar and LclArrVar are in the range 0 to 9, the index for ARRCDP
is in the range 1 to 10.


Imports System.Math

Inherits BlockBase
Dim BlkScpSclrVar As Double

Dim BlkScpArrVar(10) As Double

Dim LclSclrVar As Integer

Dim LclArrVar(10) As Double
10/04 Honeywell

PRefList.Read()
If Restart <> None Then Initialize()
For LclSclrVar = 0 To 9
LclArrVar(LclSclrVar) = _
BlkScpArrVar(LclSclrVar) * SCLRPREFSCLR.Value
ARRCDP(LclSclrVar + 1).Value = _
LclArrVar(LclSclrVar) * SCLRPREFFXD.Value
Next LclSclrVar
End Sub
Private Sub Initialize()
Dim LclSclrVar As Integer
BlkScpSclrVar = 0
For LclSclrVar = 0 To 9
BlkScpArrVar(LclSclrVar) = LclSclrVar / SCLRCDP.Value
BlkScpSclrVar = BlkScpSclrVar + BlkScpArrVar(LclSclrVar)
Next LclSclrVar
End Sub
End Class
Two-dimensional array example

The following code segment illustrates how to access a two-dimensional array. For this
example, assume that TESTARRAY was defined in the PDE as an array with type
STRING and with first and second dimension array size of five.
‘ Example of initializing a two-dimensional 5x5 string array

For i As Integer = 0 To 4
For x As Integer = 0 To 4
Me.TESTARRAY(i, x).Value = “test” + x.ToString
Next
Next
Honeywell 10/04
Initializing in response to system events

Overview
This example illustrates use of the Restart API to select alternative initializations based
on system start-up events. The majority of CAB applications need not concern
themselves with Restart. But in some cases, you might wish to design a block type that
can be widely applied and that provides behavior that is consistent across all state
transitions.
Fast history block

In this example, you create a simple block type to collect data into a history buffer. The
block type is called HISTBUF. The intent is to collect history within the CEE at a rate
that is faster than can be supported by EPKS server. The collected history data could be
shown in the operator view by an appropriately designed custom display.
You use an array CDP called HISTORY to hold the history values. HISTORY has 64
elements. It is organized as a "wrapping" buffer in which new data constantly overwrites
the oldest data by wrapping around to the beginning of the array. Another CDP called
LASTINDEX gives the index of the most recent history value.
Data is input to the block through a CDP called PVIN. In this block design, parameter
references are not used. Instead, you plan for input data to PVIN to arrive through a
Control Module graphical connection.
PDE definitions
Assume that you decided not to use PRefs in the solution to this problem. CDP
definitions are shown below:
Table 63 Value CDP definitions

PVIN Data element FLOAT 0 VIEWONLY NOLOAD 0.0

to be 64
historized
LASTINDEX Index of most INT32 0 VIEWONLY NOLOAD 0

recent history
value
HISTORY History value FLOAT 64 VIEWONLY NOLOAD 0.0

array 64
10/04 Honeywell
HISTORY is a one-dimensional array CDP. You decided to leave its index lower bound
at the default of 0 as this is natural with a wrapping buffer.
Program

Imports System.Math

Inherits BlockBase

LASTINDEX.Value = (LASTINDEX.Value + 1) Mod 64
HISTORY(LASTINDEX.Value).Value = PVIN.Value
End Sub

Dim i As Integer
Select Case Restart
Case CEEWarmStart
PVIN.Value = NaN
' Assume most of the history is valid but insert some Nan
' values so the operator can see there is a discontinuity.
For i = LASTINDEX.Value + 1 To LASTINDEX.Value + 3
HISTORY(i Mod 64).Value = NaN
Next i
LASTINDEX.Value = ((LASTINDEX.Value + 3) Mod 64)
Case Else
' This is where we end up for Restart of BlockLoad,
Honeywell 10/04
Example using data type TIME
' BlockActivate or CEEColdStart. In all of these cases

' we must assume there is no valid history.
PVIN.Value = NaN
LASTINDEX.Value = 63
For i = 0 To LASTINDEX.Value
HISTORY(i).Value = NaN
Next i
End Select
End Sub
End Class

Shift calculations
One use of time processing within CAB would be to run a block periodically,
synchronous with local wall clock time. This could be useful in calculating relevant data
at the end of an operator shift.
There is more than one way to address this need within ACE. This example solves the
problem with a CAB type called SHIFTCALC. SHIFTCALC is intended to run within a
CM that executes periodically, perhaps once per minute. Every minute, the SHIFTCALC
instance checks whether it is time to do shift calculations and if so, does them.
The shift interval is hard coded at eight hours within the program and is phased to
correspond to midnight, 8:00 A.M., and 4:00 P.M. SHIFTCALC uses the Now property
of the .NET structure DateTime to identify when to execute calculations. Now returns
the value of local time. Thus, in SHIFTCALC, shift calculations always occur at the local
target times regardless of changes in daylight savings time. The interval between the
midnight calculations and the 8:00 AM calculations is normally eight hours. When local
time shifts into daylight savings time in spring, the interval is shortened to seven hours.
When local time shifts out of daylight savings time in fall, the interval is lengthened to
nine hours.
SHIFTCALC records the actual time at which the calculations have occurred within the
value CDP LASTRUNTIME. LASTRUNTIME has the EPKS data type TIME. Since
TIME is always transported as universal time, the program must be written to adjust for
the difference between its internal timing (local time) and the externally transported time
(universal time). The ToUniversalTime method of DateTime is used to do this.
10/04 Honeywell
Although EPKS transports TIME values as universal time, they are always displayed as
local time. Thus a supervisor can verify timely execution of a SHIFTCALC instance by
examining LASTRUNTIME on an operational display. The display will show the time of
last calculation as local time.
Value CDP definition for SHIFTCALC

The CAB uses one value CDP, shown below:
Table 64 Value CDP definition for SHIFTCALC

LASTRUNTIME Time of last TIME 0 VIEWONLY NOLOAD -----

shift
calculation
Algorithm for SHIFTCALC

The algorithm for the CAB is listed below:

Imports System.Math

Inherits BlockBase
Dim NextCalcHour As Integer
Dim CurrentTime As DateTime

Dim CurrentHour As Integer
If Restart <> None Then

NextCalcHour = Now.TimeOfDay.Hours
Honeywell 10/04
Example using data type TIMEOFDAY
NextCalcHour = (NextCalcHour + 8 – NextCalcHour Mod 8) Mod 24

End If
CurrentTime = Now
CurrentHour = CurrentTime.TimeOfDay.Hours
If CurrentHour = NextCalcHour Then
NextCalcHour = (CurrentHour + 8) Mod 24
LASTRUNTIME.Value = CurrentTime.ToUniversalTime
DoShiftCalculations()
End If
End Sub
Private Sub DoShiftCalculations()

' Do shift calculations.
End Sub
End Class
Note that in the code above the internal subroutine DoShiftCalculations() is declared with
VB.NET access type Private. This is not strictly necessary. But it is recommended as it
accurately documents the way in which the subroutine can be used. Subroutines in CAB
types can only be used internally to the type.

Slow monitoring calculations
Another example of the use of time processing within CAB is to have a calculation
execute periodically at regular intervals, or upon the occurrence of special events, but
asynchronous with wall clock time. This could be useful for an application that does
process monitoring with associated calculations.
There is more than one way to address this need within ACE. This example solves the
problem with a CAB type called MONCALC. MONCALC is intended to run within a
CM that runs periodically, perhaps once per minute. Every minute, the MONCALC
instance checks whether it is time to do monitoring calculations and if so, does them.
MONCALC is set up to run under three conditions:
• On demand if the operator requests it by writing ON to the Boolean value CDP
"RUNNOW."
• Whenever the block is loaded or activated and whenever you go through a cold or
warm start.
10/04 Honeywell
• Periodically every three hours since its last execution.

MONCALC uses the DateTime property UtcNow rather than Now as the basis for its
timing. Now returns local time whereas UtcNow returns universal time. Using UtcNow
insures that the time between calculations will always be three hours since last execution
unless there is a special event to make execution happen sooner. This is true regardless of
changes in daylight savings time.
MONCALC always records the time of last execution in the value CDP
"LASTRUNTIME". In this example it is assumed that LASTRUNTIME is only of
interest to within the time of day so it is assigned the EPKS type TIMEOFDAY. Within
the program LASTRUNTIME is derived form a universal time value using the DateTime
property TimeOfDay. But it is always displayed as local time within operational displays.
Value CDP definitions for MONCALC

The CAB includes two value CDPs, which are defined as follows:
Table 65 Value CDP definitions for MONCALC
Parameter Parameter Data type First Access Config Default

name description dim lock load value
array
size
RUNNOW If ON causes BOOLEAN 0 VIEWONLY NOLOAD TRUE

program to
run
LASTRUNTIME Time of last TIMEOFDAY 0 VIEWONLY NOLOAD -----

calculation
Honeywell 10/04
Algorithm for MONCALC

The algorithm for CAB MONCALC is listed below:

Imports System.Math

Inherits BlockBase
Dim NextRunTime As DateTime
If Restart <> RestartEnum.None Then Initialize()

If RUNNOW.Value Then
RUNNOW.Value = False
NextRunTime = Now.UtcNow
TOD1.Value = NextRunTime
End If
If (Now.UtcNow >= NextRunTime) Then

LASTRUNTIME.Value = NextRunTime.TimeOfDay
NextRunTime = NextRunTime.AddMinutes(3.0)
DoCalculation()
End If
End Sub

RUNNOW.Value = True
If Restart = RestartEnum.BlockLoad Then _
LASTRUNTIME.Value = New TimeSpan(0, 0, 0)
Send(“Executing Initialize subroutine”)
10/04 Honeywell
Example using data type DELTATIME
End Sub
Private Sub DoCalculation()

Send(“Executing DoCalculation”)
End Sub
End Class
Note that in the code above the internal subroutine DoCalculations() is declared with
types can only be used internal to the type.

Time-out monitor
Another example of time processing within CAB is a type, TIMEOUTMON, which
looks for a start and stop signal within a specified time period. Such a block could be
used to send alarms or to take other action if a process operation took too long. This
functionality already exists within the CEE native block set. So TIMEOUTMON would
not be implemented within CAB unless there was a particular reason to have the timing
logic closely integrated with other programmatic processing. It does serve as a good
illustration of how to use a CDP of type DELTATIME within CAB.
In this example, TIMEOUTMON supports two Boolean CDPs, STARTTIMING and
STOPTIMING. It supports a configuration CDP called TIMEOUT that allows the
timeout interval to be specified. TIMEOUT is of type DELTATIME. TIMEOUTMON
also supports a ViewOnly CPD called TARGETTIME. TARGETTIME is assigned
during timing operations and displays the time by which the operation must complete.
Timing operations can be retriggered by setting STARTTIMING to ON if timing has
already started.
Note that within the program, TIMEOUT has the .NET type TimeSpan and can be added
to a variable of type DateTime to develop a target time.
Value CDP definitions for TIMEOUTMON

The value CDPs for this example are given in the following table:
Honeywell 10/04
Table 66 Value CDP definitions for TIMEOUTMON
Parameter Parameter Data type First Access Config Default

name description dim lock load value
array
size
STARTTIMING Start or BOOLEAN 0 VIEWONLY NOLOAD -----

restart timing
operation
STOPTIMING Stop timing BOOLEAN 0 VIEWONLY NOLOAD -----

operation
TIMEOUT Timeout DELTATIME 0 VIEWONLY LOAD 00:01:00

interval
TARGETTIME Time by TIME 0 VIEWONLY NOLOAD -----

which
operation
must
complete
Algorithm for TIMEOUTMON

The following is a listing of the algorithm for TIMEOUTMON:

Imports System.Math

Inherits BlockBase
Dim Running As Boolean

10/04 Honeywell
If Restart <> RestartEnum.None Then

STOPTIMING.Value = False
STARTTIMING.Value = False
TARGETTIME.Value = _
New DateTime(2000, 1, 1, 0, 0, 0, 0).AddHours(7)
End If
If STOPTIMING.Value Then
STOPTIMING.Value = False
Running = False
End If
If STARTTIMING.Value Then
Running = True
TARGETTIME.Value = Now.UtcNow.Add(TIMEOUT.Value)
TARGETTIME.Value = TARGETTIME.Value.Add(TIMEOUT.Value)
End If
If Running And (Now.UtcNow >= TARGETTIME.Value) Then

Running = False
HandleTimeOut()
End If
End Sub
Private Sub HandleTimeOut()

' Take appropriate actions.
Send("CAB TimeOut.")
Send("TargetTime = " + TARGETTIME.Value.ToString)
Send("TimeOut = " + TIMEOUT.Value.ToString)
End Sub
End Class
Note that in the code above the internal subroutine HandleTimeOut() is declared with
types can only be used internal to the type.
Honeywell 10/04
Use of data access status in CAB

Device monitor with Stop/Run command
This example illustrates a CAB type DEVMON that monitors a remote device that is
connected through an OPC Server FB. DEVMON reads device status to report if there is
a communication problem or if the device is not operating. It also supports a simple
stop/run command. As part of stop/run handling, DEVMON issues stores and verifies
status of the store requests.
DEVMON's program is intended to run at a moderately high rate to insure that device
status changes are reported quickly. But let us assume that you are unsure of whether the
OPC connection will always return status information as quickly as the block executes.
You could design the program to assume it always runs more slowly than the round trip
communication time. But instead, you prefer to set things up so that DEVMON will
always work, regardless of whether it runs faster or slower than communications.
Under this assumption, values read from the device might come back more slowly than
the DEVMON execution rate. This is not really a problem for the design because the last
value read will be held until the next is available. The only effect would be that the
response time is limited by the communication speed.
Slow communication response is more of an issue for stores since you wish to do status
verification. But this can be handled by using "WritePending" status of parameter
references.
Value CDP for DEVMON

One value CDP is used for DEVMON, as shown in the following table:
Table 67 Value CDP definition for DEVMON

array
size
OPERCMD Receives INT32 0 OPERATOR NOLOAD 0

Stop/Start
commands
10/04 Honeywell
Parameter OPERCMD is intended to take on three possible values.

• 0 means no command has been issued.
• 1 commands the device to stop.
• 2 command the device to run.
The operator is intended to use only values 1 and 2. Storing 0 is to have no effect.
Parameter references for DEVMON

Two parameter references are used in DEVMON. Their definitions are shown in the
following table:
Table 68 Parameter reference definitions for DEVMON
Parameter name Reference data type Parameter description Data flow
DEVICECMD INT32 Writes Stop/Start commands OUTPUT
DEVICESTS INT32 Reads Stopped/Running status INPUT
At instance configuration time, DEVICECMD is to be configured to point to the

command parameter of a particular remote device while DEVICESTS is to be configured
to point to the status parameter of that same device.
The values for these references are determined by the device specifications. Assume they
are as follows.
DEVICECMD points to a parameter that uses these values.
• 0 means stop
• 1 means run
DEVICESTS points to a parameter that uses these values.
• 0 means stopped
• 1 means running
• 2 means failed
Honeywell 10/04
Algorithm for DEVMON

The algorithm for DEVMON is listed below:

Imports System.Math
Imports System.DateTime
Imports CAB.CommandEnum
Imports CAB.DeviceCommandEnum
Imports CAB.DeviceStatusEnum
Public Enum DeviceCommandEnum : DeviceStop : DeviceRun : End Enum

Public Enum DeviceStatusEnum
DeviceStopped
DeviceRunning
DeviceFailed
End Enum
Public Enum CommandEnum : NoCommand : Stop_ : Run : End Enum

Inherits BlockBase
Dim CommandState As Integer

CommandState = NoCommand
OPERCMD.Value = NoCommand
End If
If OPERCMD.Value <> NoCommand And CommandState = NoCommand Then

Select Case OPERCMD.Value
10/04 Honeywell
Case Stop_
DEVICECMD.Value = DeviceStop
DEVICECMD.Write()
CommandState = Stop_
Case Run
DEVICECMD.Value = DeviceRun
DEVICECMD.Write()
CommandState = Run
Case Else
' Operator error, ignore
End Select
ElseIf CommandState <> NoCommand Then

If Not DEVICECMD.WriteStatus <> WritePending Then
CommandState = NoCommand
If DEVICECMD.WriteStatus <> OK Then
PROGSTSDESC.Value = "Write to DEVICECMD failed: " + _
DEVICECMD.WriteStatus.ToString()
Abort()
End If
End If
Else ' CommandState = NoCommand And OPERCMD.Value = NoCommand

DEVICESTS.Read()
If DEVICESTS.ReadStatus <> OK Then
PROGSTSDESC.Value = "Read of DEVICESTS failed: " + _
DEVICESTS.ReadStatus.ToString()
Abort()
ElseIf DEVICESTS.Value <> DeviceRunning Then
PROGSTSDESC.Value = "Device not running"
Abort()
End If
End If
End Sub
End Class
Honeywell 10/04
Use of parameter reference variables in CAB
Here are some things to note about the above program.

• Three enumeration types are defined to make the program more self-documenting:
DeviceCommandEnum, DeviceStatusEnum, and CommandEnum. To avoid having to
use fully qualified enumeration member names (for example, using "None" instead of
"CommandEnum.None"), three imports statements were added near the top of the
program. Each of these enumerations is defined within the VB.NET namespace called
"CAB." Thus, the imports statements take the form
"Imports CAB.CommandEnum".
• There is a member called “Stop_” in the CommandEnum enumeration. The name
"Stop" would have been more natural but could not be used because it collides with a
VB.NET keyword.
• There is no apparent reason to expose the value of CommandState to the outside
world. Thus, it is defined as a block scope variable rather than a CDP.
• The program checks for bad values of OPERCMD within the Select statement. If
found, it simply over-writes them.
• The program uses the built-in PROGSTSDESC parameter to publish any problems it
discovers.
• The program uses the Abort() subroutine to force an exception and event when a
problem is discovered.

Setting control state for a group of CMs
In this example, you decide to implement a CAB type called SETMODE to serve as a
utility for an SCM. Most of the time an instance of SETMODE does nothing. But when
requested by an SCM, it puts a set of up to five CMs into a state where they are doing
automatic regulatory control.
SETMODE takes three actions in response to an SCM request to go on control.
• Verifies that EXECSTATE is Active for each CM. If an Inactive EXECSTATE is
found it does not change it automatically. Instead it asks a human being to do so.
• Sets MODEATTR to Program.
• Sets MODE to Auto.
10/04 Honeywell
SETMODE also supports the operation of taking CMs out of the automatic operating
mode.
Value CDPs for SETMODE

Two value CDPs are used in SETMODE. They are defined in the following table:
Table 69 Value CDP definitions for SETMODE
Parameter Parameter Data First Access Config Default

name description type dim lock load value
array
size
REQUEST SCM writes to INT32 0 PROGRAM NOLOAD 0

request change in
control action.
RESPONSE SCM reads to INT32 0 VIEWONLY NOLOAD 0

learn of
completion of
request.
REQUEST can take these possible values:

• 0 means no request
• 1 means request for manual control
• 2 means request for automatic control
RESPONSE can take these possible values:
• 0 means the requested action is underway
• 1 means the request succeeded
• 2 means the request failed
Parameter references for SETMODE

In the design of SETMODE, you anticipate up to five CMs to be manipulated. Thus, you
have five sets of parameters to reference. You design SETMODE to handle a total of 15
parameter references as follows:
Honeywell 10/04
Table 70 Parameter reference definitions for SETMODE
Parameter Reference Parameter description Data flow

name data type
EXECSTATE1 INT32 Points to EXECSTATE for Control Module 1 INPUT
MODEATTR1 INT32 Points to MODEATTR for Control Module 1 OUTPUT
MODE1 INT32 Points to MODE for Control Module 1 OUTPUT
SETMODE is written to manipulate parameters EXECSTATE, MODEATTR and

MODE for each CM referenced.
10/04 Honeywell
Algorithm for SETMODE

The algorithm for SETMODE is listed below:

Imports System.Math
Imports System.DateTime
Imports CAB.RCModeAttrEnum : Imports CAB.RCModeEnum

Imports CAB.CMExecStateEnum
Imports CAB.MyRequestEnum : Imports CAB.MyResponseEnum

Imports CAB.MyStateEnum
Enum CMExecStateEnum
Inactive = 0 : Active = 1
End Enum
Enum RCModeAttrEnum
Operator = 1 : Program = 2
End Enum
Enum RCModeEnum
RCManual = 0 : RCAutomatic = 1
End Enum
Enum MyRequestEnum
NoRequest = 0 : ControlManual = 1 : ControlAutomatic = 2
End Enum
Enum MyResponseEnum
Pending = 0 : Succeeded = 1 : Failed = 2
End Enum
Honeywell 10/04
Enum MyStateEnum
NoAction = 0 : DoWrite = 1 : DoCheck = 2
End Enum
Class CMRefClass
Public IsNull As Boolean
Public ExecState As Int32PRef
Public ModeAttr As Int32PRef
Public Mode As Int32PRef
End Class

Inherits BlockBase
Dim CMRef(5) As CMRefClass

Dim State, ModeTarget As Integer
Dim IllegalNullRef As Boolean
Dim LastI As Integer
Dim I As Integer, FoundNullCMRef As Boolean
State = NoAction
ModeTarget = RCManual
REQUEST.Value = NoRequest
RESPONSE.Value = Succeeded
IllegalNullRef = False
If Restart = BlockLoad Then
' For each CMRef assign the PRefs and check for consistency.
' If inconsistency is found, flag bad configuration.
If Not SetUpCMRef(0, EXECSTATE1, MODEATTR1, MODE1) Then
IllegalNullRef = True : Exit Sub
End If
IllegalNullRef = True: Exit Sub
End If
10/04 Honeywell

End If
End If
End If
' CMRef(0) at least must be non-null

LastI = 0
If CMRef(LastI).IsNull Then
End If
' Find the last non-null CMRef
For I = 1 To 4
If Not CMRef(I).IsNull Then
LastI = I
Else
Exit For
End If
Next I
' All non-null CMRefs must be at the low indices
For I = LastI + 1 To 4
If Not CMRef(I).IsNull Then
End If
Next I
End If
End Sub
Honeywell 10/04
Function SetUpCMRef(ByVal I As Integer, ByVal ExecState As _

Int32PRef, ByVal ModeAttr As Int32PRef, ByVal Mode As _
Int32PRef) As Boolean
' Assign the PRefs into the CM refernce object

CMRef(I).ExecState = ExecState
CMRef(I).ModeAttr = ModeAttr
CMRef(I).Mode = Mode
' Make sure that for each CM reference
' either all PRefs or none are null
CMRef(I).IsNull = ExecState.IsNull
If CMRef(I).IsNull <> ModeAttr.IsNull Or _
CMRef(I).IsNull <> ModeAttr.IsNull Then
' This is a disallowed configuration, indicate error
SetUpCMRef = False
Else
' This is an allowed configuration, indicate no error
SetUpCMRef = True
End If
End Function
' If CE who created instance made mistake with

' null PRef configuration
' report an error and force the instance into exception state
If IllegalNullRef Then
PROGSTSDESC.Value = "Bad parameter reference configuration"
Abort()
End If

PRefList.Read()
10/04 Honeywell
If REQUEST.Value <> NoRequest Then

Select Case REQUEST.Value
Case ControlManual
ModeTarget = RCManual
State = DoWrite
Case ControlAutomatic
ModeTarget = RCAutomatic
State = DoWrite
Case Else
' Bad REQUEST.Value entered, will overwrite
End Select
REQUEST.Value = NoRequest
RESPONSE.Value = Failed
End If
If State <> NoAction Then

Select Case State
Case DoWrite
Select Case ProcessWrite()
Case Failed
Response.Value = Failed
State = NoAction
Case Else ' MyResponseEnum.Pending
State = DoCheck
End Select
Case DoCheck
Select Case CheckWriteStatus()
Case Failed
Response.Value = Failed
State = NoAction
Case Succeeded
Response.Value = Succeeded
State = NoAction
Case Else ' MyResponseEnum.Pending
' Keep checking
End Select
Honeywell 10/04
End Select
End If
' Store values to destination for any output references

' whose values were written
PRefList.Write()
End Sub
Function ProcessWrite() As Integer

Dim I As Integer
Dim InactiveFound As Boolean
InactiveFound = False
For I = 0 To LastI
If CMRef(I).ExecState.Value <> Active Then
Send("EXECSTATE Inactive at CM number" + CStr(I))
InactiveFound = True
End If
Next I
If InactiveFound Then Return Failed
For I = 0 To LastI
CMRef(I).ModeAttr.Value = Program
CMRef(I).Mode.Value = ModeTarget
Next I
Return MyResponseEnum.Pending
End Function
Function CheckWriteStatus() As Integer

Dim I As Integer
Dim Response As Integer
For I = 0 To LastI
Response = Check1ParameterWrite(CMRef(I).ModeAttr)
If Response <> Succeeded Then
Return Response
Else
Response = Check1ParameterWrite(CMRef(I).Mode)
If Response <> Succeeded Then Return Response
End If
Next I
10/04 Honeywell
Return Succeeded
End Function
Function Check1ParameterWrite(ByVal Parameter As Int32PRef) _

As Integer
If Parameter.WriteStatus = WritePending Then
Return MyResponseEnum.Pending
ElseIf Parameter.WriteStatus <> OK Then
Return Failed
Else
Return Succeeded
End If
End Function
End Class
Here are some things to note about the above program:

• In VB.NET, enumeration members can each be defined on a separate line or they
can be defined on the same line if each is separated by the VB.NET line separator,
":". Here the program listing is made a little more compact by putting enumeration
members on the same line, as in the following.
Enum enumMyRequest
None = 0 : ControlManual = 1 : ControlAutomatic = 2
End Enum
• The program uses a simple VB.NET class to group parameter references that point to
the same Control Module. This is the class "CMRefClass".
• CMRefClass has 3 data members of type "Int32PRef". There is an additional
Boolean data member, "IsNull". When True, IsNull indicates that all of the parameter
references are null. When false, IsNull indicates that none of the parameter references
are null. The IsNull data member of CMRefClass is set by using the IsNull property
of Int32PRef to identify null references.
• The program uses a block scope array variable, "CMRef(5)" to allow indexing over
each CM.
• Within the Initialize() subroutine are copies of the parameter references
established at configuration time into CMRef(). This is a way to work around the fact
that CAB does not support indexed parameter references.
Honeywell 10/04
• The CMRef array is only initialized as a result of block configuration load. It's not
necessary to do this initialization at any other time as the address of a parameter
reference can only change during load.
• Initialize() also does validation checking on the parameter reference configuration of
the instance. The CAB type is designed so that all instances must obey these rules:
− If any of the three parameters on a particular CM are referenced then all three
must be referenced.
− Up to five CMs can be referenced but at least one CM must be referenced.
− If only one CM is referenced then the parameter references labeled "1" must be
used.
− The non-null references must be at low indices and the null references at high
indices.
• The program has defined four internal functions to make the program simple and
readable. These are Initialize(), SetUpCMRef(), ProcessWrite(), CheckWriteStatus()
and Check1ParameterWrite(). These routines are distinct from Execute() in that they
are unknown to the CAB system infrastructure. Also, no other CAB type can use
them.
• Two of the internal functions, SetUpCMRef() and Check1ParameterWrite(), pass
arguments of type Int32PRef.
10/04 Honeywell
Honeywell 10/04
CAB and CDB operations
Startup and shutdown
Custom Algorithm Blocks
Startup and shutdown of the CAB build-time environment (tools for creating CAB types)
are manual procedures within the Experion CB application. Startup of the MSVS
development environment occurs when you use CB menu selections to initiate the
creation or edit of a CAB type. Shutdown occurs when you end the creation or edit
session by closing MSVS.
Startup and shutdown behavior of CABs in the run-time environment follows that of the
ACE application on which they are hosted. Behavior is equivalent to that of any native
block running on ACE. This includes block activation or deactivation. In addition, CAB
algorithm execution terminates automatically if its execution time exceeds 250
milliseconds (see “Transition descriptions”).
Custom Data Blocks

Startup and shutdown of the CDB build-time environment (tools for creating CDB types)
are manual procedures within the Experion CB application. Startup of the PDE tool
occurs when you use CB menu selections to initiate the creation or edit of a CDB type.
Shutdown occurs when you end the creation or edit session by closing the PDE.
CDBs run on PC hardware, hosted by the ACE application. In this case, startup and
shutdown behavior within the run-time environment is equivalent to that of any native
blocks running under Experion ACE.
Process operations
Monitor CAB and CDB
Monitoring CAB and CDB operations is the same as for strategies using native blocks.
The normal Experion monitoring features apply to CAB and CDB. CAB and CDB can be
monitored as part of routine process operations, which would normally be conducted
from Station. You can also use standard Windows performance monitoring tools. See
“Resource management” for more information.
View CAB alarms

CAB alarms are reported in exactly the same manner as other Experion alarms. For
information on alarms specific to CAB, see “CAB alarms.”
Honeywell 10/04
View CAB and CDB from Station
View CAB and CDB from Station

Overview
As with native blocks, CAB and CDB can be monitored in Station. Some of the
applicable Station capabilities are:
• Faceplate display—you can view selected parameters such as:
− CDPs that you have configured to be visible on the faceplate.
− CABSTATE and CABCOMMAND FDPs that appear on the faceplate by
default.
− Other FDPs that you select (they must be FDPs that are allowed to be exposed).
• Detail Display
• Custom schematics—can include CDPs from CABs and CDBs.
• Alarm Summary—CAB alarms will appear here.
• Message Summary—allows you to view CAB message strings generated in the CAB
program with the Send() subroutine.
• CM charts.
• Block Properties forms.
All of these functions are standard with Experion Station.
Properties forms specific to CAB and CDB

Overview
CAB and CDB block property forms can be viewed in CB and in Station, in the same
manner as native block forms. CAB and CDB forms have some parameters and tabs that
are unique, and these are described here.
TIP
The block property forms can be customized in PDE when the type is defined.
The form configurations shown below are the default configurations.
Honeywell 10/04

For a summary of the FDPs displayed on the following forms, see Table 23 Summary of
CAB FDPs not common with native blocks.” Detailed descriptions of the parameters are
in the section “Detailed description Of CAB specific FDPs.” Information on how to
customize the Block Configuration Forms is found in the Parameter Definition Editor
Reference.
Main tab of a CAB block property form

The following image shows the portion of the CAB Block Property form Main tab that
contains CAB-specific parameters. See the references cited in “Where to find
information” above for information on each parameter shown. Note that all of these
parameters are read-only on both the project and monitor side instances.
Figure 34 CAB-specific parts of CAB block property form Main tab
10/04 Honeywell
Main tab of a CDB block property form

The following images are of portions of the CDB Main tab that contain CDB-specific
parameters. See the references cited in “Where to find information” above for
information on each parameter shown. Note that these parameters are read-only on both
the project and monitor side instances.
Figure 35 CDB-specific parts of CDB block properties form Main tab
Value CDPs tab for CAB and CDB

This tab is present for both CAB and CDB if value CDPs were configured when the type
was defined.
Figure 36 Value CDPs tab of CAB and CDB block properties form
The figure shows a portion of a CAB properties form. A CDB form will not have the
Parameter References, Source, and Alarms tabs.
If you view the Value CDPs tab on the monitor side, you can change CDP values on the
running CAB. If you view the tab on the project side, you can change values only if the
parameter’s Configuration load attribute was set to LOAD when you created the type,
but they will not be reflected in the monitor side instance until you do a load.
Honeywell 10/04
Parameter References tab

This tab is present for CAB if parameter references were configured when the type was
defined.
Figure 37 Parameter References tab of CAB block properties Form
If you view this tab on the project side, you can use the browse buttons to configure
parameter references (or change existing references). You can also type in or past in a
parameter reference address instead of using the browse button. You must do a load for
these parameters to be reflected on the monitor side instance. If you view the tab from the
monitor side, you can see the last-loaded references but you cannot change them.
Source tab
This tab is present for CAB instances. It displays the CAB algorithm. On the project side,
it displays the most recent code saved to ERDB from MSVS. On the monitor side, it
shows the last-loaded version of code (the code that the instance is using). If you modify
and save code, you must do a load to transfer the new code to the monitor side instance.
The Source tab has some important uses. It can be used to compare the code that is
running in the CEE (monitor side) with the code stored in the ERDB (project side). It can
also be used to recover code that has been saved over. See ‘Recover CAB source code.’
10/04 Honeywell
Figure 38 Source code tab on CAB block properties form
Honeywell 10/04
Alarms tab
This tab is present on CAB Block Properties forms.
Figure 39 Alarms Tab on CAB Block Properties Form
For information on the parameters that are displayed on this tab, see “CAB alarms.”
You can change configuration values on the project side, but you must do a load to
reflect them on the monitor side. You cannot change values on the monitor side.
10/04 Honeywell
Honeywell 10/04
CAB and CDB system administration
CAB development environment administration
Recovering from a Control Builder crash
In the unlikely event that Control Builder crashes while Visual Studio is open to create or
edit a CAB type, it is possible that the Visual Studio process will not terminate properly.
If this happens, you will need to use Task Manager to delete any instance of devenv.exe
that is running.
User management
User management functions
CAB and CDB use the standard Experion user management features. For example,
access to Control Builder requires a logon password. Access to parameters in the run-
time environment are determined by the Access Lock attributes that are configured when
the block type is created.
The CAB developer’s license is a user management function that is special for CAB. A
developer’s license is required for users to be able to create and edit CAB types. For
more information, see “Licensing considerations.”
Setting user permissions

Creating and editing CAB types in Microsoft Visual Studio .NET, requires the user to
have Administrative privileges on the target PC or be a member of the Engineers group.
Establishing a User account for SimACE

In order for a user to be able to debug CAB programs that are executing in a
SimACE, the following setup must be performed.
• The NT user account that the user is logged on the client must also exist on the
SimACE with the same password.
• This User account on the SimACE must be a member of the "Administrators" group.
• To prevent the user from logging on the SimACE, the "Deny logon locally" Policy
should be set for the user. This is done by executing "Local Security Settings" under
Administrative Tools and clicking on "User Rights Assignment".
• On the client, the User account should be added to the "Debugger Users" group.
Honeywell 10/04
Resource management
Resource management
Overview
Most resource management functions for CAB and CDB are the same as normal
Experion system resource management functions. Because of the nature of CAB,
however, you might wish to pay special attention to monitoring ACE processor and
memory utilization. The section “Determine ACE shutdown horizon” contains
information about how to estimate ACE memory usage, especially the memory
consumed by “orphan” CAB types resulting from development and debug activities.
This section describes three CAB FDPs that may help you determine if a CAB instance is
nearing its performance limits. This section also contains some tips for using standard
Windows monitoring tools to observe ACE memory and processing statistics.
You can also obtain information from Experion monitoring functions. For example, if
your CAB applications start to experience timeout errors, it could be an indication that
you are starting to overload the CPU. It could also indicate that a CAB algorithm is in an
unintended loop.
Honeywell 10/04
Resource management
Use performance monitoring FDPs

CAB infrastructure includes three FDPs that can be used be used to view certain CAB
performance-related measurements. For detailed descriptions of these parameters, see
“Detailed description Of CAB specific FDPs.” The three parameters are:
• CABEXECTIMER— This parameter contains the time in microseconds required
during the last execute cycle to run the user’s CAB code. This timer starts when the
user’s code is invoked and ends after the user’s code is finished and all associated
CAB error handle and watchdog code is complete. By using this parameter, you can
determine if the execution time of your CAB is approaching the 250-millisecond
limit. If you determine that the CAB is at or near the execution time limit and it has a
significant number of parameter references, you can use the CABPREFRDTIM and
CABPREFWRTIM parameters to determine the contribution of parameter reference
processing times to the overall execution time.
• CABPREFRDTIM—This parameter contains the total time in microseconds spent
outside of CAB user code processing parameter reference read requests during the
current execute cycle.
• CABPREFWRTIM—This parameter contains the total time in microseconds spent
outside of CAB user code processing parameter reference write requests during the
current execute cycle.
10/04 Honeywell
Resource management
Use Task Manager

You can view memory and processor utilization graphically from the Performance tab
of Windows Task Manager.
Figure 40 Task Manager performance tab
Honeywell 10/04
Resource management
Use Performance Monitor

Another useful tool is the Windows performance monitor (perfmon), which can be
configured to monitor one or more system functions. The following procedure shows
how to configure perfmon to monitor ACE processor and memory utilization.
Step Action
1 Click Start, choose Run, enter “perfmon” in the Open box, and click OK.
2 Right-click and choose Properties.
10/04 Honeywell
Resource management
Step Action
3 Click Add.
Honeywell 10/04
Resource management
Step Action
4 Select Process in the Performance Object box. Choose ACE in the instance
list. Choose % Processor Time in the list of counters. Click Add.
10/04 Honeywell
Resource management
Step Action
5 Next choose Private Bytes from the list of counters. Click Add.
Honeywell 10/04
Resource management
Step Action
6 Click OK to close the Properties dialog box. The ACE processor and memory
utilization will be shown and monitored. In this manner, other items of interest
can be added to the display for monitoring. Note—you will probably have to
return to the property pages and adjust the Scale on the Data tab and the
Maximum and Minimum values on the Graph tab in order to get a meaningful
display.
10/04 Honeywell
Backup and restore
Backup and restore

Backup and restore functions for the ERDB and other Experion system components are
covered in the Experion Administration and Startup Guide.
CAB and CDB take advantage of the ACE checkpoint and restore functions. See the
Application Control Environment User Guide for information. You can also refer to
“Recover a CAB with checkpoint restore” and “Recover a CDB with checkpoint restore”
in this guide.
ACE shutdown procedure for reclaiming CAB memory

ACE must be shut down and restarted in order to reclaim .NET memory used to hold
obsolete CAB types. (See “Determine ACE shutdown horizon” for a discussion of this
requirement.) The following outlines the procedure that you should use.
Step Action
1 Create an up-to-date checkpoint for the ACE.
2 Use CB to open the ACE configuration form on the monitoring side.
3 Use the CEE Command to set the CEE State to IDLE.
4 Use the ACE Command to set the ACE State to SHUTDOWN.
5 Load the ACE
6 Restore the checkpoint
7 Use the CEE Command to set the CEE State to RUN.
Honeywell 10/04
CAB and CDB troubleshooting and maintenance
Troubleshooting approach
Overview
Debugging takes place in the three stages of CAB and CDB development:
• Development activity in the CB/MSVS/PDE environment.
• Off-process debugging using SIM-ACE (using SIM-ACE is optional but highly
recommended).
• On-process debugging.
These three stages are discussed at an overview level in “Test and debug the CAB.” The
section you are reading now presents more detailed information.
Troubleshooting approaches and tools

This section covers troubleshooting approaches and tools that you can use in
troubleshooting strategies that include CAB and CDB instances. These topics that are
covered are:
• CAB instance states—This topic covers the states that a CAB can be in. You can
monitor the CABSTATE parameter to determine if the CAB is operating normally or
if an exception has occurred.
• CAB alarms—This topic covers the four alarms that are specific to CAB.
• Debug with SIM-ACE—This topic covers the process of debugging a CAB in an
off-process environment using SIM-ACE and the MSVS debugging tools.
• CAB fault handling—This topic contains detailed information about how faults are
handled by CAB infrastructure. It includes a table of CAB faults and error codes. It
also includes a summary of faults that can be prevented by site practices.
Honeywell 10/04
CAB instance states
CAB instance states

Overview
The state of the CAB instance is shown in the CABSTATE FDP, which appears on the
faceplate by default. This section defines the various states and the conditions that cause
the CAB instance to transition from one state to another.
State diagram
All CAB types have the CABSTATE parameter. This parameter provides summary
information on the operating state of the CAB instance. CABSTATE is a view only
parameter. In some cases the operator can affect the value of CABSTATE by writing to
parameter CABCOMMAND.
Behaviors of CABSTATE and CABCOMMAND are illustrated in the following
diagram. Transitions are indicated as either "auto" or "man." Automatic transitions are
triggered automatically by system infrastructure or by actions taken by the CAB
program. Manual transitions are caused by explicit user command.
Honeywell 10/04
CAB instance states
Figure 41 Instance state diagram for FDP CABSTATE
Note that in the above diagram Quit is usually asserted manually. It is possible for Quit to
occur automatically. But this only happens if the CAB type has been programmed to
assert Quit itself.
10/04 Honeywell
CAB instance states
State descriptions
Each value of CABSTATE is described in the following table:
Table 71 CAB instance states
CABSTATE Description
Unloaded CAB instance has been created and is waiting for completion of
program load.
Unloaded is a transient state. It only becomes a persistent state in

the event of a communication or processing error that prevents
program load from completing.
Normal CAB instance is processing the Execute() subroutine whenever its

parent CM is running.
CAB program has been loaded. CAB instance is executing or not,

depending on whether it's parent CM has EXECSTATE = Active.
Data access to FDPs and CDPs is fully operative.
Exception CAB instance is processing the Execute() subroutine whenever its

parent CM is running. An exception is being thrown within
Execute(). An event has been reported.
Program is running and access to FDPs and CDPs is fully

operative. Execute() processing repeatedly results in "throw" of an
unhandled exception. The exception could be caused by a
program defect (for example, integer-divide-by-zero) or by
intentional program action (for example, Abort() function being
called without Catch). Exception reverts to Normal automatically
on the first execution cycle that ceases to produce any unhandled
exceptions. If there is a program defect, the state persists until the
program is corrected and the CAB instance is reloaded.
Depending on design of the CAB type, an event is issued on initial
entry into state Exception. This event remains active until the
state ends or until the parent CM is inactivated. Information on
exception type is available from parameters EXCPTNTYPE and
EXCPTNMSG (see “Detailed description Of CAB specific FDPs”)
whenever CABSTATE = Exception. A program can detect that it is
operating in the Exception state by using the CABSTATE API
(see “Fixed definition parameter CABSTATE”).
Honeywell 10/04
CAB instance states
CABSTATE Description
Terminated CAB instance is not processing the Execute() subroutine. A low

alarm is active.
CAB instance responds to read/write requests for FDPs and

CDPs but is not processing the Execute() subroutine regardless of
the state of its parent CM. Terminated state is only entered as a
result of uncontrolled program execution. Uncontrolled execution
is defined as processing which lasts longer than ½ the ACE base
cycle of 500 milliseconds. Terminated state does not return to
Normal automatically. Instead, either the CAB instance must be
reloaded or the operator must write Run or Quit to
CABCOMMAND. Run causes the CAB instance to resume
Execute() processing but in all likelihood execution will again go
out of control leading to Terminated. A low alarm is issued on
initial entry into Terminated. The alarm remains active until the
state changes to Normal or Dormant, or until the parent CM is
inactivated.
Dormant CAB instance is not processing the Execute() subroutine. No

alarm is active.
CAB instance responds to read/write requests for FDPs and

CDPs but is not processing the Execute() subroutine regardless of
the state of its parent CM. This state is supported to allow an
operator to eliminate alarm noise while waiting for an engineer to
correct program defects. If appropriate to an application,
programs can be written to automatically turn themselves off by
entering this state. System infrastructure never causes an
automatic transition into the Dormant state. A program can place
itself in the Dormant state by using the CABCOMMAND API (see
”Fixed definition parameter CABCOMMAND”).
Be aware that CABSTATE Dormant is completely independent of

the EXECSTATE of the parent CM of the CAB instance. Thus, if
the CAB instance has CABSTATE = Normal and the parent CM
goes through the transition EXECSTATE -> Inactive and then
EXECSATET -> Active, CABSTATE remains Normal. Although
CAB does not execute when EXECSTATE = Inactive, CABSTATE
never goes Dormant in response to a change in EXECSTATE.
10/04 Honeywell
CAB instance states
Transition descriptions
Each possible transition in CABSTATE is described in the following table:
Table 72 Transitions in CAB state
Transition Description
Load Completion Occurs automatically after completing load of the CAB

instance.
Unhandled Exception Occurs automatically if a program defect causes an

exception to be thrown (for example, divide-by-zero error)
or if the program design has intentionally caused an
exception to be thrown without being caught. Use of the
Abort() API without a corresponding Catch causes this
transition.
Exception Clear Occurs automatically on the first processing cycle where

conditions leading to throw of the exception are no longer
present.
Timeout Occurs automatically if program execution lasts longer

than ½ the ACE base cycle of 500 ms.
CABCOMMAND -> Quit Occurs when a human being explicitly commands the
CAB instance to stop executing. This might be done to
eliminate alarm noise if the instance has repeatedly gone
to Terminated, indicating that it is defective and cannot
execute. It might also be commanded when CABSTATE
was Normal or Exception, though this would happen
rarely if ever. Quit could also occur automatically if the
CAB program were designed to cease execution in
response to specific detected conditions.
CABCOMMAND -> Run Occurs when a human being explicitly commands the
CAB instance to resume execution. This would generally
be used when CABSTATE is Dormant. It could be used
when CABSTATE is Terminated. But in that case the
instance would most likely go right back to state
Terminated.
Honeywell 10/04
CAB alarms
CAB alarms
Overview
CAB programs can work in conjunction with other blocks to generate process alarms.
For example, a CAB instance can deliver a computed PV value to a Data Acquisition
block to generate one or more PV alarms. Similarly, it can set the PV value on a Flag
block to generate a discrete alarm.
Beyond this, there are four notifications built into the CAB infrastructure. All of these are
alarms. Two of the notifications are associated with values of CABSTATE. Although
associated with CABSTATE, they are not reported as state change notifications. The
other two notifications are associated with CAB parameter access. These are optionally
enabled at the time the CAB type is designed.
Full notification recovery is supported for each of these notifications without burden on
the CAB programmer. Support is built into the CAB infrastructure. Also, each
notification is implemented so as not to overburden the notification-reporting channel.
After an alarm goes active it is never re-reported until it has returned to normal.
CAB state Terminated

This alarm is reported when the CAB instance execution must be terminated due to
overly long execution. Its priority and severity are instance-configurable using the
TRMNTALM.PR and TRMNTALM.SV parameters (see “Detailed description Of CAB
specific FDPs”). These parameters default to Low priority and 0 severity. The alarm
remains active until the operator changes CABSTATE to Normal or to Dormant.
Information reported with the alarm includes parent CM tag name, CAB instance
descriptor, the condition (shown as "TERMINATED"), and whether the report indicates
alarm or return too normal.
CAB state Exception

This alarm (condition shown as “EXCEPTION”) is reported whenever a CAB instance
incurs an exception. It remains active until the first subsequent execution that incurs no
exception. CAB programs can be designed to induce the Exception alarm under special
conditions. This is described in “Subroutine Abort().” The alarm priority and severity are
configurable using the EXCPTALM.PR and EXCPTALM.SV parameters (see “Detailed
description Of CAB specific FDPs”). This alarm’s priority and severity are instance-
configurable and default to JOURNAL priority and 0 severity. Information reported with
the alarm includes parent CM tag name, CAB instance descriptor, the condition (the
condition value distinguishes the three from one another), and whether the report
indicates alarm or return too normal.
10/04 Honeywell
CAB alarms
Read error
This alarm (condition shown as “READERR”) is optionally enabled at CAB type design
time by setting the default value of parameter READERROPT to Event. The alarm is
reported whenever parameter READSTATUS <> OK. The alarm priority and severity
are configurable using the RDERRALM.PR and RDERRALM.SV parameters (see
“Detailed description Of CAB specific FDPs”). This alarm’s priority and severity are
instance-configurable and default to JOURNAL priority and 0 severity. Information
reported with the alarm includes parent CM tag name, CAB instance descriptor, the
condition (the condition value distinguishes the three from one another) and whether the
report indicates alarm or return too normal.
Write error
This alarm (condition shown as “WRITEERR”) is optionally enabled at CAB type design
time by setting the default value of parameter WRITEERROPT to Event. The alarm is
reported whenever parameter WRITESTATUS <> OK. The alarm priority and severity
are configurable using the WRTERRALM.PR and WRTERRALM.SV parameters (see
“Detailed description Of CAB specific FDPs”). This alarm’s priority and severity are
instance-configurable and default to JOURNAL priority and 0 severity. Information
reported with the alarm includes parent CM tag name, CAB instance descriptor, the
condition (the condition value distinguishes the three from one another) and whether the
report indicates alarm or return too normal.
Honeywell 10/04
CAB alarms
FDPs that capture exception information

CAB infrastructure includes three FDPs that can assist in debugging code that is causing
exceptions. The three parameters are:
• EXCPTNLINENM— Contains the source file name and source line number of the
function executing on the last exception incurred by CAB program.
• EXCPTNMODULE— Contains the name of the function executing on the last
exception incurred by CAB program.
• EXCPTNMSG— Publishes descriptive information on the last exception incurred by
CAB program.
• EXCPTNTYPE—When CABSTATE=Exception, EXCPTNTYPE contains a string
indicating the type of exception that has been thrown. Refer to the detailed
description for the format and examples.
For detailed descriptions of these parameters, see “Detailed description Of CAB specific
FDPs.”
TIP
These parameters only show the exact information about the exception when
the program was built to the Debug target.
10/04 Honeywell
Debug with SIM-ACE
Debug with SIM-ACE

Overview
Simulation ACE (SIM-ACE) is the ACE application in simulation mode (it is not a
separate application). It allows you to run a debug version of a CAB application in a
defined strategy in an off-process environment.
The MSVS debugger

The MSVS debugger is a powerful tool that allows you to observe the run-time behavior
of your program and determine the location of coding errors. Historically, many
programmers debugged their software by incorporating output functions such as print or
MsgBox at various points in the code to provide visibility into the code operation. CL
programmers have used Send statements or writes to CDS parameters for the same
purpose. While this can be an effective technique, it is cumbersome to add the additional
code and then to remove it when debug is complete. And, there is always the risk that the
added code will affect the operation of the program.
Using the MSVS debugger, you can monitor the variables in your program without
adding special debugging code. You can insert breakpoints to freeze code execution at
points of interest. When the program is halted in the break mode, you can view local
variables and other relevant data using MSVS facilities such as Watch Window,
QuickWatch Dialog Box, and Memory Window. You can even edit your code and
change variable values when halted at a breakpoint.
Scope
This guide contains only an outline of how to use SIM-ACE. For detailed information,
refer to the Simulation ACE User Guide. Similarly, this guide does not cover the details
of using MSVS, including using the debugger capabilities. Refer to the Microsoft Help
for these details. For example, in MSVS choose Help > Contents. Choose Visual Basic
from the Filtered by list. Navigate as follows: Visual Studio.NET > Developing with
Visual Studio.NET > Building, Debugging and Testing > Using the debugger as
shown in the following figure:
Honeywell 10/04
Debug with SIM-ACE
Figure 42 MSVS help contents
This would be a good place to start when looking for general information about using the
debugger.
10/04 Honeywell
Debug with SIM-ACE
Basic characteristics of SIM-ACE

• A dual processor node will support up to four SIM-ACEs. A single processor ACE
node will support up to two SIM-ACEs.
• The SIMENABMLE parameter in the CEEACE FB determines whether the ACE is
in the ACE or SIM-ACE mode (TRUE = SIM-ACE mode).
• Only one MSVS debug session at a time can be attached to a SIM-ACE for CAB
debugging. Refer to Step 7 in the procedure in “Setup procedure for CAB debugging
on SIM-ACE” for information about detecting that another user has a debugger
attached to the SIM-ACE and determining who that user is.
ATTENTION
Attach the debugger ONLY to ACE.exe. Do not attach the debugger to any
other process on the same node or on a remote node. If you attach to another
process, the process might crash when you terminate the debugging session
resulting in loss of view or other undesirable consequences.
ATTENTION
Attach the debugger to nodes that will be used as SIM-ACE. Do not attach the
debugger to ACE nodes that are on process. See the discussion in “Security
policy.”
Setup procedure for CAB debugging on SIM-ACE

The following procedure outlines the steps required to initiate a debug session on ACE
using the MSVS debugger with a CAB that is built to the debug target.
ATTENTION
You must have proper privileges to run debugger on ACE. See Establishing a
User account for SimACE to establish the proper User account.
Table 73 The Procedure to attach the MSVS debugger to ACE
Step Action
1 Build a debug version of your CAB and save to ERDB. Leave MSVS open.
Honeywell 10/04
Debug with SIM-ACE
Step Action
2 Note: ACE.exe must not be running before configuring and loading as SIM-
ACE.
Open the properties form for the CEEACE FB and check the SIMENABLE
option on the Main tab. Close the form.
3 Load and activate SIM-ACE, CEE, and the CM with CAB block instance.
4 If you have more than one SIM-ACE configured, you need to determine the
process ID for the one that has your CAB. In the monitor view, right click on
the CEE that contains your CAB and choose Module Properties.
Note the process ID (2524 in the figure below). Close the form.
5 With an edit session open for your CAB, choose Debug > Processes from the
MSVS menu.
10/04 Honeywell
Debug with SIM-ACE
Step Action
6 Make sure that the Show system processes checkbox is checked.
Browse for the name of the remote machine in your network where the SIM-
ACE is running. If you have more than one ACE running, select the one with
the ID that matches the Process ID you determined in Step 4. Click Attach.
Honeywell 10/04
Debug with SIM-ACE
Step Action
7 If the ACE.exe process is unavailable (dimmed), it indicates that another user
has a debug session attached to the ACE. You can determine the name of
that user’s computer by collapsing the Title field to expose the right portion of
the ACE process line, as shown in the following figure.
8 Choose Common Language Runtime program type. Click OK.
10/04 Honeywell
Debug with SIM-ACE
Step Action
9 Now you can set a breakpoint in your CAB program. Note that CB will show
SIM-ACE and everything running on it on the monitor view in red when the
program sits on the breakpoint.
Note: Since CB will not respond when breakpoints are set, you must change
input values in the MSVS environment (see “Tips for using MSVS with SIM-
ACE”).
10 When you are through debugging, choose Debug > Stop Debugging.
Tips for using MSVS with SIM-ACE

• You can step through your code using step buttons with the Debug toolbar displayed.
• You can view or change values of CDPs defined for the CAB within the
Auto/Locals tabs.
• You can also view or change values in the Command Window.
Honeywell 10/04
CAB fault handling
CAB fault handling

Principles
The CAB system incorporates built-in fault handling to insure that you can produce safe
behavior of control applications at run time. Some of the key principles are:
• A run-time fault detected by a CAB instance impacts only that instance and does not
impact any other block instance.
• External process and system disruptions are normal. Conditions such as process
variable over range, external node failure, or inter-node communication failure do not
cause CABs to stop executing. Instead, they optionally report a notification, continue
to execute, and clear the notification after the disruption goes away.
There are a wide variety of faults that can affect CAB programs. Overall system
detection and response is implemented within multiple subsystems. Some faults are
detected and handled at execution time. Others are detected before execution occurs and
are prevented.
Function limiter and supported namespaces

The function limiter in CAB will catch code that is not allowed and will display an error
message in the output window within the CAB Developer environment (Microsoft Visual
Studio IDE). CAB does not support declare statements that allow you to access functions
in external DLLs. The namespaces and classes in the following table are supported and
enforced within the CAB Developer environment. Function limiter catches code that is
not allowed; that is, use of classes not listed in the table.
Supported namespaces and classes

Figure 43 .NET constructs allowed for CAB applications
Functional Area .NET Namespace Class Method
Structure
Visual Basic .NET Microsoft.VisualBasic Collection, Constants, any

run-time library ControlChars,
Conversion,
DateAndTime,
ErrObject, Financial,
Globals, Information,
Strings, VbMath
10/04 Honeywell
CAB fault handling
Structure
.NET run-time Microsoft.VisualBasic. any any

Compiler Services. CompilerServices
The Visual Basic
compiler requires System.Runtime.Com
this. pilerServices.Runtime
Helper
Fundamental .NET System Any Exception class, any

Classes and Array, BitConverter,
Structures Buffer,
CharEnumerator,
Convert, DBNull,
Enum, Environment,
EventArgs, Math,
Object,
OperatingSystem,
Random,
ResolveEventArgs,
String, TimeZone,
Type, ValueType,
Version
ArgIterator, Boolean,
Byte, Char, DateTime,
Decimal, Double,
Guid, Int16, Int32,
Int64, SByte, Single,
TimeSpan, UInt16,
UInt32, UInt64
ICloneable,
IComparable,
IConvertible,
ICustomFormatter,
IDisposable,
IFormatProvider,
IFormattable
Various Collections System.Collections any Any

Classes
Various Specialized System.Collections.Sp any any

Collections Classes ecialized
Honeywell 10/04
CAB fault handling
Structure
Type converters System.ComponentM Any Type Converter any

odel class
Performance Data System.Diagnostics Any Counter class, any

Any InstanceData
class, Any
PerformanceCounter
class
CounterSample
Debug help System.Diagnostics Debug Close, Flush, Indent,

Unident, Any Write
methods
Culture-related System.Globalization any any

information
Text and String System.Text any any

manipulate classes
.NET regular System.Text.RegularE any any

expression engine xpressions
Summary of fault handling

The following table summarizes information about CAB faults. The information is
organized around two fundamental items:
• Fault Cause.
• Fault Detection and Response.
The table covers faults specific to CAB. There are various types of instance configuration
faults that CABs have in common with native blocks. These are discussed elsewhere
within Experion documentation.
10/04 Honeywell
CAB fault handling
Table 74 Summary of CAB fault handling
Fault cause Fault detection and Examples Comments

response
Attempt to use Detection at program Use of programming After a CAB has been
programming build time leading to statements that attempt built in Visual Studio
construct CAB “compiler” error. to access the system with no error, the CAB
inappropriate to registry. will scan the user’s
control mission. program verifying that
Invocation of graphical the constructs used are
user interface services. appropriate for process
control. Any
Attempted file access
inappropriate constructs
under atomic execution.
found are presented to
Attempted use of thread the user as CAB
scheduling services. “compiler” error and
must be removed
Attempted use of OS before the user’s
timer utilities for CAB program can be built
program execution successfully. This
scheduling. feature, however, may
not flag every construct
that is detrimental to
process control and
therefore, site
practices must also be
in place to prevent
this fault category.
The consequence of not
preventing a specific
construct varies
depending on the
particular fault caused.
In some cases they
might be as bad as
crash of the entire CEE.
In some cases they
might be detected and
neutralized by the long
execution time-out built
into the CAB
infrastructure.
Honeywell 10/04
CAB fault handling

response
Attempt to load Detection at program Communication error The fault is detected at

program in load time leading to occurs during load the time the CAB type is
presence of reject. causing timeout or loaded to the CEE. The
communication or packet corruption. program load is
resource error. rejected. Note that
Resources reserved for program load happens
CAB programs are implicitly when user
exceeded during the commands instance
course of program load. load if the program is
not already present
within the CEE.
Attempt to load Detection at instance Loading a block The fault is detected at

block instance in load time leading to instance with a the time the CAB
presence of reject. configuration parameter instance is loaded to the
configuration or assigned to a value CEE. The instance load
resource error. outside the allowed is rejected. Users will be
range defined for the forced to correct the
block type. error and reload the
instance.
Loading a block when a
memory resource limit
has been exceeded..
Attempt to execute Detection at run time Parameter store check Data access errors
in presence of data signaled by status fails at target block. cause program
access error. information readable status to be
and optional event. Indexed parameter on set without causing
external block is program execution to
accessed with out-of- cease. The degree to
range index. which these errors are
detected and managed
Parameter is accessed
within the CAB program
on external block that
is a decision made by
no longer exists.
the program designer.
Target block is not Data access errors also
loaded. cause status feedback
to the operator and
Host node of target optionally enabled
block has failed. events. See additional
comments on
Communication link to “Parameter access
target node has failed. faults” after this table.
10/04 Honeywell
CAB fault handling

response
Attempt to execute Detection at runtime Algorithm design is This type of algorithmic

in presence of short signaled by flawed and causes defect is detected by
duration algorithmic exception. integer-divide-by-zero. language runtime
design defect. See additional support. It causes an
comments on Divide- exception to be thrown
by-zero handling after which halts the current
this table. cycle of program
execution. Program
Algorithm design execution is attempted
causes out of range again on the
index to be used on subsequent cycle. See
array local to the CAB. comments on
“Exception handling”
Algorithm design
after this table.
causes excessive
function call recursion
leading to stack
overflow. See additional
comments on
Unbounded recursion
after this table.
Attempt to execute Detection at runtime Algorithm design This type of error is

in presence of long leading to causes loop execution detected by a CEE
duration algorithmic termination. which prolongs block monitoring service. It
design defect. execution for ½ base causes program
cycle or longer. execution to be
terminated. Execution
Function call recursion does not resume until
prolongs block the CAB is taken out of
execution for ½ base the terminated state by
cycle or longer. See explicit human
Unbounded recursion intervention. Both
after this table. engineer and operator
access rights are
sufficient to restart the
block. See comments
on “Overlong
execution” after this
table. Also see “Loops
In "Catch" Or "Finally"
clauses.”
Honeywell 10/04
CAB fault handling

response
Attempt to have Detection at runtime One ACE has multiple This restriction is to
more than 101 off- signaled by exception CAB instances that prevent CAB from
node, peer-to-peer if the have a total of more exhausting the ACE
parameter WRITEERROPT than 101 peer-to-peer cyclic store resources.
reference stores in value is set to Event. parameter references This applies only to off
an ACE node, peer-to-peer
stores. If this limit is
exceeded, the user
block code will receive a
store limit exceeded
status on the offending
parameter(s).
Parameter access faults

CAB infrastructure supports detection of parameter access faults in two ways:
information provided to the CAB program, and information provided to the operator.
For the program, the APIs "ReadStatus" and "WriteStatus" are provided for each
parameter reference. This information can be used or ignored by the CAB programmer.
CAB infrastructure itself never aborts program execution or throws an exception in
response to a parameter access error. If this behavior is desired, it must be deliberately
designed into the program. Further information on the status APIs may be found in
section “Detailed description Of CAB specific FDPs.”
For the operator, two FDPs are supported: READSTATUS and WRITESTATUS.
READSTATUS normally shows OK. If a read error occurred on the last execution,
READSTATUS shows the first non-OK status encountered during execution.
WRITESTATUS behaves analogously for parameter writes. Two other parameters,
READERROPT and WRITERROPT, allow CAB types to report events in response to
read or write errors. For further information on READSTATUS, WRITESTATUS,
READERROPT and WRITEERROPT, see the section “Detailed description Of CAB
specific FDPs.”
Divide-by-zero handling
System treatment of divide-by-zero is different depending on whether the numbers are
integer or floating point. The former causes an exception to be thrown. The latter
continues processing as normal. The reason for the difference is that, unlike integers,
10/04 Honeywell
CAB fault handling
IEEE 754 floating-point numbers have a representation for infinity. This allows for
consistent handling of floating-point divide-by-zero without the use of an exception.
Unbounded recursion
There are two possible responses to an unbounded recursion: throw exception, or
terminate. In general, it is not possible to predict ahead of time which of these will occur.
It depends on how the program is implemented and whether or not available stack would
be exhausted before expiration of ½ base cycle duration.
Exception handling
Some faults are detected by language run-time services, causing an exception to be
thrown. Response to the exception varies depending on how the CAB program has been
written.
If an exception handler has been provided within user-written code, it catches the
exception and continues processing according to its own design. It may cause the
program to run to completion or it may break program execution early. If program
execution breaks for the current cycle, it starts fresh at the next execution cycle.
If the program does not contain a user-written handler to catch the exception, then
exception handling is provided by system code. Default system behavior is to cause
program execution to break and then start fresh at the next execution cycle. After
program execution has been broken, parameter CABSTATE is set to Exception. This
allows the abnormal state to be read by the operator in cases where an exception fires
repeatedly. In addition, system implementation causes an event to be reported under the
name of the CAB instance and its CM parent. For further information on CABSTATE
and the exception event see “CAB instance states.”
Overlong execution
CEE has a built-in monitoring service that allows CAB programs to use, at most, ½ of the
base cycle time. If execution of an individual CAB instance exceeds this duration,
execution is stopped, the CABSTATE is set to Terminated, and an alarm is reported. The
block instance never runs again until it is restarted by a human being. After it is restarted,
the alarm and state parameter return to normal. For further information on CABSTATE
and the long execution alarm, see “CAB instance states.”
Honeywell 10/04
CAB fault handling
Loop overrun detection is done on the basis of CAB instances rather than on CAB types.
Thus, if a given instance uses a flawed program and has data conditions that allow the
flaw to be triggered, it is taken out of service. If another instance uses the same program
but does not have data conditions that trigger the defect, it is not taken out of service.
In some cases, an individual block using ½ the duration of the base cycle will be enough
to cause a control processing cycle overrun. Forcing the block into a termination state
prevents this from happening repeatedly.
Loops In "Catch" Or "Finally" clauses

CEE uses .NET thread abort services to terminate a block that has executed too long.
Characteristics of these services make it impossible for CEE to terminate a block under
certain unusual circumstances. In particular, a block cannot be terminated if it is looping
within the Catch or Finally clauses of a "Try" statement. It is recommended that site
practices forbid the use of loops within Catch or Finally clauses. The need for such loops
does not arise within CAB control programs.
Site responsibilities in CAB fault handling

There are some types of faults that must be prevented by site practices. These are
summarized in the following table.
10/04 Honeywell
CAB fault handling
Table 75 Summary of site responsibilities for fault handling
Fault cause Specific case Additional information
Attempt to use Use of any programming See the first row of Table 74 Summary of
programming construct that accesses CAB fault handling.”
construct disk.
inappropriate to
control mission. Use of any programming
construct that uses
command line monitor input
or output.
Use of any programming

construct that uses
Graphical User Interface.
A list of specific .NET

constructs that should not
be used in CEE control
applications is given in the
table below.
Attempt to execute in Use of loops in "Catch" or See the last row of Table 74 Summary of
presence of long "Finally" clauses CAB fault handling..
duration algorithmic
design defect.
Attempt to allocate Static allocation of very The majority of excessive memory

large amounts of data. large data structure such as allocations would cause an
an array. Dynamic data OutOfMemoryException to be thrown if
structure growth such as sufficient memory resources are not
calls to ‘new’ in a loop. available. The OutOfMemoryException
error is detected by a CEE monitoring
service. It causes program execution to be
terminated. Execution does not resume
until the CAB is taken out of the
terminated state by explicit human
intervention. Both engineer and operator
access rights are sufficient to restart the
block.
Honeywell 10/04
CAB fault handling
The table below lists .NET constructs that are allowed in CEE control applications. Note
the explanatory items at the end of the table.
Table 76 .NET constructs appropriate to control mission
Functional area .NET namespace Class structure Method
Visual Basic .NET run- Microsoft.VisualBasic Collection, Constants, any

time library ControlChars,
Conversion,
DateAndTime,
ErrObject, Financial,
Globals, Information,
Strings, VbMath
Visual Basic .NET run- Microsoft.VisualBasic. any any

time Compiler CompilerServices
Services. The Visual
Basic compiler
requires this.
10/04 Honeywell
CAB fault handling
Fundamental .NET System Any Exception class, any

Classes and Array, BitConverter,
Structures Buffer,
CharEnumerator,
Convert, DBNull,
Enum, Environment,
EventArgs, Math,
Object,
OperatingSystem,
Random,
ResolveEventArgs,
String, TimeZone,
Type, ValueType,
Version
ArgIterator, Boolean,
Byte, Char, DateTime,
Decimal, Double,
Guid, Int16, Int32,
Int64, SByte, Single,
TimeSpan, UInt16,
UInt32, UInt64
ICloneable,
IComparable,
IConvertible,
ICustomFormatter,
IDisposable,
IFormatProvider,
IFormattable
Various Collections System.Collections any any

Classes
Various Specialized System.Collections.Sp any any

Collections Classes ecialized
Type converters System.ComponentM Any Type Converter any

odel class
Honeywell 10/04
CAB fault handling
Performance Data System.Diagnostics Any Counter class, any

Any InstanceData
class, Any
PerformanceCounter
class
CounterSample
Debug help System.Diagnostics Debug Close, Flush, Indent,

Unident, Any Write
methods
Culture-related System.Globalization any any

information
Text and String System.Text any any

manipulate classes
.NET regular System.Text.RegularE any any

expression engine xpressions
• When just the namespace is specified, the user can use any construct (class,
structure, etc.) in this namespace.
• When items are listed in the Class/Structure column, just those classes and structures
specified in that namespace can be used by the programmer. For example, the class
System.Int32 can be used, but System.IntPtr cannot.
• When items are listed in the Method column, just those metheds specified for that
class in that namespace can be used. For example, the method
System.Diagnostics.Debug.WriteLine can be used, but
System.Diagnostics.Debug.Assert cannot.
CAB error reporting

System infrastructure reports CAB related errors in several different ways. Error
reporting can vary depending on where the error is detected within the CAB life cycle.
The table below shows how users learn of errors depending on the phase of the CAB life
cycle. See “CAB and CDB error messages and codes” for exact error messages and
possible workarounds.
10/04 Honeywell
CAB fault handling
Table 77 Techniques for reporting CAB errors
Phase of Where error Information is reported

detection
Type creation Errors such as source code syntax errors are reported directly in Microsoft
time Visual Studio .Net 2003.
Errors related to commissioning the CAB type within ERDB are reported by CB
as they occur.
Errors related to commissioning the CAB type within ERDB are also recorded
within the EPKS error log files. These files have the name "ErrLog_n.txt" where
n is an integer. They can be found in folder "c:\Documents and Settings\All
Users\Application Data\Honeywell\Experion PKS".
Instance Errors related to the process of converting CAB instances to a different type are
conversion time reported by CB as they occur.
These errors are also recorded in the Experion error log files.
Instance Errors related to the process of configuring CAB instances are reported by CB
configuration as they occur.
time
Instance Errors related to the process of assigning the CM parent of CAB instances are
assignment time reported by CB within error dialogs as they occur.
Instance load Errors related to the load of CAB instances and to the load of the CAB
Time programs associated with the instances are reported by CB as they occur.
Program Program defects that result in throw of an exception that is not caught by user
execution time written code are reported by issuing an event and by setting parameters
CABSTATE, EXCPTNTYPE and EXCPTGNMSG.
Program defects that result in excessive execution time are reported by issuing
an alarm and by setting parameter CABSTATE.
Parameter access errors are reported in parameters READSTATUS and

WRITESTATUS and are also reported as events depending on the design of
the CAB type.
Operations Time Errors that result from attempts to store inappropriate values to CAB
parameters are reported by Experion Station with a status indication at the time
they occur.
Honeywell 10/04
CAB fault handling
Phase of Where error Information is reported

detection
Export / Import Errors detected at import are reported within the error log files.
Time
Informational messages associated with import that are not errors are reported
within a supplementary log file. This file is called "IXP_Log.txt" and may be
found in folder "c:\Documents and Settings\All Users\Application
Data\Honeywell\Experion PKS".
The following table provides examples of CAB error conditions that are detected by the
system. It indicates how the user is informed of the error and recommends a user
response.
Table 78 CAB error type examples and recommended actions
Phase of Type of error System response Recommended user

detection action
Type creation User attempts to open CB presents error If it is only desired to

time a CAB type for edit message indicating that view the type, open with
while it is under edit by operation is disallowed the View command. If it
another engineer. and why. is desired to edit the
type read EDITLOCK to
identify the engineer
who is editing the type.
Contact the engineer.
EDITLOCK may be
viewed by opening the
CAB form from the
library tree.
See Note 2.
Type creation Program source code MSVS reports build errors. If meaning of error is
time has compile errors. See Note 3. unclear consult MSVS
help documentation.
Correct error, rebuild.
Type creation User attempts save of MSVS presents error Use Save As to save
time pre-existing type to message with options to type with a different
ERDB after deleting or Save As or Cancel. type name and/or library
modifying a parameter name. Later, convert
definition. existing instances to
new type.
See Note 4.
10/04 Honeywell
CAB fault handling

detection action
Instance User attempts CB presents error Cancel the convert

conversion time conversion of existing message. operation. Remove
instance to a modified connection that
type after parameter references the
deletion. A deleted parameter that has
parameter has been been deleted. Re-
referenced in instance attempt conversion.
connections.
See Note 4.
Instance User attempts The value (name / On the project side,

conversion time conversion of existing address of referenced modify the block.param
instance with parameter) of the PRef is values that the PRef
parameter references retained even if the user instance is pointing to.
to a different instance has changed the data type
with parameter of the PRef at the CAB
references pointing to type that is the destination
data that is a different of the convert operation.
data type. On a read of the
converted PRef type, the
FailSafe value will appear.
On a write of the
converted PRef type, the
FailSafe value will appear
in the block.param that the
PRef is pointing to.
Instance User attempts to point CB presents error Change parameter

configuration a parameter reference message indicating that reference to point to a
time to a parameter of operation is disallowed parameter of supported
unsupported data type and why. data type.
such as STRUCT.
See Note 5.
Instance User attempts to CB presents error Assign CM to an ACE

assignment time assign a CM message indicating that platform.
containing a CAB operation is disallowed
instance to a platform and why.
that does not support
CAB.
Honeywell 10/04
CAB fault handling

detection action
Instance load User attempts to load CB presents error User can see that value
time an instance whose message indicating that of parameter
CAB type has not been operation is disallowed INCOMPLETE is On by
successfully built. and why. opening the CAB form
from the library tree.
User must rebuild CAB
type.
See Note 2.
Instance load User attempts to load CEE returns parameter Load instance to ACE
time an instance to an ACE access error on load. platform which has CAB
for which the CAB run- CABSTATE shows value run-time.
time license has not Unloaded.
been purchased.
Instance load Communication failure CEE returns parameter Repeat instance load.
time occurs during load of access error on load.
CAB program. CABSTATE shows value
Unloaded.
Instance load User assigns CEE returns parameter Change CDP

time configuration CDP with access error on load. configuration value in
value outside the instance or modify CAB
defined range. type to support wider
configuration range.
Program Parameter reference CEE returns data access Load the missing block
execution time points to local block error to complete
that has not been (CABAccStatusEnum. configuration of the
loaded. ConfigurationMismatch) to overall control strategy.
CAB instance. CAB
program responds as
designed. Error
information is posted in
parameter READSTATUS
or parameter
WRITESTATUS.
Depending on design of
the CAB type an event
may be reported. See
Note 1.
10/04 Honeywell
CAB fault handling

detection action
Program Parameter reference CEE returns data access Fix the node that has
execution time points to remote block error failed.
in node that has failed. (CABAccStatusEnum.
CommFail) to CAB
instance. CAB program
responds as designed.
Error information is posted
in parameter
READSTATUS or
parameter
WRITESTATUS.
Depending on design of
the CAB type an event
may be reported. See
Note 1.
Program Program has been CEE puts CAB instance Operator responds as
execution time designed to invoke the into state Exception. directed by defined
Abort() subroutine in Parameter CABSTATE operational practices for
response to a run-time has value Exception. the site.
detected error Parameter EXCPTNTYPE
condition. has the value
"Honeywell.CAB.AbortExc
eption". Exception event is
active. See Note 6.
Program Program has defect CEE puts CAB instance Operator may change
execution time that causes exception into state Exception. CABSTATE to Dormant
to be thrown. Parameter CABSTATE to cause the event to go
has value Exception. inactive. CE should
Exception event is active. correct program defect
Parameter EXCPTNTYPE and reload instance.
contains a string that
indicates the type of
exception. For example,
for an integer-divide-by-
zero error EXCPTNTYPE
would contain
"System.OverflowExceptio
n". See Note 6.
Honeywell 10/04
CAB fault handling

detection action
Program Program has defect CEE puts CAB instance Operator may change
execution time that causes overly long into state Terminated. CABSTATE to Dormant
execution. Parameter CABSTATE to eliminate alarm
has value Terminated. noise. CE should
Terminated alarm is correct program defect
active. and reload instance.
Operations time Operator stores CEE rejects the store and Store correct value or
inappropriate value to returns status code. wait for CAB instance to
FDP or CDP. enter a state when the
store can be accepted.
Export / Import Import of CAB type is CB automatically changes Inspect library name
time attempted when library name and places after import. If desired,
identical library name status message in error modify the automatically
and type name are log. assigned name to a
already used within preferred name.
target ERDB.
See Note 7.
Export / Import Import of CAB instance CB reports error and fails Go back to system from
time is attempted when the import. which CAB instance
corresponding type was exported. Repeat
was not included with the export including the
the export files and is CAB type. Go to target
not already in ERDB. system. Repeat the
import.
See Note 7.
Note 1
Parameter access errors are returned to the CAB program at run time as members of
enumeration CABAccStatusEnum. This is further discussed in “Enumeration
CABAccStatusEnum.” Also, see description of parameters READSTATUS,
WRITESTATUS, READERROPT and WRITEERROPT in “Detailed description Of
CAB specific FDPs.”
Note 2
Block type locking flags are discussed in “Block type locking flags.”
Note 3
All VB.NET compile errors are documented within MSVS.
10/04 Honeywell
CAB fault handling
Note 4
Procedures involved in the modification of CAB types are discussed in “Modify a CAB.”
Note 5
Data types supported by CAB parameter references are discussed in “Data types for
CDPs and parameter references.”
Note 6
CABSTATE and related functionality is discussed in “CAB instance states.”
Note 7
Import of CAB types is described in “Import CAB.”
Honeywell 10/04
CAB fault handling
CAB and CDB error messages and codes

This section covers errors that occur in MSVS. The table below summarizes these errors,
which can appear in pop-up dialog boxes or other MSVS windows. These errors are not
identified by error codes. There are other errors detected by Honeywell code that are
identified by error codes, and they are documented in the Control Builder Error Codes
Reference. You can do a search for the error code number in Knowledge Builder to locate
information about the error.
In addition, you might see MSVS compiler errors that are identified by Microsoft error
code numbers. These are documented in MSDN.
TIP
You can select a Microsoft error code number and press F1 to bring up MSDN
help.
If any of these errors occur, please contact your TAC representative if the workaround
provided is not sufficient.
Table 79 CAB/CDB error messages
Error type VS CAB build-time pop-up dialog
Error message Warning: Data Type of Parameter LOADDATA1 does not match the selected
block.
Description Indicates that during a Convert operation, the LOADDATA1 parameters of the
instance you are converting, and the type you are converting from, do not
match. The LOADDATA1 parameter is an internal parameter that contains the
CAB program (dll) when the program is built.
Cause If you use the Function Block Convert to convert a CAB type to another CAB
type and the new CAB type is in an incomplete state, you will get this warning in
the Convert dialog. You will get the same error in the case where you have a
CAB instance that is incomplete and now you convert it to a CAB type that is
complete.
Workaround It will convert okay and the result will have the Incomplete Lock set.
10/04 Honeywell
CAB fault handling
Error message <CAB name> is being used by <Machine name/ User name>.
The CAB type is locked either by an open project chart, configuration form, or
an Import/Export operation by the user named in the message above. Do you
want to correct the problem before continuing? If you select "No", you will need
to contact your administrator to clear this CAB's Active Lock before it can be
used again.
Description This indicates that the database has locks set related to the CAB type.
Cause DB locks are set by a chart being open, a properties form open, or
import/export by another user when attempting to do a Save As to ERDB
operation or the user is exiting Visual Studio and is saving their data to the
ERDB.
Workaround You will need to either release the DB lock (or have the user that has the DB
lock release it) by finding the operation that has it locked (e.g. close a chart or
properties form, wait for export to finish) and try the operation again. If you do
not do this, you will need to have the lock removed later by an Admin using the
DBAdmin tool.
Error message The EditLock value cannot be reset. You will need contact your administrator
to clear the EditLock from this CAB. You will not be able to reedit this CAB until
this is done.
Description It means that a serious failure occurred while trying to reset the Edit Lock.
Cause Failure with Honeywell code.
Workaround You can contact TAC and provide the error logs to find out why the Edit Lock
could not be reset. You can have the admin reset the Edit Lock by using the
DBAdmin tool.
Honeywell 10/04
CAB fault handling
Error message The EditLock value for <block name> in <library name> cannot be reset. You
will need to contact your administrator to clear the EditLock from this CAB. You
will not be able to reedit this CAB until this is done.
Description This is the same as the previous only on a Save To ERDB As operation.
Cause Failure with Honeywell code.
Workaround You can contact TAC and provide the error logs to find out why the Edit Lock
could not be reset. You can have the admin reset the Edit Lock by using the
DBAdmin tool.
Error message An unexpected error occurred within the CAB Development Environment.
Please contact your Honeywell representative.
Description Error in CAB edit session.
Cause This indicates that a serious problem occurred.
Workaround You should contact TAC and provide the ErrorLog file.
Error message An unexpected error occurred within the CAB Development Environment and it
will be closed. The Development Area is <Development Area Path>' and
contains this project and will not be deleted. Please contact your Honeywell
representative.
Description Error in CAB edit session.
Cause This indicates that a serious error occurred.
Workaround There probably are changes that were not saved to the ERDB. The Build
Directory will be left with the modified def files and programs. You should
contact TAC to investigate the problem. The Error Log will show more detailed
information for TAC.
10/04 Honeywell
CAB fault handling
Error message <New block name> is an invalid name or is already being used in <library
name>.
Description Invalid name for CAB block was entered.
Cause Indicates on a Save As to ERDB, that you entered a name that is already used
or the name and/or library has invalid characters in it.
Workaround See “Open a new CAB block type for edit” for proper naming conventions
and/or check to make sure the CAB name isn’t already being used.
Error message This command is not available when editing a CABlock.
Description CAB edit session VS message.
Cause You tried to do an operation that is not allowed. (for example, adding a
reference).
Workaround Do not attempt VS option.
Error type VS CAB build-time “Compiler” error shown in the Task List and Output Window.
Error message CAB Error: Not allowed to use <class or method name>.
Description Inappropriate construct for process control.
Cause You are trying to use a class or method not appropriate for process control.
Workaround Do not use this class or method. Click on the Task List item to take you to the
construct that is not allowed. Building the CAB will not be successful until all
inappropriate constructs are removed. If you believe that this construct is
appropriate for process control, you need to contact TAC.
Honeywell 10/04
CAB fault handling
Error message CAB Error: Not allowed to Declare references to external procedures.
Description Using Declare Statement.
Cause You are trying to use the Declare statement to access external procedures.
This is not allowed.
Workaround Do not use the Declare statement. Click on the Task List item to take you to
the approximate area where the Declare statement is located. Building the
CAB will not be successful until all Declare statements are removed. Any
procedures that you want to access must be part of the CAB.
Error message Ildasm.exe has generated errors and will be closed by Windows. You will need
to restart the program.
An error log is being created.
Description Error occurred during a build of a CAB.
Cause This indicates that a serious problem occurred with the .Net Framework.
Workaround You should contact TAC.
Error message <cdpname>.Value: Value of type ‘<VBDataType>’ cannot be converted to

Honeywell.CAB.BlockMap.<CABDataType>CDP.
Description Syntax error
Cause You failed to add “.Value” to a CDP name when referencing its value.
Workaround Add “.Value” to the CDP name and rebuild.
10/04 Honeywell
CAB fault handling
Error message <prefname>.Value: Value of type ‘<VBDataType>’ cannot be converted to

Honeywell.CAB.BlockMap.<CABDataType>PRef’
Description Syntax error.
Cause You failed to add “.Value” to a PRef name when referencing its value.
Workaround Add “.Value” to the PRef name and rebuild.
Honeywell 10/04
Contacting TAC
Contacting TAC
Overview
If you encounter a CAB or CDB problem that you cannot resolve it using the
documentation, you will need to contact TAC. This section lists the information required.
Information required for build-time problems

1. Provide the ErrLog.txt from both the client (where the error was returned) and the
server. This is located under "Documents and Settings/AllUsers/Application
Data/Honeywell/Experion PKS."
2. If the error indicates that the files were left in the Build Directory and a path is
given to this directory, these files are needed. They will be in a directory
"Documents and Settings/<user id>.Application Data/Honeywell/Experion
PKS/Engineering Tools/CAB/Build/<GUID>"
3. Export the CAB Type that for which the error occurred and provide these files.
4. Include an exact description of what the user was doing and the replies by the user
to any prompts that were displayed.
5. Provide any Event Messages in the Event Viewer.
6. Provide the exact error that was displayed to the user.
Information required for run-time problems

1. Provide the CAB log file from the ACE server. This is located under "Documents
and Settings/AllUsers/Application Data/Honeywell/Experion
PKS/CAB/Trace/<ACE server name>/CABBlockManager_x_y.txt.” The “x” and
“y” are unimportant - just whatever trace file is there. If there is more than one,
provide all.
2. Export the CAB Type(s) that might be involved in the error, along with the CM that
the CAB instance(s) are in, and provide these files. Some users may be unwilling to
send the types and CMs for security and/or proprietary reasons.
3. Provide any Event Messages in the Event Viewer.
4. Provide the exact error that was displayed to the user.
5. It may be necessary for TAC to get involved to enable the internal CAB tracing that
is available. The users are not informed on how to enable this feature.
10/04 Honeywell
Contacting TAC
Honeywell 10/04
CAB API reference
Overview
The overall CAB map
Figure 44 below is a map of the overall CAB API. The CAB type is shown in the center
of the diagram. Solid arrows indicate that CAB types have a general dependence on the
designated elements. The dashed arrow from the CAB box to the BlockBase box
indicates a particular kind of dependence—that class CAB inherits from class BlockBase.
Figure 44 Overall map of CAB API
10/04 Honeywell
CAB API reference
APIs supplied from CAB to system
The overall API can be broken down into three areas:

• Elements supplied by the CAB type to the system.
This is shown near the center of the map and consists of the class CAB along with the
subroutine Execute().
• Elements supplied by the system infrastructure to the CAB type.
This is shown by the four largest boxes. There are Enumerations, CDP Definition
Classes, Parameter Reference Classes, and the base class, BlockBase.
• Elements supplied by the VB.NET language infrastructure to the CAB type.
This is shown by the box to the right of the class CAB box..
The following topics describe the syntax for the Honeywell-defined elements of the CAB
API. Some include short, illustrative examples. Further examples can be found in the
scenarios section of this document.
APIs supplied from CAB to system

Class CAB
The CAB class is the block type definition that the CAB programmer supplies to the
system. Many of its characteristics are actually supplied by class BlockBase from which
it inherits. BlockBase is automatically provided by system infrastructure.
When a CAB type is created, the system automatically generates a code frame to serve as
the starting point for algorithm development. This is described in “Layout of the
development environment.” The main task of the CAB programmer is to provide
definitions for the one public method of class CAB: Execute().
Subroutine Execute() of class CAB

Definition of algorithm content for this subroutine is required. See ”Code CAB
algorithm” for further information.
Honeywell 10/04
CAB API reference
APIs supplied from system to CAB

Enumeration RestartEnum
Enumeration RestartEnum provides the type for the Restart API.
Table 80 Members of enumeration RestartEnum
Member name Value
None 0
CABToNormal 5
CEEWarmStart 10
CEEColdStart 20
BlockActivate 30
BlockLoad 40
Restart can be used to identify whether system events have occurred that may require
special initializations. A value of None indicates that no system event has occurred.
Usage is illustrated below.

If Restart <> RestartEnum.None Then
Select Case Restart
Case RestartEnum.CABToNormal
' initializations for CABToNormal event
Case RestartEnum.BlockLoad
' initializations for BlockLoad event
Case RestartEnum.BlockActivate
' initializations for BlockActivate event
Case RestartEnum.CEEColdStart
' initializations for CEEColdStart event
Case RestartEnum.CEEWarmStart
' initializations for CEEWarmStart event
End Select
End If
' do regular processing
End Sub
10/04 Honeywell
CAB API reference
Members of RestartEnum can be referenced by the full name (for example,

"RestartEnum.BlockLoad") or by the short name (for example, "BlockLoad"). To use
the short name, an Imports statement must be inserted ahead of other program
declarations as follows:
Imports Honeywell.CAB.SysCommon.RestartEnum
For many CAB implementations it is not necessary to do special initializations in

response to system events. Enumeration RestartEnum and the Restart API merely give
the programmer a range of options to handle any eventuality.
See “Data initializations under Execute()” and “Property Restart()” for further
information on Restart and RestartEnum.
Enumeration CABAccStatusEnum
Enumeration CABAccStatusEnum is predefined for use with the ReadStatus and
WriteStatus properties of the parameter reference classes. Its definition is as follows:
Table 81 Members of enumeration CABAccStatusEnum
Member name Value Descriptive name
OK 0 OK
Bad 10 Bad—This indicates an error that is not covered by other

enumeration values in this table.
RightsViol 11 Rights Violation—Indicates that the store is currently

locked out because of a condition that can be changed by
the operator. A classic example would be if CAB had an
access level of Program and was trying to store MODE
but MODEATTR was not equal to Program.
AccLevelViol 12 Access Level Violation—A store is being attempted by the

CAB instance which is rejected because the access level
in use for the CAB (Program or Continuous Control) is
permanently forbidden by the parameter. See “Access
Lock attribute for CDPs” for more information.
IllegalValue 13 Illegal Value
RangeLimExc 14 Range Limit Exceeded
IndexLimExc 15 Index Limit Exceeded
Honeywell 10/04
CAB API reference
Member name Value Descriptive name
ConfigMis 16 Configuration Mismatch
CommFail 17 Communication Failure
WritePending 18 PRef Write is Pending
WriteRejected 19 PRef Write was Rejected because a write was attempted

while status was WritePending
The value returned by the ReadStatus property is of type CABAccStatusEnum. Usage is

illustrated below where FLOW is a parameter reference used for input.
If FLOW.ReadStatus <> CABAccStatusEnum.OK Then

' do error processing
Else
' do normal processing
End If
To use the short form of a CABAccStatusEnum member name (for example, "OK"
instead of "CABAccStatusEnum.OK"), the following statement can be inserted ahead of
any other program declarations:
Imports Honeywell.CAB.SysCommon.CABAccStatusEnum
For a more detailed example on the usage of CABAccStatusEnum and the parameter
reference property ReadStatus see “Use of data access status in CAB.”
Enumeration CABCommandEnum
Enumeration CABCommandEnum is predefined for use with the CABCOMMAND
property of BlockBase. It can also be used with a parameter reference that points to the
CABCOMMAND FDP of another CAB block. Its definition is as follows:
10/04 Honeywell
CAB API reference
Table 82 Members of enumeration CABCommandEnum
Member name Value
None 0
Quit 1
Run 2
See “Fixed definition parameter CABCOMMAND” for information on the use of this
enumeration with property CABCOMMAND.
Enumeration CABStateEnum
Enumeration CABStateEnum is predefined for use with the CABSTATE property of
BlockBase. It can also be used with a parameter reference that points to the CABSTATE
FDP of another CAB block. Its definition is as follows:
Table 83 Members of enumeration CABStateEnum
Member name Value
Unloaded 0
Normal 1
Exception 2
Terminated 3
Dormant 4
See “Fixed definition parameter CABSTATE” for information on the use of this
enumeration with property CABSTATE.
CDP classes
CAB infrastructure provides a predefined class for each supported CDP data type. When
the CAB program reads and writes CDPs, it is reading and writing a VB property of these
classes. The complete set of classes is listed below:
Honeywell 10/04
CAB API reference
Table 84 Custom data parameter classes
Class name
BooleanCDP
Int32CDP
Float64CDP
StringCDP
TimeCDP
DeltaTimeCDP
TimeOfDayCDP
CDP classes are never used to explicitly declare variables within CAB programs and are
not exposed within the CAB API. Instead, they are used implicitly by virtue of
predefined CDP objects declared within class BlockBase.
Each CDP class is defined to have a property called "Value." This property has the type
implied by the name of the class and is used to read or write the value of the CDP. The
declaration of the Value property and other properties for class Float64CDP is shown
below. For all other classes the properties are declared with syntax that is equivalent
except for data type in the Value and Item properties, with the following exception: Min,
Max, Sum, and Avg apply to Float64CDP class only.
10/04 Honeywell
CAB API reference
Table 85 Declaration of members for class Float64CDP
Member Declaration Description

name
Value Public Property Value() Allows read and write of value

As Double for the CDP.
Rank Public ReadOnly Property Gets the rank (number of

Rank() As Integer dimensions) of the array. For
a scalar parameter, it is zero.
For a single dimension array,
it is one. For a two-dimension
array, it is two.
Item Public ReadOnly Default No reason to access this

Property Item(Index as property. It is added by .NET
Integer)As because there is an “Indexer”
Honeywell.CAB.BlockMap.Fl property on the class (for array
oat64CDPIndex access). “Item” is a method
that behaves like the array
specification – used instead of
“(index).” There is no reason
for the CAB to use this
because the normal array
specification is simpler.
GetType() Public Function GetType() No reason to access this

As System.Type property. GetType comes with
all classes and returns the
system “type” of this object.
Min Public Function Min() As If the CDP is an array

Double parameter (1D or 2D), this
returns that smallest value
found in all of the elements. If
this is a scalar parameter, it
returns that value.
Max Public Function Max() As If the CDP is an array

returns that largest value
found in all of the elements. If
this is a scalar parameter, it
returns that value.
Honeywell 10/04
CAB API reference

name
Sum Public Function Sum() As If the CDP is an array

returns the sum of all of the
elements. If this is a scalar
parameter, it returns that
value.
Avg Public Function Avg() As If the CDP is an array

returns the average of all of
the elements. If this is a scalar
parameter, it returns that
value.
For any of these Float64CDP member functions, if the CDP value is NaN (for scalar
CDPs) or any element in the array (for array CDPs) is a NaN, a NaN is returned.
If Temp1 is defined as a Float64CDP then CABMath.Min (Temp1) is equivalent to
Temp1.Min(). This is true for all CABMath functions.
The example below shows how CDP objects are used. Here it is assumed that two
Float64CDPs, Temp1 and Temp2, have been defined for the CAB type using PDE.
TEMP1.Value = 50.0
TEMP2.Value = TEMP1.Value
Parameter reference classes

CAB infrastructure provides a predefined class for each supported reference data type.
When the CAB program reads and writes parameter references, it is reading and writing
members of these classes. The complete set of classes is listed below:
10/04 Honeywell
CAB API reference
Table 86 Parameter reference classes
Class name
BooleanPRef
Int32PRef
Float64PRef
StringPRef
TimePRef
DeltaTimePRef
TimeOfDayPRef
PRef classes can be used to explicitly declare variables within CAB programs. However,
this is a minority use case. Usually, the PRef classes are used implicitly by virtue of pre-
defined PRef objects declared within class BlockBase. For an example of explicit use of
PRef classes, see “Use of parameter reference variables in CAB.”
Each PRef class has several members. Member declarations are shown in Table 87 below
using Float64PRef as an example. For all other PRef classes, member declarations are
equivalent except for the Value property. Declaration of the Value property differs only
in data type.
Honeywell 10/04
CAB API reference
Table 87 Declaration of members for class Float64PRef

name
Value Public Property Accesses the value of a

Value() As Double parameter that was read by a
PRef Read(), or sets the value to
be written by a PRef Write().
Read() Public Sub Read() Called for input or input/output

PRefs before the Value property
is read. Causes data to be
transferred into the block. Attempt
to call Read() on a PRef whose
data flow attribute is output
causes a data access error. The
data flow attribute is configured in
the PDE and allows you to specify
INPUT, OUTPUT, or both
(IN/OUT) for a PRef’s data
direction.
Write() Public Sub Write() Called for output or input / output

PRefs after the Value property
has been written. Causes data to
be transferred out of the block.
Attempt to call Write on a PRef
whose data flow attribute is input
causes a data access error.
Attempt to call Write on a PRef
whose WriteStatus is
WritePending causes a data
access error and the WriteStatus
will change to WriteRejected.
The data flow attribute is
configured in the PDE and allows
you to specify INPUT, OUTPUT,
or both (IN/OUT) for a PRef’s data
direction.
10/04 Honeywell
CAB API reference

name
ReadStatus Public ReadOnly Returns the data access status

Property ReadStatus() for the last Read() or
As CABAccStatusEnum PRefList.Read() transaction of the
PRef. Can be used to identify
data access failures before using
the Value. See “Enumeration
CABAccStatusEnum” for a
description of possible values
returned by ReadStatus.
WriteStatus Public ReadOnly Returns the data access status

Property WriteStatus() for the last Write() or
As CABAccStatusEnum PRefList.Write() transaction of
the PRef. For local writes, the
WriteStatus is available during the
same cycle of execution as the
Write() invocation. For remote
writes, WriteStatus will be
WritePending during the same
cycle of execution and change to
a different status in subsequent
cycle of execution if and when the
write is completed. See
“Enumeration
CABAccStatusEnum” for a
description of possible values
returned by Write Status.
Attempting a Write() when the
WriteStatus is WritePending will
cause the WriteStatus to change
to WriteRejected.
Honeywell 10/04
CAB API reference

name
IsNull Public ReadOnly Returns True when the PRef is

Property IsNull() As undefined. Allows for instance
Boolean configurations that define some
but not all PRefs. This property is
used if a CE wishes to define a
general-purpose block type that
allows varying numbers of
references. For an example of the
use of IsNull see “Use of
parameter reference variables in
CAB.”
10/04 Honeywell
CAB API reference
Although the PRef classes support several members, only a few are used with any
frequency. Value is used most often, being essential in any program that has PRefs.
Read() and Write() are used occasionally. But it turns out that for most programs,
PRefList.Read() and PRefList.Write() can be used instead with less coding effort. This is
discussed in “Parameter reference list class.” ReadStatus is used occasionally depending
on how the programmer has chosen to organize error handling for data access. IsNull is
used quite rarely.
The following paragraphs illustrate the use of the most frequently used PRef members.
Read(), ReadStatus, and Value

The example below shows the use of Read(), Value and ReadStatus. Here it is assumed
that PV is a predefined Float64PRef while LASTPV and BADPVCOUNT are predefined
Float64CDPs.
PV.Read()
If PV.ReadStatus = CABAccStatusEnum.OK Then
LASTPV.Value = PV.Value
BADPVCOUNT.Value = 0
' use PV.Value
ElseIf BADPVCOUNT.Value <= 3 Then
BADPVCOUNT.Value = BADPVCOUNT.Value + 1
' use LASTPV.Value
Else
' handle case of PV which has become unuseable
End If
In the example above, ReadStatus is used merely to obtain a binary indication of whether
the PV value is useable. Since PV is real valued, the IsNan() function of the VB.NET
Double structure could equally well be used. This is because PRefs automatically set
Value to the fail-safe value for any read access that does not complete successfully. For
reals, the fail-safe value is NaN. Thus, the first two lines of the above code could be
replaced with the following:
PV.Read()
If Double.IsNan(PV.Value) Then
Honeywell 10/04
CAB API reference
Of course many applications using process variables would not be implemented to hold a
last good PV value over execution cycles where the current PV was unavailable. For
these applications, there might not be any need to use ReadStatus or IsNan() at all.
PV.Read()
' use PV.Value regardless of whether it's bad or good
In the above segment, the computation implied by the comment would process correctly
if there had been no error on the PV access. If there had been an error, it would propagate
NaN values. The final result of the computation would end up either as a useable value or
as NaN.
Examples of conditions that would cause a data access error for Read() of a PRef are
deletion of the block supplying the input, failure of the node supplying the input, or
communication failure. Note, however, that an error in definition of the CAB type could
cause this condition as well.
If parameter reference PV were declared to be an output and not an input, then the error
path discussed above would execute. Similarly, if a parameter reference were used as an
output but had not been declared as such within PDE, the runtime output reference would
not work.
Write()
A more compelling motivation for the use of ReadStatus can be found in the case of
references that are not real-valued.
Consider the example below which uses ReadStatus and Write() as well. Here it is
assumed that MODE and MODEATTR are Int32PRefs, SP is a Float64PRef and
LocalModeAttr is a local INTEGER. The PRefs point to parameters on a block in the
same CEE as the CAB instance. It is also assumed that the CAB type has been designed
to write parameters with an access level of "PROGRAM" (that is, FDP ACCESSLEVEL
was set to PROGRAM at the time the CAB type was created).
10/04 Honeywell
CAB API reference
MODEATTR.Read()
If MODEATTR.ReadStatus <> CABAccStatusEnum.OK Then
' handle error condition
Else
LocalModeAttr = MODEATTR.Value
' Program Mode Attribute is 2
MODEATTR.Value = 2
MODEATTR.Write()
' Auto Mode is 1
MODE.Value = 1
SP.Value = 50.0
MODEATTR.Value = LocalModeAttr
MODE.Write() : SP.Write() : MODEATTR.Write()
End If
There are several things to note about the above example. First, observe that the code is
written with a general sequence in which invocations of Read() precede the use of Value
for input PRefs, and stores to Value precede invocations of Write() for output PRefs. The
Value property acts like a local data cache with no connection to the world outside the
CAB block. To transfer data into Value, Read() must be invoked first. To transfer data
out of Value, Write() must be invoked afterwards.
Next, observe the use of ReadStatus. MODE and MODEATTR are not real-valued. Thus
there are fewer options for error detection. CAB infrastructure does automatically supply
a fail-safe value for Int32PRefs (zero). But this fail-safe value is not uniquely different
from all operational values. To get around this, ReadStatus is used to unambiguously
identify whether the referenced data is useable.
Now observe the use of Write() in the above example. The purpose of this code segment
is to write 50.0 to the set point of a RegCtl block.
As noted above, the CAB type has been designed to write with access level of Program.
This means that MODE at the PID target must be Auto in order for SP stores to be
accepted. To accomplish the MODE and SP write, MODEATTR must first be set to
Program. If this isn't done and done in the right order, then the target RegCtl block will
ultimately reject the SP write. However, the example assumes the MODEATTR change
must be temporary. Thus, MODEATTR must be returned to its original value after the
write is complete.
Honeywell 10/04
CAB API reference
The code above accomplishes these objectives. MODEATTR is written twice, once to
change into program mode attribute and once to return to its original value. The
sequencing of writes to MODEATTR, MODE, and SP are such that the SP write will be
accepted.
Note, however, that the code is somewhat verbose. Every PRef used for input requires a
call to Read() and an access to Value. Every PRef used for output requires an access to
Value and at least one call to Write. In fact, the style of coding shown above is not
frequently used. “Parameter reference list class” describes a style of coding that requires
fewer statements.
Be aware that the example above applies to cases where the CAB instance and the
destination block for writes are in the same CEE. For considerations on communications
between CAB and remote blocks see “Data access integrity.”
WriteStatus
The code segments below illustrate two potential uses for WriteStatus. They attempt to
set a CM's EXECSTATE to Active and then verify that the store went through. Here
EXECSTATE is an Int32PRef.
EXECSTATE.Value = 1
EXECSTATE.Write()
If EXECSTATE.WriteStatus <> CABAccStatusEnum.OK Then
' do error processing
End If
The code segment above assumes that the value of WriteStatus is available for use
immediately after the invocation of Write(). This would be true if the EXECSTATE
reference pointed to a block within the same CEE as the CAB block. If this constraint
were always met, the above code would accomplish the intended purpose. However, if
the program designer wished to avoid this constraint, the program would have to be
written differently.
To handle status collection for remote writes, the programmer must first realize that they
can only be detected after sufficient time has passed for the write to be sent and for the
status to be returned. Since CAB and VB.NET do not support preemption, the program
would have to be written to detect write status in a later execution cycle. Furthermore,
depending on the latency of the status return and on the period of the CAB block, the
status value may or may not be available by the first execution to follow the Write()
invocation.
10/04 Honeywell
CAB API reference
The code segment below illustrates the use of WriteStatus in a manner that is valid for
both local and remote references. DoCheck and DoWrite are local Boolean state
variables used to control the check and write actions.
If DoCheck Then
If EXECSTATE.WriteStatus = CABAccStatusEnum.WritePending Then
' no status to check yet
Else If EXECSTATE.WriteStatus <> CABAccStatusEnum.OK Then
' handle error
Else
' write went through
DoCheck = False
End If
End If
If DoWrite Then
DoWrite = False
EXECSTATE.Value = 1
EXECSTATE.Write()
DoCheck = True
End If
When status is collected after a parameter write operation, it may or may not be available
immediately after the write. If the parameter is remote—that is, if it is owned by a block
in an environment different from the one hosting the CAB program—then the write
status is unknown until a subsequent CAB execution. For an example of using the Status
property with output references, see “Use of data access status in CAB.”
Parameter reference list class

There is a single PRef list class whose purpose is to group predefined PRefs so that
Read() and Write() operations may be commanded in bulk. Parameter References are
allowed to be loaded with a NULL reference. When a read or write operation is
commanded, only “non-NULL” PRefs will be read or written.
Honeywell 10/04
CAB API reference
Table 88 Parameter reference list class
Class name
PRefListClass
Class PRefListClass is never used to explicitly declare variables within CAB programs
and is not exposed within the CAB API. Instead, it is used implicitly by virtue of the
predefined object in BlockBase called "PRefList."
Members of PRefListClass are described in the following table.
Table 89 Description of members of class PrefListClass

name
Read() Public Sub Read() The Read() method of PRefListClass is typically

called at the start of Execute() to fetch data into
the Value property of each input or input /
output PRef. Using Read() generally prevents
the need to call the Read() subroutine for
individual PRefs. However, the list Read() and
individual Read() calls may both be used within
the same subroutine.
At the completion of the Read operation, the

ReadStatus property for each PRef read will be
updated to reflect the status of the Read.
The list Read will only attempt to read

parameter references that have been
configured (non-NULL).
10/04 Honeywell
CAB API reference

name
Write() Public Sub Write() The Write() method of PRefListClass is

typically called at the end of Execute() to store
data out of the Value properties of output and
input/output PRefs.
Using Write() generally prevents the need to call

Write() subroutine for individual PRefs.
However, the list Write() and individual Write()
calls may be used within the same subroutine.
A call to Write() does not cause write of all

outgoing PRefs. Instead, it writes only those
outgoing PRefs whose Value properties have
been assigned at least once during the current
execution cycle. Write() performs writes in an
order, which matches the order assignments
were made to the Value properties during
execution.
At the completion of the Write operation, the

WriteStatus property for each PRef written will
be updated to reflect the status of the Write.
The list Write will only attempt to write

parameter references that have been
configured (non-NULL).
Only the “last” value set for a PRef will be

written by the list Write. Multiple “PRef.Value =
<value”>” statements may be executed prior to
the PrefList.Write(), but only the last value set
for each PRef will be stored.
GetType() Public Function The GetType function comes with .Net. It will
GetType() probably not be used by the general CAB
programmer. It gets the System.Type of the
current instance.
Init() Public sub Init() The Init() method should NOT be called by user
code. This is an internal method used to set up
the list for all of the Prefs.
Honeywell 10/04
CAB API reference
Use of PRefListClass can be illustrated using a variant of the example from the section
"Write().” Note that it is still assumed here that the target PID block being written to is in
the same CEE as the CAB instance.
PRefList.Read()
If MODEATTR.ReadStatus <> OK Then
' handle error condition
Else
LocalModeAttr = MODEATTR.Value
' Program Mode Attribute is 2
MODEATTR.Value = 2
MODEATTR.Write()
' Auto Mode is 1
MODE.Value = 1
SP.Value = 50.0
MODEATTR.Value = LocalModeAttr
End If
PRefList.Write()
In the example above, PRefList is the single instance of PRefListClass that is predefined
within BlockBase. The Read() call of the example from the section “Write()” has been
replaced with a call to PRefList.Read(). Three of the four Write() calls have been
replaced with a single call to PRefList.Write(). The Write() call after the first assignment
to MODEATTR.Value is still required as MODEATTR is written twice within the same
execution cycle. The order of assignments to MODEATTR.Value, MODE.Value, and
SP.Value are faithfully preserved by PRefList.Write().
The example above applies to cases where the CAB instance and the destination block
for writes are in the same CEE. For considerations on communications between CAB and
remote blocks see “Data access integrity.”
CABMath class
Four CABMath functions are available: Min, Max, Sum, and Avg. The following table
describes the methods for these functions. For examples of the usage of these functions,
see “Examples of CABMath functions usage.”
In the table, “Logical Declaration” shows how the function would be logically used.
“Actual Declaration” shows how the method is actually declared and how it would
appear in IntelliSense.
10/04 Honeywell
CAB API reference
Table 90 Methods in the CABMath class
Method Logical declaration Actual declaration Description

name
Min Public Function Public Shared Returns the smallest value

Min(value1 As Function Min(ByVal found in all of the values
Double, value2 ParamArray specified.
as Double, ...) values() As
As Double Double) As Double
Public Function Public Shared Returns the smallest value
Min(values() As Function Min(ByVal found in all of the
Double) As ParamArray elements of the 1
Double values() As dimensional array.
Double) As Double
Public Function Public Shared Returns the smallest value
Min(values(,) As Function Min(ByVal found in all of the
Double) As values(,) As elements of the 2
Double Double) As Double dimensional array.
Public Function Public Shared When all of the
Min(value1 As Function Min(ByVal parameters passed in are
Float64CDP, ParamArray scalar parameters, this
value2 as values() As returns the smallest value
Float64CDP, ...) Honeywell.CAB.Bloc found in all of the CDP
As Double kMap.Float64CDP) parameters specified.
As Double
If any of the CDP

parameters are arrays, an
ArgumentException is
thrown
Public Function Public Shared When value is an array
Min(value As Function Min(ByVal parameter (either a 1D or
Float64CDP) As value As 2D), this returns the
Double Honeywell.CAB.Bloc smallest value found in all
kMap.Float64CDP) of the elements in the
As Double array. If it is not an array
parameter, it just returns
the value of the CDP.
Honeywell 10/04
CAB API reference
Method Logical declaration Actual declaration Description

name
Max Public Function Public Shared Returns the largest value

Max(value1 As Function Max(ByVal found in all of the values
Double, value2 ParamArray specified.
Public Function Public Shared Returns the largest value
Max(values() As Function Max(ByVal found in all of the
Double) As ParamArray elements of the 1
Double values() As dimensional array.
Double) As Double
Public Function Public Shared Returns the largest value
Max(values(,) As Function Max(ByVal found in all of the
Double) As values(,) As elements of the 2
Double Double) As Double dimensional array.
Max(value1 As Function Max(ByVal parameters passed in are
value2 as values() As returns the largest value
Float64CDP, ...) Honeywell.CAB.Bloc found in all of the CDP
As Double kMap.Float64CDP) parameters specified.
As Double
If any of the CDP

thrown
Max(value As Function Max(ByVal parameter (either a 1D or
Double Honeywell.CAB.Bloc largest value found in all
kMap.Float64CDP) of the elements in the
As Double array. If it is not an array
parameter, it just returns
the value of the CDP.
10/04 Honeywell
CAB API reference
Sum Public Function Public Shared Returns the sum of all of

Sum(value1 As Function Sum(ByVal the values specified.
Double, value2 ParamArray
Public Function Public Shared Returns the sum of all of
Sum(values() As Function Sum(ByVal the elements of the 1
Double) As ParamArray dimensional array.
Double values() As
Double) As Double
Public Function Public Shared Returns the sum of all of
Sum(values(,) As Function Sum(ByVal the elements of the 2
Double) As values(,) As dimensional array.
Double Double) As Double
Sum(value1 As Function Sum(ByVal parameters passed in are
value2 as values() As returns the sum of all of
Float64CDP, ...) Honeywell.CAB.Bloc the CDP parameters
As Double kMap.Float64CDP) specified.
As Double
If any of the CDP

thrown
Sum(value As Function Sum(ByVal parameter (either a 1D or
Float64CDP) As value As 2D), this returns the sum
Double Honeywell.CAB.Bloc of all of the elements in
kMap.Float64CDP) the array. If it is not an
As Double array parameter, it just
returns the value of the
CDP.
Honeywell 10/04
CAB API reference
Avg Public Function Public Shared Returns the average of all

Avg(value1 As Function Avg(ByVal of the values specified.
Double, value2 ParamArray
Public Function Public Shared Returns the average of all
Avg(values() As Function Avg(ByVal of the elements of the 1
Double) As ParamArray dimensional array.
Double values() As
Double) As Double
Public Function Public Shared Returns the average of all
Avg(values(,) As Function Avg(ByVal of the elements of the 2
Double) As values(,) As dimensional array.
Double Double) As Double
Avg(value1 As Function Avg(ByVal parameters passed in are
value2 as values() As returns the average of all
Float64CDP, ...) Honeywell.CAB.Bloc of the CDP parameters
As Double kMap.Float64CDP) specified.
As Double
If any of the CDP

thrown
Avg(value As Function Avg(ByVal parameter (either a 1D or
Double Honeywell.CAB.Bloc average of all of the
kMap.Float64CDP) elements in the array. If it
As Double is not an array parameter,
it just returns the value of
the CDP.
For any of the CABMath functions, if any value passed in is a NaN, the function returns
a NaN.
10/04 Honeywell
CAB API reference
Examples of CABMath functions usage

The examples below show how the CABMath functions are used. Here it is assumed that
three Float64CDPs, Flow1, Flow2, and Flow3, have been defined for the CAB Type
using PDE and that MinFlow, MaxFlow, TotalFlow, and AverageFlow have been
defined as double variables.
MinFlow = CABMath.Min(FLOW1, FLOW2, FLOW3)

MaxFlow = CABMath.Max(FLOW1, FLOW2, FLOW3)
TotalFlow = CABMath.Sum(FLOW1, FLOW2, FLOW3)
AverageFlow = CABMath.Avg(FLOW1, FLOW2, FLOW3)
A Min and Max function also exists in the MSVS Math class found under the System
namespace of the .NET framework. However, these only take two parameters where the
CABMath functions allow any number of parameters. Also, the System.Math functions
do not allow the user to specify an array.
FDP classes
CAB infrastructure defines classes to make a subset of FDPs accessible from within the
CAB program. They are never used to explicitly declare variables and are not exposed
within the API. Instead, they are used implicitly by virtue of instances predefined in
BlockBase.
Table 91 Fixed definition parameter classes
Class name
Float64FDP
StringFDP
CABCommandEnumFDP
CABStateEnumFDP
BooleanFDP
Each FDP class is defined to have a single property called "Value." This property has the
type implied by the name of the class and is used to read or write the value of the FDP.
The declaration of Value for class Float64FDP is shown below. For all other classes,
Value is declared with syntax that is equivalent except for data type.
Honeywell 10/04
CAB API reference
Table 92 Declaration of members for class Float64FDP

name
Value Public Property Value() Allows access to value for the

As Double FDP. Depending on characteristics
of the FDP, it may be view only.
Base class
Class "BlockBase" is the parent of class "CAB" that establishes the algorithm definition
for the CAB type. The only reference to BlockBase within a CAB program occurs in the
declaration of class CAB. The CAB programmer uses BlockBase through the variables,
properties, and subroutines that it defines and that are inherited by class CAB. Inherited
content includes the following.
Predefined CDP variables

The predefined CDP variables inherited from BlockBase are the internal expression of
the custom parameter definitions established within PDE. Examples of predefined CDPs
include TEMP1 and TEMP2 in the section “CDP classes” and LASTPV and
BADPVCOUNT of section “Read(), ReadStatus, and Value.” Further examples can be
found in the scenarios section of this document.
Predefined parameter reference variables

The predefined PRef variables inherited from BlockBase are the internal expression of
the reference definitions established within PDE. Examples of predefined PRefs include
FLOW of “Enumeration CABAccStatusEnum,” PV of “Read(), ReadStatus, and Value,”
MODEATTR, MODE, and SP of “Write(),” and EXECSTATE of “WriteStatus.”
Further examples can be found in the scenarios section in this document.
Predefined parameter reference list

BlockBase defines an object called "PRefList" that is an instance of PRefListClass. See
“Parameter reference list class” for a description.
10/04 Honeywell
CAB API reference
Predefined FDPs and subroutines

Your CAB inherits certain predefined items from BlockBase that provide access to
information maintained by the system regarding your block. These items are:
• Three Predefined FDPs
− PROGSTSDESC
− CABCOMMAND
− CABSTATE
• Two special, or restricted FDPs—These are, strictly speaking, not true FDPs but
they appear in a CAB program like FDPs. They are only available to user code and
cannot be accessed from outside the block.
− PERIOD
− PROCSPECEXEC
• Two subroutines
− Send()
− Abort()
• One Property
− Restart
These items are described in the following topics.
Fixed definition parameter PROGSTSDESC

PROGSTSDESC is an instance of StringFDP inherited from BlockBase. It is a string that
can hold up to 64 characters and maps directly into the PROGSTSDESC FDP of the
CAB instance. The Value property of PROGSTSDESC has read/write permission from a
CAB program even though a read returns only what was written – in most cases.
PROGSTSDESC can be used by the CAB algorithm to inform operators of errors
detected during execution. It can be used alone, or it can be used in combination with an
exception condition that is generated intentionally by invoking the Abort() subroutine.
This causes the generation of an event that is recorded in the event summary display and
the event journal.
Honeywell 10/04
CAB API reference
The CAB infrastructure never writes to PROGSTSDESC except to clear it to blank in

connection with a small number of conditions. These conditions are as follows:
• PROGSTSDESC is automatically cleared on CAB instance load.
• PROGSTSDESC is automatically cleared when the parent CM transitions to Active.
• PROGSTSDESC is automatically cleared when CABSTATE transitions to Normal.
The example below illustrates the use of PROGSTSDESC. This is an extension of the
example given in “Read(), ReadStatus, and Value.” In the following example, PV is a
parameter reference while LASTPV and BADPVCOUNT are CDPs.
If PV.ReadStatus = OK Then
LASTPV.Value = PV.Value
BADPVCOUNT.Value = 0
' use PV.Value
ElseIf BADPVCOUNT.Value <= 3 Then
BADPVCOUNT.Value = BADPVCOUNT.Value + 1
' use LASTPV.Value
Else
' handle case of PV which has become unuseable
PROGSTSDESC.Value = "Bad PV: " + PV.ReadStatus.ToString
Abort()
End If
In the example above, the programmer has chosen to send out an event with the
statement "Abort()." This causes the CAB instance to go into state Exception as soon as
the Abort() subroutine is called. No further statements within the program are executed
on the current execution cycle.
Before generating the event the programmer publishes the cause of the error by writing a
description into PROGSTSDESC. To produce the error description, the programmer has
used the "Bad PV: " string literal. The string literal is combined with the string
representation of the current value of the parameter access status for the PV parameter
reference. To convert the binary enumeration value into a string representation, the
programmer has used the VB.NET "ToString" method.
In the above example the displayed value of PROGSTSDESC would vary depending on
what kind of parameter access error had occurred. If the access status had been
CommFail then PROGSTSDESC would take on the following value:
"Bad PV: CommFail"
10/04 Honeywell
CAB API reference
Fixed definition parameter CABCOMMAND

CABCOMMAND is an instance of CABCommandEnumFDP inherited from BlockBase.
It allows the CAB block to cause a transition in its own CABSTATE. The only value that
can be written to CABCOMMAND is CABCommandEnum.Quit. The Value property
of CABCOMMAND is write-only from a CAB program.
TIP
A CAB algorithm containing the statement CABCOMMAND.Value =
CABCommandEnum.Run will compile, load, and run without errors, but the
statement will have no effect.
The code below illustrates how CABCOMMAND might be used. This example assumes
that other code within the program detects conditions that warrant a shutdown of self.
The need for shutdown is signaled within the program by setting the internal variable
Shutdown to True.
If ShutDown Then
CABCOMMAND.Value = CABCommandEnum.Quit
End If
The action of the code above is different from that of the Abort() subroutine. Abort()
causes immediate cessation of the current cycle of execution, immediately changing the
CABSTATE to Exception. Setting CABCOMMAND to Quit allows all statements in the
current cycle to complete and then causes CABSTATE to go to Dormant. When Abort()
is called, the CAB program resumes execution on the next cycle. When
CABCOMMAND is set to the value of Quit, the CAB program does not resume
execution until commanded to do so by a human being or by another application.
Fixed definition parameter CABSTATE

CABSTATE is an instance of CABStateEnumFDP inherited from BlockBase. Its type
is CABStateEnum. It provides the current value of the CABSTATE FDP of the block.
The Value property of CABSTATE is view only from a CAB program.
Although CABStateEnum has four possible values, only two of these can be seen using
CABSTATE FDP. These are CABStateEnum.Normal and
CABStateEnum.Exception. For the other two states, the CAB program is never
executing so it cannot observe these states through use of the CABSTATE FDP.
Circumstances under which it is useful for a program to read its own CABSTATE are
probably rare. The code below illustrates how CABSTATE might be used.
Honeywell 10/04
CAB API reference
If CABSTATE.Value = CABStateEnum.Exception Then

' We've entered an unexpected exception ...
' do special error processing
End If
Note that the CABSTATE FDP is used for examining the self state of a CAB instance.
For examining the state of different CAB instances, a PRef must be used. When
CABSTATE of other CAB instances is observed, it is possible for any of the four states
to be seen.
Restricted FDP PERIOD

PERIOD is an instance of Float64FDP inherited from BlockBase. It provides the value of
the PERIOD parameter of the parent CM of the CAB instance. Units are seconds. The
Value property of PERIOD is view only. This FDP does not exist as an external
parameter on the block. It is only available to the user code.
Use of PERIOD is illustrated by the following example in which DelayCycles is assumed
to be a block scope variable with units of CAB execution cycles. DelayCycles is
computed at initialization time from a configuration parameter called DELAYMINS.
DELAYMINS units are minutes.

DelayCycles = DELAYMINS.Value * 60.0 / PERIOD.Value
End If
Restricted FDP PROCSPECEXEC

PROCSPECEXEC is an instance of BooleanFDP inherited from BlockBase. It provides
the current value of the BPS parameter of the CAB instance's parent CM. The Value
property of PROCSPECEXEC is read/write from a CAB program even though writing
this parameter has no effect on the block execution. It is intended only to provide
information to the block about how it was started. PROCSPECEXEC can only be
referenced in the CAB program. It cannot be viewed on the properties form, cannot be
placed on the faceplate, and cannot be referenced by parameter reference or by
connectors. It simply mirrors the parent CM’s Block Process Special (BPS) parameter
and is for use in the CAB program only.
PROCSPECEXEC returns True whenever the current execution of the CAB instance was
caused by a process special request to the parent CM.
10/04 Honeywell
CAB API reference
If PROCSPECEXEC.Value Then
' Do special processing
End If
' Do normal processing
Note that the mnemonic for this restricted FDP is "PROCess SPECial EXECution".
Subroutine Send()
Subroutine Send() allows text to be sent to the operator message display. Messages
appear in those consoles mapped to the area assigned to the parent CM of the CAB
instance. Send() supports a single string argument that can be up to 132 characters long.
Each string sent corresponds to one line in the message display. The signature of Send()
is shown below.
Table 93 Declaration of subroutine Send()
Member name Declaration
Send() Protected Sub Send(ByVal Message As String)
The single argument of Send() can be constructed using the inherent string conversion
capabilities of VB.NET. In the example below, Send()is used to present a string literal
and floating-point values. ReportPressValues is a local Boolean variable and the array
Press is a block scope variable. The VB.NET line continuation character, "_", is used to
put multiple floating point values on a single message line even though they do not
conveniently fit into a single line of source code.
If ReportPressValues Then
Me.Send("Pressure Array:")
Send(CStr(Press(0)) + " " + CStr(Press(1)) + " " + CStr(Press(2)) _
+ " " + CStr(Press(3)) + " " + CStr(Press(4)))
Send(CStr(Press(5)) + " " + CStr(Press(6)) + " " + CStr(Press(7)) _
+ " " + CStr(Press(8)) + " " + CStr(Press(9)))
End If
Honeywell 10/04
CAB API reference
Note that in the example above, two of the send statements have the syntax "Send()", but
one has the syntax "Me.Send()". The name "Me" refers to the CAB class instance. Any
members of the CAB instance can be referred to by their name directly or by the
contstruct "Me.<member name>." The two different syntaxes are equivalent in terms of
execution properties. The advantage of using Me.<member name> is that it causes the
Visual Studio IntelliSense feature to display a list of all members of the CAB class right
after the user types "Me." This prevents the need to remember all members inherited
from BlockBase when coding.
Message notifications issued with the Send() subroutine differ from alarms and other
notifications in that they do not support automatic event recovery. It is unlikely but
possible that under conditions of notification overload, one or more messages requested
by a CAB program might not be sent. If this happens, an error message is sent after the
notification communication channel clears. The text of the message is as follows:
"!! Message(s) lost due to notification overload !!"
Messages reported through the Send() API can be seen in the same Station displays as
messages sent by the CEE message block. They are visible from the message summary
display or from the event journal.
Subroutine Abort()
BlockBase supports a subroutine which allows the program to break the current cycle of
execution. Calling Abort() when there is no surrounding Catch clause does the following:
• Prevents any further instructions from executing in the current cycle.
• Puts CABSTATE into Exception.
• As with any Exception condition, reports an alarm.
• As with any Exception condition, execution of the block resumes on the next cycle.
Abort() is supported for programmer convenience. Almost the same effect could be
achieved by calling the VB.NET Throw statement without an enclosing Catch statement.
Abort() can be used if the progammer prefers not to throw exceptions explicitly. There
are slight differences between Abort() and Throw in the way in which CAB FDPs reflect
the Exception state. For example, parameter EXCPTNTYPE contains the following
string after Abort() has been called:
"Honeywell.CAB.AbortException"
If a Throw is explicitly called the contents of EXCPTNTYPE are determined by the
exception type used for the Throw.
10/04 Honeywell
CAB API reference
The declaration of Abort() is shown below.

Table 94 Declaration of subroutine Abort()
Abort() Protected Sub Abort()
Use of Abort() is illustrated in the example of “Fixed definition parameter

PROGSTSDESC.”
Property Restart()
BlockBase supports the Restart property that allows code executing under the Execute()
calling tree to detect whether one of a set of system events has occured. The set of events
that can be detected is defined by the enumeration RestartEnum. The declaration of
Restart is as follows:
Table 95 Declaration of property Restart()
Restart() Public ReadOnly Property Restart() As

Honeywell.CAB.SysCommon.RestartEnum
The parentheses are optional as there are no variables to pass. Use of Restart is illustrated
by the example of “Enumeration RestartEnum.” Further information can be found in the
section “Data initializations under Execute().”
Honeywell 10/04
CAB API reference
APIs supplied from VB.NET to CAB

Some constructs of interest
Many of the functionalities essential for CAB are built into VB.NET. Functionalities
specific to VB.NET are not described here.
Some.NET constructs often used in CAB applications are as follows.
• System Namespace
• System.Math Class
• System.Double Structure
• System.String Class
• System.DateTime Structure
• System TimeSpan Structure
These and other .NET APIs are described in the documentation for Visual Studio .Net
2003.
Private and public access types In CAB programs

VB.NET is used in CAB types in a way that specifically supports CEE control block
applications in CEE. Thus, using VB.NET in CAB is somewhat different from using
VB.NET for a general-purpose application on a PC platform. Some key points are noted
below.
• Exactly one subroutine defined in a CAB type is known to CEE. This is the
Execute() subroutine.
• The declaration of Execute() is established in an automatically generated code frame
when a CAB type is first created. This declaration should not be altered.
• Execute() is always declared with the VB.NET access type Public. This is required
in order for CEE to access these subroutines.
• Aside from Execute(), subroutines and functions declared internal to a CAB type are
always private. This is true regardless of whether they are declared with access type
Private, access type Public or with no explicit access type at all. Within CEE one
CAB type cannot call the subroutines or functions defined by another. It is
recommended that CAB subroutines always be declared with access type Private to
make the code self-documenting.
10/04 Honeywell
CAB API reference
• Class variables (block scope variables) are always private within CAB. Regardless
of whether they are declared with access type Private, access type Public, or with no
explicit access type, they can only be used by the CAB instance that owns them.
• CDPs declared for a CAB type using PDE are effectively public. But they are not
made public through the same mechanism as a Public class variable in VB.NET. The
mechanism depends on CEE services and allows the CDP to be visible beyond the
hardware platform that hosts the CAB instance. For one CAB instance to access the
CDPs of another CAB instance or of a native block instance, PRefs must be used.
This cannot be done through inherent data reference capabilities of VB.NET.
Honeywell 10/04
Glossary of terms and acronyms
Introduction

Introduction
Overview
This section contains a compilation of special terms and acronyms that appear throughout
the guide.
Special terms and acronyms

.NET
Next generation integrated software platform for distributed computing offered by
Microsoft. CAB builds its functionality on programming language capabilities that are
part of the .NET suite of functionalities.
.NET CLR
.NET Common Language Run time. A set of language services which make it possible
for .NET programs to run on a target platform.
ACE
Application Control Environment
AICHANNEL
One type of IO block supported within CEE.
AND
One type of logic block supported within CEE.
API
Application Programming Interface
10/04 Honeywell
Basic block
Blocks that can exist only as dependent blocks within container blocks. Basic blocks
have dependent names. That is, their names are not unique within the PKS name space
until qualified by the name of their parent container block. CABs and CDBs are always
basic blocks.
Block instance
A single copy or instance of a block type. Holds a unique set of data values that can
specify the properties of a block type. See block type and block template.
Block template
A concept of block that incorporates some qualities of block type and some qualities of
block instances. A template is like a type in that it can serve as the pattern from which
one or more instances are created. It is like an instance in that one template can be copied
to make another. A template can serve as the master for changes to parameters that
propagate to all derived instances. Like an instance, a template is always dependent on an
independently defined block type. See also the definitions for block type and block
instance.
Block type
A universal definition of block data set and or block algorithm that can be physically
realized in multiple different copies or instances. See also Block Instance and Block
Template.
Build a program
The operation of compiling and linking a CAB program is often referred to within this
document as "building" it.
CAB algorithm
The control computation of a CAB. The algorithm is to be distinguished from the data
definition of the block. The algorithm is expressed within the CAB program.
Honeywell 10/04
CAB program
The programming language description of the CAB algorithm written in VB.NET. While
the algorithm is defined with the CAB program, the public, persistent data of a CAB is
defined as a set of CDPs through the use of PDE. CDP definitions established by PDE
are known to the CAB Program but are not explicitly declared within the CAB program.
CAB
Custom Algorithm Block
CB
Control Builder
CDB
Custom Data Block
CDP
Custom Data Parameter
CE
Control Engineer
CEE
Control Execution Environment
CM
Control Module
Configuration of block instances

This document maintains a distinction between the activity of "configuring" the instance
of a block and "creating" or "modifying" the type definition of a block. In the context of
native blocks, the type definition cannot be changed so there is no ambiguity about what
"configuration" might mean. In the context of custom blocks the activity of creating a
block type is very different from the activity of configuring a block instance. This
document uses the term "configure" when referring to the assignment of data values to a
block instance.
10/04 Honeywell
Component block
Within CEE, a component block is a block contained in a container block. Component
blocks are usually Basic Blocks, though within Experion, CMs can be components of
other CMs.
Connections
See “graphical connections.”
Container Block
Within the CEE architecture a container block is one capable of holding other blocks.
There are two types of container blocks: SCMs and CMs. SCMs are inherently single-
level. Their component blocks can only be basic blocks. In Experion, CMs can be multi-
level. They can hold basic blocks as components but they can also hold other CMs.
Container blocks have independent names (tag names). Some people prefer to think of
container blocks as "modules."
Control Module
A container block that supports execution of continuous algorithm blocks. In Experion, It
also supports containment hierarchies by being able to contain itself. CAB and CDBs are
always contained in CMs.
Convert
In the context of block types and block instances this term refers to a configuration
operation supported by CB. It allows an instance of one block type to be converted into
an instance of another block type.
Custom Data Block

A block for which the Control Engineer provides the definition. CDBs are similar to
CABs except that they have no program. They have only data, defined within custom
data parameters.
Honeywell 10/04
Custom Data Parameter

A custom parameter defined by a Control Engineer. Native block types support fixed
definition parameters only. They do not support CDPs. Instead, CDPs are supported on
CAB types and CDB types. CABs allow a CE to define both a custom algorithm and a
custom data set and to publish that data set as CDPs. CDBs allow a CE to define a
custom data set with no associated algorithm. CDBs are independent data containers that
can be placed in any CM independent of CABs.
DATAACQ
A signal conditioning and alarm block supported within CEE.
Data owner principle

A principle sometimes used in object oriented programming. The data owner is the agent
that owns the data. His ability to modify the data is unrestricted. Distinct from the data
owner are agents that may wish to modify the data but do not own it. Writes from
external agents are subject to validity checks by the data owner before being accepted. In
CAB, the instance is considered the data owner of all CDPs. Writes by the CAB program
to its own CDPs is unrestricted. Writes from external agents are subject to automatic
validity checks that are determined by attributes that define the CDPs.
DLL
Dynamic Link Library
Edit Lock
A string parameter associated with all CAB and CDB types. When blank, it indicates that
the type is available for edit. When non-blank it contains the machine name and user
name of the person who is editing the type. Edit Lock is automatically set when an edit
session starts and automatically cleared when the session ends. A type may be opened for
viewing when it is already open but it cannot be saved to ERDB. The value of Edit Lock
can be viewed for a block type by opening the form from the library tree.
10/04 Honeywell
EE
Execution Environment
ERDB
Engineering Repository Database
EU
Engineering Unit
Exception handler
A programming construct provided in modern programming languages such as VB.NET.
Exception handlers allow error conditions to be detected and forwarded to the software
agent designed to respond. Error handling can be coded more concisely with Exception
handlers than through the traditional technique of passing error status up through a
calling tree. Exception handling is expressed through the use of "Try," "Catch," and
"Finally" clauses in VB.NET. Within CAB programs, Exception handlers can be used at
the discretion of the CE. When not used, runtime exceptions (for example, integer-
divide-by-zero exception) are caught by CAB system services, which terminate current
execution and resume it on the next cycle.
FDP
Fixed definition parameter
Fixed Definition Parameter

In the context of CAB types and CDB types, this term is used in contrast to custom data
parameter. CABs and CDBs have some parameters whose definition is fixed by the
system design. Users who create block types may be able to assign one or two attributes
of these parameters, most notably the value, but they cannot change anything else about
the definition. For native block types all parameters are fixed definition parameters.
However, there is no need to use the longer term in that context since no possible
confusion with CDPs arises.
Honeywell 10/04
Graphical connections
Connections used to interconnect parameters. Wire connections are used within a CM
between pins exposed on blocks. Parameter connections are used between blocks in
different CMs, (although they can also be used within the same CM). Parameter
connections are implemented using symbol pins that are also exposed on the blocks.
GUID
Globally Unique Identifier. This identifier is generated in such a way that it will not
reoccur on any other PC. In CAB, it is stored in the BLOCKTYPEID parameter and
appears on the source code tab in MSVS. A new GUID is generated on each build.
IDE
Integrated Development Environment
IEEE 754
Prevalent standard for floating point arithmetic in computing.
Incomplete Lock
A flag parameter associated with all CAB types. When On it indicates that the parameter
definitions and algorithm definition of the type have not been rebuilt since changes were
made. The act of rebuilding clears the lock. A CAB type can be instantiated when the
Incomplete Lock is set, but it cannot be loaded.
INF
+INF and –INF are bit patterns in IEEE 754 that represent respectively positive and
negative infinity. Any magnitudes that are too large to not be represented within the
defined range of the floating-point number are represented instead as +INF or –INF.
I/O
Input/Output
10/04 Honeywell
Monitor Side Instance

Every block instance within ERDB can have two distinct copies: the monitor side
instance and the project side instance. The monitor side instance corresponds to data
within the ERDB but also maps directly to the runtime data within the execution
environment and within the Experion server. This is the copy that is viewed when the
block is live and operative within the system.
MS
Microsoft, Inc.
MSVS
Microsoft Visual Studio .Net 2003
NaN
Not A Number. A set of bit patterns in IEEE 754 numbers that are not part of the defined,
ordinal numerical range. They can be used to represent alternative data states such as
"bad data."
Native blocks
Blocks whose type cannot be created or modified by application engineers who use the
Experion system. Examples include PID, Device Control and Data Acquisition.
OS
Operating System
Parameter Definition Editor

A GUI tool used for creating and assigning attributes of custom data parameters. For
CAB types, the Parameter Definition Editor is used within MS Visual Studio .Net 2003.
For CDB types it is used directly within Control Builder.
PDE
Parameter Definition Editor
Honeywell 10/04
PKS
Process Knowledge System
PRef
Parameter reference
Project side instance

Every block instance within ERDB can have two distinct copies: the monitor side
instance and the project side instance. The project side instance corresponds to the one
that is under edit and has not yet been deployed within the runtime system. It is stored
exclusively within ERDB.
SCE-C200
Simulation Control Environment for the C200 embedded controller.
SCM
Sequence Control Module
Sequence Control Module

A container block that supports execution of blocks specifically designed to support
sequence control. SCMs support a limited number of components blocks: Handlers,
Transitions and Steps. SCMs support only a single level of containment.
SIM-ACE
Simulation environment for the ACE supervisory controller. SIM-ACE cannot be used
for on-process control. It is the intended platform for CAB source level debugging in
which break point activity can disrupt the main execution thread.
SR
System Repository
System Repository
The file where all Experion Server point data is stored.
10/04 Honeywell
System template
Block profile
Template
Block template
UI
User Interface
User template
Block template
Honeywell 10/04

Custom Algorithm Block

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Custom Algorithm Block

Hochgeladen von

Copyright:

Verfügbare Formate

Experion

Custom Algorithm Block and

Copyright 2004 by Honeywell International Inc.

Experion™ is a trademark of Honeywell International Inc.

Other brand or product names are trademarks of their respective owners.

Parameter Definition Editor Reference

Application Control Environment User Guide

Simulation ACE User Guide

Control Building Guide

Control Builder Components Reference

Control Builder Components Theory

Control Builder Parameter Reference

Honeywell organization WWW address (URL)

Industry Solutions http://www.acs.honeywell.com

Organization Phone number

United States Honeywell International Inc. 1-800-343-0228 Sales

Asia Pacific Honeywell Asia Pacific Inc. (852) 23 31 9133

Europe Honeywell PACE [32-2] 728-2711

Latin America Honeywell International Inc. (954) 845-2600

ATTENTION: Identifies information that requires special

TIP: Identifies advice or hints for the user, often in terms of

REFERENCE -EXTERNAL: Identifies an additional source of

REFERENCE - INTERNAL: Identifies an additional source of

CAB AND CDB PURPOSE ...................................................................55

CAB data characteristics ..................................................................................................... 72

CAB AND CDB SYSTEM PLANNING AND DESIGN .......................... 79

CAB AND CDB TYPE PLANNING AND DESIGN ............................... 91

CAB fixed definition parameters...........................................................................................97

CAB AND CDB INSTALLATION AND UPGRADE.............................107

CAB configuration procedures........................................................................................... 113

Remote communication with group integrity requirements.................................................155

Export CAB ....................................................................................................................... 190

CDB CONFIGURATION ..................................................................... 195

Discover CDB dependency relationships ...........................................................................222

CAB AND CDB EXAMPLE SCENARIOS ...........................................225

Two-dimensional array example........................................................................................ 258

CAB AND CDB OPERATIONS .......................................................... 285

CAB AND CDB SYSTEM ADMINISTRATION....................................293

CAB AND CDB TROUBLESHOOTING AND MAINTENANCE ..........303

FDPs that capture exception information .......................................................................... 311

CAB API REFERENCE ...................................................................... 347

GLOSSARY OF TERMS AND ACRONYMS.......................................383

Table 42 Access locks for CDPs ................................................................................. 204

Table 84 Custom data parameter classes ...................................................................353

Figure 27 Saving Modified CDB Types ....................................................................... 216

Who should use this guide

Terms and acronyms

What are Custom Algorithm Blocks?

What is a Custom Data Block?

Getting started tutorial

Description of the tutorial example

The tutorial is separated into four parts:

Create a CAB type

Parameter name: FLOW

Parameter description: Demo custom parameter

Data type: FLOAT64

Access lock: OPERATOR

Configuration load: LOAD

Default value: 2.2

Save the PDE data by clicking the indicated button.

A confirmation message appears briefly.

Instantiate the CAB type in a control strategy

Click OK to save the configuration and close the properties form.

7 Double-click the NUMERIC block to bring up its properties form.