Sie sind auf Seite 1von 518

System Configuration

D800010X072

2004-2006 Fisher-Rosemount Systems, Inc. All rights reserved.


Printed in USA
DeltaV, the DeltaV design, and PlantWeb are marks of one of the Emerson Process Management group of
companies. All other marks are property of their respective owners. The contents of this publication are
presented for informational purposes only, and while every effort has been made to ensure their accuracy, they
are not to be construed as warrantees or guarantees, expressed or implied, regarding the products or services
described herein or their use or applicability. All sales are governed by our terms and conditions, which are
available on request. We reserve the right to modify or improve the design or specification of such products at
any time without notice.

Contents
Developing the Control Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
System Capacities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Using Fieldbus Technology in the Control Strategy . . . . . . . . . . . . . . . . . . . . . . . . . 9
Using Fieldbus Blocks in the Control Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Deciding Where to Run Control Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Fieldbus Control Strategy Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Downloading the Block Configuration and Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Troubleshooting Fieldbus Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Changing Function Block Parameter Values in Fieldbus Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Parameter, Field, and Function Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35


Electronic Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Hiding Intellectual Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Protecting Your Engineering Standards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Expressions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Syntax Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Syntax for SFC Step Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Using the Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
I/O References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Matrix Parameter References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Inputs/Outputs of the Calc/Logic Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
External References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Internal References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Dynamic References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Diagnostic Parameters in Expressions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
SFC Commands and State Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Non-Stored Action Qualifier Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Stored Action Qualifier Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Overriding Reset (R) Qualifier for Resetting Stored Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Confirms for Pulse Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

iii

Alarms and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87


Alarms and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
System Alarm Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Alarm Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Alarm Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Custom Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Events and Alarms Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Collecting Alarm and Event Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

The Continuous Historian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131


Setting up the Continuous Historian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Configuring the Continuous Historian Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Configuring History Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
History Data Sets and Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
History Data Set Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
History Data Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Data Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Composite Ff Status Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Composite Historian Status Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Aggregate Functions Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Historian Run-Time Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Continuous Historian Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Continuous Historian Data Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Continuous Historian Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Continuous Historian Automated Backup Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Continuous Historian Excel Add-In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
The Legacy Historian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
DeltaV OPC Historical Data Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
DeltaV OPC History Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
OPC Historical Data Access Clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
OPCHDAClient.exe Sample Input Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Controller Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197


Auto-Sense Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Commissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Decommissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Inter-Controller Communications Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Controller Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Controller Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Preserving Configuration and Controller Data During Power Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

I/O Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210


I/O Card and Channel Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Card Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Channel Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
DeltaV Redundant I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Important Considerations for Using Redundant I/O Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Installing and Connecting Redundant Terminal Blocks and Series 2 Cards . . . . . . . . . . . . . . . . . . . . . . . . 231

iv

System Configuration

Switchover Causes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232


I/O Redundancy, Parameters and DSTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Auto-Sensing and Configuring Series 2 Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Identifying and Troubleshooting Series 2 Redundant Cards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Example Switchover Situations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
DeltaV Remote I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Device Signal Tags and SCADA Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Foundation Fieldbus Technology Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Communication Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
User Application Layer - Fieldbus in the DeltaV System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Fieldbus Devices General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Foundation Fieldbus Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Fieldbus Device Configuration Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Serial Devices and the DeltaV System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Maximum Number of Values for Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Modbus Function Codes Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Using Serial Data in Control Strategies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Serial Card Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Serial Card Data Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
HART Devices and the DeltaV System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Scaling HART Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Error Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Using Error Conditions for Control Strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Link Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
AS-Interface - General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
AS-Interface in the DeltaV System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Profibus DP - General Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Profibus DP in the DeltaV System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
DeviceNet - General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
DeviceNet in the DeltaV System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Configuring DeviceNet Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Using Profibus DP, DeviceNet, and AS-Interface with DeltaV Function Blocks . . . . . . . . . . . . . . . . . . . . . . . 314
Anti-Aliasing Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Overrange and Underrange Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
NAMUR Limit Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Failure Action Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
What Causes a Card to Enter Its Failure Action Mode? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Failure Action by Card Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Isolated Input Channel Error Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Outputs After a Self-Test Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Analog Output Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Discrete Output Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Integrating PROVOX and RS3 I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

Customizing the Process History View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321


Downloading Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

Uploading Recorded Parameter Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340


Referencing Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
System Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
DeltaV Configuration Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
DeltaV Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Control Studio Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Online and Debug Viewing of Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Online and Debug Viewing of SFCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Using Modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Composites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Recipe Studio Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
I/O Configuration Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
System Alarm Management Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Standard Exports and Imports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Export, Import, and Bulk Edit of Configuration Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
User-Defined Exports and Imports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
DeltaV-INtools Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
DeltaV Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
DeltaV Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479

Recommended Configuration Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481


Recommended Practices for Using Fieldbus and Profibus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Fieldbus Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Fieldbus System Capacities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Write Requests to Static or Non-Volatile Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Configure Communications Failure Modes for Fieldbus Valves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Put PID Algorithm in Final Control Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Inspect the Import Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Changing Series 1 H1 Card Type to Series 2 Card Type in DeltaV Explorer. . . . . . . . . . . . . . . . . . . . . . . 483
Profibus Failsafe Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Profibus Vendor Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Testing Target to Actual Integer Values in Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Recommended Practices for Configuring Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Estimate Controller Loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Installation Instructions from the DeltaV CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Naming Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Recommended Practices for Creating Pictures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
General Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
Use a One-Second Refresh Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
Monitor CPU Usage on Pictures with Object Run-Time Attributes Enabled . . . . . . . . . . . . . . . . . . . . . . . 486
Use Reserved Pictures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
Displaying Matrix Parameter Arrays in DeltaV Operate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
Creating Datalinks for Command and State Driven Algorithm Type Modules . . . . . . . . . . . . . . . . . . . . . 487
Recommended I/O Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487

vi

System Configuration

Using HART Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487


Controller Redundancy Configuration Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Configuring User-Defined RTD Input Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Configuring a Sequence of Events (SOE) Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Recommended Practices for Using DeltaV Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Determining When an SFC Action Completes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Creating and Using Source Linkages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Looping and Branching in Recipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Avoiding Infinite Loops in a Recipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Avoiding Extra Memory Usage on the Batch Executive Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Copying the Batch Operator Interface Configuration Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Segmenting Equipment into Specific IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Renaming a Batch Historian Workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Backing Up and Maintaining Batch Historian Archive Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Archiving Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Backing Up Archived Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Deleting Data from the Main Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Recommended Practices for Creating the Control Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Downloading Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Creating Custom Engineering Units Descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Understanding Expression Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Writing Expressions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Confirming an Action for a Pulse Qualifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Recommended Practices for General Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Interpreting Function Block Status Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Understanding DeltaV Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Naming Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Backing Up Continuous and Batch History Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Recommended Practices for Alarms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Using the Assign Alarm Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Suppressing Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Selecting Message Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Recommended Practices for Using Version Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Recommended Practices for Printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Adding Printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Printing to File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501

vii

viii

System Configuration

Developing the Control Strategy


The configuration engineer uses a top-down engineering approach to develop the control strategy for a DeltaV
system. The DeltaV system is divided into levels so that the users can choose the level of detail at which they want or
need to work. The following figure shows the levels into which the DeltaV system is divided:

Control Strategy Diagram


Typically, the configuration engineer follows this sequence:
1

Makes high-level decisions that apply to the overall system and plant and uses the DeltaV Explorer to define the
system characteristics. (The configuration engineer does not need to be concerned with lower details initially.)

Moves down a level in detail and decides how to logically divide system into areas. Areas are logical divisions of
a process control system. They can be physical plant locations or main processing functions.

Progresses another level and identifies the modules that control the field devices within those areas. The
configuration engineer can use the existing modules in the library as starting points for the modules required by
the control strategy.

All of the previous steps can be done in the DeltaV Explorer. Using the library provided, more than three-fourths of
the control strategy can be developed by duplicating existing library modules in the DeltaV Explorer. Then, the
Developing the Control Strategy

control strategy for the unique modules is defined using Control Studio. In Control Studio, engineers can define and
modify the control strategies, cut and paste a large portion of the configuration, and then fill in the details.
Engineers can also decide when to move to the next level of detail. In each level, most of the structure and
characteristics for typical control strategies are already configured for the engineer, except for minor details.
For example, module templates are used as a starting point for modules. The templates can define everything about
the type of control, except for a few operating parameters. Using this type of general approach, the engineers can lay
out the control strategies at each level, cut and paste the major pieces, fill in details, and then reveal the next level of
detail.
DeltaV software supports three types of common control languages for configuration: function blocks, sequential
function charts, and structured text. Within a single control module, you can intermix these control languages. For
example, a single module can leverage function blocks for closed loop analog control and Sequential Function Charts
to perform interlocking.
All three languages execute within the controller in their native form. There is no translation from one language to
another prior to execution.

System Configuration

System Capacities
The following tables specify the capacity values of the DeltaV system. Refer to Batch System Capacities for batchrelated capacity limits.
Inside this topic
Capacity Limits for System Topology
Capacity Limits for Workstations
Capacity Limits for Remote Networks and Workstations
Capacity Limits for Controllers
Capacity Limits for Remote I/O Nodes
Capacity Limits for SIS
Capacity Limits for System Topology
Description of System Capacity

Limit

Control Network nodes

120

Total simplex and redundant controllers


per control network (each redundant
controller pair counts as a single node)

1001

Remote I/O nodes per control network

602

Workstations per Control Network


(non-remote)

60 workstations3 consisting of:


1 ProfessionalPLUS Station
Up to 10 Professional Stations
Up to 59 Operator, Maintenance and/or
Base Stations
Up to 10 Application Stations (this is the
supported limit)

Remote workstations (using Remote


Access Services or RAS) per system

72 (10 on each of 7 Application Stations


and 2 on the ProfessionalPLUS Station).

Application Stations set up as RAS


servers

DeltaV Remote Clients


(using Windows Remote Desktop
Connection and Terminal Server)

7200 graphic data links on all displays


open through a terminal server4
60 database connections per terminal
server5
15 concurrent sessions per terminal
server6

DSTs per system

30,000 DSTs distributed among


controllers and Application Stations

SCADA tags per system

25,000

System Capacities

Description of System Capacity

Limit

Asset Manager Servers

50

1. This is a fixed system limit. The system does not permit the configuration of more
than 100 controller nodes.
2. Additional - not counted against Control Network nodes or controller nodes.
3. This is a fixed system limit. The system does not permit the configuration of more
than 60 workstation nodes.
4. Graphic updates slow considerably when the total data links exceeds 7200. No
warning message is given.
5. If the limit is reached, a message warns that the application can't connect to the
database and it shuts down.
6. This is a tested limit, not a fixed limit.
Capacity Limits for Workstations
Description of Workstation
Capacity

Limit

For ProfessionalPLUS, Professional,


Operator, Maintenance and Base Stations
with Appropriate Licenses Installed
Total Unique Display links for systems
using DeltaV Operate
The total includes: dynamic property
links per display and
real-time trends per display. Data links
typically count as one link.

<300
(recommended)
300 to 600
(performance degradation)
>600
(significant performance degradation)
>1000
(not supported)

Maximum open applications

30 (not all can be database connections)

Records per event chronicle

500,000

Maximum open DeltaV Explorer


applications

Maximum open Control Studio


applications

History values

250*

Open faceplates per module type

Open detail displays

Open pictures

30 (for proper operation, do not exceed


25.)

Workstation Object Identifiers

16,000

System Configuration

Description of Workstation
Capacity

Limit

For the ProfessionalPLUS Station only


Plant areas

100

Modules per unit

255

Named sets

1000 (includes system enumeration sets.


The number available to users is less.)

Alarm types

255

DeltaV user accounts per system

200

Parameters per security level

150

Maximum open engineering tasks on


Professional Workstations

60 (includes applications open on local


ProfessionalPLUS workstations)

Number of concurrent Professional


Workstations connected

For Application Stations only


OPC data values

30,000

Maximum assigned modules

1,500

DSTs for Data Acquisition and


Calculation Control

2,000

SCADA tags

25,000

History values

20,0001

* The continuous historian's ability to record values is dependent on the number of


values collected and the sampling period specified for those values in the Add or
Modify History Collection dialog box. To ensure that all values are collected,
configure the number of values and their sampling period such that the value of the
LOAD diagnostic parameter in the historian subsystem remains below 12%.
Alternatively configure the number of values and their sampling period such that the
value of ItemPSec remains below 2500.

System Capacities

Capacity Limits for Remote Networks and Workstations


Description of Workstation
Capacity

Fixed Limit

Remote workstations per


ProfessionalPLUS (where the
ProfessionalPLUS is acting as the Remote
Access Server)

2*

Remote workstations per Remote Access


Services (RAS) Application Station

10 total

*Additional remote workstations can access the ProfessionalPLUS for engineering data
if they use another machine as their Remote Access Server.
Capacity Limits for Controllers

Description of Controllers Capacity

Limit

Fastest module scan time

100 ms

Simultaneous online sessions

I/O cards per controller

64

DSTs per controller

750
Controller interfaced to PROVOX I/O 750
Controller interfaced to RS3 I/O - 750

SCADA tags

3,200

Modules1

750

Nesting levels per control module

Controller free time minimum2

10%

Controller free memory3

400K

Unsolicited data reporting4

Controller and remote I/O node - 2000


exception reports per second

Maximum incoming unsolicited exception


reports

250 per second

Maximum exception reports from one


node to another node

750 per second

Write operations per node

20 per second

Minimum reporting rate

Controller and remote I/O node- 500 ms

Controller Object Identifiers5

10,000

System Configuration

Description of Controllers Capacity

Limit

Virtual Control Object Identifiers5

16,000

Function Blocks per module

2506

1. The actual value might be less, depending on control strategy complexity.


2. Maintaining the free time above the recommended level ensures overhead to handle
plant upsets, alarm bursts, and so on. Controller redundancy affects controller loading,
as described below.
3. Maintaining the recommended amount of free memory ensures that modules can be
applied to the controller through a partial download, in most cases. Some SFCs or other
batch-related modules could require more than 400K of free memory to support partial
downloads. For batch controllers, several megabytes may be required to support the
configuration. Keep track of the value of the phase logic SIZE parameter and the value
of the controller FREMEM parameter to ensure that there is enough memory.
4. Develop configurations using a recommended limit of 1000 parameters per second
for the controller and remote I/O node. Exceeding these recommended limits may affect
system performance.
5. The controller uses object identifiers to keep track of remote items such as modules
with which it is communicating. Each connection with a remote item consumes one
object identifier. Maintain the FreOID parameter value above 2000. A FreOID
parameter value below 2000 may result in interrupted control and communication
failure. If the FreOID value is low, you can increase it by decreasing the number of one
or more of the following: the devices communicating with the controller, the modules
from which the controller reads data, the modules running in the controller, and various
I/O items (for example, associated I/O cards, channels, datasets, ports, and so on).
6. The practical number of function blocks per module depends on a number of factors
including configuration and associated I/O.
Controller redundancy has an impact on controller free time. Redundancy typically requires 20% more controller
CPU than the same configuration in a simplex controller. Larger configurations require more CPU time for
redundancy processing. A large configuration (for example, 300 modules) could require 25% or more of the
controller CPU for redundancy processing. The loading estimation tool might not adequately account for redundancy
CPU loading on systems with more than 150 modules. The controller loading estimation tool is included on the
DeltaV installation CD #4 in the _Support\Tools\LoadEstimator folder.
Capacity Limits for Remote I/O Nodes
Description of System Capacity

Fixed Limit

Remote I/O cards per Zone 2 Remote I/O Node

Remote I/O cards per Zone 1 Remote I/O Node

Controller assignment per I/O card

Controller assignment per Remote I/O Node

Remote I/O Node assignment per controller

16

System Capacities

Capacity Limits for SIS


Description of Capacity

Limit

Application Limits
Total function blocks per SIS module (including
blocks in composites)

250*

Function blocks in the top level of a SIS module

127*

Function blocks per composite block

127*

Levels of composite nesting in a SIS module

Logic Solver Limits


SIS modules in a Logic Solver

Secure parameters per Logic Solver

Logic Solvers per controllers

32 (simplex)

Logic Solvers that can publish data globally on one


controller

Logic Solvers per system that can publish globally

32

Non-secure parameter references per logic solver

24

Temporary variables defined using VAREND_VAR


per expression

32

Workstation Limits
Simulated Logic Solver Cards assigned to a
ProfessionalPLUS workstation with Windows Server
2003

Simulated Logic Solver Cards assigned to a


ProfessionalPLUS workstation with XP Professional

System Limits
SISNet Repeater pairs in a DeltaV system

32

SISNet repeater rings in a system

Secure parameters published globally per system

256

Logic Solvers

1024

* The actual value may be less depending on a number of factors


including: the complexity of SIS module configuration and the number
and type of SIS function blocks used.

System Configuration

Using Fieldbus Technology in the Control


Strategy
This book contains information on developing a control strategy that uses fieldbus technology.

Using Fieldbus Blocks in the Control Strategy


The following sections provide some guidelines for using fieldbus function blocks in DeltaV control applications.
Remember that all fieldbus function blocks in a control module must execute on the same fieldbus segment.
Use Only the Available Number of Links
Fieldbus devices allow a limited number of links between their function block parameters and parameters in other
fieldbus devices. Some devices support input and output links called publisher and subscriber VCRs and other
devices support links called Free VCRs. A subscriber VCR is an output from a fieldbus device to an input in another
device on the segment. The input device can be another fieldbus device or a controller. A publisher VCR is an output
from a DeltaV controller to the input of a parameter in a fieldbus device. For example, suppose a device allowed only
four links as inputs to their function blocks and only four links as outputs from their function blocks. This limit is
quickly reached if Feed Forward, Cascade, and Track control methods are used because these types of control require
more inputs and outputs. During application configuration, the DeltaV system notifies you if the subscriber or
publisher limit for a device has been reached. Refer to the VCR Specifications topic for the maximum number of
subscriber and publisher links supported by fieldbus devices that use these types of links.
Free VCRs function as either input or output links or device alarms. Device alarms require one Free VCR. For
example, if a device supports five Free VCRs and one Free VCR is used for a device alarm, then four Free VCRs are
available to the device. Refer to the VCR Specifications topic for the maximum number of Free VCRs supported by
devices that use these types of links.
Understanding Module Scan Rate and Macrocycles
The module scan rate as defined in Control Studio and the macrocycle are independent. The module scan rate
determines how often the module executes while the macrocycle determines how often the fieldbus function blocks
on the port execute.
Note Each segment that is connected to a Series 2 H1 card is capable of supporting at least one, 100 or 200 ms
module by setting the requested macrocycle to 150 ms. To avoid communications problems such as download
timeouts and slow AMS updates, keep the number of devices on the segment to a minimum if a 150 ms macrocycle is
used.
The requested macrocycle is the user-specified execution time for all the fieldbus function blocks on the segment.
The calculated macrocycle time (calculated by the DeltaV system) includes an adjustment that allocates time for
unscheduled data transfers. Use the DeltaV Explorer to specify the requested macrocycle, read the calculated
macrocycle and minimum schedule spacing, and display a visual representation of the macrocycle. To specify the
requested macrocycle, click the right mouse button on the fieldbus port, click Properties, and then click the General
tab. The actual macrocycle is the greater of the requested or calculated macrocycle. Click the Advanced tab to read
the minimum schedule spacing. The minimum schedule spacing is the spacing between consecutive compel data
messages. This value is writeable to maintain compatibility with older fieldbus devices; however, it should be
changed only if recommended by Emerson Process Management. Reducing the value can cause communication
problems and increasing the value can reduce control loop performance. The default value has been tested to work

Using Fieldbus Technology in the Control Strategy

properly with all approved fieldbus devices. To access a visual representation of the macrocycle, click the View
Schedule button on the Advanced tab to launch the Macrocycle Viewer application.
Use these guidelines to determine the actual macrocycle:
1

The actual macrocycle is equal to the requested macrocycle if the calculated macrocycle is less than or equal to
(<=) the requested macrocycle.

The actual macrocycle is equal to the calculated macrocycle if the calculated macrocycle is greater than (>) the
requested macrocycle. The following table provides some examples that show how the actual macrocycle is
determined:
If the requested
macrocycle is:

and the calculated


macrocycle is:

then the actual


macrocycle is:

1 second

0.6 seconds

1 second

1 second

1.2 seconds

1.2 seconds

0.5 seconds

1 second

1 second

0.5 seconds

0.8 seconds

0.8 seconds

Understanding the Stale Link Count Limit


The DeltaV software automatically configures a Stale Link Count Limit parameter for communication between
fieldbus devices and for communication between the DeltaV system and fieldbus devices. The Stale Link Count
Limit specifies the number of communications that can be missed before the parameter status is set to BAD. If the
limit is set too low (for example, if it is set to one), then inputs can be set momentarily to BAD and control can go to
MANUAL under normal operations. The default Stale Link Count Limit for the DeltaV software is three for
communications between fieldbus devices. The DeltaV system can set the Stale Link Count Limit to more than three
for communications between the DeltaV Controller and the fieldbus if the module execution rate is faster than the
schedule macrocycle.
Note This parameter is automatically set by the DeltaV system and is not user configurable.
Use a Conservative Scan Rate to Minimize Segment Loading
For function blocks that are assigned to fieldbus devices, the module and block scan rates determine how fast the
controller updates the block parameters over the fieldbus segment. It is highly recommended that the scan rates be as
slow as the application can tolerate to minimize communications loading on the fieldbus segment.
Limit Write Requests to Fieldbus Function Block Parameters
Because of the effect on the segment's bandwidth, it is recommended that you limit write requests to fieldbus function
blocks to three (no more than 30 outstanding requests per controller for any one time) and use write requests only
when necessary. Like module execution times, write requests can impact the rate at which the View List is scanned
and can use up a good deal of the fieldbus bandwidth. For example, if a Calc block's output is linked to an external
reference that is tied to the SP of a fieldbus PID block, the system will attempt a write of the value (over the fieldbus)
to the fieldbus device with each execution of the module.

10

System Configuration

Note Be especially careful when using periodic writes to static fieldbus parameters in an expression since this type of
write can increment the block's static revision parameter (ST_REV), which then causes the controller to issue two
more requests to read static View List data. Refer to the Fieldbus Foundation specification for more information on
the View List. For the DeltaV system, VIEW_3 is constantly being read, but VIEW_4 is requested when the static
revision counter (contained in VIEW_3) is incremented.
Limit Periodic Writes to Static or Non-Volatile Parameters
It is recommended that you limit the number of periodic writes to all static or non-volatile parameters such as
HI_HI_LIM, LOW_CUT, SP, TRACK_IN_D, OUT, IO_OPTS, BIAS, STATUS_OPTS, SP_HI_LIM, and so on.
Static parameter writes increment the static revision counter, ST_REV, and are written to the device's non-volatile
memory. Consult the device documentation to determine if a parameter is static or non-volatile. If writes to a static
parameter are unavoidable, it is recommended that the module logic first read the parameter value, then compare the
existing value to the new value, and write the new value only if it is outside an acceptable deadband.
Note Fieldbus devices have a non-volatile memory write limit. If a static or non-volatile parameter is configured to
be written periodically, the device can stop its normal operation or fail to accept new values after it reaches its limit.
Use Valid Input and Output Links
When linking to fieldbus resident function block parameters, the DeltaV system restricts users to only input and
output parameters. Other non-linkable parameters are not visible for the links. Similarly, Show and Hide parameters
are not supported for fieldbus function blocks.
Use Valid Channel Assignments
Fieldbus Input (AI) and Output (AO) function blocks must have a valid channel number for device signals. When you
configure a fieldbus AI and AO block, you must set the channel parameter to a valid number or the blocks will remain
in OOS mode. Refer to the device documentation and to the Valid Units and Channel Values for Fieldbus Devices
topic.
Use Valid XD_SCALE
Fieldbus Input (AI) and Output (AO) function blocks must have a valid XD-SCALE. When you configure fieldbus
AI and AO function blocks, you must set valid XD-SCALE units or the block will remain in OOS. Only the AI
function block XD-SCALE units can change the units in the transducer. XD_SCALE EU100 and EU0 do not have to
match because only XD_SCALE units are transferred to the transducer block. Check proper scale and unit
information using the transducer block properties for the specific transmitter. To find units for a device, refer to the
Valid Units and Channel Values for Fieldbus Devices topic.
Assign Fieldbus Function Blocks to Devices
If a module contains any <unassigned> fieldbus function blocks, the LAS is unable to generate the schedule for the
entire module even if the module contains properly linked and assigned function blocks.
You are notified of any <unassigned> modules during a download of the fieldbus device. In Control Studio, click the
right mouse button on the function block and then click Assign to Fieldbus Device.
Configuring Fieldbus Function Block Tags
Fieldbus function block tags configured in the DeltaV Explorer are included in device downloads. This means that
the function block tag in the DeltaV system matches the tag in the device. As a result, users reading function block

Using Fieldbus Technology in the Control Strategy

11

tags directly from a device can easily locate that function block in the DeltaV system and vice versa. Here are a few
things to keep in mind about naming fieldbus function blocks:
1

It is recommended that function block tags in a fieldbus device are not changed with a handheld digital device.

Changing a function block tag in the DeltaV Explorer requires a device download.

When a function block tag is changed in the DeltaV Explorer, a blue triangle appears on the device indicating
that the change must be downloaded to the device to synchronize the device database with the DeltaV database.

When a device is downloaded, control and I/O running in the device is suspended. Be sure to follow appropriate
control safeguards.

Download Modules First After Replacing Fieldbus Devices


After a fieldbus device or revision is replaced manually, blue triangles ( ) appear on the port, the device, and any
function blocks assigned to the device. The blue triangle indicates that the item needs to be downloaded. First,
determine if any modules assigned to the port require a download. If so, download the module and take the default
option to include the port and the device in the download.

12

System Configuration

Deciding Where to Run Control Function Blocks


Certain control function blocks can run in the fieldbus devices or in the DeltaV controller. This topic discusses the
pros and cons of each method.
Consider a simple regulatory control loop with an AI, PID, and AO function block. The AI block must run in the
transmitter and the AO block must run in the valve. The PID block can run in either of the field devices or in the
DeltaV Controller. The configuration of the control module's function block diagram is similar regardless of where
the PID algorithm runs. The difference is in how you assign the PID block. In DeltaV Control Studio, you can assign
the PID block to fieldbus and run it in either the transmitter or valve, or you can drag the PID block off the palette and
run it in the controller.
Following is a summary of the advantages of each method.
Running the PID block in the device:

improves controllability due to


synchronous execution
conserves controller CPU resources
reduces the number of VCRs on the
segment

Running the PID block in the


controller:

provides additional control options,


such as form and structure
can facilitate conditioning of the input
and output, if required

Running the PID Block in the Fieldbus Device


Synchronous Execution Improves Controllability
For typical PID loops, control performance is about the same when it is done in the DeltaV Controller with classic I/
O or on a fieldbus segment within the devices. This may not be true with hybrid control where the control loop spans
the fieldbus segment and the controller. This issue involves sampling rates and synchronous versus asynchronous
execution and is not limited to the DeltaV software. Any time a host system provides the control using fieldbus
devices on an H1 segment, control performance can be sacrificed unless the loop dynamics are sufficiently slow.
To understand why control performance can be compromised with hybrid control, compare control in the DeltaV
controller using classic I/O with control in fieldbus devices. Control in the controller is asynchronous, that is, the
execution of control modules and function blocks is not synchronized with the execution of the I/O cards or I/O bus
communication. But analog I/O cards scan at a fast rate (around 25 milliseconds) and I/O bus communication is fast
(typically between 20 and 80 milliseconds depending on the number and mix of I/O cards). Even though all these
elements are asynchronous, a control module can easily execute at a scan rate of 500 milliseconds without violating
the rule of thumb that the control interval be at least three times slower than the longest asynchronous sampler.
Control on the H1 fieldbus segment is synchronous, but the execution rate is somewhat slow due to the low
bandwidth bus and low power processors used in the devices. Execution of function blocks on an H1 segment is
scheduled in a given scan (called the macrocycle) such that an AI function block in a transmitter executes before the
PID block (in the transmitter or valve), which executes before the AO block in the valve. The LAS (Link Active
Scheduler), normally the H1 interface card, orchestrates the communication between devices over the fieldbus such
that block execution and communication are synchronized. The achievable macrocycle time on a segment is a
function of the number and type of devices on the segment and the amount of control and monitoring configured. As
a result, it is possible to limit the number of devices on a segment to achieve the desired macrocycle, say 500
milliseconds to 1 second. Synchronous control on the H1 segment at the macrocycle rate is as good or better than
control in the controller at the same control interval.

Using Fieldbus Technology in the Control Strategy

13

Control performance becomes an issue if the PID block runs in the controller and the AI and AO blocks run in
devices on the segment. In this case, the AI and AO blocks execute once each macrocycle, but execution and
communication with the PID block in the controller is asynchronous. The difference between this hybrid control and
control in the controller using classic I/O is that with classic I/O, input and output data can be transferred to and from
the I/O bus every 25 milliseconds. With hybrid control, this transfer of data occurs at the macrocycle rate of about
500 milliseconds to 1 second. There is no real control benefit achieved by executing the PID block in the controller
faster than three times the macrocycle rate. If the macrocycle is 500 milliseconds, the fastest control interval of
benefit is 2 seconds. A 1 second macrocycle supports a practical control interval no faster than the 5 second option.
Therefore, hybrid control can compromise the controllability of loops with fast dynamics.
As can be seen in the Macrocycle Viewer, when one or more blocks run in the controller, the control loop is not
synchronized to the macrocycle and all blocks in the control loop run at the beginning of the macrocycle followed by
scheduled Compel Data transfer messages. This allows the H1 card to optimize non-scheduled communication since
all scheduled CD messages occur successively and devices that quickly respond with CD response messages will free
up additional bandwidth for unscheduled traffic.
Conserves Controller CPU Resources
Running a function block in a field device instead of in the controller reduces the block's controller CPU demand by
approximately 50 percent. Running the block in the device eliminates the demand on the controller CPU caused by
the execution of the block's control algorithm. However, there is processing required to communicate view list data
between the field block and the extended block (sometimes called a shadow block) in the controller. The net result is
about a 50 percent reduction in controller CPU resources when the block resides in the device.
Reduces the Number of VCRs on the Segment
There are two types of VCRs (Virtual Communication Relationships) on each port: publisher and subscriber VCRs.
An H1 interface card can support up to 50 total publisher and subscriber links on each port. Running the PID block in
the controller consumes three VCRs on the port for one simple loop. Running the PID block in the transmitter
consumes two VCRs and running it in the valve consumes one VCR. Running one VCR or two VCRs does not
significantly reduce the number of devices the segment will support. However, using three VCRs for a simple loop
can significantly reduce the number of devices the segment will support.
Running the PID Block in the DeltaV Controller
Provides Additional Control Options
The FFPID extended block may not support all the parameters supported by the PID block in the fieldbus device. You
can configure the full set of parameters when the PID block runs in the controller. Or, you can use the FFPID_RMT
extended block with compatible devices to use the full set of parameters.
May Facilitate Input Output Conditioning (if required)
When a control loop goes beyond the simple AI-PID-AO combination, there may be a rationale for having the PID
block reside in the controller. In most cases however, there are calculation blocks available in fieldbus devices for this
purpose. Examples of conditioning include, but are not limited to the following:

selecting the input from multiple sensors

compensating a flow for temperature and pressure

characterizing the control output

rate limiting the control output during a startup or shutdown situation

If you find it necessary to perform this type of conditioning in the controller, you do not lose anything by also running
the PID block in the controller because anything done in the controller (such as conditioning) eliminates synchronous

14

System Configuration

control. However, it is usually possible for the entire loop to reside in field devices on the segment, thus maintaining
synchronous execution. For example:

Use the Input Selector function block to select the input from multiple sensors.

Use the Arithmetic block for pressure-temperature compensation.

Use the Signal Characterizer block to characterize both the forward and backward paths of the control
output.

Enable rate limiting by placing the AO block in Auto mode and manipulating the setpoint during startup or
shutdown (Setpoint rate limits apply in Auto mode but not in Cas mode).

Using Fieldbus Technology in the Control Strategy

15

Fieldbus Control Strategy Procedures


Inside this topic
Define the Control Strategy
Select the Blocks
Assign Blocks to Fieldbus
Configure Parameters
Connect Inputs and Outputs
Assigning the Strategy to a Node
Saving a Strategy
This document explains how to use the DeltaV applications to implement a control strategy that includes fieldbus
devices. This is not a comprehensive resource as requirements for a host system, such as the DeltaV system, differ
between devices but, rather, a starting point. For complete information, refer to the device's user manuals, the online
help for the DeltaV applications, and related Books Online topics.
Define the Control Strategy
No more than 64 field function blocks can be assigned to any H1 card. An H1 card can support two fieldbus
segments. A maximum of 16 devices and 32 function blocks can run on a segment.
You use the DeltaV Control Studio application to create the control strategy. You can start Control Studio from the
task bar by clicking Start | DeltaV Engineering | Control Studio, or you can launch Control Studio from the
Applications menu in the DeltaV Explorer. Remember that Control Studio has extensive online help. You can access
the help through the Help menu (Help/Control Studio Help Topics), the "What's this?" commands (select an object
and click the right mouse button), and the context-sensitive help on the dialog boxes.
Defining the control strategy consists of selecting the blocks you want to use, assigning the blocks to run in a fieldbus
device or in the controller, configuring the blocks' parameters, and connecting the blocks' inputs and outputs. Then
you assign the strategy to a node, save the strategy, commission the device, and download the device and strategy.
You will use several Control Studio window panes to define the control strategy: the Palette, Diagram, and Parameter
panes. The following image shows a basic strategy and points out the Control Studio window panes that are used to
create it.

16

System Configuration

For this example, we will use a basic control strategy composed of an AI, AO, and PID block, and we will configure
one parameter for an AI block. The intent of this example is to explain how to use the DeltaV Control Studio
application to create a control strategy - not to show you how to create a control strategy for a particular device.
Consult your device documentation for function block parameter definitions and recommended values and other
configuration options for your device.
Selecting the Blocks
Click the down arrow in the list box at the top of the palette and select IO. This makes the I/O function blocks
available to you.
1

Drag the Analog Input function block from the palette to the diagram pane to create a generic AI block. The
handles around the AI block indicate that it is selected.

At this point, you may want to rename the AI block to make it meaningful to you. Select the block with the right
mouse button and click Rename.

Assigning Blocks to Fieldbus


For information on how assigning blocks to fieldbus devices affects loop performance and how you can achieve
maximum performance, refer to the topic Using DeltaV Tune with Fieldbus Devices.
Now we will assign the AI block to a fieldbus device. Remember that for fieldbus, blocks can run in either the
controller or the fieldbus devices. The decision about where to run the blocks is based on your requirements, and

Using Fieldbus Technology in the Control Strategy

17

there are pros and cons to each method. Refer to the Deciding Where to Run Control Function Blocks topic for help
in making the decision. For this exercise, we will run the blocks in the device.
1

18

Select the block with the right mouse button and click Assign I/O | To Fieldbus. (To run the blocks in a controller,
click Assign I/O | To Signal Tag.)

System Configuration

Click the Browse button and find the device to which you want to assign this block. Navigate through the
controller, I/O card, port, and device to get to the blocks. Some devices may have more than one AI block
because the device may be capable of outputting more than one variable. In this image, the device, PDT2, has
two AI blocks: FFAI1 and FFA12.

Select one of the AI blocks and click OK. Now that the block has been assigned to a device, we will configure a
parameter for the device.

For information on how assigning blocks to fieldbus devices affects loop performance and how you can achieve
maximum performance, refer to the topic Using DeltaV Tune with Fieldbus Devices.
Configuring the Parameters
If it is not already selected, select the AI block, and you will see its default set of parameters listed in the parameter
pane. In order for the device to work properly, you must configure the device's parameters.
1

Double-click Filtered by at the top of the parameter list.

This opens the Parameter Filtering dialog.

Using Fieldbus Technology in the Control Strategy

19

Click the Select All button to make all parameters visible to you.

The CHANNEL and XD_SCALE parameters must be correctly configured for AI and AO blocks or a configuration
error will occur when the device is downloaded.

20

System Configuration

Let's take the CHANNEL parameter as an example of how to configure a parameter. Because each device may be
capable of more than one measurement, when you configure an AI block, you specify which measurement you want
the block to process. The value for the CHANNEL parameter tells the block which measurement to process.
3

Double-click the CHANNEL parameter to open the Properties dialog for this parameter. The device
manufacturer publishes valid values for the channels, and much of this information is available in DeltaV Books
Online. Now, we'll find that information in books online.

Using Fieldbus Technology in the Control Strategy

21

Select the question mark


in the upper right corner of the dialog, drag it to the Value field, and press the left
mouse button. This opens context-sensitive help for the Value field.

The help contains a link to the Valid Units and Channel Values for Fieldbus Devices topic. Click the link to open
this topic in DeltaV Books Online. Once in Books Online, click your device in the list of devices to find the valid
units and channel values for the device.

Enter that value in the Value field and click OK.

Now you know how to configure a parameter for a block. Experiment with Control Studio and open the Properties
dialog boxes for other AI parameters or drag another block onto the diagram and look at its parameters. When you are
ready, configure the other blocks in your control strategy. Consult the device documentation for recommended
parameter values. Then, connect all inputs and outputs, assign the strategy to a node, and save and download the
strategy.
Connecting Inputs and Outputs
Algorithms that determine how information is exchanged between devices run in the background in Control Studio.
You wire the blocks together in Control Studio to create the algorithms that describe how you want the blocks to
execute. The output of one block flows into another block as an input. In our example control strategy, the output of
the AI block flows into the PID block as input, the output of the PID block flows into the AO block as input, and so
on.

22

System Configuration

To wire blocks together:


1

Click the connection point where you want the wire to begin. The cursor turns into a

Hold the left mouse button down and drag the cursor to the end point.

Release the left mouse button at the end point and the line is drawn between the two points.

If you have trouble drawing the connections, use the Connection tool

on the toolbar.

Assigning the Strategy to a Node


Now, you assign the strategy to a node to tell the DeltaV system where it will run. A strategy can be assigned to a
workstation or a controller. Generally, control strategies run in a controller.

Click the Assign to Node button

on the toolbar.

Select the controller to which you want to assign the module and click OK.

Saving a Strategy
Once you have created your control strategy and assigned it to a node, you must save it. A strategy is saved as a
module.
1

Click File | Save.

In the Look in: box, select the location (Area) where you want the strategy to run.

Name the module and click Save.

Using Fieldbus Technology in the Control Strategy

23

Downloading the Block Configuration and Strategy


Inside this topic
Confirming a Module's Operation
Using Methods
Configuring Device Parameters
You have assigned the strategy to a node, saved it, reconciled differences between the device and placeholder, and
commissioned the device. The changes you have made are stored in the DeltaV database but have not yet been
written to the device. The DeltaV system places a blue triangle next to the device in DeltaV Explorer to indicate that
the device needs to be downloaded.

Select the device with the right mouse button and click Download | Fieldbus Device. DeltaV software informs
you if items subordinate to this one also need to be downloaded and can verify the configuration if you choose.

Make sure the modules associated with the devices on the segment have been downloaded. The module
information must be sent to the H1 card before devices are downloaded.

Read the important Warning and if you are sure you want to download, click Yes.

When the download is complete, the blue triangle disappears from the device.

There may be other blue triangles in the DeltaV Explorer hierarchy. Download those items if you are comfortable
doing so or read the DeltaV Explorer help on downloading for more information.
Confirming a Module's Correct Operation
Control Studio's On-line mode is a powerful tool for confirming a module's correct operation and for diagnosing
module problems. You must assign and download a module before you can view it in On-line mode.
1

Open the module in Control Studio.

Click View | On-line to create an online session in which you can examine module and block parameters.

If the module is operating correctly, the outputs are displayed next to the block.

If there is a problem with a function block, a red X appears on the function block. To determine the source of the
problem, perform the following steps:

Check the BLOCK_ERR parameter (double-click a parameter to edit it) and determine if the block is out of
service (OOS) or if it has a block configuration error. Among the problems that can cause a block to be out
of service are misconfiguration, bad sensor input, and problems with the download.

Check the status of the block's input and output parameters. For example, a status of BadNoCom indicates
that information is not being sent to the block's inputs.

If the block has a bad PV, verify that the correct XD_SCALE, UNITS, and RANGE are transferred.

If the data has intermittent bad status, check the required macrocycle and the module execution rate. The
module execution rate should be >= 2 times the actual macrocycle.

Remember that if you make any changes in On-line mode, the changes are not saved in the database. Use Control
Studio or Explorer to upload the changes to the database.

24

System Configuration

Using Methods
For the example, we'll use the Set Sensor Connections method to configure the sensor connections for a Rosemount
Multivariable Temperature Transmitter, Model 3244 MV. The interface to this method is much like a software Wizard
and the method resides in the Transducer block for this device. Refer to the Device Descriptions and Methods topic
for more information about methods. Depending upon the type of device you are working with, you might have to put
AI and AO blocks in Out of Service or Manual mode before running a method. (Refer to the device documentation
for a description of the methods available for the device.)
1

Select the device, click the right mouse button on the Transducer block, and select Sensor Config | Set Sensor
Connections.

Select the sensor that you want to configure and click Next.

Using Fieldbus Technology in the Control Strategy

25

Click the down arrow on the list box, select the sensor type, and click Next.

Click the down arrow on the list box, and select the sensor connection type (2, 3, or 4-wire connection).

When the configuration is complete, click Finish.

Configuring Device Parameters


Use the DeltaV Explorer to view current device parameters and change parameter values. The parameters are
grouped on tabs associated with the Resource and Transducer blocks.

26

System Configuration

Select the device with the right mouse button and click Configure.

The Device Configuration dialog box opens. The Resource block parameters are displayed by default when the dialog
opens.

Using Fieldbus Technology in the Control Strategy

27

The tabs along the top of the dialog indicate the various parameter groupings. Click a tab to view the parameter
values.

Enter or select new values for parameters that can be edited. When you edit a value, the tab and edited field
changes to yellow.

Remember that help is available for any of the fields on this dialog. Select the
the field for which you want help, and click the mouse button.

in the upper right corner, drag it to

Click the Transducer block to view and edit the Transducer block parameters.

Click the tabs to view parameter values and enter or select new values for editable parameters.

When you are finished, either click the OK button to commit parameter changes and close the dialog box or click
the Apply button to commit parameter changes and continue working in this dialog box.

28

System Configuration

Troubleshooting Fieldbus Loops


Confirm this information before proceeding with troubleshooting.

Can't Download a Module

Can't Download a Port

Can't Download a Device

Don't Understand Block Errors

Intermittent Block Errors

Output Blocks are not Tracking a Valve's Actual Position

PID Block's Actual Mode is Stuck in IMAN

Can't Commission a Device

A Valve is Hunting

Devices are Dropping Off the Segment

Confirm this Information Before Proceeding with Troubleshooting


Your devices are fieldbus-registered and Emerson-approved. Visit www.easydeltav.com/keytechnologies/fieldbus/
index.asp to confirm that your devices are registered and approved.
Your segment is properly terminated, grounded, and wired. Use the Fieldbus Segment Checkout Procedure to confirm
these conditions.
The H1 card is communicating with the DeltaV system. Use the H1 Card's LEDs to monitor communication between
the card, controller, and devices.
The ports on the H1 card are enabled. Check that Enabled is selected on the Port's Property page in DeltaV Explorer.
Your devices are commissioned. Be sure that there are no yellow exclamation points (
DeltaV Explorer or check the device state in DeltaV Diagnostics.

)on the device in the

You have the most recent firmware updates for the H1 card and controller. Run the DeltaV Controller Update Utility
to upgrade the firmware.
You have read the device documentation and know the function block parameter definitions and recommended values
and other configuration options for your device.
You have the most recent version of the Fieldbus Specification for reference. Visit the Fieldbus Foundations website
at www.fieldbus.org to learn how to get the most recent version of the specification.
Can't Download a Module

Look for Red Xs (

) on the module diagram in Control Studio online or debug. Common errors are:

Incorrect function block MODE: A red X on an AI or AO block could indicate an incorrect mode. Typically, an
incorrect mode causes unexpected block output, static output values, or no signal from an active transmitter. Be sure
that the Target and Actual modes for the AI block is AUTO and the Target and Actual modes for the AO block is
CASCADE.
Incorrect Transducer or Resource block MODE: Also check that the Transducer and Resource blocks' Actual
modes are AUTO. Be sure that a Transducer block that configures a Primary, Secondary, or Tertiary variable is in

Using Fieldbus Technology in the Control Strategy

29

AUTO mode. If it is in Out of Service (OOS) mode, the PV value on a function block that references a channel will
be bad. Be aware that some devices make use of a default Transducer block mode such as Manual to facilitate device
commissioning. It is possible that a default Transducer block mode is contributing to loop inoperability.
Incorrect CHANNEL: A red X on an AI block, an unexpected AI value, or a transmitter or valve that does not return
a value could indicate an incorrect channel. Because each device may be capable of more than one measurement,
when you configure an AI block you must specify which measurement you want the block to process. The value for
the CHANNEL parameter tells the block which measurement to process. The device manufacturer publishes valid
channel values and much of this information is available in DeltaV Books Online. It is possible that the value for the
CHANNEL parameter changed between device revisions and an incorrect channel number and or Engineering Units
is in use. To find the correct channel number in Books Online, select the channel parameter in the parameter view
window, select What's This from the context menu, and follow the link to the Valid Units and Channel Values for
Fieldbus Devices topic.
Tip Use Event Viewer if you're having problems isolating module parameters that failed to download. Open the
Event Viewer and, in the Desc2 column, look for the block and parameter associated with Attribute Override
Failure:MODULE/PARAMETER. For example Attribute Override Failure:AI1/XD_SCALE.
Incorrect choices for L_TYPE parameter: An incorrect choice for L_TYPE parameter can cause a red X on a
fieldbus function block in Control Studio. If L_TYPE is set for Indirect or Indirect Square Root and the XD_SCALE
is set incorrectly for the type and channel of the device, an error can occur. A red X can occur if L_TYPE is set to
Direct and the device requires that OUT_SCALE equals the XD_SCALE or if the device does not support Direct for
L_TYPE.
Incorrect choice of Engineering Units in XD_SCALE: A red X on a fieldbus function block in Control Studio or
the block going to Out of Service could indicate an incorrect choice of Engineering Units (EU) in XD_SCALE
depending upon the setting of the L_TYPE parameter. Some fieldbus functions blocks use an XD_SCALE parameter
that defines scaling ranges, engineering units, and the number of decimal places used to display the engineering units
associated with the channel input value. An incorrect EU value will cause an Attribute Override Failure which will be
listed in the Event Viewer (see the preceding Tip). The Primary Value Type configured in the Transducer block
should match the EU configured in the fieldbus block. The majority of fieldbus devices can be configured through the
EU in the XD_SCALE parameter.
Incorrect choice of Engineering Units in OUT_SCALE: A red X on a fieldbus function block in Control Studio or
the block going to Out of Service could indicate an incorrect choice of Engineering Units (EU) in OUT_SCALE
depending upon the setting of the L_TYPE parameter. Some fieldbus functions blocks use an OUT_SCALE
parameter that defines scaling ranges, engineering units, and the number of decimal places used to display the
engineering units associated with the OUT value of the fieldbus function block. An incorrect EU value will cause an
Attribute Override Failure which will be listed in the Event Viewer. A configuration error can occur if the Primary
Value Type configured in the Transducer block does not match the OUT_SCALE EU configured in the fieldbus
function block.
Block Out of Service: A red X on a block in Control Studio could indicate that the block is Out of Service (OOS).
This can be caused by a device problem or can occur if the Resource and/or Transducer block is OOS. Select the
device in DeltaV Explorer and click Status/ Conditions to access the device's Resource and Transducer blocks. The
status should be clear with no errors. Use DeltaV Diagnostics and look at device communication statistics and port
communication statistics and check the port integrity.
Bad status on input block's PV: Bad status on an input block's PV can be caused by incorrect choice of Engineering
Units (EU) and range in the XD_SCALE parameter or an incorrect output value in the Transducer block. The Primary
Value Type in the Transducer block should match the EU configured for the AI or AO block.

30

System Configuration

Note The use of bad status on an input block's PV can be a design decision. For example, it can be used to show that
the input PV or status propagation from a linked block is outside a qualified range.
SHED_OPT is zero: A red X on an AO or DO block in Control Studio online could indicate that the value for
SHED_OPT is zero. The value for SHED_OPT must be non-zero.
A module may fail to download because the device will not download. Refer to Can't Download a Device to ensure
that the problem does not originate at the device.
Can't Download a Port
Often, a port will fail to download because a module or modules is not downloaded. Use the Event Viewer to isolate
parameters that failed to download. Open the Event Viewer (click Start | DeltaV |Operator | Process History View)
and in the Desc 2 column of the event grid look for the block and parameter associated with Attribute Override
Failure.
Also, in DeltaV Explorer check for blue triangles
on modules assigned to controllers. A blue triangle indicates an
item that needs downloading. Modules with extended blocks, (a DeltaV function block that communicates with a
function block running in a fieldbus device) must be downloaded before the port to which the device is connected is
downloaded.
Common module download failures are described in Can't Download a Module.
Don't Understand Block Errors

Function block errors show up as yellow question marks (


) in Control Studio online. DeltaV function blocks,
including those capable of running in fieldbus devices, report standard function block error information through the
BLOCK_ERR parameter. Each block's BLOCK_ERR parameter is documented in Books Online. Function blocks
that run in fieldbus devices report additional, device-specific block error information through BLOCK_ERR. You
must refer to the device documentation to understand these device-specific errors. Also, more information on device
block errors may be available from the device's Status/Conditions context menu item. Refer to the Fieldbus Devices
topic for more information on status conditions. Among the most common block errors seen with the DeltaV system
are Out of Service, Input Failure/Bad PV, Configuration Error, Link Configuration Error:
Out of Service: One or more of the blocks (function block, Resource block, Transducer block) is in Out of Service
(OOS) mode. To see the function block mode, look at its MODE parameter in Control Studio. To see the Resource
and Transducer blocks' mode, select the device in DeltaV Explorer, select Status | Conditions, and look for the mode
information.
Input Failure/Bad PV: Often, this is caused by an incorrect channel, incorrect choices in the XD_SCALE parameter,
failures in the Transducer block, or the Transducer block is in OOS mode.
Configuration Error: Most likely this is caused by an incorrect channel and/or incorrect choices in the XD_SCALE
parameter.
Link Configuration Error: This is often device-specific and could mean that the device does not accept a certain
configuration or a link is improperly configured. For example, not all devices support a configuration in which two
fieldbus links from one function block output running in one fieldbus device are connected to two inputs in another
device. Refer to the device documentation's description for this block error.

Using Fieldbus Technology in the Control Strategy

31

Device-Specific Errors
The following errors refer to internal device errors that may be serious and may require service or device
replacement. Refer to the device documentation if you encounter these errors:
Lost NV Data
Lost Static Data
Memory Failure
The following errors are used by the manufacturer to alert users of a possible device problem and to alert users that
the device needs maintenance now or in the near future:
Device Needs Maintenance Now
Device Needs Maintenance Soon
Intermittent Block Errors
Intermittent function block errors that show up as a red X on an output in Control Studio in online mode and/or block
errors that come and go in Event Viewer could be caused by an incorrect module execution time or an incorrect
requested macrocycle. The module execution time and the macrocycles are independent. Module execution time
determines how often a module executes while the macrocycle is the execution time for a single iteration of the
fieldbus function blocks running in all the devices on the port. The requested macrocycle is user-specified and the
calculated macrocycle is system-calculated. The calculated macrocycle time includes an adjustment that allocates
time for unscheduled data transfers. As a rule of thumb, the module execution time should be >= 2 times the
calculated macrocycle. Modules with all blocks running in field devices can run with a module execution rate equal
to or greater than the macrocycle.
Output Blocks are not Tracking a Valve's Actual Position
If an output block (AO or DO) is not tracking an actual valve position, try selecting Output Readback in the device's
Resource block if the device supports Output Readback. When this option is selected, the output block uses the
Readback parameter from the Transducer block as its Readback value (showing the actual valve position). If this
option is not selected, Readback is the value of the measured or implied actuator position associated with the OUT
value, in percent.
PID Block's Actual Mode is Stuck in IMAN
When a PID block is the upstream block of a cascade pair, it will go to IMAN as its Actual mode when its
downstream partner, (an AO block for example), is not in CASCADE preventing the PID from closing the cascade.
Putting the AO block in CASCADE mode usually causes the PID to leave IMAN and return to its Target mode.
Note Some devices' AO block will not go into CASCADE mode if AUTO is not enabled in the Permitted mode. The
Permitted mode can be changed only in Control Studio in edit mode.
Additionally, be sure that the PID's BKCAL_IN is connected to the downstream block's BKCAL_OUT. Failure to
make this connection can result in the PID's Actual mode going to IMAN.
Can't Download a Device
Non-Emerson devices may repeatedly fail to download. This can occur if the default values have been overwritten.
First try decommissioning and then recommissioning the device. If this does not work and the device supports "Reset
to Factory Defaults", reset the device to the factory defaults. Finally, refer to the device documentation.

32

System Configuration

A device can fail to download if the device does not support the requested macrocycle (the user-specified execution
time for all the fieldbus function blocks on the segment). Refer to the device documentation for supported macrocycle
times.
Can't Commission a Device
A device that does not commission could be lacking its device description (DD) files. Refer to problems
commissioning devices for more information on troubleshooting this issue.
A duplicate address on a port can also prevent a device from commissioning. Check each device's NodeAddr
parameter in DeltaV Diagnostics or check the Port's Status parameter for a status of Duplicate Address on Link and
then check each device's NodeAddr parameter.
A Valve is Hunting
Run a valve signature and calibrate the valve.
Devices are Dropping Off the Segment
Device alerts and PV Bad Alarm indications could mean that devices are dropping off the segment. This can be due to
low voltage or noise on the segment. Noise can be caused by inadequate termination, the device itself, shielding, or
grounding. The Fieldbus Segment Checkout Procedure provides some help in isolating voltage and noise problems.
Devices dropping off the segment can also be caused by scheduling problems involving the module execution rate
and/or the macrocycle. Refer to Intermittent Block Errors for information on module execution rate and macrocycles.

Using Fieldbus Technology in the Control Strategy

33

Changing Function Block Parameter Values in Fieldbus


Devices
You can change parameter values for function blocks that run in fieldbus devices the same way that you change
parameter values for function blocks that run in the DeltaV Controller. You can use:

DeltaV Operate to write the value through a datalink that allows data entry

Control Studio online or debug to write the value for any writeable function block parameter in the device

DeltaV Explorer or Control Studio to download the module

Using DeltaV Operate


From DeltaV Operate you can enter the data through any datalink that allows data entry. Typically this is done from a
faceplate or detail display, but it can also be done from a primary control display.
When you enter the data, the workstation writes the value to the parameter in the extended block (sometimes called a
shadow block) in the control module in the controller. The extended block communicates data to and from the block
in the fieldbus device. When the extended block receives the write request from the workstation, it does not
immediately update its own parameter value. Rather, it passes the write down to the fieldbus device. On the next scan
of the control module in the controller, the extended block asks the block in the device for its dynamic view list
parameter data. If ST_REV, the static revision, has incremented since the previous scan, the field block updates the
extended block with its static view list parameter data. ST_REV is incremented any time a static parameter is written.
At this point, the extended block parameter values match those in the field block. After the next unsolicited reporting
of data by the control module to the workstation and update of the display in DeltaV Operate, the value that had been
written is visible on the display.
Display update times may appear slower following writes to parameters in field blocks as compared to writes to
controller-resident blocks because of the additional communication over the fieldbus segment. The delay can become
significant when there are more than 10 devices are the segment.
Using Control Studio Online or Debug
From Control Studio online or debug you can enter any writeable function block parameter in the fieldbus device.
The mechanism for the update of the value in the device is the same as described above. Device-sourced function
blocks that appear in control module function block diagrams are really controller-resident extended blocks. Any
writeable parameter can be changed in the extended block, but some parameters require that the target mode be OOS
(Out of Service) in order for the update in the device to be successful.
Using DeltaV Explorer or Control Studio to Download the Module
You can download the control module from the Explorer or from Control Studio. In order for extended block
parameters to be sent to the device during the download, you must check the function block on the download dialog
(the DeltaV software does this for you when a parameter has been changed in the configuration database). When the
function block is checked, the values of all configurable parameters in the extended block are sent to the device for
update. This technique is the least efficient and most time consuming method of making function block parameter
changes in the device. The high level of communication that occurs on the H1 segment during this type of download
does not impact control, but can result in slower display response at the operator workstation.
When possible, it is better to change fieldbus function block parameters from the Operator Station or Control Studio
online than to download. To update the values in the configuration database after making a change from the Operator
Station or Control Studio online, use the DeltaV Explorer or Control Studio to upload the module.

34

System Configuration

Parameter, Field, and Function Security


Inside this topic
DeltaV Locks
Locks Assigned to Function Block Parameters
Locks Assigned to Functions
Lock Examples
Through the use of locks and keys, the DeltaV system provides security mechanisms at both the parameter and fields
level and at the function level. At the parameter and fields level, the DeltaV system allows you to control which users
can write to specific parameters and parameter fields in the run-time information. At the function level, the DeltaV
system allows you to control which users can perform certain functions.
The DeltaV User Manager application provides an interface to the five essential components of security:

Locks - Prevent users from changing the parameters and parameter fields assigned to the lock and prevent
users from performing certain functions. You use the Explorer to assign locks to parameters, parameter
fields and functions. It is helpful to think of a lock as something that specifies the name of the key that grants
access.

Keys - Provide permissions to individual users or whole groups of users. Each key is associated with a lock.
You grant keys under the group and user properties dialogs. Users can be granted any number of keys or
none at all.

Groups - Enable you to classify users together and grant keys to everyone in the group.

Users - Are DeltaV system and Windows users. You can assign users to one or more groups. The DeltaV
User Manager application also allows you to create new Windows users without accessing the Windows
User Manager application. When you create a new user, you can specify whether the user is a Windows user,
a DeltaV system user, or both.

Areas - Some keys can be granted to DeltaV users for specific areas. Use this feature to grant write access to
operators for control modules within the operators' responsibility and withhold access to other similar
modules outside their responsibility. Other keys apply to all areas and the only choice when granting these
keys is <Sitewide>.

DeltaV Locks
In the DeltaV system, locks prevent users from changing the parameters and parameter fields assigned to the lock and
prevent users from performing certain functions.
Locks for parameters are assigned to parameter names rather than to specific instances of parameters. In other words,
a lock on HI_LIM applies to all instances of parameters named HI_LIM. To lock a specific instance of a parameter,
you must create a unique name for that parameter, such as HI_LIM1.
Locks and keys assigned at the field level override those on the parameter itself. This means that specific parameter
fields can be open to a large number of users while the parameter as a whole remains generally restricted.
Note Because security settings on fields have precedence over parameter security settings, you must be very careful
when defining access to fields. For example, if access to GAIN is restricted, but access to the CV field has been
defined as less restricted, users with the less restrictive access will be able to change the GAIN parameter.
When users make write requests to a specific parameter field, the system checks for a lock on the field. If there is no
lock, the system checks for a lock on the parameter itself. When there is no lock on the parameter, the default lock is
used. Users can write to the field of the parameter only when they have a key corresponding to the lock. Additionally,

Parameter, Field, and Function Security

35

the workstation properties can restrict parameter writes by area. That is, the parameter can only be written to if the
user has the key for the area and that area is assigned to the current workstation.
Locks are also assigned to various user functions such as downloading, uploading, changing the configuration
database and so on. Functions are assigned to default locks initially. You can change the lock associated with a
function.
Security is located under the setup component in the Explorer hierarchy. Assign locks to parameters and parameter
fields through the Parameter Security and Field Security properties under the Security section. Assign locks to
functions through the Function Security properties under the Security section. You can also assign a default lock
(keep in mind that many users might have a key to this lock). When you do not assign a lock to a parameter or field,
the default lock applies.
If you want to remove all security from a parameter, the lock specified for that parameter must be assigned to all
users. For example:
1

Rename an unused lock (for example, User Lock 10) to something descriptive like, "Everyone".

Use the "Everyone" lock on parameters that to which everyone needs write access (or at least to fields that do not
have a field name lock defined).

In DeltaV User manager, create a group named "All Users".

Assign the "Everyone" key to the "All Users" group, sitewide (that is, in all plant areas defined).

Make sure all DeltaV users are members of the "All Users" group.

The result is that all DeltaV users get the "Everyone" key in all defined plant areas. This enables them to write to
parameters associated with the Everyone key unless a field name lock exists.
If you create a new parameter in Control Studio with a unique name, you must add the parameter to the Parameter
Security section in Explorer in order to assign a lock to it. Otherwise, the default lock applies.
Note that there might be locks on the fields of a parameter you create. Field locks are determined by the parameter
type on which the parameter is based.
Locks Assigned to Function Block Parameters
Any function block parameter that is writable has a lock assigned to it. You can change the lock assignments made by
the system. Keys to all of the parameter and field locks (except Diagnostic) can be granted to specific plant areas.
Refer to the following table for a default list of the parameter and field locks and a description of each lock's function:
Parameter and Field Locks
Lock

Assigned to parameters that...

Alarms

concern alarms and the alarm horn. The Alarms lock affects access to
the HORN parameter and the HENAB, MACK, and NALM fields.

Control

an operator needs to write to in order to control the process. Examples


of parameters with the Control lock are MODE, SETPOINT, and
OUTPUT.

Restricted Control

supervisors and engineers write to in order to configure the process.


Operators typically do not write to these parameters. Examples of
parameters with the Restricted Control lock are CONTROL_OPTS and
DISABLE.

36

System Configuration

Lock

Assigned to parameters that...

Tuning

maintenance technicians and supervisors write to in order to tune


performance. Typically (although not always), operators do not write
to these parameters. Examples of parameters with the Tuning lock are
GAIN, RESET, and HIGH_LIM.

Diagnostic

affect diagnostic information maintained by the system, such as


parameters that reset instance counts.

System Records

affect the records kept by the system, such as parameters that turn off
the recording of event records.

User Locks 1 through 10

you specify. These locks provide flexibility to your security scheme.


Note When Recipe Authorization is enabled, User Lock 06 through
User Lock 10 are reserved for recipe approval signers.

Locks Assigned to Functions


Locks are assigned to various user functions, such as downloading, uploading, changing the configuration database,
and so on. Functions are assigned to default locks initially. Use the DeltaV Explorer to change the lock associated
with a function. Refer to the Batch Functions Security and Campaign Manager Security topics for information about
the batch functions and locks. Refer to the History Data Set Security topic for information on Continuous Historian
data set security functions and locks. Refer to the following table for a list of the function locks, the default function
to which each lock is assigned, and descriptions of the tasks that users with a key to the lock can perform:
Locks and Associated Functions
Function

Default
Associated
Lock

Operation Function

Can Apply
to Specific
Area?

ACTION_VERIFY

Restricted
Control

verify an action in Control


Studio online and DeltaV
Operate which requires a
verifier's Electronic Signature.
(Usually supervisors are granted
the key to the lock associated
with this operation.)

Yes

ADMIN_CONFIG_DB

System Admin

use the database administrator


tools to create, copy, and rename
databases.

No

CHANGE_CONFIG_DB

Can Configure

make changes to the


configuration database, access a
module in debug mode.

No

CHANGE_DEVICE_DB

Can Calibrate

use AMS Device Manager


device configuration and
calibration features.

No

CHART_SAVE

Can Configure

save Process History View


configuration.

No

Parameter, Field, and Function Security

37

Function

Default
Associated
Lock

Operation Function

Can Apply
to Specific
Area?

DIAGNOSTIC_DATA_CLEAR

Diagnostic

reset all communication, port,


and device statistics; clear
integrity history.

No

DIAGNOSTIC_SWITCHOVER

Diagnostic

initiate a controller switchover.


Note: Users must have the key
to the Control lock to perform a
controller switchover.

No

DOWNLOAD_CONFIG

Can Download

download configuration and


setup data to system nodes.

No

INSPECT_TUNE

Tuning

within Inspect: change the


Enabled/Disable flag for a areas,
modules and blocks. Change the
alarming flag for a block. Set
items on the View | Options
property sheet. Set the limits.

Yes

REPLACE_DEVICE

Can Calibrate

make changes to the Fieldbus


device in the configuration
database. This key allows the
user to:
Replace FF device
Decommission FF device
Commission FF device
Download FF device
Download FF port
Modify resource and
transducer blocks using
AMSinside dialogs
Modify device properties
This key is not needed if the user
already can
CHANGE_CONFIG_DB.

No

UPDATE_FIRMWARE

System Admin

use the controller upgrade utility


to upgrade firmware for
controllers, I/O cards, and other
devices.

No

UPLOAD_CONFIG

Can Configure

upload configuration, setup data


to system nodes.

No

USER_SECURITY_ATTACH_LOCKS

Can Configure

attach functions to locks in


DeltaV Explorer.

No

USER_SECURITY_USERMANAGER

Can Configure

make changes in the User


Manager.

No

38

System Configuration

Function

Default
Associated
Lock

Operation Function

Can Apply
to Specific
Area?

VC_ADMINISTRATOR

System Admin

undo the check out of items


checked out by other users.

No

VC_CHECKOUT_CHECKIN

Can Configure

check items in and out of a


version control database.

No

VC_DEVICE_CHECKOUT_CHECKIN

Can Calibrate

check Fieldbus device in and out


of a version control database.
Not needed if the user already
has
VC_CHECKOUT_CHECKIN.

No

VC_DOWNLOAD_CHECKEDOUT

System Admin

download items that have been


checked out of the version
control database.

No

VC_DOWNLOAD_UNAUTHORIZED

System Admin

download recipes that are not


authorized.

No

VC_PURGE_RECOVER_ITEMS

System Admin

use the DeltaV Explorer to purge


and recover items from the
version control database.

No

VC_ROLLBACK_ITEMS

System Admin

use the DeltaV Explorer to


rollback to a previous version.

No

VC_SET_LABEL

Can Configure

label items in the version control


database.

No

Lock Examples
Removing a parameter or field from the security dialog lists in DeltaV Explorer may have unintended consequences.
The following examples illustrate the effect of removing parameters and fields from the security dialog lists.
Example 1: Attempt to write FIC101/MYPARAM.CV

Field name is CV. CV is not listed in the Field Security dialog.

Parameter name is MYPARAM. MYPARAM is not listed in the Parameter Security dialog.

System Default security is configured as Control.

Result: The lock in effect is Control. Users with the Control key in FIC101's plant area can write it.
Example 2: Attempt to write FIC101/MYPARAM.CV

Field name is CV. CV is not listed in the Field Security dialog.

Parameter name is MYPARAM. MYPARAM is configured as Tuning in the Parameter Security dialog.

System Default security is configured as Control.

Result: The lock in effect is Tuning. Users with the Tuning key in FIC101's plant area can write it. Users with the
Control key in FIC101's plant area cannot write it.

Parameter, Field, and Function Security

39

Example 3: Attempt to write FIC101/MYALARM.PRI

Field name is PRI. PRI is configured as System Records in the Field Security dialog.

Parameter name is MYALARM. MYALARM is configured as Tuning in Parameter Security dialog.

System Default security is configured as Control.

Result: The lock in effect is System Records. Users with the System Records key in FIC101's area can write it. Users
with the Tuning key in FIC101's plant area cannot write it. Users with the Control key in FIC101's plant area cannot
write it.

40

System Configuration

Electronic Signatures
Inside this topic
Configuring Electronic Signatures
Electronic Signature Properties
Signature Policies
Assigning Policies to Modules
Signature Policy Inheritance
Using Signature Policies with Contained Modules
Electronic Signatures at Run Time
Using Electronic Signatures When Acknowledging Alarms on Pictures
Electronic signatures are user names and passwords that provide accountability for operator writes to certain module
parameters and fields from DeltaV Operate and Control Studio online. Electronic Signatures do not apply to writes to
OPC and to the DeltaV Excel Add-In application. Electronic signatures is a DeltaV system preference that can be
disabled (hidden) if not required or enabled selectively on an area-by-area, module-by-module basis. Electronic
signatures does not change the existing DeltaV security feature that controls who is able to make changes to
parameters. Rather, it uses a signature to authenticate the operator's identity. That is, the signature is used as an
additional check to ensure that the operator is who he claims to be. The operator must have a valid user name and
password and the required privileges to perform the action in the area in which the module resides. The write is not
allowed if the operator fails to enter a valid username and password and if the operator does not have the required
privileges in the area in which the module resides.
Depending upon the criticality of a module to the process, no signature, one signature (confirmer), or two signatures
(confirmer and verifier) can be configured. It is possible to allow the same person to be both the confirmer and
verifier of an operator write. Typically, the verifier is a higher-level employee whose signature approves the change
the confirmer is making. The verifier must hold the key to the ACTION_VERIFY function lock. To allow the same
person to be both Confirmer and Verifier, select Properties from the Electronic Signatures context menu and select the
checkbox. If the electronic signature succeeds, the date and time the electronic signature authentication occurred, the
node from which the change occurred, a description of the action, and the confirmer and verifier names are recorded
in the event chronicle and can be seen through the Process History View application. Similarly, failed attempts at
confirming or verifying an action are also recorded and visible through the Process History View. In addition to the
Process History View application, failed confirm or verify attempts are also recorded in the Batch Historian if it is
collecting chronicle events and can be viewed through the Batch History View application.
Operator Comments
The operator has the option of entering a comment about the parameter change. Operator comments are recorded in
the Desc2 field in the Process History View application. This field is truncated at 240 characters. By default, the
system adds the string VALUE SIGNED FOR = xxxxx before the comment. That is, the system adds additional
characters to your comment and these additional characters are counted in the 240 character limit. So for example if
you changed a value to 365 and entered the comment "changed value for tank1" the Desc2 field will total 48
characters and read:
VALUE SIGNED FOR = 365 (changed value for tank1)
The system calculates the length of the string VALUE SIGNED FOR = xxxxx plus the length of the comment. If the
comment will cause Desc2 to exceed 240 characters, the system posts a message asking that the comment be
shortened. The length of the comment is limited to the lesser of: 200 characters or what fits in the Desc2 field. If
VALUE SIGNED FOR is a string that exceeds that 240 characters, the value is truncated at 240 characters in the
Desc2 field in Process History View and no comment is saved with the value.
The DeltaV system does not enforce the use of operator comments; this decision is left to plant managers.

Electronic Signatures

41

Note Do not use the Enter key to create a line break in the Comment field. Pressing the Enter key in the Comment
field is the same as selecting the OK button; it dismisses the dialog and performs the command.

Configuring Electronic Signatures


Electronic Signatures must be enabled as a system preference to be used in a DeltaV system. Click Start | DeltaV |
Engineering | System Preferences and enable Electronic Signatures. Once enabled, an Electronic Signatures container
is created under Setup in the DeltaV Explorer.

Electronic Signatures Container in DeltaV Explorer Hierarchy


Electronic Signature Properties
Use the Electronic Signatures Properties dialog to enable electronic signature support in DeltaV Operate and Control
Studio online and to allow the confirmer and verifier to be the same person.

Electronic Signatures Properties Dialog Box


Enabling electronic signatures from this dialog enables the electronic signature capability in DeltaV Operate and
Control Studio online. If electronic signatures are not enabled here, no signatures are required for any write. Before
electronic signatures can be used, you must enable electronic signatures for the process areas in which the modules

42

System Configuration

reside and define a signature policy for the modules. If electronic signatures is not enabled for an area, no signatures
will be required for writes to modules in that area. To enable electronic signatures in a process area, select Properties
from the area's context menu and select Enable Electronic Signature. It is necessary to download the Setup data after
making a change to electronic signature properties. When the change affects either the Batch Executive or the
Campaign Manager, those subsystems must be downloaded.
Signature Policies
Signature policies define the module parameters and fields that will require a signature before an operator can write to
it, the type of signature required, and the default signature requirement for the module parameters and fields not listed
in the signature policy. The signature requirement options are Comment Only, Confirm, Confirm and Verify, None.
Note The signature policy for Field Confirmation takes precedence over the policy for Parameter Confirmation even
if the Field Confirmation requirement is less stringent than the Parameter Confirmation requirement.

Properties Page for Configuring Parameter Confirmation Requirements


Signature policies can be renamed and deleted from the database. They are subject to Version Control if Version
Control is enabled. Policies can be printed and database objects that have a relationship with the policy (References)
can be requested for them.
Signature policies are under the Electronic Signatures container in the DeltaV Explorer.
Assigning Policies to Modules
Electronic Signatures can be applied either broadly on a system-wide basis or selectively on an area-by-area, moduleby-module basis to facilitate granular configuration, testing, and commissioning. Polices can be assigned to modules
at configuration time and temporarily disabled on an area or the entire system during testing or when signatures are

Electronic Signatures

43

not required. Then when the configuration is ready for normal operation, Electronic Signatures can be enabled at the
level of granularity required for your situation.
Each module can have only one policy assigned to it; however, there is no limit to the number of signature policies
allowed in the database.
Tip Carefully consider the use of slew buttons in operator graphics. Slew buttons are used to gradually increase or
decrease a value and can be difficult to use on parameters that are subject to Electronic Signatures since each click on
a slew button is a separate parameter write.
To assign a policy to a non-class-based module or module template, select Electronic Signature from the module's
context menu and browse to the policy.

Dialog for Assigning a Signature to a Module


Once a policy is assigned to a module and the module is downloaded, signatures will be required for writes to the
module parameters specified in the policy.
In addition to modules made directly in an area or from a module template, electronic signature policies can be
assigned to the following types of classes:

Control module classes

Equipment module classes

Unit classes

Phase classes

Signature policies cannot be assigned to process cell classes.


If you change the Signature Policy on a reference to a Phase Class under a Unit Class, the change is made on the
Phase Class itself and propagates to all references to the Phase Class under the Unit Class.
Signature Policy Inheritance
A signature policy is inherited by an instance of the class; however, the inheritance can be overridden and removed at
the instance level. To override or remove an inheritance on an instance, select Electronic Signatures from the
instance's context menu, deselect "Enable Class Signature Policy", and browse to a new policy, or leave the Name
field blank, and click OK. Be sure to download the Setup Data after making changes.

44

System Configuration

Dialog for Assigning a Signature Policy to a Class-Based Module


If an instance does not override the class signature policy, the instance's policy follows the class if the class's policy
changes.
Using Signature Policies with Contained Modules
It is possible for one module (a container module) to contain another module (a contained module). When a
container/contained module is viewed online in Control Studio, the opened module appears first in the module path
string. The signature policy that is applied for container/contained modules is determined by the policy assigned to
the first module in the module path string. For example, suppose that Policy_A is assigned to ModuleA and ModuleA
contains ModuleB. If ModuleA is opened, the path string in Control Studio online is ModuleA/ModuleB. Now
suppose that a different policy, Policy_B, is assigned to ModuleB. If ModuleA is opened for editing in Control
Studio and the parameter changed belongs to ModuleB, Policy_A is applied because it is the policy assigned to the
container module ModuleA which appears first in the path string. To have Policy_B applied to ModuleB changes,
ModuleB should be opened directly in Control Studio online. These same rules apply when datalinks are added to
pictures in DeltaV Operate. The Datalink Browser automatically places the contained module first in the module
path. However, if you manually edit a module path, be aware that the signature policy is determined by the module
name that appears first in the path string.
Electronic Signatures at Run Time
In Control Studio online, dialogs that are used to modify parameters, such as the Mode Properties dialog,
automatically launch the Electronic Signature dialog when electronic signatures are configured for the parameter.
However, in DeltaV Operate only objects inserted with the following tools launch the Electronic Signatures dialog:

Datalink Stamper

Datalink Formatter

DeltaV Data Entry Expert

SIS Data Entry Expert

When an operator clicks a button or presses Enter after writing to a parameter that is subject to an electronic
signature, the electronic signature dialog box opens. The parameter is not written until the required signature is
provided. The following image shows the Electronic Signature dialog box that opens in Control Studio online when a
Confirm and Verify signature is required for a parameter write. The appearance of this dialog varies depending upon
the signature requirement.

Electronic Signatures

45

Electronic Signature Dialog for Confirm and Verify Signature Requirement


Using Electronic Signatures When Acknowledging Alarms on Pictures
Electronic signatures can be applied when individual alarms or all alarms on pictures are acknowledged and when
individual or all alarms on Alarm Summary and Alarm Filter pictures are acknowledged. In addition, electronic
signatures can be applied when alarms on pictures such as faceplates that use ActiveX controls are acknowledged.
There are three ways to configure electronic signatures for alarm acknowledgement:
1

Default-level signature requirements

Parameter-level signature requirements

Field-level signature requirements

Default-Level Signature Requirements


Signature policy defaults apply to the module parameters and fields not otherwise listed in the signature policy. To
use policy defaults only, configure the default entry to the signing level needed for alarm acknowledgement. Do not
configure the policy with any alarm parameters (ALARMS, HI_ALM) or alarm fields (NALM, MACK). When an
alarm is acknowledged on a module with this policy assigned, the policy default becomes the signature requirement
on all of the picture types (Alarm List, Alarm Filter, faceplates using ActiveX Controls, pictures that use individual
parameters and the ALARMS parameter in datalinks).

46

System Configuration

Parameter-Level Signature Requirements


Parameter-level signature requirements for acknowledging alarms can be used for Alarm List pictures, Alarm Filter
pictures, and ActiveX Controls on faceplates as well as for pictures that use individual parameters in datalinks and the
ALARMS parameter in datalinks. For Alarm List and Alarm Filter pictures and faceplates using ActiveX Controls,
configure the policy to include the desired module alarm parameters such as HI_ALM or LO_LO_ALM. Refer to the
Alarms and Events Reference topic for information on module alarm parameters. If you are not configuring a defaultlevel signing requirement in the policy, you must include the ALARMS parameter. Configure ALARMS to the
signing requirement that you desire for default alarm acknowledgement on the module. For pictures (other than
Alarm List, Alarm Filter, and faceplates using ActiveX Controls) that use datalinks such as FIC-100/
HI_ALM.F_CUALM to display data as numbers or text, configure the policy to include the parameters used in the
datalinks on the picture. For pictures that use the ALARMS parameter, datalinks with ALARMS[1] such as FIC-100/
ALARMS[1].A_ATTR are required on the picture. Refer to the Alarms and Events Reference topic for information
on how to use this parameter. Configure the policy to include the ALARMS parameter when datalinks with the
ALARMS parameter are used in pictures.
Field-Level Signature Requirements
Field-level signature requirements for acknowledging alarms can be used for all of the picture types discussed in this
topic: Alarm List, Alarm Filter, faceplates using ActiveX Controls, as well as pictures that use individual parameters
and the ALARMS parameter in datalinks. To use a field-level signature requirement, configure the policy to include
the NALM field. Remember that field requirements take precedence over parameter requirements even if the field
requirement is less stringent than the parameter requirement. Refer to the Alarms and Events Reference topic for
information on how to use the NALM field.
Acknowledging All Alarms
When the Acknowledge All command is used on any of the picture types (Alarm List, Alarm Filter, faceplates using
ActiveX Controls, pictures that use individual parameters and the ALARMS parameter in datalinks), only one
signature is required to acknowledge all alarms on the picture. However, the Event Chronicle will contain a
SIGNATURE entry and a CHANGE entry for each alarm acknowledged. When using the Acknowledge All
command, be aware that the most stringent signature policy for any of the modules found on the picture is applied.

Electronic Signatures

47

Hiding Intellectual Property


Use the Hide Internal Structure command to conceal any intellectual property contained in your DeltaV system's
Composite Templates, Control Module Classes, Equipment Module Classes, and Phase Classes and in any instance of
these templates and classes.

Types of Items Whose Internal Structure can be Hidden


The Hide Internal Structure command hides function blocks but module level parameters remain visible. This image
shows a composite template whose internal structure is fully visible. Instances of this composite template, such as a
module, can be opened in DeltaV Control Studio in online, edit, and debug modes.

A Fully Visible Composite Template


The following image shows the same composite template with a hidden internal structure. Because the internal
structure is hidden, this composite template cannot be opened in Control Studio in edit mode. However instances of
this template, such as a module, can be opened in online and debug modes but users are not allowed to drill into the
composite instance to see the internal structure.

48

System Configuration

Composite Template with Hidden Internal Structure


For Module Class parameter shortcuts, (parameters that have the "Allow instance value to be configured" option
enabled), the Hide Internal Structure command does not conceal the parameter path in instances of the Module Class.
If you do not want parameter paths revealed in instances of the class, you must rename the parameters before using
the Hide Internal Structure command.
To rename parameters:
1

Select the Control or Equipment Module Class at the Library level and choose Configure from the context menu.

Select the Parameters or I/O tab in the Configuration dialog.

Select the parameter and click the Rename button.

Enter a parameter name that will not reveal the path and click OK.

Close the Configuration dialog.

Now select the Control or Equipment Module Class and click Hide Internal Structure.

You must have DeltaV System Admin and Can Configure keys to access the Hide Internal Structure feature. Refer to
the Parameter and Function Security topic for more information on locks and keys.
To hide an item's internal structure:
1

Open DeltaV Explorer

Select the item (Composite Template, Control Module Class, Equipment Module Class, and Phase Class).

Choose Hide Internal Structure from the context menu.

Enter a password, confirm the password, and click OK.

Note An item cannot be hidden if it is in a protected category. Refer to Protecting Your Engineering Standards for
information on hiding items in protected categories.

Hiding Intellectual Property

49

A hidden item cannot be:

Opened in Edit mode in Control Studio (instances of the item can be opened in Control Studio in online and
debug modes).

Copied

Converted to another type that would reveal the internal structure. For example, a linked composite cannot
be converted to an embedded composite.

Drilled into (if linked composite)

Modified in any way

A hidden item's properties and history collection cannot be changed. However, a hidden item can be deleted. An
instance of a hidden item can be modified from the Properties, History Collection, and Configure dialogs. Parameter
shortcut values can be changed on an instance.
After an item's internal structure has been hidden, it can be accessed only with the password used to hide the
structure. In most cases the owner of the intellectual property has the password. When a configuration that contains
hidden items is exported, the hidden items and password are encrypted. The password persists even if the hidden item
is exported, then deleted, and imported or re-imported into a different database. An item from an unencrypted
configuration cannot be imported into the DeltaV system if that item already exists in the database and its structure is
hidden.
It is important to provide information about the owner of a hidden item. For example, suppose a problem arises with
a control module with a hidden internal structure and users need to contact the module's owner for help. It is
recommended that you use one or more string parameters to hold information about the owner and/or the item's
revision. Before hiding an item's internal structure, use Control Studio to add the string parameters. Be sure to add the
parameters at the item's top level to ensure that the parameters remain visible after the item is hidden. Refer to the
Control Studio online help for information on adding parameters.
If DeltaV Version Control (VCAT) is enabled, do not check in an item that is unhidden. If an unhidden item is
checked in, the internal structure of that version of the item can be viewed in VCAT history.

50

System Configuration

Protecting Your Engineering Standards


Once your engineering standards have been designed and validated for a project and saved in a DeltaV Library
category, you can use the Protect command to prevent users from modifying items in that category. The following
items can be protected:

Composite and module templates (specific parameters of class-based templates can also be protected,
regardless of the protection status of the category).

Control module, equipment module, phase, and unit classes

Library Categories that can be Protected


Items are protected through the use of a password. Users must have the Can Configure key to set and remove a
password. A user with the System Admin key can unprotect an item without the password. When a categories are
unprotected, all the items in that category become unprotected for all users. Protected parameters of class-based
templates remain protected. Refer to the Parameter and Function Security topic for more information on locks and
keys.
To protect a library category:
1

Open DeltaV Explorer.

Select the library category (Composite and Module Templates, and Control Module, Equipment Module, Phase,
and Unit Classes) and choose Protect from the context menu.

Enter and confirm a password.

Click OK.

Items in protected categories cannot be modified, deleted, moved or overwritten and new items cannot be added to a
protected category.
Note The Hide Internal Structure command cannot be applied to an item in a protected category. To hide an item in a
protected category, first hide the item and then protect the category to which the item belongs.
To protect a parameter in a class-based template:
1

Open DeltaV Explorer.

Select the parameter of a class-based template and choose Protect from the context menu.

Protecting Your Engineering Standards

51

It is not possible to remove the protection in instances of the module made from the template.
Protection is not automatically preserved during a manual database export and import. To preserve protection when
manually exporting and importing a database, check the 'Include the data for a DeltaV software upgrade' checkbox.
However, protection is automatically preserved when a DeltaV installation is upgraded with the DeltaV Upgrade
Wizard.

52

System Configuration

Expressions
One of the fundamental capabilities required in a controller is its ability to compute expressions. An expression is
structured text that represents a calculation and has a specific syntax. The expressions provide information for
process operators so that they can make control decisions. This section provides an overview of the functions,
operators, and syntax used for expressions.
To write an expression, use the Expression Editor. The Action, Calc/Logic, and Condition function blocks, as well as
the Sequential Function Charts, allow you to enter expressions for execution in the controller.
Caution When writing expressions using an external editor, only use a plain ASCII text editor (Notepad is
recommended). Using other editors can cause the expression to change during the load and save process.
Expressions can be used for the following applications:

Action Block Expression The expression in the action block allows you to evaluate an equation and assign
the result of the evaluation to a parameter within the DeltaV system.

Condition Block Expression Used with Boolean-valued expression. To set the condition, you must specify
an expression as TRUE. Note that the timed part of condition definitions should not be part of the
expression, but rather part of the definition of the condition.

Calculation/Logic Block Expression Used with a collection of expressions whose results can be assigned
to function block parameters or module parameters.
For example, for an expression in a Calc/Logic block (CALC1) in the composite, COMPOS1, that is in the
composite, COMPOS2, that is a block in the module, MOD, you can:
Reference a CALC1 parameter within the block, IN1.CV.
Reference a COMPOS1 parameter within a composite, ^/ATTR.CV.
Reference a COMPOS2 parameter outside a composite, /COMPOS2/PARAM.CV.
Reference a Module (MOD) parameter, /MSTATUS.CV.
Reference another Module parameter, //FIC101/PID/SP.CV.
Reference a diagnostic parameter from the module, //NODEX/OINTEG.
Reference a DST parameter for the module, //DST/FIELD1_VAL_PCT.

SFC Step Actions Used to assign the result of an expression to a database item, which can be an SFC step,
state variable, or a parameter.

SFC Step Transitions Used with a Boolean-valued expression. When it is evaluated as TRUE, the
transition is triggered and associated steps are enabled or disabled.

SFC Step Mode Used to allow operators (with the appropriate privileges) complete control over SFC
execution by requiring that all transitions be forced. The operator also has the power to redo a given step
before proceeding or to restart the sequence from a different point by changing the active step. The SFC can
be placed into Step mode from Control Studio Online or Debug views.

Syntax Rules
An expression is made up of operands, operators, functions, constants, and comments. Each expression must follow a
specific syntax to be valid. The basic rules for valid DeltaV syntax expressions include:

Calculation/Logic Block definitions have a temporary variable capability.

Expressions

53

The Condition function block evaluates a multi-line expression. The assignment operator (:=) is not a valid
operator.

The Action block requires the use of the assignment operator (:=). All other operators are valid in the Action
block provided the final evaluation of the expression is an assignment.

Named set constants are represented by SetName:valueName.

The only data type supported is floating point.

An external (or database) reference is represented by a 'path' surrounded by single quotes.

The expression should end with a semi-colon (;). DeltaV software usually adds a semi-colon for you if one is
not there.

The number of characters in an expression cannot exceed 9941. You can reduce expression length by
relocating part of the expression or by making the expression code more compact.

Note The expression evaluator is stack oriented and allows a maximum of 32 operands and operators. The use of
parentheses to organize the expression minimizes the stack usage. The equations are evaluated using RPN (Reverse
Polish Notation).
Relative Notation
The following rules indicate the relative notation of parameters in an expression.
Relative Notation Rules
Notation

Relates to
Rule

Rule

//

External

References a parameter that is outside this


module.

Module relative

References a parameter within the current


module.

Block relative

References a parameter up one block level.

/+/

Phase relative

References a parameter within a batch phase.

Assignment Statements
The := operator is an operator in DeltaV expressions. This operator allows for the assignment of calculated values to
locations inside and outside of the current block. Examples of the assignment operator follow:
'Block1.mode.target' := MAN;
RADIUS := .5;
OUT1:= 5 *RADIUS;
Assignment statements can be in any of the following formats:
output := value;
or
'external reference path' := value;
or
temporary variable := value;

54

System Configuration

If you wanted to increment a module-level parameter called SYRUP, the expression might look like this:
'/SYRUP' := '/SYRUP' + 1;
Note The assignment operator is not valid in the Condition block. However, the assignment operator is required in the
Action block.
If-Then-Else-End_if Statements
The IF-THEN-ELSE-END_IF structure allows you to execute conditional code in expressions. When a block tests a
condition that evaluates to TRUE, it executes one set of the statements; otherwise, it executes a different set of
statements. The following example illustrates the IF-THEN-ELSE-END_IF structure:
IF '/Block1.mode.ACTUAL' = MAN THEN
'/Block1.mode.TARGET':= AUTO;
ELSE
OUT1:= IN1;
END_IF;
Note DeltaV software allows you to use ENDIF or END_IF for your convenience. However, structured text typically
requires the use of the keyword END_IF.
In the preceding example, the condition tested is whether 'Block1.mode.ACTUAL' is equal to manual. Notice that the
'=' operator is not used as an assignment operator, but rather to test the two operands for equality. If the condition is
TRUE, the 'Block1.mode.TARGET' is set to AUTO; otherwise, OUT1 is set to the value of IN1. Multiple statements
can be placed between the THEN keyword and the ELSE keyword as well as between ELSE and the END_IF
keyword.
It is not always necessary to use the ELSE portion of the statement. For example, if you wanted to set the parameter
CALC block parameter OUT1 to TRUE when the process variable of PID1 in LIC-549 goes above 75, the expression
would look like this:
IF '//LIC-549/PID1/PV.CV' > 75 THEN
'OUT1.CV'

:= TRUE;

ENDIF;
Note The CV extension in this example stands for current value. If the choice exists, ST stands for status.
After you enter an expression, you can validate the expression syntax. The validation process identifies syntax
problems with the expression and any unresolved parameters. The expression can be saved to the database with
syntax errors, but the errors should be corrected before downloading the expression.
While-Do-End_While
The WHILE-DO-END_WHILE structure allows you to continue executing a group of statements while the value of
an expression is True. This structure is available in the Calc/Logic and Action function blocks.
The following example illustrates the WHILE-DO-END_WHILE structure:

Expressions

55

I := 1;
WHILE (I <= 5) DO
'^/PARAM1'[I][1]:= I + .12;
I := I + 1;
END_WHILE;
Note The indices are outside of the single quotes unless the .CV field is used. The parameter syntax must be exactly
as shown in the example ('^/PARAM1'[I][1]). It is recommended to show all access to the matrix parameter (an input
or output parameter defined as a floating point array type) using two dimensions where the second is always [1].

Warning If a WHILE loops more than 1998 counts, the loop will be stopped, BLOCK_ERR and MSTATUS will be
set, and the loop will not be executed until the module is downloaded.
Exit
This structure prematurely exits the innermost WHILE-DO loop currently being executed. The EXIT statement can
only appear inside the statements of a WHILE_DO loop.
The following example illustrates using EXIT in a WHILE-DO loop:
I := 1;
WHILE (I <= 5) DO
'^/PARAM1'[I][1]:= I + .12;
IF ('^/PARAM1'[I][1] > 5) THEN
EXIT;
END_IF;
I := I + 1;
END_WHILE;
Note This command is only available in the Calc/Logic and Action function blocks because that is where the
WHILE-DO construction is supported.
GOTO label
The GOTO label structure transfers processing to the statement identified by the specified label. A label definition is
a string followed by a colon (:).
The following example illustrates the GOTO label construct:
REM This expression takes IN1 to the IN2 power
cnt:=0;
answer:=1;
REM The following statement creates the label begin
begin:
IF cnt>=IN2 THEN
GOTO end;
END_IF;
answer:=answer*IN1;
cnt:=cnt+1;
GOTO begin;
end:
OUT1:=answer;

56

System Configuration

Syntax for SFC Step Actions


For SFC step actions, the type of action determines the valid expressions. The three action typesBoolean, nonBoolean, and Assignmenthave the following impacts on expressions:

Assignment Assigns the result of an expression to a destination. For example, the following action text
sets a parameter to 1:
'//XV-101/DC1/SP_D':=1;

Boolean Sets a destination to TRUE. This destination must be a module-level Boolean parameter of the
module you are working on. The action text for this type of action is the Boolean parameter, and the action
qualifier defines the action (when to set this parameter to TRUE). For example, if you want to set a Boolean
parameter to TRUE for the module called MPARAMETER, enter the following action text:
MPARAMETER

Non-Boolean Executes a specific block. This block can be either a composite block or a function block,
but it must be in the module you are working on. Action Text for this type of action is the function block
name. The action qualifier defines the action (when to execute this block). For example, to execute a PID
block called PID1, enter the following action text:
PID1

Tip To add a block to an SFC, select the Hierarchy View. Click the right mouse button and then click Add. Select the
type of block to add, and answer the questions.

Note Blocks that are not referenced by a non-Boolean action run continuously in the controller.

Using the Variables


Variables are only used in expressions for the Calc/Logic Function block. You can simplify complex calculations by
using variables to temporarily store values. The following examples show how variables can be used in a Calc/Logic
block.
pi := 3.14159;

This expression assigns the value of input1 to the RADIUS variable:


RADIUS := IN1;

This expression assigns the value of 2 times the RADIUS to the DIAMETER variable:
DIAMETER := 2.0 * RADIUS;

This expression assigns the value of 2 times pi times the RADIUS to the CIRCUMFERENCE variable:
CIRCUMFERENCE := 2.0 * pi * RADIUS;

This expression assigns the value of pi times the RADIUS squared to the AREA variable:
AREA := 3.14 *(RADIUS * * 2);

These expressions assign the variables to outputs of the Calc/Logic function block:
OUT1 := DIAMETER;
OUT2 := CIRCUMFERENCE;
OUT3 := AREA;

Expressions

57

Some keywords are reserved for DeltaV expressions and cannot be used as local variable names. Refer to the
Keywords topic for information on the reserved keywords.
From the above information, it is apparent that variables do not have to be declared. They are assumed to be variables
because of the absence of quotation marks (,) around their names. Variable names are not case sensitive.
All variables are floating point numbers. The value of a variable is retained from one scan to the next. The initial (first
scan) value of a variable is zero.
The scope/visibility of variables is limited to the Calc/Logic function block in which they exist.

VAR...END_VAR; This structure is used to declare local variables in expressions in CALC function
blocks. If the Option Explicit statement is used it must be followed by VAR...END_VAR to declare local
variables. Otherwise, any temporary variables that are not declared within the VAR...END_VAR structure
(when using Option Explicit) will not be accepted by the structured text parser.
Option Explicit; (* This is optional.*)
VAR
(* Used to declare local variables *)
T63;
T64;
T17;
T18;
END_VAR;
T63 := .5;
T64 := -15.803;
T17 := SIGN(T63);
T18 := SIGN(T64);
T62 := 88; (* This will give an error with the option explicit since no
T62 declared; otherwise no error is flagged. *)

(* *) - This is a comment notation. Anything between "(*" and "*)" is treated as a comment, even if it spans
lines. These comments do not nest. The first occurrence of "*)" will terminate the comment no matter how
many instances of "(*" have occurred. The content of this comment has no effect on any processing.

REM - This denotes that a remark is following. Text on the line following "REM " (note the space after
REM is required) is treated as a comment. The content of this statement has no effect on any processing.

Temporary Variables
Temporary variables allow you to simplify complex calculations by using variables to temporarily store values.
The following rules apply to temporary variables:

The name of a temporary variable can only use A to Z, a to z, 0 to 9 and _.

The name cannot start with 0-9 and is case insensitive.

There is no way to declare temporary variables.

There is no checking that a variable has been assigned before it is used.

Slight misspellings of a variable will result in errors in the expression.

The following is an example of using temporary variables:


RADIUS := 5.0;
DIAMETER :=2.0 * RADIUS;
circumference := 3.14 * DIAMETER;

58

System Configuration

I/O References
You can reference I/O signals in your expressions and use them in your calculations. You need to supply the full path
of the signal, and possibly the parameter. For example, if you were referencing the input signal on the first channel,
CH1, of the second card, C02, in a controller's subsystem, and the controller was CTRL3, the reference to that
channel in your expression could look like this:
'//CTRL3/IO1/C02/CH1/FIELD_VAL_PCT
When you are reading data from a channel, you do not have to specify the parameter field. If you do not specify a
field, the default (.CV) field is implied.
When you are writing data to a channel, you can reference specific parameters. If you do not specify a field, the
default (.CV) field is implied.
You can read and write data to the I/O channels in your expressions to obtain the behavior you want. For example,
suppose you wanted to convert an analog value to its corresponding temperature in Celsius. For this example, assume
you have a temperature transmitter that sends an analog signal of 1 to 5 Volts. The voltage corresponds to a range of 0
to 200C, and you want to convert the analog value to a temperature value so that you can display it for the operator.
First, you need to know which channel the 1-to-5 volt signal is on. For this example, assume that it is the signal on the
channel we used previously.
For the calculation, you would need to subtract 1.0 from the voltage because the temperature scale is zero-based.
Then, you would need to multiply the value by 50 because 1.0 volt corresponds to 50 degrees in this example. The
expression for the conversion might look like this:
CELSIUS := '//CTRL3/IO1/C02/CH1/FIELD_VAL_PCT' *(4.0/100.0)* 50;

Matrix Parameter References


In the DeltaV system, a matrix parameter is defined as a two-dimensional floating point array parameter. Arrays can
contain as many as 240 elements. Arrays are arranged in a [row][column] combination of up to 127 by 127 as long at
the total number of elements does not exceed the 240 element maximum.
Note You cannot change the size of an array during runtime. Attempts to write to the .ROWS or .COLS fields of a
matrix parameter are ignored.
The array parameter participates in redundancy only if the number of elements is 200 or less. If there are more than
200 elements, the parameter does not transfer across the controller redundancy link.
Note In batch expressions you can use array elements as values for step attributes, phase parameters, report
parameters, recipe formula parameters, recipe step parameters, and unit parameters.
Define a matrix by selecting Floating point array when defining an output parameter.

Expressions

59

Properties of an Output Parameter Configured as a 3 by 3 Floating Point Array


Access array elements by extending the database reference with indices. There are two ways to do this:

'array'[row][column]
In this form the array index references (row and column) are outside of the single quotes. The row and
column specifiers can be variables or expressions. This form returns the default field (.CV) value of an array
element. The index values are checked against the matrix definition.
For example:
'ARRAY1'[MY_INDEX][2*abs(a)]
The row index value is a variable and the column index variable value is an expression.

'array[row][column].field'
In this form the entire array reference is enclosed in single quotes and field is required. In this form row and
column specifiers must be integer constants. The index values are checked against the index dimensions.
You must use this form to access fields other than CV.
For example:
'ARRAY1[2][3].AWST'

Note Matrix Parameter indices start at 1 but an index of 0 (zero) is interpreted as 1. For example, an index of [0][0] is
interpreted as [1][1].

60

System Configuration

Use either of these forms to access array elements in expressions. Note that you must enter array indexes manually in
the expression editor.
To add and display historical array parameters, the syntax must be entered as follows:
'Module/reference[2][1].CV'
To display and use the array parameter in DeltaV Operate, reference the array on the graphic as follows:
'DVSYS.Module/reference[2][1].F_CV'
Note The DeltaV system updates array parameter values in the workstations every 10 seconds. Array values that
change more frequently than 10 seconds cannot all be properly displayed at the workstations.
When using matrix parameter referencing and the array resides in a different controller from the module writing to it,
create the logic (in the module) to confirm each array element write before attempting the next array element write.
Confirmation is not needed if the array and module both reside in the same controller.

Inputs/Outputs of the Calc/Logic Block


The inputs and outputs allow you to read values wired as inputs to a block or assign values to wired outputs from the
block. The Calc/Logic block supports direct access to its inputs and outputs. The Action and Condition function
blocks, however, do not have the ability to refer to wired inputs and outputs. The following examples show how a
Calc/Logic block expression can use wired inputs and outputs:

The following expression multiplies the input, IN1, by 2.0 and pi to compute a temporary variable:
CIRCUM := IN1 * 2.0 * 3.14;

The following expression assigns the value of the input, IN1, to the output, OUT1:
OUT1:= IN1;

The following expression assigns the status field of input to the status field of the output:
'OUT.ST' := 'IN2.ST';

Note The single quotes are required when a parameter field (CV or ST) is appended.

External References
External references are a built-in feature of the DeltaV software that allows you to refer to any input, output, or
parameter that is available in any module in the DeltaV system. These external references are best configured by
using the parameter browser available in all the expression dialogs. The browser brings up a graphical list of areas,
blocks, and parameters. By selecting a parameter from the browser, you can avoid the potential of typographical
errors and case-sensitivity when referencing block parameters.
Note When using a reference field other than the .CV field, you will need to type the field name. Refer to the External
Reference Parameter topic for field descriptions.
References are denoted in expressions by surrounding the reference in single quotes (' '). Paths to external references
are denoted by double slashes (//). For example, if a block in module LOOP1 is named BLOCK1, an external
reference to a parameter in BLOCK1 looks like:

Expressions

61

IF ('//LOOP1/BLOCK1/MODE.ACTUAL' = MAN)THEN
OUT1 := 5.0;
ENDIF;

Internal References
Internal references are DeltaV built-in parameter data types. They allow you to refer to any input, output, or
parameter that are available within the current module or phase. The best way to configure internal references is by
using the parameter browser available in all of the expression dialogs. By selecting a parameter from the browser, you
can avoid the potential of typographical errors and case sensitivity when referencing block parameters.
Note When using a reference field other than the .CV field, you will need to type the field name. Refer to the Internal
Reference Parameter topic for field descriptions.
For a module, MOD, that contains the composite, COMPOS2, that contains the composite, COMPOS1, that contains
the function block, PID1, all of the internal references shown below refer to the same parameter:
Module relative /COMPOS2/COMPOS1/PID1/GAIN
Module relative /PID1/GAIN
Block relative ^/COMPOS1/PID1/GAIN
For phases, a reference to a phase parameter looks like:
Phase relative /+/WDOG_STATE.CV

Dynamic References
A dynamic reference parameter is a variation of the external reference parameter that lets you define a path to a value
that is selected at run-time during execution of the algorithm. The selection is based on information not available at
configuration (for example, an operator entry, a recipe parameter passed from batch control, or a run-time value of a
control variable).
The best way to configure dynamic references is by using the parameter browser available in all of the expression
dialogs. By selecting a parameter from the browser, you can avoid the potential of typographical errors and case
sensitivity when referencing block parameters. Refer to the Dynamic Reference Parameter for field descriptions.
Dynamic references are established by assigning a parameter reference path string to the .$REF field of a dynamic
reference parameter. For example, if a tank has two input valves, INLETA and INLETB, the value for the dynamic
reference parameter, INLET.$REF, can be assigned the setpoint of INLET_A using a statement such as:
'INLET.$REF' := "//INLETA/SP"
Following is an example using a string variable to store the parameter reference path:
'STRINGVAR' := "INLETA/SP"
'INLET.$REF' := 'STRINGVAR'

62

System Configuration

Diagnostic Parameters in Expressions


You can use diagnostic parameters in expressions to check the integrity and status of specific devices. Using the
diagnostic parameters in expressions, you can perform error handling and react to unexpected conditions. For
example, you could use a condition block and write an expression that checks the status of an I/O card. If the status is
bad, you could execute a different control strategy. The expression for checking the status of an IO card would look
similar to the following:
'//CTLR1/IO1/C02/STATUS' != GOOD;
Note As a general guideline, for parameters with a numeric value, the status is GOOD if it is zero. For Boolean
parameters, FALSE is a GOOD status, and TRUE indicates an error.

Hint You can use the report mode


using, if you are not sure.

button on the Browse Dialog to check the type of parameter that you are

For a numeric value, the expression would look similar to the following:
'//CTLR1/IO1/C02/CH02/STATUS' = 0;

Strings
Strings can be used in all types of expressions in the DeltaV system. The use of strings allows great flexibility when
constructing or selecting parameter reference paths in internal, external, and dynamic reference parameters.
A reference parameter/field can be assigned a string constant or a string variable. String constants are enclosed in
quotation marks (" "). String variables are enclosed in single quotes (' ').
Note Strings referring to module names and associated paths must always use uppercase letters.
Supported string functions are described below.

String Assignment A string constant can be assigned to a parameter/field. For example:


'OUTLET_POS.$REF' := "VLV1004/AO/OUT.CV";
'OUTLET_POS.$REF' := "";

// empty string

constant

A string parameter/field can be assigned to another string parameter/field. For example:


'TEMPSTR2.CV' := 'TEMPSTR1.CV';
'OUTLET_POS.$REF' := 'TEMPSTR2.CV';
A named set string value can be assigned to a string parameter/field. For example:
'STRING.CV' := 'NAMED_SET.CVS';

Numeric Value to String Conversion If the right side of the assignment evaluates to a numeric value and
the left side of the assignment is a string parameter, the numeric value is converted to a string, and the string
is assigned.

String to Numeric Value Conversion If the right side of the assignment evaluates to a string value and
the left side of the assignment is a numeric parameter, the string is converted to a float, which is then
converted to the type of the numeric parameter.

Expressions

63

String Comparison Using Relational Operators Two relational operators, equal (=) and not equal (!=),
can be used to compare string parameter/fields or string constants, as in the following:
IF
THEN
IF
THEN
IF
THEN
IF
THEN

('OUTLET_POS.$REF' = "VLV1004/AO/OUT.CV")

("VLV1004/AO/OUT.CV" != 'OUTLET_POS.$REF')

('TEMPSTR2.CV' = 'TEMPSTR1.CV')

('TEMPSTR2.CV' != 'TEMPSTR1.CV')

Other relational operators are not supported for string comparison.

String Concatenation The full path is constructed from a partial path string (for example, a module name)
and concatenated with a another string (such a string constant) using a plus operator (+). For example:
'OUTLET_POS.$REF' := 'MODULE.CV' + "/PID/SP.CV";

Note Strings written from expressions are limited to 256 characters. The software does not check if the limit is
exceeded and no messages appear. You must ensure that strings written from expressions are no longer than 256
characters.
If one of the terms is a string and the other is numeric, the numeric term is converted to a string and the two strings are
concatenated, resulting in a string. For example:
'TEMPSTR.CV' := "FIC";
'TEMPNUM.CV' := 105;
'TEMPSTR2.CV' := 'TEMPSTR.CV' + 'TEMPNUM.CV''
IF 'TEMPSTR2.CV' = "FIC105" THEN // would be true

String Selection Function (SELSTR) The SELSTR function allows selection from up to five string
constants or string parameters, based on an input to the string selection function. It is intended to take the
place of a series of IFTHEN statements and temporary string parameters.

SELSTR takes float one term (expected to hold an integer value) and five string terms (usually string constants),
returning a string that corresponds to the value of the float term:
Float Value

String Returned

<1.0

empty string

>= 1.0 and <2.0

first string parameter

>= 2.0 and <3.0

second string parameter

>= 3.0 and <4.0

third string parameter

>= 4.0 and <5.0

fourth string parameter

>= 5.0 and <6.0

fifth string parameter

>=6

empty string

64

System Configuration

For example:
'OUTLET_POS.$REF':= SELSTR('SEL.CV',
"FIC101",
"FIC102",
"FIC103",
"",
"") + "/PID1/SP.CV";

Operands
An operand is the data or item in the expression that is operated on. All values are managed as floating point data.
This includes parameters of function blocks that are floating point values.
The valid operands in an expression are:

Named set constants in the form 'SetName:ValueName'.

Inputs (references to inputs of a function block that are float with status data types).

Outputs (references to outputs of a function block that are float with status data types).

Input Device Signal Tags (DSTs) (references to input signals that are float with status data types.

Note The expression evaluator is stack oriented and allows a maximum of 32 operands and operators. The use of
parentheses to organize the expression minimizes the stack usage. The equations are evaluated using RPN (Reverse
Polish Notation).

Operators
Operators allow you to make complex calculations with arithmetic operations within expressions. Operators use
operands to act upon. Normally, operators are used in the following order:
Operand1
Operator
Operand 2;
For example:
OUT1 := 5;
This example shows the use of the addition operator:
OUT1 :=5 + 5;
Normally, the value of the calculation is assigned to either an output, external reference, or temporary variable. The
following operators are supported in DeltaV expressions:
+, -, *, /, AND, OR, NOT, XOR, MOD, !, =,<>, ~=, !=, <, >, <=, >=, **, :=, (,), x?y:z, ~, ^,&, %
Note The equality operator (=) takes precedence over the AND and OR operators. However, it is important to write
your expressions using parenthesis so that the result is as expected.

Expressions

65

Operator Description
Operator

Description

Notes

Multiply

The multiplication operator (*) causes its two operands to be


multiplied.

Divide

The division operator (/) causes the first operand to be divided by


the second. If the first operand is less than zero and the second
operand is zero, the divide operator returns the value 3.402823466e+38. If the first operand is greater than or equal to
zero and the second operand is zero, the divide operator returns
the value +3.402823466e+38.

Add

The addition operator (+) causes its two operands to be added.

Subtract

The subtraction operator (-) causes the second operand to be


subtracted from the first.

?:

Conditional

The conditional operator is a ternary operator (it takes three


operands).
Result := Conditional-expression ? Expression : Expression The
first operand is evaluated and all side effects are completed before
continuing.
When the first operand evaluates to True (a nonzero value), the
second operand is evaluated.
When the first operand evaluates to False (0), the third operand is
evaluated.
For example, the expression alpha<beta ? delta : gamma; (where
alpha and beta are simple operands) means that if alpha is less
than beta, then evaluate delta; otherwise, evaluate gamma.
You many need to rearrange your operands to use the ?: operator.
For example, to write the conditional statement:
IF IN1 < 90 THEN
OUT1 := IN1;
ELSE
OUT1 := 90;
ENDIF;
using the ?: operator, the statement is as follows:
OUT1 :=(IN1<90) ? IN1 : 90
Note Always simplify the second and third operands when using
the ?: operator.

66

System Configuration

Operator

Description

Notes

&

Bitwise AND

The AND (bit) operator compares each bit of its first operand to
the corresponding bit of its second operand. If both bits are 1, the
corresponding resultant bit is set to 1. Otherwise, the
corresponding resultant bit is set to 0.

AND

Logical AND

The logical AND operator produces the value 1 if both operands


are 1 (non-zero). If either operand is 0, the result is 0.

Bitwise OR

The inclusive OR (bit) operator compares each bit of its first


operand to the corresponding bit of its second operand. If either
bit is 1, the corresponding resultant bit is set to 1. Otherwise, the
corresponding resultant bit is set to 0.

OR

Logical OR

The logical OR operator performs an inclusive OR operation on


its operands. The result is 0 if both operands are 0. If either
operand has a non-zero value, the result is 1.

Bitwise NOT

The bitwise complement (or bitwise NOT) operator produces the


bitwise complement of its operand.
Note This operator only works on signed values.

! or NOT

Logical NOT

The logical negation (logical NOT) operator sets the result to 0 if


its operand is TRUE (non-zero). If its operand is False (0), the
result is 1.

Bitwise
Exclusive OR

The OR (bit) operator compares each bit of its first operand to the
corresponding bit of its second operand. If one bit is 0 and the
other bit is 1 (non-zero), the corresponding resultant bit is set to 1.
Otherwise, the corresponding resultant bit is set to 0.

XOR

Logical
Exclusive OR

The logical exclusive OR operator compares the first operand to


the second operand. If one operand is 0 and the other is 1 (nonzero), the result is 1. Otherwise, the result is 0.

Expressions

67

Operator

Description

Notes

MOD or %

Modulus
operator

MOD is the remainder of simple integer division. For example, 13


/ 5 (13 divided by 5) is 2 with a remainder of 3. Therefore, 13
MOD 5 is 3. When the division is inexact, the result is determined
by the following rules:
When the right operand is zero, the result is zero.
When both operands are positive, the result is positive.
When either operand is negative and the result is inexact, the
result is defined as follows:
In division where either operand is negative, the direction of
truncation is toward zero.
When either operation is negative in division with the remainder
operator, the result has the same sign as the dividend (the first
operand in the expression). For example -13 MOD 5 is -3, but 13
MOD -5 is 3.

Equality test

The first operand is equal to second operand.

>

Greater than

The first operand is greater than the second operand.

<

Less than

The first operand is less than the second operand.

>=

Greater than or
equal to

The first operand is greater than or equal to second operand

<=

Less than or
equal to

The first operand is less than or equal to second operand.

!= or <> or ~=

Does not equal

The first operand is not equal to the second operand.


Note The ~= operator only works on signed values.

**

Raise to power

The power operator computes the first operand raised to the power
of the second operand. If the first operand is negative and the
second operand is not an integer, the result is zero.

:=

Assignment to
output

The simple-assignment operator assigns its right operand to its left


operand.

Note The expression evaluator is stack oriented and allows a maximum of 32 operands and operators. The use of
parentheses to organize the expression minimizes the stack usage. The equations are evaluated using RPN (Reverse
Polish Notation).

68

System Configuration

Operator Precedence Rules


Precedence
Order

Operation

Symbol

Order of
Evaluation

Parenthesis

(Expression)

Nonassociative

Raise to power

**

Left

Logical NOT
Bitwise NOT

! or NOT
~

Left

Multiply
Divide
Modulus Operator

*
/
MOD or %

Left

Add
Subtract
Unary minus

+
-

Left

Equality test
Greater than
Less than
Greater than or equal to
Less than or equal to
Does not equal

=
>
<
>=
<=
!= or <> or ~=

Left

Bitwise AND

&

Left

Bitwise Exclusive OR

Left

Bitwise OR

Left

10

Logical AND

AND

Left

11

Logical Exclusive OR

XOR

Left

12

Logical OR

OR

Left

13

Conditional

?:

Right

Functions
The DeltaV software supports a wide variety of functions. DeltaV functions are generally in the following format:
FunctionName( param1, param2, ..., paramN)
Note that the function name is followed by a parenthesis, and the parameters of the function are separated by
commas. These functions can be used in either the Assignment or IF-THEN-ELSE-END_IF expression constructs.

Expressions

69

Expression Functions
Function

Description

Notes

ABS (x)

Absolute value of x

Returns the absolute value of parameter x.

ACOS (x)

Arc cosine of x

Returns the arcosine of x in the range 0 to


radians. If x is less than -1 or greater than 1,
ACOS returns a zero value.

ASIN (x)

Arc sine of x

Returns the arcsine of x in the range -/2 to /2


radians. If x is less than -1 or greater than 1,
ASIN returns a zero value.

ASR16 (i,n)

Arithmetic Shift i Right n


bits, an emulation of
PROVOX ASR in DeltaV
expression.

Assumes 16 bit operand for sign preservation

ATAN (x)

Arc tangent of x

Returns the arctangent of x in radians.

COS (x)

Cosine of x

Returns the cosine of x where x is in radians.

EXP (x)

Exponential of x

Returns the exponential of the parameter x if


successful. On overflow, the function returns the
MAX floating point (3.4E38). On underflow, the
function returns a zero value.

EXPT (x,y)

Raise x to the power of y

Computes x raised to the power of y. If x equals


zero and y equals zero then EXPT returns a value
of one (1). If x is less than zero and y is not an
integer, EXPT returns a value of zero (0).

EUP (e,p0,p100)

Conversion from
Engineering Units (EU)
(e) to percent given the
values at 0% (p0) and
100% (p100).

Standard linear interpolation.

FRACT (x)

Returns fractional part of


a number

Returns the fractional part of x. The result is


positive if x is greater than or equal to zero. The
result is negative if x is less than zero.

LN (x)

Natural logarithm of x

Returns the natural logarithm of x if successful.


If x is not positive, LN returns a zero value.

LOG (x)

Log base 10 of x

Returns the logarithm base 10 of x if successful.


If x is not positive, LOG returns a zero value.

LOG2 (x,y)

Log base x of y

LOG 2 (x,y) returns the logarithm base x


(operand one) of y (operand two) when
successful. If x or y is not positive, LOG2 returns
a zero value and Bad status.

70

System Configuration

Function

Description

Notes

LOGEVENT

Returns a float value of


1.0 if the call succeeded
and a value of 0.0 if the
call failed.

Causes information about significant events


detected in the control module algorithm to be
recorded in the DeltaV Process History log.
LOGEVENT takes one parameter (a string
representing the event to be recorded) and
records it in the Desc2 field of the process event
record associated with this module.
Note There is an 80-character limit on the Desc2
field.

MAX (x,y)

Maximum of x and y

The return value is the greater of the two


specified values.

MIN (x,y)

Minimum of x and y

The return value is the smaller of the two


specified values.

PEU (p,p0,p100)

Conversion from Percent


(p) to Engineering Units
(EU) given the values at
0% (p0) and 100%
(p100).

Standard linear interpolation.

ROL (x,y)

Rotate x to the left by y


bits

Rotates the unsigned x by y bits to the left. The


function wraps bits rotated off one end of the
value to the other end. (Same as ROTL.)

ROR (x,y)

Rotate x to the right by y


bits

Rotates the unsigned x by y bits to the right. The


function wraps bits rotated off one end of the
value to the other end. (Same as ROTR.)

ROTL (x,y)

Rotate x to the left by y


bits

Rotates the unsigned x by y bits to the left. The


function wraps bits rotated off one end of the
value to the other end. (Same as ROL.)

ROTL16 (i,n)

Rotate i Left n bits - an


emulation of PROVOX
16 bit ROTL in DeltaV
expression.

Assumes 16 bit operand.

ROTR (x,y)

Rotate x to the right by y


bits

Rotates the unsigned x by y bits to the right. The


function wraps bits rotated off one end of the
value to the other end. (Same as ROR.)

ROTR16 (i,n)

Rotate i Right n bits emulation of PROVOX


16 bit ROTR in DeltaV
expression.

Assumes 16 bit operand.

ROUND (x)

Round x to nearest float

Rounds x to the nearest integer value.

SELSTR (x,a,b,c,d,e)

Select a string

Returns the string represented by a, b, c, d, or e


depending on value of x.

Expressions

71

Function

Description

Notes

SHL (x,y)

Shift x left by y bits, no


carry

Shifts x left by y number of positions and fills


with zeroes (0).

SHR (x,y)

Shift x right by y bits, no


carry

Shifts x right by y number of positions and fills


with zeroes (0).

SIGN (x)

Sign indicator of x

Returns a Boolean True value (1) if x is positive


or zero. Returns a Boolean False value (0) if x is
negative.

SIN (x)

Sine of x

Returns the sine of x where x is in radians.

SQRT (x)

Square root of x

Returns the square-root of x. If x is negative,


SQRT returns x.

STR_TO_TIME (x)

Epoch time of x

Converts an ISO 8601 formatted string to an


Epoch time value.

STBT (i,b,n)

Set a bit position (n) in an


integer value (i) to a given
boolean value (b).

SYSSTAT (x)

This function returns a


TRUE or FALSE when
queried for system
condition x. User passes
one of the enumerated
values for $sysstat_opts.

Allowable values for $sysstat_opts are


Switchover
AnyDownload
MyDownload
Powerfail
TotalDownload

TAN (x)

Tangent of x

Returns the tangent of x where x is in radians.

TIME (x)

Time of x, where x is a
named set value of
$time_format

Returns the current Local or UTC time as an


Epoch Time value (the number of seconds since
midnight, January 1, 1972).
Note: Assign the output of this value directly to
an output parameter to have it update at one
second intervals. If you set an OUT value in a
Calc block, then wire the output to a parameter, it
updates every 64 seconds.

TIME_TO_STR (x, y)

Time y expressed in
format x

Returns the time of day (in ISO 8601 format) of


the specified Epoch time.

TRUNC (x)

Floor function

Returns a floating point value representing the


largest integer that is less than or equal to x. That
is, TRUNC rounds x to the next lowest integer
value.

Constants
Constants are predefined, unchangeable values in expressions. These constants let you test values against DeltaV
system values without you having to know their internal representations.

72

System Configuration

DeltaV TRUE/FALSE Constants


Constant

Explanation

FALSE

Boolean FALSE. This is always equivalent to 0.0,


whether comparing or assigning.

TRUE

Boolean TRUE. If assigning ('item' := TRUE) then


'item' is set to 1.0. If comparing to TRUE ('item' =
TRUE) the statement is TRUE if the value of 'item'
is >= 1.0.

Note Comparing TRUE/FALSE constants in an expression should only be used against Boolean elements or when
the floating point value is either 0.0 (FALSE) or >=1.0 (TRUE).
DeltaV Status Constants
Status constants are implemented as an 8-bit status word. The numeric value of the status word is determined by
which bits are set.
A CALC block's OUT parameters default to a status of GOOD (128). The expression must explicitly set the status.
Status propagation is not automatic in the Calc block. You can set the status to a numeric value (refer to the topic
Function Block Status Values).
You can also use the GOOD, BAD or UNC constants (for example, 'out1.st' := UNC). There are also constants for the
limit status (the two least significant bits of the status word). If the signal is also limited or constant, you can use these
additional constant words (LIMITED_CONSTANT, LIMITED_HIGH, LIMITED_LOW), but you must combine
them with the status constant (GOOD, BAD, UNC). For example, to set the status to GOOD High Limited, use the
expression 'out1.st':= GOOD | LIMITED_HIGH. The "|" operator is a bitwise OR function. The expression writes a
value of 130 to the status.
Constant

Explanation

BAD

If assigning BAD to a parameter status, the status is set to BAD NonSpecific


NotLimited (numeric value 0).
When comparing a status to BAD, the expression evaluates to TRUE if the
status is <=63.

GOOD

If assigning GOOD to a parameter's status, the status is set to


GoodNonCascade NonSpecific NotLimited (numeric value 128).
When comparing a status to GOOD, the expression evaluates to TRUE if the
status is GoodNonCascade (that is, in the range of (inclusive) 128 to 191).
To test a status for the entire range of GOOD statuses (GoodNonCascade and
GoodCascade), use the greater than or equal to operator (>=). That is, the
value is >= 128.

LIMITED_CONSTANT

When a status field is compared to LIMITED_CONSTANT using the equality


operator (=), the result will be TRUE if the limit status is
LIMITED_CONSTANT.

LIMITED_HIGH

When a status field is compared to LIMITED_HIGH using the equality


operator (=), the result will be TRUE if the limit status is LIMITED_HIGH.

Expressions

73

Constant

Explanation

LIMITED_LOW

When a status field is compared to LIMITED_LOW using the equality


operator (=), the result will be TRUE if the limit status is LIMITED_LOW.

UNC

If assigning UNC to a parameter status, the status is set to Uncertain


NonSpecific NotLimited (numeric value 64).
When comparing a status to UNC, the expression evaluates to TRUE if the
status has a value in the range of (inclusive) 64 to 127.

DeltaV Mode Constants


Constant

Explanation

AUTO

When a mode parameter is connected to an input and compared to AUTO (automatic)


using the equality operator (=), the result will be TRUE if the Actual mode is set to
AUTO. If AUTO is used for assignment, the automatic Target mode will be written.
The numeric value of the AUTO constant is 16.

CAS

When a mode parameter is connected to an input and compared to CAS (cascade) using
the equality operator (=), the result will be TRUE if the Actual mode is set to CAS. If
CAS is used for assignment, the cascade Target mode will be written. The numeric
value of the CAS constant is 32.
Note The CAS constant is not compatible with fieldbus block modes. The Fieldbus
specification calls for the AUTO bit and the CAS bit to be set in order to request the
CAS target mode. For fieldbus function blocks, use the numeric value 48 to set the
target mode to CAS. This value (48) sets both the AUTO bit (16) and the CAS bit (32).

IMAN

When a mode parameter is connected to an input and compared to IMAN (Initialized


Manual) using the equality operator (=), the result will be TRUE if the Actual mode is
set to IMAN. The numeric value of the IMAN constant is 2.

LO

When a mode parameter is connected to an input and compared to LO (Local Override)


using the equality operator (=), the result will be TRUE if the Actual mode is set to LO.

MAN

When a mode parameter is connected to an input and compared to MAN (Manual)


using the equality operator (=), the result will be TRUE if the Actual mode is set to
MAN. If MAN is used for assignment, the manual Target mode will be written. The
numeric value of the MAN constant is 8.

OS

When a mode parameter is connected to an input and compared to OS (Out of Service)


using the equality operator (=), the result will be TRUE if the Actual mode is set to OS.
If OS is used for assignment, the manual Target mode will be written. The numeric
value of the OS constant is 1.

74

System Configuration

Constant

Explanation

RCAS

When a mode parameter is connected to an input and compared to RCAS (remote


cascade) using the equality operator (=), the result will be TRUE if the Actual mode is
set to RCAS. If RCAS is used for assignment, the remote cascade Target mode will be
written. The numeric value of the RCAS constant is 64.
Note The RCAS constant is not compatible with fieldbus block modes. The Fieldbus
specification calls for the AUTO bit and the RCAS bit to be set in order to request the
RCAS target mode. For fieldbus function blocks, use the numeric value 80 to set the
target mode to RCAS. This value (80) sets both the AUTO bit (16) and the RCAS bit
(64).

ROUT

A manual mode where the OUT value is supplied by an external control program rather
than directly by the operator. OUT is supplied through the ROUT_IN parameter. The
block maintains a back calculation output value (ROUT_OUT) to provide bumpless
transfer when the mode is changed.

These constants can be used as numerical values only. Never assign values to constants or use these reserved words as
temporary variables in Calc/Logic blocks.

Comments
Comments are statements placed in an expression that act solely as a documentation tool for users. They have no
effect on the expression. The structures of a comment can take two forms:

REM A single line comment. Any text placed on a line that follows the line that this keyword is on is
ignored. The following example demonstrates a comment using this structure:

REM This code was written June 1998 by B. Gates

(* *) A multiline comment structure that must have the start and the end comment operator to be complete.
The following example demonstrates a comment using this structure:

(* This comment was started on this line


and finished on this line *)

Keywords
The following are reserved keywords in the DeltaV expressions, and they cannot be used as variable names:
ABS

EXP

MAX

SHL

ACOS

EXPT

MIN

SHR

AND

EUP

MOD

SIGN

ASIN

FALSE

NOT

SIN

ASR16

FRACT

OR

SQRT

ATAN

GOOD

OS

STBT

AUTO

GOTO

PEU

SYSSTAT

Expressions

75

BAD

IF

REM

TAN

CAS

IMAN

ROL

THEN

COS

LIMITED_CONSTANT

ROR

TRUE

DO

LIMITED_HIGH

ROTL

TRUNC

ELSE

LIMITED_LOW

ROTL16

UNC

END_IF

LN

ROTR

VAR

END_VAR

LO

ROTR16

XOR

END_WHILE

LOG

ROUND

WHILE

LOG2

SELSTR

MAN

SFC Commands and State Transitions


The modules containing SFCs in the DeltaV system have some predefined states and commands that support
sequencing. The SFC can transition from one state to another depending on the commands it receives. SFCs have the
following 5 states:

IDLE

ACTIVE

STOPPED

COMPLETED

BLOCKED

The SFC also has the following predefined commands:

Start Sequence

Stop Sequence

Reset Sequence

The COMMAND parameter of the SFC module reflects the commands that transition the SFC into different states.
The following figure shows the state transitions and commands for SFCs:

76

System Configuration

SFC Flow Chart

Expressions

77

Actions
Each step is associated with a number of actions. An action can assign a parameter value, set a variable, or run a
function block. Therefore, there are three different types of actions:

Assignment assigns the result of an expression to a variable. When an assignment action is active, the
specified expression is evaluated, causing the destination parameter to be written with the result. No special
action is taken when the transition to inactive occurs.

Boolean references a module-level Boolean parameter of the module you are defining. The associated
Action Text is the Boolean parameter. The action qualifier determines when the parameter is set to TRUE.

Non-Boolean references a function block that is in the module hierarchy. The Action Text is the function
block name. The action qualifier defines when the function block executes.

Note You cannot write directly to a Device Signal Tag (DST) value in an action, even though the action parser allows
you to configure it.
Each action must have a configured action qualifier, which helps define when the action is active. Whether or not an
action is active can be determined given its action qualifier and the step that is associated with the action. The step
that is associated with an action is the step that initiated the action.
Note If an action modifies a destination while that destination is currently being updated by an active action, the
results will be unpredictable.
There are two basic types of action qualifiers: non-stored and stored. An additional type of qualifier, the reset action
qualifier (R), is used in conjunction with stored qualifiers to reset a stored action.
Non-Stored Action Qualifiers:
N Non-Stored
L Time Limited
D Time Delayed
P Pulse
Stored Action Qualifiers:
S Set (Stored)
SD Stored and Time Delayed
DS Delayed and Stored
SL Stored and Time Limited
Actions with a non-stored type of qualifier are only active while the associated step is active or for a portion of the
time that the step is active, depending on the specific qualifier.
Actions with a stored type of qualifier either are active for only a portion of the time that the associated step is active
or remain active after the associated step has gone inactive, depending on the specific qualifier.

78

System Configuration

Note Actions within a step are initially executed at step time=0 seconds. This affects the execution of time-relation
actions. For example, if you configure a step action with a time delay of 10 seconds (time>=10), that step action is
idle from step time=0 to step time=10. When the step time>=10 seconds, the action is executed. It is important to use
the >= operator to ensure that the transition will trip when running on a heavily loaded system or when the system is
being downloaded. Using time=10 operator requires that the time be 10 seconds and no more or less. If the timer
count is 10.1 due to a download, then the action will not trip. Using >= allows that step to trip at any point
immediately after 10 seconds.
A third type of action qualifier, the overriding reset (R) qualifier is used to reset a stored Boolean or Non-Boolean
action. For example, if you want to start an action in Step 1 and continue it until Step 5, you can either use a nonstored qualifier for the first four steps, or you can use a stored qualifier in Step 1 and a reset in Step 5. You can also
reset a stored qualifier by performing an assignment action and setting the active parameter of the action to False.
This is the only way to reset a stored assignment action. Refer to the Overriding Reset (R) Qualifier for Resetting
Stored Actions topic for more details.
Note The order of execution of actions in a given SFC step is effectively in parallel. The order of the actions in the
Action View does not imply any execution order in the controller.

Non-Stored Action Qualifier Types


Non-stored Action Qualifier (N)
A non-stored action of ANY type means that the action is only active while the step is active. A reset is not needed
before the next write to the destination.
Assignment Action
The assignment statement is evaluated (and the assignment made) on each scan through the step actions while the
step is active. When the step goes inactive, the assignment destination retains the assigned value.
Boolean Action
The Boolean destination referenced is written to TRUE on each scan through the step actions while the step is active.
When the step goes inactive, the Boolean destination returns to False.
Non-Boolean Action
The function block referenced is evaluated for each scan through the step actions while the step is active.

Time Limited Action Qualifier (L)


A time limited action is similar to a non-stored action except that you can specify a maximum time that the action
might be active.
Note Actions within a step are initially executed at step time=0 seconds. For a time limited action of 10 seconds, the
action is active from step time=0 to step time=9 and does not execute at step time=10.
Assignment Action

Expressions

79

The assignment statement is evaluated (and the assignment made) on each scan through the step actions until either
the time limit specified as part of the action configuration is met or the step goes inactive.
Boolean Action
The Boolean destination referenced is written to TRUE for each scan through the step actions until either the time
limit specified as part of the action configuration is met or the step goes inactive.
Non-Boolean Action
The function block referenced is evaluated for each scan through the step actions until either the time limit specified
as part of the action configuration is met or the step goes inactive.

Time Delayed Action Qualifier (D)


A time delayed action is similar to a non-stored action except you can specify a delay time before that action goes
active. If the step goes inactive before the time delay is satisfied, the action does not go active as a result of this
action.
Assignment Action
The assignment statement is evaluated (and the assignment made) on each scan through the step actions once the time
limit specified as part of the action configuration is met. The action goes inactive when the step goes inactive.
Boolean Action
The Boolean destination referenced is written to TRUE for each scan through the step actions once the time limit
specified as part of the action configuration is met. The action goes inactive when the step goes inactive.
Non-Boolean Action
The function block referenced is evaluated for each scan through the step actions once the time limit specified as part
of the action configuration is met. The action goes inactive when the step goes inactive.

Pulse Action Qualifier (P)


A pulse action of ANY type means that the action is only active on the first scan through the actions when the step
goes active.
Assignment Action
The assignment statement is evaluated (and the assignment made) on the first scan through the step actions when the
step goes active. After the first scan, the assignment destination retains the assigned value, but it is not rewritten for
each scan.
Boolean Action
The Boolean destination referenced is written to TRUE on the first scan through the step actions when the step goes
active. The Boolean returns to False on the second scan through the actions.
Non-Boolean Action
The function block referenced is evaluated on the first scan through the step actions when the step goes active.

80

System Configuration

Stored Action Qualifier Types


Set (Stored) Action Qualifier (S)
A set (stored) action goes active when the step becomes active and stays active until reset. While the action is active,
the action text is evaluated on every scan through the step actions. Refer to the reset action qualifier description to see
how a reset can be done for each action type.
Assignment Action
The assignment statement is evaluated (and the assignment made) on each scan through the SFC actions. The action
remains active until a reset action is evaluated for this set action. Refer to the reset action qualifier description to see
how a reset can be done for an assignment action.
Boolean Action
The Boolean destination referenced is written to TRUE for each scan of the step actions while the set action remains
active. The action remains active until a reset action is evaluated for that same Boolean destination. Refer to the reset
action qualifier description to see how a reset can be done for a Boolean action.
Non-Boolean
The function block is evaluated on each scan through the step actions. The action remains active until a reset action is
evaluated for that same function block. Refer to the reset action qualifier description to see how a reset can be done
for a non-Boolean action.
Note When the SFC stops, all actions stop.
Because when the SFC stops all actions stop, you cannot have a stored action reset a sequence when the sequence
stops.

Stored and Time Delayed Action Qualifier (SD)


A stored and time delayed (SD) action is similar to a stored action except that you can specify a delay time before the
action goes active. If the step goes inactive before the time delay is satisfied, the action still goes active as a result of
this action once the time delay is satisfied.
When you create an assignment action with a Stored and Time Delayed (SD) qualifier and you have the SFC
connected so that it loops back and continues to restart, the action will delay every time through the sequence, if it
was reset.
For example, S1 in the following figure contains a stored delay action, A1. Suppose A1 is a assignment action with
the text '/PARAM1' := '/PARAM1' + 1; and a delay of 30 seconds. When S1 becomes active, A1 becomes
active. A1 waits 30 seconds and then increments PARAM1. S3 contains an action that resets A1. Because it has been
reset, A1 will delay every time S1 becomes active.

Expressions

81

If A1 was not reset, it would stay active and keep the same output. (The delay would not recur.) So, if you did not
want the delay to occur every time through the sequence, you would not reset the action every time. The same is true
for a Time Delayed and Stored (DS) qualifier.
The only difference between the Stored and Time Delayed (SD) and the Time Delayed and Stored (DS) qualifier
occurs when the step goes inactive before the delay is finished. If this happens before the delay is complete in an SD
action, the action is stored, but in a DS action if the step goes inactive before the delay is complete, the action is not
stored because the delay did not complete.
Note When the SFC stops, all actions stop.
Also note that when the SFC stops, all actions stop. Therefore, you cannot have a stored action reset the sequence
when the sequence stops.
Assignment Action
The assignment statement is evaluated (and the assignment made) on each scan through the step actions, once the
time delay specified as part of the action configuration is met. The action actually goes active (and can be reset) when
the step initially goes active. The action then stays active until a reset action is evaluated for this assignment
statement. Refer to the reset action qualifier (R) description to see how a reset can be done for an assignment action.
Boolean Action
The Boolean destination referenced is written to TRUE for each scan through the step actions, once the time delay
specified as part of the Action configuration is met. The action actually goes active (and can be reset) when the step
initially goes active. The action then stays active until a reset action is evaluated for that same Boolean destination.
Refer to the reset action qualifier (R) description to see how a reset can be done for a Boolean action.
Non-Boolean Action
The function block usage referenced is evaluated for each scan through the step actions once the time delay specified
as part of the action configuration is met. The action actually goes active (and can be reset) when the step initially
goes active. The action then stays active until a reset action is evaluated for that function block usage. Refer to the
reset action qualifier description to see how a reset can be done for a non-Boolean action.

82

System Configuration

Time Delayed and Stored Action Qualifier (DS)


A time delayed and stored action is similar to a stored action except that you can specify a delay time before that
action goes active. If the step goes inactive before the time delay is satisfied, the action does not go active as a result
of this action, and a reset is not required.
Assignment Action
The assignment statement is evaluated (and the assignment made) on each scan through the step actions once the time
delay specified as part of the action configuration is met. The action actually goes active when the time delay is
reached and stays active until a reset action is evaluated for this assignment statement. Refer to the reset action
qualifier description to see how a reset can be done for an assignment action.
Boolean Action
The Boolean destination referenced is written to TRUE for each scan through the step actions once the time delay
specified as part of the action configuration is met. The action actually goes active when the time delay is reached and
stays active until a reset action is evaluated for that same Boolean destination. Refer to the reset action qualifier
description to see how a reset can be done for a Boolean action.
Non-Boolean Action
The function block referenced is evaluated for each scan through the step actions once the time delay specified as part
of the action configuration is met. The action actually goes active when the time delay is reached and stays active
until a reset action is evaluated for that function block. Refer to the reset action qualifier description to see how a reset
can be done for a non-Boolean action.
Stored and Time Limited Action Qualifier (SL)
A stored and time limited action is similar to a stored action except that you are allowed to specify a maximum
amount of time for this action to be active. The action goes active when the step goes active and then remains active
until the configured time has elapsed or a reset is evaluated. If the configured time limit is reached, a reset is not
required.
Assignment Action
The assignment statement is evaluated (and the assignment made) on each scan through the step actions once the step
goes active. The action stays active until the time limit specified as part of the action configuration is met or a reset
action is evaluated for this assignment statement. Refer to the reset action qualifier description to see how a reset can
be done for an assignment action.
Boolean Action
The Boolean destination referenced is written to TRUE for each scan through the step actions starting when the step
goes active. The action stays active until the time limit specified as part of the action configuration is met or a reset
action is evaluated for that same Boolean destination. Refer to the reset action qualifier description to see how a reset
can be done for a Boolean action.
Non-Boolean Action
The function block referenced is evaluated for each scan through the step actions starting when the step goes active.
The action stays active until the time limit specified as part of the action configuration is met or a reset action is
evaluated for that function block. Refer to the reset action qualifier description to see how a reset can be done for a
non-Boolean action.

Expressions

83

Overriding Reset (R) Qualifier for Resetting Stored Actions


To stop the evaluation of a stored type of action, an action with the reset action qualifier is generally used. Any stored
action that is active must be reset before a new value can be stored in that destination with predictable results.
How you reset a stored action depends on the type of stored action it is (either Boolean, non-Boolean, or assignment).
To reset a stored Boolean or non-Boolean action, you define a Boolean or non-Boolean action with a reset qualifier
that resets either the Boolean parameter (for a Boolean action) or the block (for a non-Boolean action). For example,
suppose S1 in the following figure of an SFC contains a stored Boolean action, A1.

A1 references a Boolean parameter called PARAM1. When the step S1 becomes active, the action A1 becomes active
and the parameter PARAM1 is set to TRUE. In summary, you have an action A1 with:
Type:

Boolean

Qualifier:

Stored

Text:

'/PARAM1/

A1 stays active after the step becomes inactive because it is a stored action. Therefore, the parameter, PARAM1,
continues to be set to TRUE until you reset the action. To reset the action and the Boolean parameter, PARAM1, you
must create a step with an action that has a reset qualifier. For example, if you wanted to reset the Boolean parameter,
PARAM1, during step S3, you could define a Boolean action for step S3 that has a Reset action qualifier and uses
PARAM1 for the action text. Then, when S3 becomes active, PARAM1 is reset. In summary, you would create an
action with:
Type:

Boolean

Qualifier:

Reset

Text:

PARAM1

84

System Configuration

You can use this approach for either a Boolean or a non-Boolean action. However, to reset an assignment action, you
must write the reset text differently. For example, suppose the same SFC contains a stored assignment action, A2, in
step S1. When the step S1 becomes active, A2 becomes active and increments the parameter, PARAM2. In summary,
you have an action A2 with:
Type:

Assignment

Qualifier:

Stored

Text:

'PARAM2' := 'PARAM2' + 1;

The action stays active after the step becomes inactive because it is a stored action. Therefore, the parameter,
PARAM2, continues to be incremented until you reset the action. To reset an assignment action, you must make the
action inactive. You do this by setting the ACTIVE parameter to False. Therefore, you would create a non-stored
action that sets 'S1/A2/ACTIVE' to False. For this example, you could use a Pulse (P) action qualifier. In summary, to
reset the assignment action, A2, you would create an action with:
Type:

Assignment

Qualifier:

Pulse (P)

Text:

'S1/A2/ACTIVE' := False;

Note If there is a parallel divergence in your sequence, you must put the reset action in all of the paths of the parallel
divergence to make sure that the action gets reset.

Confirms for Pulse Actions


You can add a confirm expression to an action that has a pulse qualifier. To confirm an action, the action must be
defined as a Pulse qualifier (which is configured on the Action Properties General dialog). Select the Action
Properties Confirm dialog for that action. Write the confirmation expression and assign a timeout value. When the
SFC step containing this action becomes active, the action is initiated. If confirmation is enabled, the confirmation
expression is run. If confirmation does not occur within the timeout value, the action fails.
For example, suppose you want to confirm that the motor is running before moving to the next action in the step. In
this example, the action is to start the motor (Pulse qualifier with the action, SP:MOTOR=RUN, and a failure timeout
set to 20 seconds). The Confirm expression for the Start motor step is PV:MOTOR = RUNNING with a possible
confirm timeout value of 20 seconds.
If there are no pending confirms and no failed confirms, the step action or actions have completed successfully. If the
expression evaluates to TRUE, the SFC will proceed to the next step.
A confirm requires either a Timeout value or a Timeout expression. You could set the Confirm Timeout to a Time
value of 5, meaning that if the motor does not start running within 5 seconds the confirm times out. A timeout value
of 0 means there is no time limit on the confirm timeout.
When a step becomes active, the PENDING_CONFIRMS parameter for the step is set to equal the number of actions
with confirms in the step. In our example, we have one action with one confirm. So, PENDING_CONFIRMS is set to
1. When a confirm either completes or times out, the PENDING_CONFIRMS is decreased by one. When all confirm
actions within the step have either completed or timed out, PENDING_CONFIRMS is set to 0.

Expressions

85

If a confirm condition times out (the Confirm Timeout time expires or the Confirm Timeout expression becomes
TRUE before the Confirm expression becomes TRUE), the FAILED_CONFIRMS parameter is incremented by 1 and
the CONFIRM_FAIL parameter is set to TRUE.
The CONFIRM_FAIL parameter is available at the action level, the step level, and in the SFC. It can be used to send
an alarm so that the operator can take appropriate action.
It is left to the user to configure the transition (following the action with a confirm) to allow confirmation to occur.
This can be achieved by the transition expression being:
'S2/PENDING_CONFIRMS.CV' = 0 AND 'S2/CONFIRM_FAIL.CV' = False
An action with a pulse qualifier can have a built-in delay. This is useful when one or more pulse actions in a step do
not occur immediately after the step becomes active. For example, delays can be used to achieve sequencing within a
step. In this case, each action in the step (except the first one) has a delay configured. The second action is delayed
until the first is completed. The third is delayed until the second is completed, and so on. This technique offers several
advantages. Using a single step can help simplify complex diagrams. If a sequence must occur very quickly, doing the
sequence in a single step can avoid the one-scan delay required by each transition expression.
A delay uses either a delay time value or a delay expression. To add a delay time or expression, select the action and
go to the Action Properties dialog's General tab. As a default, there is no delay time on an action with a pulse
qualifier. If you want an action to be delayed until the previous action has completed, select Expression and enter a
delay expression. Typically, the previous action will already have a confirm expression configured. The delay
expression can check the previous action's state to see when it is complete. The previous action's state will be
complete when its confirm expression evaluates to true. Then, the delay expression will evaluate to true, causing its
pulse action to occur.
The delay expression checks the STATE parameter of the previous action. The path is StepName/ActionName/
STATE. The following example delay expression checks to see if the value of the STATE parameter in action A1 of
step S1 is complete.
'S1/A1/STATE.CV' = '$sfc_action_states:Complete'

86

System Configuration

Alarms and Events


This book contains information on alarms and events in DeltaV software. Click on an item in the Table of Contents
inside this book for more information.

Alarms and Events


Inside this topic
Process Alarms Overview
Device Alarms Overview
Asset Optimization Alarms Overview
An event is any noteworthy occurrence in your process or system that you want the system to react to and record.
Events that are brought to the operator's attention are alarms. Along with standard alarms and events, the DeltaV
system provides the means for users to easily create their own specific alarms and events. Alarms can be applied to
any parameter. When that parameter is non-zero, the system can generate an alarm. The event can be logged to the
Event Chronicle and optionally brought to the operator's attention as an alarm.
The DeltaV system supports the following means for generating alarms:

Standard alarm detection (PV alarms) is provided in the input and PID function blocks. The alarm limits are
configured within the function block. When the alarm condition is detected, the alarm active parameter is set
to 1 (for example, the high limit has been exceeded: HI_ACT = 1).

Custom alarms can be applied to any parameter within a control module. When the parameter is non-zero,
the alarm is set to active (1).

Fieldbus device alarms are generated by fieldbus devices based on the built-in fieldbus device alerts and
PlantWeb alerts when the device alarms are enabled.

HART device alarms are generated by the system based on internal device information. The DeltaV system
polls the HART devices and translates the information into DeltaV alarms.

Asset alarms are generated by external, mechanical assets such as turbines, engines, pumps, and motors and
by external, optimization assets. Asset alarms are integrated into the DeltaV system through an External
Asset Server running on an Application Station.

The DeltaV Operate application provides special preconfigured displays that show operators the most important
active alarms under their control. Active alarm lists can be shown by plant area or unit. With the appropriate security
keys, the operator can acknowledge alarms and suppress noisy alarms until the cause can be resolved.
This section refers to alarms generated in function blocks and modules as process alarms because they are typically
triggered by a process change. This section also refers to alarms that are derived from a fieldbus or HART device as
device alarms.

Process Alarms Overview


The DeltaV system supports the following process alarms:

predefined (standard) alarms

custom alarms

Standard alarms consist of HIGH-HIGH, HIGH, LOW-LOW, LOW, DEVIATION HIGH, and DEVIATION LOW.
Standard alarms are only available in function blocks with built-in alarm state computation.

Alarms and Events

87

Custom alarms are supported at the module level (except unit modules and phase logic modules). Custom alarms
reference existing parameters or user-defined expressions. A custom alarm can be used as an alarm for the operator or
an event to be logged. You customize the alarm by selecting from a set of options.
DeltaV process alarms require alarm calculation and alarm detection.
Calculation - Many DeltaV function blocks include alarm state calculations. Any Boolean parameter can provide the
alarm calculation component for a module. This component is the input to alarm detection. You can also create your
own alarm state calculations by using function blocks that support expressions (for example, the Calc/Logic and
Condition function blocks).
Detection - In order for a module to detect the result of an alarm state calculation, you must associate the result of
that calculation with a specific alarm parameter. When the alarm state calculates to the TRUE value, the associated
alarm parameter triggers.
For the standard alarms, simply select the function block on the diagram, click the right mouse button, and then click
Assign Alarm. The software determines the detection parameters for you. For custom alarms, click the alarm view
pane (lower-right window in Control Studio), click the right mouse button, and then click Add. You select the
detection parameters for the alarm.

Device Alarms Overview


Fieldbus and HART devices can report conditions directly to the DeltaV system. These conditions can range from
potential problems such as hardware failures within the device, loop problems, and misconfigured parameters, to
proactive reporting of upcoming maintenance needed.
Device condition functionality is dependent on the device. Foundation fieldbus devices support either standard
Foundation fieldbus alerts or PlantWeb alerts.
Standard Foundation Fieldbus alerts - Devices report alerts in a single alarm: abnormal. This alarm is based on the
standard Block Alarm definition.
PlantWeb alerts - Devices report alerts in one of three alarms: Failed, Maintenance, and Advisory. The device alerts
have been organized into one of these alarms based on the importance of the alert condition to the health of the
device. These device alarms are visible through the DeltaV Operate alarm interface tools such as the alarm banner
and the alarm summary object. The are also visible in the DeltaV Explorer. Device alarms can be added to your
DeltaV displays as well. They may also provide a recommended action based on alarms. The Configuring Device
Alarms topic provides more information.
Although the alarm interface tools and operator displays give visibility to device alarms, the Diagnostics application
remains the primary tool to find the cause of device integrity status problems.
Within DeltaV software, all Foundation Fieldbus devices also have a communications failure (Not Communicating)
alarm. This alarm is generated when DeltaV software recognizes that a device is no longer communicating on the H1
segment.
HART devices support either standard HART alarming or PlantWeb alerts:
Standard HART alarming - All HART devices connected to non-remote I/O report standard status information to a
set of channel parameters. The DeltaV system assigns this information to three possible alarms: Failed, Maintenance,
and Advisory.
PlantWeb alerts - Devices report status and specific diagnostic (command 48) information which the DeltaV system
assigns to three possible alarms: Failed, Maintenance, and Advisory. Only the status values are also available as
HART channel parameters.

88

System Configuration

Asset Optimization Alarms Overview


Alarms on external mechanical assets such as turbines, engines, pumps, and motors and alarms on external
optimization assets that are monitored and diagnosed by systems that adhere to the Asset Optimization Architecture
can be integrated into the DeltaV system and configured for PlantWeb alerts. External assets report alerts in one of
four alarms: Not Communicating, Failed, Maintenance, and Advisory. Asset alarms are visible through the DeltaV
Operate alarm interface tools such as the alarm banner and the alarm summary object and through DeltaV Inspect.
Asset alarms can be added to DeltaV displays. Asset alarms are configured in the DeltaV Explorer. The Configuring
Asset Optimization Alarms for PlantWeb Alerts topic provides more information.

Alarms and Events

89

System Alarm Management


Inside this topic
Plant Areas
Alarm Priorities
Alarm States
Alarm Types
Alarm Importance
Plant areas, alarm priorities, alarm types, and alarm states all affect the way the system manages individual alarms.
Understanding these concepts is key to developing a good system alarm strategy. This section describes these systemwide concepts. For more information on events and alarms, refer to the Events and Alarms Reference topic.

Plant Areas
Each module is associated with a single plant area. Even if the module appears in the DeltaV Explorer under a unit
module and the unit module is under a process cell, they are all under a plant area and, therefore, are associated with
that plant area.
Devices and Area Association
Fieldbus and HART devices are also associated with areas. If the device is not associated with a control strategy its
area defaults to the area of its associated controller or Logic Solver.
HART Device Area Association - HART device alerts default to the associated controller's alarm area (in the case of
Logic Solvers, this is the Logic Solver's alarm area.). If you configure and saved an I/O block in a module that
references the DST for the HART Device, the module's area becomes the alarm area for the device alerts. This area
remains the associated alarm area until the reference or the module is deleted. If you delete the module, the area
returns to the default controller area. If you rename the module, the new name is reflected as the associated module
name for the device alerts. Also, if a second module is created with an I/O block referencing the same DST, the area
remains assigned to the first module.
To change the area assignment, you must first delete the existing I/O reference in the existing module and then
configure and save the different module with a new I/O reference.
You can find the area and module that the HART device alarms are currently associated with from the Alarms &
Displays tab of the device properties dialog as shown below.

90

System Configuration

Fieldbus Device Area Association - When you assign a module's function block to the primary function block in a
fieldbus device, the device is associated with the plant area (and unit) that contains the referencing module. The
primary function block of a device is the function block with the lowest block index number. This block normally
appears as the first block under the device in the DeltaV Explorer. For fieldbus devices, if the module is deleted or if
the module function block associated with the primary function block in a fieldbus device is deleted, the device
defaults to the area associated with its controller.

Workstations and Areas


While workstations can read and write parameters from anywhere in the system (unless restricted in the workstation
properties dialog), they can only monitor events and maintain a list of active alarms in plant areas that have been
assigned to the workstation's Alarms and Events subsystem.
Any module or device that has an alarm reports it to all workstations to which the module's area is assigned, as long
as the workstations' Alarms and Events subsystems have been enabled. A workstation monitors (logs to the Event
Chronicle) all events in the system that are associated with the plant areas assigned to it.
When you assign an area to a workstation and download it, you must log off the workstation and log on again before
you can see the associated alarms in the Alarm List.
You can add as many as 99 plant areas and assign the plant areas to specific workstations. Make these changes
through the DeltaV Explorer. To assign an area to the Alarms and Events subsystem for a workstation, select the area
and drag and drop it to the workstation's Alarms and Events subsystem. To view the areas assigned to a workstation,
click Alarms and Events (under the workstation name).

Alarms and Events

91

Note A module must also be assigned to the node where it is to execute (a controller or an Application Station is
acceptable for some modules). This is done by assigning (dragging and dropping) the module to the Assigned
Modules subsystem under the desired execution node.
If you do not want an operator to have the authority to control an area (that is, have write parameters in associated
modules), you can configure your system so that the operator has no parameter writing privileges (security write
keys) in that area. Subsequently, when that operator is logged on, alarms from that area are not displayed in the Alarm
Banner or the Alarm List pictures. This way, you can control which alarms are seen by a particular operator. To define
which areas a user is responsible for, define parameter security write keys for specific areas in the DeltaV User
Manager. For information on how to lock alarm parameters, refer to the Parameter and Function Security topic.
Additionally, you can configure the workstation to restrict control to only the areas assigned to the workstation
through the workstation's properties dialog. Therefore, when a user that has sitewide privileges logs on to the
workstation, that user can only affect control to the areas assigned to the workstation. This prevents a user from
controlling an area when the alarms cannot be displayed on the workstation. This is the default configuration when
you create a workstation.
The workstation shows the alarms it processes to DeltaV Operate only if the current user has any parameter security
write keys for the area that contains the alarm. For example:
Areas in the workstation's Alarms and Events
subsystem

Areas in which the user has write privileges

Areas displayed in the Alarm Banner or Alarm List


when this Operator is logged on

Additionally, this user can only write to parameters in Areas C & D when logged on to this workstation (providing the
user has the key for the lock to which the parameter is assigned).

Alarm Priorities
Alarm priorities indicate to the operator the importance of an alarm. The priority affects the order in which alarms
appear in the Alarm Banner and the Alarm List pictures in DeltaV Operate.
The system presents all alarms that you configure with the same alarm priority the same way throughout the system.
If you modify the definition of a particular alarm priority, all alarms configured using that alarm priority will use the
new definition.
There are 12 possible alarm priority levels: numeric values 4 through 15 plus a special log only priority level (value
3). The highest priority value is 15 (it is used for the most important alarms). The lowest priority value is 4.
DeltaV systems prior to release 5.x used a priority system with three alarm priority levels plus the special log only
priority level (value 3):
0

CRITICAL

WARNING

ADVISORY

LOG

92

System Configuration

For backward compatibility, version 5.x no longer uses priority levels 0,1 and 2 in new configurations but will
automatically convert those old priority levels into one of the new levels (4-15).
Events with Log priority (level value 3) are not considered alarms. Use the Log priority to designate an event that is
important enough to be recorded in the Event Chronicle but is not something the operator needs to be aware of.
Events with Log priority are not displayed in the Alarm Banner and the Alarm List links and do not turn on the alarm
horn.
By default, only four of the 12 (plus Log) priority levels are available for configuring alarm parameters in the system:
Default Alarm Priority Definitions
Level
Value

Alarm
Priority
Name

Auto
Acknowledged

Auto Ack
Inactive

Horn Sound

15

CRITICAL

No

No

Buzz.wav

11

WARNING

No

No

Alert_tone.wav

ADVISORY

Yes

No

Beep.wav

LOG

Yes

No

none

You can define up to eight additional priorities using the DeltaV Explorer. You can also modify the alarm priority
names to better describe your alarm prioritizing system. Priority levels that are not explicitly configured are given the
same properties as the next higher configured priority level.
The acknowledged status of the alarm, the current alarm state, the priority value, and the time stamp on the alarm
determine the alarm's importance in the system. Alarms with the larger priority values have the higher importance.
Refer to the Alarm Importance topic for more information.
The following figure shows the dialog in the Explorer for an alarm priority.

Alarms and Events

93

Setting Alarm Priority Properties Window


The alarm priority properties include the following:
Value - Determines the priority value of the alarm priority. The higher the number, the greater the importance of the
alarm.
Auto Acknowledge New Alarms - Determines if alarms of this priority are automatically acknowledged at the time
of alarm detection. The acknowledgment state of an alarm can affect flashing and the order in which alarms are
presented in DeltaV Operate.
Auto Acknowledge when Inactive - Determines if alarms of this priority are automatically acknowledged when the
condition causing the alarm clears. This means that the alarm would no longer be shown in the Alarm Banner or
Alarm List pictures even if the operator never acknowledged the alarm.
Alarm Banner shows - Determines when alarms of this priority are displayed in the Alarm Banner. The choices are
Not Hidden, Unit, and Module. Not Hidden specifies that active alarms of this priority are always shown in the Alarm
Banner identified by its module (or device) name. The Module selection specifies that alarms of this priority should
be identified by their module names and are not shown in the Alarm Banner if there is a more important alarm in
Alarm Banner already showing this module name (the module would be identified at most once in the Alarm
Banner). The Unit selection specifies that alarms of this priority should be identified by the name of the unit
associated with this module, and these alarms are not shown in the Alarm Banner if there is a more important alarm in
Alarm Banner already showing this the name of this unit (the unit would be identified, at most, once in the Alarm
Banner).

94

System Configuration

Wave file - Determines the sound associated with active alarms of this priority. The DeltaV system includes several
WAV format files. When you download the system, these files are copied to \DeltaV\data\sounds. When an alarm
goes into the active state, the system plays a WAV file in a loop-back mode so that it sounds until the operator
acknowledges the horn. You can disable the sound for alarms of a certain priority by deleting the WAV file reference.
Alarms that are auto-acknowledged still play their wave files.

Alarm States
In the DeltaV system, alarms have six potential states, determined by the values of the fields of the alarm parameter.
The following table shows the relationship between the alarm states and values of the alarm parameter fields:
State

OPSUP
Field

ENAB
Field

CUALM
Field

LAALM
Field

NALM
Field

Suppressed

1 ("YES")

(either 0 or 1)

Determined
by alarm state

Determined by
alarm state

Forced to 0
("NO")

Disabled

0 ("NO")

0 ("NO")

Forced to 0
("OK")

Forced to 0
("OK")

Forced to 0
("NO")

Inactive
acknowledged

0 ("NO")

1 ("YES")

0 ("OK")

0 ("OK")

0 ("NO")

Active
unacknowledged

0 ("NO")

1 ("YES")

Non-zero
(alarm word)

Non-zero
(alarm word)

1 ("YES")

Active
acknowledged

0 ("NO")

1 ("YES")

Non-zero
(alarm word)

Non-zero
(alarm word)

0 ("NO")

Inactive
unacknowledged

0 ("NO")

1 ("YES")

0 ("OK")

Non-zero
(alarm word)

1 ("YES")

Any time the state of an alarm changes, the system updates the alarm's information in DeltaV Operate and generates
an alarm state change event that can be recorded in the Event Chronicles.

Alarm Types
An alarm type defines a set of characteristics that determine how alarms appear on displays and in the Event
Chronicle. Each standard alarm is associated with one of these alarm types. If you create a custom alarm, you select
or create the alarm type associated with it. Device alarms do not require alarm types. The alarm words are defined by
the device's definition data, and the information communicated from the device is automatically converted into
device alarm messages.
Note that the alarm type does not define an alarm calculation for the alarm, you must define the alarm calculation for
custom alarms. See Custom Alarm Calculation for more information. A single alarm type can be assigned to several
alarms to give them the same display characteristics.
There are 19 predefined alarm types. You can use these alarm types as they are, modify them, or create additional
ones. Alarm type names are case sensitive.

Alarms and Events

95

Alarm Type Properties


Alarm Type
Name

Alarm
Word

Category

Alarm
Message

Adapt Alarm Active

ADAPT

INSTRUMENT

Adapt Alarm Active %P1

Any Alarm

ANY

SYSTEM

Any Alarm Value %P1

Change From Normal

CFN

PROCESS

Change From Normal Value %P1

Change of State

COS

PROCESS

Change of State

Communication Error

COMM

INSTRUMENT

Communication Error

Deviation Alarm

DEV

PROCESS

Deviation Alarm Target %P1 Actual %P2

Discrete Device

FAILED

PROCESS

%P1

Floating Point Error

FLT

SYSTEM

Floating Point Error

General I/O Failure

IOF

INSTRUMENT

General I/O Failure

High Alarm

HIGH

PROCESS

High Alarm Value %P1 Limit %P2

High High Alarm

HIHI

PROCESS

High High Alarm Value %P1 Limit %P2

Inspect Limit Active

INSPECT

INSTRUMENT

Inspect Limit Active %P1

Low Alarm

LOW

PROCESS

Low Alarm Value %P1 Limit %P2

Low Low Alarm

LOLO

PROCESS

Low Low Alarm Value %P1 Limit %P2

New Alarm

NEW

SYSTEM

New Alarm Value %P1

Open Circuit Detected

OCD

INSTRUMENT

Open Circuit Detected

Overrange

OVER

INSTRUMENT

Overrange Value %P1

Rate of Change

RATE

PROCESS

Rate of Change Rate %P1 Limit %P2

Statistical Alarm

ERROR

SYSTEM

Statistical Alarm Type %P1 Value %P2

Underrange

UNDER

INSTRUMENT

Underrange Value %P1

Note %P1 and %P2 represent the values of user-defined parameters. When configuring an alarm with Control Studio,
check to see if the alarm message expects any user-defined parameters. If so, configure which parameter in that
module should be read at the time of alarm detection to replace the %P1 (and %P2) in the alarm message. Userdefined parameters typically capture the value that caused the alarm, the limit value that was in effect at the time the
alarm was detected, and so on.
When the custom alarm requires a message that is different from the available Alarm Types messages, you must
create a new alarm type. Before trying to use the alarm type in assigning an alarm to a module, you must create the
new alarm type.
The following figure shows the dialog in the Explorer for an alarm type.

96

System Configuration

Setting Alarm Type Properties Window


An alarm type determines the following:
Alarm word - Appears in DeltaV Operate when the alarm is active or unacknowledged. The alarm word can appear
in the Alarm Banner, the Alarm List picture, and in the detail and faceplate displays for the standard DeltaV modules.
When you create a custom display or an Alarm List, you have the option to make the alarm word or the alarm name
appear in the display.
Although device alarms do not have an alarm type, they do have one of the following alarm words: COMM,
FAILED, MAINT, ADVISE, and ABNORM.
Alarm category - Appears in the Event Chronicle for every alarm state change (state changes are listed in the Alarm
States topic). You can use the category for sorting and filtering alarm data inside Event Chronicle.
Alarm message - Appears in the standard Alarm List picture. The alarm message is defined as the Description field.
The message is also logged in the Event Chronicle.
For process alarms, the alarm message is a combination of text strings and variables that you supply in the following
form:
text string %P1 text string %P2
where %P1 and %P2 represent parameter values. You define the parameters in the Optional Alarm Message
Parameters section of the System Alarm Type dialog through the Explorer.

Alarms and Events

97

For example, if you want the operator to see a message like the following for an alarm:
High Alarm 80 Alarm Limit 72
you would type the following in the alarm message box:
High Alarm %P1 Alarm Limit %P2
and use the following parameters for %P1 and %P2:
Parameter 1: PV
Parameter 2: HI_LIM
For process alarms, the alarm message affects all the alarms associated with the alarm type unless you override both
the message and message parameters for a specific alarm in Control Studio.
For device alarms, the alarm message is determined by the information available from the device for the most recent
condition change contributing to the alarm's activation. Fieldbus devices do not report a second condition
contributing to an alarm until the first condition clears. The only message displayed describes the first condition
causing the alarm.

Alarm Importance
The acknowledged status of the alarm, the current alarm state, the priority value, and the time stamp on the alarm
determine the alarm's importance in the system:

Unacknowledged alarms have a higher importance than acknowledged alarms.

After the acknowledgement status is considered, alarms that are still active are considered more important
than alarms that have already cleared but have not been acknowledged by the operator yet.

When more than one alarm has the same acknowledgment status and active status, alarms with larger
priority values have the highest importance.

When more than one alarm has the same priority value, active status, and acknowledgment status, the newer
alarm has a higher importance.

For example, the most recent, acknowledged, active alarm with a priority value of 15 is the most important alarm in
the system. Then, a new alarm occurs that is unacknowledged and has a priority value of 4. This new alarm is of
higher importance than an acknowledged alarm with a priority value of 15 because of the acknowledgement status of
the alarms.

98

System Configuration

Alarm Configuration
Inside this topic
Configuring Standard Alarms
Standard Alarms Calculation
Standard Alarm Detection
Conditional Alarming
Deviation Alarming
Standard Alarm Presentation
Modifying Process Alarms
Configuring Device Alarms
Device Alarm Requirements
Enabling Device Alarms
Configuring Asset Optimization Alarms for PlantWeb Alerts
The following sections describe how standard and device alarms are configured. For information on how to create a
custom alarm, refer to the Custom Alarms topic. For information on alarm fields, refer to Events and Alarms
Reference topic.

Configuring Standard Alarms


The following sections detail calculation and detection for the DeltaV standard alarm set.

Standard Alarms Calculation


Standard alarms use alarm calculations that are predefined in the DeltaV function blocks. You can select which of the
alarm calculations you want the module to detect and present to the operator. For example, if you want only HI and
LO alarms, select only those two. The module does not detect the other potential alarms.
Examples of Function Blocks with Standard Alarms
Function Block

Standard Alarms

AI, Pulse Input, and Manual


Loader function blocks

HI, HIHI, LO, LOLO

DI function block

DISC

PID, Fuzzy Logic Control, Alarm,


and Ratio function blocks

HI, HIHI, LO, LOLO, DV_HI,


DV_LO

An example of a predefined alarm calculation is the HI alarm on the AI (analog input) function block. The HI alarm
compares the PV to a limit value as follows:
HI alarm is true if PV > Alarm Limit (HI_LIM)
To create a standard alarm, select the function block on the diagram in Control Studio, click the right mouse button
and then click Assign Alarm. On the Block Alarms dialog, select the alarms you want to use. The system provides
default information, including the name of the alarm, the alarm limit, and the alarm priority.

Alarms and Events

99

Assigning an Alarm Dialog Window


After you select the alarm, you can rename it. You can use any name that makes sense for your application, such as
FLOW_HI. When the alarm is active, the system displays this name in DeltaV Operate and includes it in the Event
Chronicle. Because FLOW_HI is a module parameter, it is displayed with a bell icon in the alarm window of Control
Studio and in the DeltaV Explorer hierarchy.
You can also modify the default alarm limit and alarm priority. The alarm limit is the value above which you want
FLOW_HI to activate an alarm. The alarm priority determines the color, sound, and importance to the operator. You
must decide how important the FLOW_HI alarm is to your plant operation, as compared to the other possible alarms
that could be occurring. Refer to the System Alarm Management topic for more details on alarm priority.
Finally, you can make each standard alarm conditional by selecting the Conditional alarming box. The Conditional
alarming box extends the block alarm parameters, enabling you to use time delays or additional process conditions to
avoid unnecessary alarms. Selecting this box makes all of the standard alarms conditional. The Conditional Alarming
topic provides more detailed information.

100

System Configuration

Standard Alarm Detection


Each standard process alarm (except for fail) uses two parameters with the following name relationship:

alarm_ACT - One (1) when true (in alarm)

alarm_LIM - Associated limit value

For example, the HI alarm shown in the preceding check box has the following parameters:

HI_ACT - HI alarm state parameter (true = in alarm)

HI_LIM - HI alarm limit parameter (PV > HI_LIM = alarm)

All standard alarms use a calculation according to the following form:


HI_ACT is true if PV > Alarm Limit
The system sends the alarm to DeltaV Operate when the HI_ACT parameter becomes true (HI_ACT is true when
HI_LIM exceeds the limit value). All alarm calculations (that is, *_ACT) are basically true/false conditions, where
the true condition indicates that the alarm is active. All alarms (for example, HI_ACT in the preceding discussion)
display the configured alarm word (for example, High) in DeltaV Operate when there is an alarm.

Conditional Alarming
The conditional alarming feature enables you to easily add alarm time delays and enable/disable alarms to minimize
nuisance alarms.
For example, when an upstream pump is turned off, the downstream low flow alarm is temporarily not meaningful.
The low flow alarm becomes a nuisance alarm when the pump is off and should be disabled. The LO_ENAB
parameter can be used to dynamically enable/disable the alarm. When this pump is turned back on, it may be best for
the low flow alarm to remain disabled for a short period of time, allowing the flow rate time to rise above the low
flow alarm limit. The LO_ENAB_DELAY parameter causes a delay in setting an alarm immediately after the alarm
has been enabled using the LO_ENAB parameter.
Function blocks and extended function blocks that have built-in standard alarms also support conditional alarming.
Conditional alarming for a function block is enabled by selecting the context choice Assign Alarm and then checking
the Conditional alarming check box. When conditional alarming is enabled, five new parameters are added to the
block for each available ACT parameter (HI_ACT, HI_HI_ACT, LO_ACT, LO_LO_ACT, DV_HI_ACT,
DV_LO_ACT and DISC_ACT). In the descriptions that follow, the term alarm_ is used to represent either HI,
HI_HI, LO, LO_LO, DV_HI, DV_LO, OR DISC, depending to the particular alarm being configured. The ACT
parameter indicates the current status of its alarm condition, with 1 (true) representing an alarm condition. The five
additional parameters are:
alarm_ENAB This parameter enables /disables conditional alarm processing for a single alarm. The default value
for this parameter is enabled (1), when conditional alarming for a function block is enabled. You can write to the
alarm_ENAB parameter to dynamically enable/disable the alarm based on external process conditions.
When alarm_ENAB is disabled (0):

The alarm_ACT parameter is immediately forced to 0 (false).

No alarm processing occurs.

alarm_DELAY_ON This parameter delays the time (in seconds) that it takes for alarm_ACT to be true (1) after the
alarm condition is detected. If the alarm condition clears before the delay time is reached, the alarm_ACT parameter
remains false (0) and the timer is reset. Every time the alarm condition clears, the timer resets.
alarm_DELAY_OFF This parameter delays the time (in seconds) that it takes for alarm_ACT to be set to 0 (false)
after the alarm condition clears. If the alarm condition reoccurs before the delay time is reached, the alarm_ACT
parameter remains true (1) and the timer is reset. Every time the alarm condition is detected, the timer resets.

Alarms and Events

101

alarm_ENAB_DELAY This parameter delays the time (in seconds) before alarm processing begins immediately
after the alarm is enabled (alarm_ENAB becomes true). The alarm_ACT parameter is forced to 0 for the time
specified (in seconds). The timer resets whenever alarm_ENAB goes from zero to 1.
alarm_HYS - This parameter is used as a deadband when resetting base alarm conditions for analog values. The
block uses the value of alarm_HYS instead of the standard ALARM_HYS. When conditional alarm detection is
enabled, the block uses ALARM_HYS as the deadband for deviation alarm conditions only.
Example
Conditional alarm behavior is influenced by the module and block execution scan rates. For example, if a module
executes at a five second scan rate and a block in the module executes every 10 module scans, then the block runs
every 50 seconds. If any conditional alarming delay is set to 50 seconds or less, the delay condition is met the next
time the block runs. So if the alarm condition is met, the alarm becomes active between 0 and 50 seconds after the
alarm condition was met. If the delay condition was set to 51 seconds, the alarm would become active between 51 and
100 seconds after the alarm condition was met.

Deviation Alarming
PID, FLC, ALM and RTO are designed to minimize nuisance deviation alarms due to SP changes. The DV_HI_ACT
or DV_LO_ACT parameters available in these blocks are forced to false for a period of time after a setpoint change is
made that is large enough to (without the suppression) cause the deviation alarm condition to become active
immediately. Changes in SP when the block is in Cas or RCas mode do not impact the calculation.
The ACT parameter is forced to False until the deviation alarm condition would normally be reset (if it had not been
suppressed).
For example, if the deviation limit is 2 and a SP change of 3 is made, a deviation alarm would typically occur.
However, since this deviation is due to a user SP change, the deviation alarm is disabled until the error (SP-PV) is less
than 2.

Standard Alarm Presentation


DeltaV Operate is the alarm presentation vehicle in the DeltaV system. The presentation is based on the alarm
properties and the alarm type. Refer to the System Alarm Management and Alarm Presentation topics for more
details on configuring the alarm presentation.

Modifying Process Alarms


All the alarms you add to a module, whether custom or standard, appear in the Alarms window in Control Studio.
To modify a standard or custom alarm:
1

Select the alarm in the Alarm window.

Click the right mouse button and then click Properties.

Edit the Alarm properties dialog.

102

System Configuration

Configuring Device Alarms


Fieldbus and HART devices support as many as four device alarms:

Not Communicating (COMM_ALM) - the device has stopped communicating.

Failed (FAILED_ALM) - the device has determined that it can not perform its critical functions.

Maintenance (MAINT_ALM) - the device has determined that it requires maintenance soon.

Advisory (ADVISE_ALM) - the device has determined a condition that does not fall into the other
categories. The severity of an advisory alarm depends on the device type.

Certain fieldbus devices may have only two device alarms: Not Communicating (COMM_ALM) and abnormal
(ABNORM_ALM). The meaning of an abnormal alarm function depends on the device type.
Refer to the device documentation for a more specific description of the parameters.
The interface shows the individual alarms for a fieldbus device in the right pane along with their configurable
parameters. The interface for HART devices is similar.

Device alarms can be enabled to participate in the DeltaV alarm interface tools such as the alarm banner and the
alarm summary.

Alarms and Events

103

Device Alarm Requirements


In order for the device alarms to participate in the DeltaV system, make sure that:

for fieldbus device alarm support, the H1 fieldbus card is a Series II card. Earlier cards do not support device
alarms.

the HART or fieldbus device follows module naming conventions. If the device name does not conform to
the module name rules, device alarms cannot be enabled and the system notifies the user.

device alarms are enabled.

Also:

Review the Plant Areas topic in order to understand in which area the device is assigned.

Assign the area that contains the device to the Alarms and Events subsystem of the appropriate workstations

Download the workstation setup data for the workstation.

Many Fieldbus devices have configurable properties that enable/disable conditions detected within the
device from contributing to causing a device alarm. Conditions that should cause an alarm should be enabled
within the device. These properties can be accessed through the Configuration properties of the device in
DeltaV Explorer.

Fieldbus devices that support PlantWeb alerts have configurable properties that can suppress communication
of each device alarm. If the device is to communicate that device alarm to the DeltaV controller, that device
alarm must not be suppressed within the device. These conditions can be accessed through the Conditions
dialog for the device in DeltaV Explorer.

HART device alarms can be suppressed through the HART device detail displays. Certain HART devices
from Emerson companies have unique detailed displays. All other HART devices (those that use the
standard status information for their alarms) use the HARTgeneric_dt.grf picture. Detail displays show all
the active conditions. Refer to Device Detail Displays for more information.

Enabling Device Alarms


Fieldbus and HART device alarms are enabled by default when you add a new device to the control network from the
Explorer library. However, device definitions from DeltaV version 6.1 and earlier do not have the alarms enabled.
You must enable them.
You can change the enabled/disabled status of the alarms for the device as a whole and for each individual alarm. The
enable/disable setting for the device is on the Alarms & Displays tab of the device properties dialog. To access the
setting:
1

Select the device.

Right-click Properties.

Click the Enable Device Alarms check box. The figure below shows the Fieldbus Device Properties dialog. The
HART Device Properties dialog is similar.

104

System Configuration

The Enable Device Alarms property determines whether the alarms are available within the DeltaV system. If this
box is not checked, the alarms will not be available through parameter browsers. In addition, the individual alarms do
not appear in the Explorer and device alarm communications will not be attempted with the device. If you disable
device alarms for a device, any configurable properties of the individual alarms (alarm enable and priority) are
discarded. If the device alarms for a device are subsequently enabled again, the configurable properties are set to their
default values.
You enable or disable individual alarms as follows:
1

Select the alarm.

Right-click Properties.

Click the Enabled check box.

Alarms and Events

105

The enabled/disabled property for the individual alarms corresponds to the .ENAB field for the alarm. Control
modules, OPC client applications and Operators using displays can change the .ENAB field for the alarm.
Note For fieldbus devices, changing the .ENAB field for a device alarm does not change the corresponding alarm
enable status in the field device. Also note that when you download the field device (along with the device alarms),
the corresponding enable is set to be consistent with the setting in the field device.
In general, it is possible to read and write the parameter fields of device alarms from control modules that run in the
same node. This type of reading and writing is typically limited to enabling or disabling certain device alarms based
on the operating state of the module. For example, you might want to disable advisory alarms, which depend on the
process to be active to work properly, when the unit is idle.

Configuring Asset Optimization Alarms for PlantWeb Alerts


External mechanical assets such as turbines, engines, pumps, and motors, and external optimization assets report
alerts in one of the following alarms:

Not Communicating (COMM_ALM) the device has stopped communicating.

Failed (FAILED_ALM) the device cannot perform it's critical functions.

Maintenance (MAINT_ALM) the device requires maintenance soon.

Advisory (ADVISE_ALM) a device condition exists that does not fall into the other categories. The
severity of the alarm depends upon the device type.

Abnormal (ABNORM_ALM) the meaning of an abnormal alarm depends on the device type.

Use the DeltaV Explorer to configure asset alarms (after you enable Asset Optimization Alarms in System
Preferences). Configuration involves adding an External Asset Server to an Application Station, configuring the
server properties, synchronizing the server configuration with the DeltaV system, and configuring properties for the
plant hierarchy, asset folders, and assets. The connection with the External Asset Server is made through the server
connection URL and the server access credentials (user name and password). The server connection URL and server
access credentials are configured in the Server Properties dialog box. Be sure to download the workstation after
configuring asset alarms.
Adding and Configuring an External Asset Server
Refer to the Getting Started with Your DeltaV Digital Automation System manual for information on adding an
Application station to the DeltaV Explorer. From the Application station, click External Asset Interfaces/New
External Server to add an External Interface Server to the configuration. Once an External Asset Server has been

106

System Configuration

added to the DeltaV system, you can delete it, rename it, configure its properties and synchronize its configuration
with the DeltaV system. Use the What's This help for information on the fields in the Properties dialog. Here are a
few things to keep in mind when configuring the server properties:

Description it is recommended that a meaningful description be used as this is what's seen in the DeltaV
Diagnostics program.

Server Connection URL and Access Credentials IP address or Node address obtained from the server's
manager + asmx application name, unique for each server.

Access Credentials Username and password in the form username|password.

Alert Synchronization Period the DeltaV system periodically polls the Asset Server for new alarm
information. Use this field to specify the time period between each poll. The range is 5 to 1440 minutes.

Node Integrity Depends on Server's Integrity the default action is for the overall integrity of the External
Asset Server to be rolled into the Application Station's integrity. It is recommended that the default be used
because operators are immediately made aware of alarms when they are visible at the Application Station.

Default Asset Alarms as new assets are created during synchronization, alarms are initially configured
based on the defaults. Alarms that are grayed on the Default Asset Alarms page are not supported on the
external asset system.

Synchronizing Configuration between an Asset Server and the DeltaV System


The Synchronize Configuration command synchronizes the configuration of the DeltaV system with the asset server.
Any differences between the DeltaV system and the asset server are changed on the DeltaV system. Synchronization
does not affect the configuration of the external asset system. Select the Asset Server, right click and select
Synchronize Configuration to open the Synchronize Configuration Wizard. Use this Wizard to make decisions about
new assets that have not been added to the DeltaV system and old assets that no longer exist on the External Asset
Server. Be sure to read the help text in the left pane of every screen. Successfully completing the Wizard builds the
Plant Hierarchy structure. Refer to Configuring Asset Properties for helpful information about using the Wizard to
customize multiple asset properties.
The following figure shows a plant hierarchy that was built in the DeltaV Explorer under the Application Station after
the server configuration was successfully synchronized with the DeltaV system.

Alarms and Events

107

Configuring the Plant Hierarchy and Asset Folders


The plant hierarchy name and asset folder names come directly from the Asset Server and cannot be renamed. They
can be deleted. If you delete a plant hierarchy or asset folder from the hierarchy in the DeltaV Explorer, all
subordinate objects are also deleted. Be aware that if an asset is deleted from the Explorer hierarchy but remains
configured on the external asset server, it will show up again in the DeltaV Explorer when the configuration is
resynchronized unless it is deleted during synchronization. Configuration options for the plant hierarchy and asset
folders include adding a description and associating alarms and events with a DeltaV plant area. When alarms and
events are associated with a plant area from the plant hierarchy or asset folders levels, all subordinate asset alarms are
included in the association. This enables large groups of asset alarms to be easily assigned to a single area. However,
an area can also be associated with a lower level asset folder. In addition, an individual asset can be associated with a
control module for area association. Association at a lower level takes precedence over a higher level.
Configuring Asset Properties
You can use the Wizard during the synchronize configuration operation to configure the properties of multiple assets.
You can also configure individual asset properties after an asset has been added to a Plant Hierarchy in the DeltaV
Explorer. Use Control/Select in the Wizard to select multiple assets and then click the Create button to customize the
properties. Use the What's This help for information on the fields in the Property dialog boxes and use the help in the
left pane of the Wizard. When assets are added to the DeltaV system, the system checks the names to ensure that no
naming conflicts exist between the asset and other modules. The system automatically modifies an asset name during
synchronization if a naming conflict occurs and includes the asset's original name in the asset's descriptor. If you
customize an asset name through the Wizard, be sure that you observe DeltaV naming conventions. Otherwise, you
will get an error message and the asset will not be added to the plant hierarchy. Refer to module naming conventions
for information. Asset configuration options include adding a description, associating a primary control display and
faceplate display with an asset, enabling and configuring asset alarms, and associating assets with a DeltaV plant area
or module. Assets can be deleted from an asset folder and renamed. If an asset is deleted from the DeltaV system, but
remains configured on the external asset system, the asset will reappear in an asset folder when the configuration is
synchronized again unless the asset is deleted during synchronization.

108

System Configuration

Description
A default description is taken from the asset server. Because the description appears in the DeltaV Operate Alarm
Banner and Alarm Summary, it is highly recommended that you ensure that the description is meaningful to
operators.
Primary Control and Faceplate Displays
Like other DeltaV device alarms, asset alarms can be associated with a faceplate display that operators use to respond
to alarms on the asset. The default asset alarms faceplate is Asset_FP. Similarly, assets can be assigned to a primary
control display. Refer to Responding to Alarms for information on the asset alarm faceplate and primary control
displays.
Area Associations
Assets can be associated with a plant area for alarm and event reporting. Area associations can be made at the
workstation, plant hierarchy, and asset folder levels. All subordinate levels are included in the area association of the
parent level unless the subordinate level is associated with a different area. Review plant areas for more information.
Module Associations
Assets can be associated with modules. For example, the vibration alarms for a pump can be detected and reported
through an asset module while the pump is monitored and operated through a control module. An asset associated
with a module is associated with the same plant area and, if applicable, the same unit/equipment/control module as
the associated module. The asset is also moved if the associated module is moved to a different area. This ensures that
all alarms, both asset and control alarms for a single piece of equipment, are always reported in the same area. If the
associated module is deleted, the asset alarm's area association is determined by the asset's parent level in the
hierarchy.
Enabling and Disabling Asset Alarms
Like other alarms, asset alarms must be enabled in order to be visible to the DeltaV system. Alarms can be enabled/
disabled for an individual asset through the Alarm page of the Asset Property dialog and enabled/disabled for an asset
and all subordinate assets through the Disable/Enable All Asset Alarms commands on the asset's context menu.
Working with Asset Alarms
The presentation and response to asset alarms in the DeltaV system is similar to other device alarms. Review the
following topics for information:

Alarm Presentation

Responding to Alarms

Diagnosing Problems
Use the DeltaV Diagnostics program to diagnose problems at the External Asset Interfaces Subsystem and server
levels. Refer to Books Online and the DeltaV Diagnostics help for information on using DeltaV Diagnostics.
Asset Alarm Requirements
For asset alarms to participate in the DeltaV system, be sure that:

The asset name conforms to DeltaV module naming conventions.

Alarms are enabled.

Plant area assignments have been made.

The areas that contain the assets are assigned to the Alarms and Events subsystem on the Application Station
as well as any Operator Station from which asset alarms are viewed.

The Application Station has been downloaded.

Alarms and Events

109

Alarm Presentation
Inside this topic
Alarm Banner
Customizing the Alarm Banner
Alarm Thresholds
Menu Commands
Troubleshooting the Alarm System
The alarm priority and current alarm state determine many of the presentation characteristics for an alarm. For more
information on alarm priority, alarm state, and alarm type, refer to the System Alarm Management topic.
The following sections describe the components of the interface application that operators use to manage alarms.

Alarm Banner
The Alarm Banner is in the lower section of the screen in DeltaV Operate. It provides buttons for the five most
important alarms monitored by this workstation for the current DeltaV user. Multiple (from two to four) monitor
workstations display the ten most important alarms. The Alarm Banner enables the operator to focus on the most
important alarms first. Any alarms of a priority (typically lower priority alarms) not shown in the alarm banner do not
sound the horn on that workstation.
The buttons show the name of the modules, units, and devices in alarm. The banner can show all active process
alarms in a module, or you can configure the alarm priorities so that only the most important alarm for a module or
unit occupies a position in the alarm banner (see the description for the Alarm Banner shows field). Maintenance
workstations are designed for managing fieldbus devices and so show only device alarms in the alarm banner.
The operator can access the display needed to correct the alarm condition by clicking the alarm in the Alarm Banner.
For device alarms, the alarm banner shows alarms with the Warning priority. Each device alarm may be triggered by
one of several device conditions. The banner shows one active alarm even if more than one device condition is
causing the alarm. For example, if two device conditions are causing a Maintenance alarm, the banner only shows
one Maintenance device alarm. For HART device alarms a message indicates that multiple conditions are active.
There is also an extended information button next to each alarm button (refer to the following figure). When you click
an extended information button, the associated alarm's time stamp, parameter name, alarm word, and alarm priority
are displayed at the bottom of the banner.
If you enable the Primary Control button and click one of the five alarm buttons (for example, CAS5), DeltaV
Operate displays the primary control display (in the main process graphic area). If you enable the Faceplate button
and click one of the five alarm buttons, DeltaV Operate displays the faceplate assigned to the module.
The control display is a property of the module or fieldbus device. You can define displays for a module using the
Explorer or Control Studio. Define the displays for a device using the Device Properties in Explorer.

110

System Configuration

DeltaV Operate Alarm Banner

Customizing the Alarm Banner


The DeltaV system allows you to manage how alarms are presented to your operator. The alarm banner in particular
enables you to present alarm information to operators concisely and intuitively while minimizing nuisance alarms
The alarm banner provides an overview of the operator's highest priority alarms. The alarms shown are based on the
areas for which the operator is responsible and are assigned to that operator's workstation. The alarm banner also
provides the ability to select an alarm and go immediately to an associated display.
The DeltaV system supports 12 different alarm priorities. Each priority includes a number of user-defined
characteristics. You define alarm priorities in the DeltaV Explorer under Setup/Alarm Preferences. Once the alarm
priorities have been defined, all alarms in your DeltaV system of that priority will behave the same (for example, they
have the same color, sound, and acknowledge characteristics). Each priority has an alarm banner option of Not
Hidden, Module or Unit. This option is set in the Alarm Priority Properties dialog box. Not Hidden specifies that
active alarms of this priority are always shown in the alarm banner. The Unit and Module selections specify that
alarms of this priority are displayed in the alarm banner only if they are the most important alarm for the associated
Unit or Module. The default selection is Not Hidden.
Since there is no one right approach for alarm presentation, the DeltaV system offers you the flexibility to easily
define system-wide alarm presentation. The following table shows six typical alarm presentation methods. Select the
method that best matches your plant operating philosophy. You can use combinations of the alarm presentation
methods. Any combination of methods should follow a general philosophy. As you develop an alarm presentation
philosophy, consider whether lower priority alarms should be treated differently than higher priority alarms or,
consider the changes that should be made in alarm behavior as the alarm priority increases. Another approach is to
think of the 12 priorities as three groups of four, where the characteristics are determined by the priority's placement
within the group.

Alarms and Events

111

Changing the default alarm presentation or a presentation method that you selected is quick and easy. Simply change
each alarm priority in the DeltaV Explorer and download the Changed Setup Data to each workstation. Alarm priority
changes are immediately seen on the workstations.
Alarm
Presentation
Methods

Alarm Banner
Behavior

Typical Use

Alarm
Philosophy

What if a module
has one alarm
that is critical
and another
alarm that is
not? What do I
see in the alarm
banner?

1. Show all alarms


(All alarm
priorities
configured to Not
Hidden. This is the
default.)

The alarm banner


shows all alarms in
priority order.

Systems with a
smaller number of
alarms per operator.

It is important for
operators to see
each individual
alarm.

The module is
shown twice
displaying the
critical alarm and
the other alarm in
priority order.

2. Show alarms by
module (All alarm
priorities
configured to
Module.)

The alarm banner


shows alarms in
priority order, by
module.

Systems with a
medium number of
alarms per operator.

Showing every
alarm adds too
much clutter to the
alarm banner.
Operators need to
see which modules
have alarm activity.
Showing only the
highest priority
alarm per module is
the most productive
approach.

The module is
shown once
displaying the
critical alarm.

Systems with a
larger number of
alarms per operator.

Operators need an
overview of the
plant from the alarm
banner. Showing
only the highest
priority alarm per
unit is the most
productive
approach.

The unit is shown


once displaying the
critical (highest
priority) alarm.

When multiple
alarms are active on
the same module,
multiple alarms are
shown in the alarm
banner for that
module.

When multiple
alarms are active on
the same module,
only the highest
priority alarm is
shown in the alarm
banner for that
module.
3. Show alarms by
unit (All alarm
priorities
configured to
Unit.)

The alarm banner


shows alarms in
priority order, by
unit.
When multiple
alarms are active
within the same
unit, only the
highest priority
alarm is shown in
the alarm banner for
that unit.

112

System Configuration

Alarm
Presentation
Methods

Alarm Banner
Behavior

Typical Use

Alarm
Philosophy

What if a module
has one alarm
that is critical
and another
alarm that is
not? What do I
see in the alarm
banner?

4. Show critical
(high priority)
alarms always,
other (lower
priority) alarms by
module

Critical Alarms

Systems with a
medium number of
alarms per operator,
with some very
critical alarms.

There are some


alarms that must
always be presented
to the operator.
However, the
majority of the
other alarms are
best presented by
module.

Both alarms are


active and
unacknowledged
the module is
shown once
displaying the
critical alarm.

The alarm banner


shows all critical
alarms in priority
order.
When multiple
critical alarms are
active on the same
module, multiple
alarms are shown in
the alarm banner for
that module.
All Other Alarms
The alarm banner
shows alarms in
priority order, by
module.
When multiple
alarms are active on
the same module,
only the highest
priority alarm is
shown in the alarm
banner for that
module.

Alarms and Events

Both alarms are


active and only the
critical alarm is
unacknowledged
the module is
shown once
displaying the
critical alarm.
Both alarms are
active and only the
non-critical alarm
is unacknowledged
the module is
shown twice
displaying both the
critical alarm and
other alarm.

113

Alarm
Presentation
Methods

Alarm Banner
Behavior

Typical Use

Alarm
Philosophy

What if a module
has one alarm
that is critical
and another
alarm that is
not? What do I
see in the alarm
banner?

5. Show critical
(high priority)
alarms always,
other (lower
priority) alarms by
unit

Critical Alarms

Systems with a
larger number of
alarms per operator,
with some very
critical alarms.

There are some


alarms that must
always be presented
to the operator.
However, the
majority of the
other alarms are
best presented by
unit.

The module and the


critical alarm show
once. The unit and
the other alarm
show once.

The alarm banner


shows all critical
alarms in priority
order.
When multiple
critical alarms are
active on the same
module, multiple
alarms are shown in
the alarm banner for
that module.
All Other Alarms
The alarm banner
shows alarms in
priority order, by
unit.
When multiple
alarms are active on
the same unit, only
the highest priority
alarm within that
unit is shown in the
alarm banner for
that module.

114

System Configuration

Alarm
Presentation
Methods

Alarm Banner
Behavior

Typical Use

Alarm
Philosophy

What if a module
has one alarm
that is critical
and another
alarm that is
not? What do I
see in the alarm
banner?

6. Show critical
(high priority)
alarms by module,
other (lower
priority) alarms by
unit

Critical Alarms

Systems with a
larger number of
alarms per operator,
with multiple
critical alarms on
modules.

There are a number


of critical alarms.
Often there is more
than one critical
alarm on the same
module. However,
operators only need
to know if a module
has any critical
alarm active. The
majority of other
alarms are best
presented by unit.

The module and the


critical alarm show
once. The unit and
the other alarm
show once.

The alarm banner


shows alarms in
priority order, by
module.
When multiple
critical alarms are
active on the same
module, only the
highest priority
alarm is shown in
the alarm banner for
that module.
All Other Alarms
The alarm banner
shows alarms in
priority order, by
unit.
When multiple
alarms are active on
the same unit, only
the highest priority
alarm within that
unit is shown in the
alarm banner for
that module.

Note You can customize the priority of the alarms displayed in the alarm banner using the UserSettings file.
UserSettings contains one setting for device alarms and one setting for process alarms. By default, all process alarms
are shown, and only HART and fieldbus device alarms of priority eight and above are shown.

Alarm Thresholds
The workstation alarm threshold determines what priority of alarms are shown in the alarm banner and sound the
horns. By default, workstations are defined to show and annunciate all process alarms (priorities 4 -15) and a subset

Alarms and Events

115

of device alarms (priorities 8 - 15). This means that device alarms with priorities below 8 will not be shown in the
alarm banner and will not sound the horn. The device alarm defaults were selected because many low priority device
alarms do not represent a potential impact on the process and are primarily intended for maintenance personal.
However, these alarms are still visible to the operator in the Alarm Summary display, in user-defined graphics and in
the Event Chronicle.
The default alarm threshold setting may be modified for one or more workstations in the UserSettings.grf file. The
workstation variables used for alarm thresholds are
frsVariables.gn_ProcessAlarmThreshold.CurrentValue
frsVariables.gn_DeviceAlarmThreshold.CurrentValue
These variables can also be changed dynamically while in run mode. For example a button can be configured to
modify the alarm banner to only show and annunciate process alarms of priorities above 12, for use during an upset.

Menu Commands
Acknowledge All - This command acknowledges all of the alarms in the selected picture provided the picture has
datalinks referencing each module down to its ALARMS[1] parameter, for example, DVSYS.LIC-101/
ALARMS[1].A_ATTR. If there is not an ALARMS[1] datalink on the picture, or if the Alarm Banner or toolbar area
is selected, no alarms are acknowledged.
Acknowledge One (Ctrl-K) - This command acknowledges a single selected alarm.

Troubleshooting the Alarm System


The section provides troubleshooting steps for some possible alarm problems.
When something should be in alarm but is not, perform the following steps:
1

Make sure that the referenced alarm parameter (for example, HI_ACT parameter in a function block) is not 0.

Make sure that the module is executing. If the module is executing, the MSTATE parameter value for the module
will be In Service.

Make sure that the alarm is enabled. The value of ENAB for both the alarm parameter and the module ALARMS
parameter must be YES. For example: FIC-101/ALARM-HI.ENAB=YES and FIC-101/ALARMS.ENAB=YES.

Check the value of NALM (the acknowledged status). The alarm might be auto-acknowledged. The value of
NALM is determined by the alarm priority (for example, ALARM-HI.PRI) and can be overridden by the
ALARMS.PRIAD field. If the alarm priority is configured as auto-acknowledged in the DeltaV Explorer and
PRIAD is not overriding the value, the alarm is auto-acknowledged.

Make sure that the necessary data has been downloaded. You must download the module in the controller. You
must also download setup data to all affected nodes (workstations and controllers) whenever the alarm type or
alarm priority configuration is changed.

Determine how many active alarms you have. If there are more than five active alarms, the alarm banner will not
show them.

When an alarm should be in THISUSER/ALARMS but is not, perform the following steps:
1

Determine which plant area the associated module is in.

Make sure that the plant area determined in step 1 is the workstation's Alarms and Events subsystem. If it is not,
assign the area and download the workstation.

Check to see if there are any active alarms in THISUSER/ALARMS. If there are, compare them with the ones
that are missing. This might suggest the problem with the alarms that are not in THISUSER/ALARMS.

116

System Configuration

Make sure that the controller is communicating. Use the DeltaV Diagnostics application to check the
communications status.

Review the steps in the above procedure, "When something should be in alarm but is not..."

When alarm state change records are missing from the Event Chronicle, perform the following steps:
1

Use DeltaV Diagnostics to make sure that the Event Chronicle is active on this workstation. The following
indications could account for missing alarm state change records:

DirBad = BAD - The specified directory for the event data could not be found, or the database could
not be created.

DskFul = FULL - The configured limit of records that can be stored in the event database has been
reached.

RecWrR = -1 - The Event Chronicle on this workstation has not been configured to be active.

Make sure that the module that contains the alarm is in an area assigned to the workstation.

Check to see if there are any alarm state change records in the Event Chronicle. If there are, compare them with
the ones that are missing. This might suggest the problem with the alarms that are missing from Event Chronicle.

Make sure that the controller is communicating. Use the DeltaV Diagnostics application to check the
communications status.

Review the steps in the above procedure, "When something should be in alarm but is not..."

When alarms do not activate the horn, perform the following steps:
1

Follow the steps in the above procedure, "When an alarm should be in THISUSER/ALARMS but is not..."
Alarms must be in THISUSER/ALARMS before a horn can be active for them.

Determine the effective priority of the horn. Alarms with a priority of Log do not sound the horn. Also,
remember that the ALARMS.PRIAD value can change the effective priority of an alarm.

Make sure that a .WAV file has been specified for the alarm priority. Make sure that the file specified is in the
\SOUND directory. Also, note that SILENCE.WAV must be in the directory for the sound card to work.

Make sure that DeltaV Operate is using the standard DeltaV alarm banner. This banner provides access to the
HORN parameters. Make sure that the horn is enabled (THISUSER/HORN.HENAB=1).

Alarms and Events

117

Custom Alarms
Inside this topic
Custom Alarm Calculation
Custom Alarm Detection
Custom Alarm Presentation
Adding Custom Alarms
Creating a Custom Calculation for the Alarm
Defining the Alarm Detection
The following sections detail the calculation, detection, and presentation aspects for the DeltaV custom alarms. For
more information on how to configure different alarms, refer to the Alarm Configuration topic.

Custom Alarm Calculation


You can perform your own alarm state calculations using any of the function blocks. Typically, you would use
function blocks that support expressions, such as:

Condition function block

Calc/Logic function block

The alarm state calculation typically uses logical and relational operators to: test the values in one or more
parameters, compute a Boolean result (0 or 1), and write it to a new state parameter.

Custom Alarm Detection


To enable DeltaV alarm features, create an alarm in the same module and attach it to the Boolean state parameter that
you computed. At the end of each module execution cycle, the alarms for the module are processed to detect any state
changes. When the custom state computation results in a value that is non-zero, the alarm is triggered and is either
displayed for the operator or logged in the event log.

Custom Alarm Presentation


DeltaV Operate is the alarm presentation vehicle in the DeltaV system. The presentation is based on the alarm
properties and the alarm type. Refer to the Alarm Presentation topic for more details on configuring the alarm
presentation.

Adding Custom Alarms


The following sections describe the entire process of creating an expression-based custom alarm. By following the
examples, you create the expression (alarm calculation), assign the alarm to the output of the expression (alarm
detection) and determine the message to the operator (alarm presentation).
Note You do not have to create your own expression to use custom alarms. You can assign a custom alarm to any
Boolean parameter on a function block or module (except unit modules, phase classes, and phase logic modules).

118

System Configuration

The basic steps for adding an alarm are as follows:


1

In the Alarms view window, click the right mouse button, and then click Add.

Select the alarm, click the right mouse button and select Properties.

In the Alarm properties dialog - General tab, name the alarm and specify the Alarm type and a Priority.

In the Alarm parameter field (still on the Alarm properties dialog - General tab), enter the parameter that triggers
the alarm.

On the Advanced tab, select the alarm characteristics (enabled or inverted).

Click OK.

Creating a Custom Calculation for the Alarm


Custom alarm calculations must be associated with a parameter that has a value of either 0 or 1. A one (1) indicates an
alarm condition, and a 0 indicates a non-alarm condition.
Note If you create your own alarm calculations you must use one of the function blocks that support expressions (for
example, the Condition function block or the Calc/Logic function block).
The following example shows how to add a custom alarm to a module using a Condition block. In this example, the
user wants to trigger an alarm every time the PV of the AI block is 70 or higher.
Note The custom calculation creates a Boolean parameter that still must be associated with the alarm. This step only
sets up the calculation that is associated with an alarm.
To create a custom calculation, perform the following steps:
1

Drag an Analog Input block onto the diagram. The Analog Input block is in the I/O function block category.

Drag a Condition block onto the diagram. The Condition block is in the Logical function block category.

Click the Condition block.

Click the right mouse button and then click Expression.

In the Expression Editor dialog, click Insert Internal Parameter.

Browse to find the HI_ACT parameter and the CV field in the AI block within this module.

Click OK.

In the Expression Editor dialog, click the >= symbol.

Enter the value 1.

10 Click Parse.
11 When the expression parses without any errors, click OK.
This sets up an expression to see if the HI_ACT parameter is greater than or equal to 70. For this module, the value of
the expression is the value of the OUT_D parameter.

Defining the Alarm Detection


Alarm detection is where you identify the parameter that you want to trigger the alarm and you associate that
parameter with the alarm.

Alarms and Events

119

Using the example in Creating a Custom Alarm Calculation (HI_ACT > 70), define the alarm detection by following
these steps:
1

Click the Condition block to select it.

Click the right mouse button in the Alarms View window, and then click Add.

Enter an alarm name. Make it relevant to the operation.

Select the alarm, click the right mouse button and select Properties.

Select an Alarm type. For this example, the Any Alarm works.

Select the Priority. The Priority of 'Log' only sends the event to the Event Journal and does not display it to the
operator.

Note This step sets the alarm presentation. Refer to the Alarm Presentation topic for more details.
7

In the Related Parameters section, select the Alarm parameter for OUT of the Condition block.

Use the Advanced tab to enable or invert the alarm characteristics or change the alarm message parameters (if
available).

Click OK.

The alarm detection is now defined for the parameter OUT of the Condition block. When the condition of HI_ACT >
70 for the AI block is reached, the output of the Condition block is set to True and the alarm is triggered.
Note If the alarm was inverted, then the alarm is triggered when OUT of the Condition block is set to False.

120

System Configuration

Events and Alarms Reference


Inside this topic
The ALARMS Parameter
Module Alarm Parameter Fields
The HORN Parameter
These sections contain information on configuring the ALARMS parameter and the HORN parameter.

The ALARMS Parameter


A module, area, or user can have many active alarms. The ALARMS parameter helps you to view and manage the
five most important active alarms associated with a module, area, or user. The ALARMS parameter is an array
parameter with values of 1 through 250. For this reason, the parameter is sometimes referred to as ALARMS[1-250].
The most important alarm is ALARMS[1]. The controller automatically creates an ALARMS parameter for each
downloaded module.
Each workstation keeps a list of active alarms that the current user should see and makes the five most important
alarms accessible for display through an ALARMS parameter for each plant area and for THISUSER.
The DeltaV system uses the ALARMS parameter associated with the current user to generate the data in the alarm
banner. The Alarm Presentation topic describes the alarm banner in more detail. The system uses the ALARMS
parameter associated with a module to generate the data in the defined faceplate and in the detail pictures for the
module.
The system determines the importance of an alarm by the following criteria:

unacknowledged alarms are more important than acknowledged alarms.

for alarms with equal acknowledgment status, the priority (CRITICAL, WARNING, ADVISORY)
determines the importance. CRITICAL is the most important priority. ADVISORY is the least important
priority. Alarms can also be assigned the LOG priority. When this happens, all alarm annunciation behavior
is suppressed (for example, the alarm no longer appears in the alarm banner, it does not sound the horn, and
so on).

for alarms with equal acknowledgment status and equal priorities, the controller uses the time stamp. The
most recent alarms are the most important.

The following examples show paths to the ASCII value of the priority for ALARMS parameters associated with the
current user, an area, and a module:

THISUSER/ALARMS[1].A_PRI

AREA_A/ALARMS[1].A_PRI

FIC101/ALARMS[1].A_PRI

Alarms and Events

121

Note The alarm parameter CUALM (current alarm) can be either zero or non-zero (the non-zero value is determined
by the alarm type and priority used). When CUALM is zero, the parameter is not in alarm. When CUALM is nonzero, the parameter is in alarm.
The alarm parameter NALM (new - unacknowledged - alarm) can be either zero (0) or one (1). When NALM is zero,
there is no new alarm. When NALM is one, there is a new, unacknowledged alarm. When the alarm is acknowledged,
the NALM value returns to zero.
The LAALM (latched alarm) parameter can be either zero or non-zero (the non-zero value is determined by the alarm
type and priority used). When LAALM is zero, the parameter is not in alarm. When LAALM is non-zero, the
parameter is in alarm. Once LAALM is in alarm (represented by a non-zero value), it remains set until both the
condition and NALM return to zero.
The following tables define all the ALARMS parameter fields for modules, areas and users. The Use Example
column assumes a Module named FIC101.
Module ALARMS Parameter Fields
Field

Use Example

Description

Read/Write

A_ (ASCII)

F_ (FLOATING)

Fields that apply to individual alarms


ATTR

FIC101/
ALARMS[1].A_ATTR

alarm
parameter
name

HI_ALM

N/A

CUALM

FIC101/
ALARMS[1].F_CUALM

Current alarm
state

OK/HIGH

0, 1, 2.....

LAALM

FIC101/
ALARMS[1].F_LAALM1

latched alarm

OK/HIGH

0, 1, 2.....

NALM

FIC101/
ALARMS[1].F_NALM

new alarm

NO/YES

0/1

PRI

FIC101/
ALARMS[1].F_PRI

priority

CRITICAL,
WARNING,
ADVISORY,
LOG2

3, 4, 5, 6, 7, 8, 9, 10,
11, 12, 13, 14, 153

TIN

FIC101/
ALARMS[1].A_TIN

timestamp
when it went
into alarm

Mon Jun 17,


1997
21:04:05:22

N/A

Fields that apply to all alarms

122

System Configuration

Field

Use Example

Description

Read/Write

A_ (ASCII)

F_ (FLOATING)

ENAB

FIC101/
ALARMS.F_ENAB

enables or
disables all
alarms in the
module

R/W

N/A

0 (NO) causes all


alarm parameters
ENAB to be
overridden and
evaluated as NO.
Causes all alarms to
be disabled.
1 (YES) is the initial
value after
download. Writing a
1 after writing a 0
restores the effect of
the individual alarm
parameter's ENAB
setting.

MACK

FIC101/
ALARMS.F_MACK

acknowledges
all the alarms
in the module

N/A

0 (NO) is the initial


value after
download.
1 (YES)
acknowledges all
alarm parameters in
the next execution
cycle and resets to 0.

Alarms and Events

123

Field

Use Example

Description

Read/Write

A_ (ASCII)

F_ (FLOATING)

PRIAD

FIC101/
ALARMS.F_PRIAD

adjust
effective
priority of all
alarms in
module

R/W

N/A

0 alarm priority as
configured 1 lowers
all alarms by one
priority (CRITICAL
alarms become
WARNING, and so
on).
2 lowers all alarms
by two priorities
(CRITICAL alarms
become
ADVISORY;
WARNING and
ADVISORY alarms
become LOG).
3 lowers all alarms
by three priorities
(all alarms become
LOG), for example:
FIC101/
ALARMS.F_PRIAD
= 0 resets all
effective alarm
priorities to be that
of the individual
alarm priorities.

1 Information about the five most important alarms in a module is accessed through ALARMS [1-5].
2 These are default priority names.
3 Active alarms that have been suppressed (OPSUP is 1 (YES)) also appear in the module's ALARMS
parameter, but their priority value is forced to the value 3 (LOG) so that they will appear only after unsuppressed
active alarms.
The following table lists the plant area level ALARMS parameter fields (used to show the top 5 active alarms in
current user's operating plant area). The Use Example column assumes a plant area named AREA_A.
Area ALARMS Parameter Fields
Field

Use Example

Description

A_ (ASCII)

F_
(FLOATING)

CUALM

AREA_A/
ALARMS[1].F_CUALM

current alarm
state

OK/HIGH

0, 1, 2.....

MODULE

AREA_A/
ALARMS[1].A_MODULE

module name

FIC101

N/A

LAALM

AREA_A/
ALARMS[1].F_LAALM

latched alarm

OK or HIGH

0,1,2,....

124

System Configuration

Field

Use Example

Description

A_ (ASCII)

F_
(FLOATING)

CV

AREA_A/
ALARMS[1].A_CV

module name
(same as the
MODULE
field)

.../FIC101

N/A

NALM

AREA_A/
ALARMS[1].F_NALM

new
(unacknowled
ged)

NO or YES

0 or 1

PRI

AREA_A/
ALARMS[1].F_PRI

priority

CRITICAL,
WARNING,
ADVISORY,
or LOG

0, 1, 2, or 3

ATTR

AREA_A/
ALARMS[1].A_ATTR

mod/param
name

FIC101/
HI_ALM

N/A

TIN

AREA_A/
ALARMS[1].A_TIN

time into
alarm

Mon Jun 17,


1997
21:04:05:22

N/A

The following table lists the THISUSER level ALARMS parameter fields (used to show the top 5 active alarms in all
of the current user's system-wide operating plant areas):
THISUSER ALARMS Parameter Fields
Field

Use Example

Description

A_ (ASCII)

F_
(FLOATING)

MODULE

THISUSER/
ALARMS[1].A_MODULE

module name

FIC101

N/A

CUALM

THISUSER/
ALARMS[1].F_CUALM

current alarm
state

OK/HIGH

0, 1, 2.....

LAALM

THISUSER/
ALARMS[1].F_LAALM

latched alarm
state

OK or HIGH

0,1,2,....

CV

THISUSER/
ALARMS[1].A_CV

module name
(same as the
MODULE
field)

FIC101

N/A

NALM

THISUSER/
ALARMS[1].F_NALM

new
(unacknowled
ged)

NO or YES

0 or 1

PRI

THISUSER/
ALARMS[1].F_PRI

priority

CRITICAL,
WARNING,
ADVISORY,
or LOG

0, 1, 2, or 3

Alarms and Events

125

Field

Use Example

Description

A_ (ASCII)

F_
(FLOATING)

ATTR

THISUSER/
ALARMS[1].A_ATTR

mod/param
name

FIC101/
HI_ALM

N/A

TIN

THISUSER/
ALARMS[1].A_TIN

time into
alarm

Mon Jun 17,


1997
21:04:05:22

N/A

Module Alarm Parameter Fields


All alarm parameters created in modules support a number of fields. For example, for a module named FIC101 with
an alarm parameter named HI_ALM to use a current alarm priority for a dynamic display, the syntax would be
FIC101/HI_ALM.PRI. The following table shows the fields available for module alarms and how they are used.
Module Alarm Parameter Fields
Field

Use Example

Description

Read/Write

A_ (ASCII)

F_
(FLOATING)

CUALM1

FIC101/
HI_ALM.F_CUALM

Current alarm
state

OK/HIGH

0, 1, 2.....

LAALM2

FIC101/
HI_ALM.F_LAALM

Latched alarm
state (active until
acknowledged)

OK/HIGH

0, 1, 2.....

CV

FIC101/
HI_ALM.F_CV

(same as
LAALM)

OK/HIGH

0, 1, 2.....

NALM3

FIC101/
HI_ALM.F_NALM

new alarm
(unacknowledged)
used for Blink on
New Alarm

R/W

NO/YES
write NO to
acknowledge

0/1

PRI

FIC101/
HI_ALM.F_PRI

Priority

R/W

CRITICAL,
WARNING,
ADVISORY,
LOG4

3, 4, 5, 6, 7, 8, 9,
10, 11, 12, 13,
14, 15

ENAB

FIC101/
HI_ALM.F_ENAB

Enables or
disables the
alarms

R/W

NO/YES

0 (NO) causes
the alarm to be
disabled.
1 (YES) causes
the alarm to be
enabled.

126

System Configuration

Field

Use Example

Description

Read/Write

A_ (ASCII)

F_
(FLOATING)

OPSUP

FIC101/
HI_ALM.F_OPSUP

Enables alarm
suppression

R/W

NO/YES

0 (NO) has no
effect on alarm
behavior.
1 (YES) prevents
activation of the
alarm. The
Alarm Suppress
picture shows all
of the suppressed
alarms.

SUPTMO

FIC101/
HI_ALM.F_SUPTMO

Alarm suppression
timeout

R/W

Time in
minutes

Time in minutes

SUPTMR

FIC101/
HI_ALM.F_SUPTMR

Alarm suppression
timer

R/W

Time in
minutes

Time in minutes

INV

FIC101/
HI_ALM.F_INV

Invert alarm input

R/W

NO/YES

0/1

1 The alarm parameter CUALM (current alarm) can be either zero or non-zero (the non-zero value is determined
by the alarm type and priority used). When CUALM is zero, the parameter is not in alarm. When CUALM is nonzero, the parameter is in alarm.
2 The alarm parameter NALM (new - unacknowledged - alarm) can be either zero (0) or one (1). When NALM is
zero, there is no new alarm. When NALM is one, there is a new, unacknowledged alarm. When the alarm is
acknowledged, the NALM value returns to zero.
3 The LAALM (latched alarm) parameter can be either zero or non-zero (the non-zero value is determined by the
alarm type and priority used). When LAALM is zero, the parameter is not in alarm. When LAALM is non-zero,
the parameter is in alarm. Once LAALM is in alarm (represented by a non-zero value), it remains set until both the
condition and NALM return to zero.
4 Using the DeltaV Explorer, you can add additional alarm priority names and map them to any value (3 through
15).

The HORN Parameter


The HORN parameter is a parameter associated with the current user that determines when the horn sounds and
whether the horn has been enabled. The format for the parameter is THISUSER/HORN. The fields supported are:

HENAB (1 is enabled. 0 is disabled.)

CV (0 stops the horn from sounding.)

The HORN parameter is intended to be used only by the operator's alarm banner. Its use in other displays or by
applications other than DeltaV Operate might interfere with the operation of the alarm banner and is not
recommended.

Alarms and Events

127

Collecting Alarm and Event Records


Inside this topic
Setting Up an Event Chronicle
Setting up SOE Collection in a DeltaV System
Managing Event Chronicle Database Size
DeltaV workstations are each capable of collecting alarm and event data. The Alarms and Events subsystem helps
you maintain a database of events and alarms called an Event Chronicle. Event Chronicle databases store alarms
records, event records, log messages and events from Sequence of Events Cards.
You determine which workstations maintain an active Event Chronicle database and the areas for which the
workstation collects the events. The Process History Viewer application enables you to view and query the alarms
and event records for any machine on the control network.
Records are stored in the Jet database file: DeltaV\DVData\Ejournal.mdb.

Specifying which Event and Alarms are Recorded


A workstation records alarms and events for the areas listed under the Alarms and Events subsystem. It is practical to
record alarms and events for the areas that match the operator span of control. If an operator on Op_Station_1 has
control of Areas 1, 2 and 3, these areas should probably be included in the Alarms and Events Subsystem on
Op_Station_1. This allows the operator to view and query events records quickly on the local machine, without
having to see records from other areas or connect to another machine to view records.
At the same time, it may also be helpful to set up the ProfessionalPlus machine to record the alarms and events for the
entire system. This enables operators to query records across all areas when necessary.
A configuration like the one shown below enables operators to view and query records within their span of control on
their local machine while enabling anyone to view or query all records by connecting to the ProfessionalPlus
machine.
Workstation

Operator
Span of
Control

Recommended Areas in
the Alarms and Events
Subsystem

ProfessionalPlus

na

Area_1
Area_2
Area_3
Area_4
Area_5

Operator Station 1

Area_1
Area_2
Area_3

Area_1
Area_2
Area_3

Operator Station 2

Area_4
Area_5

Area_4
Area_5

128

System Configuration

Setting Up an Event Chronicle


To record events in a workstation's Event Chronicle database:
1

Drag the areas for which you want to record events and alarms to the Alarms and Events subsystem using DeltaV
Explorer.

Select the Alarms and Events subsystem and right-click Properties.

Check the Enabled box.

Download the workstation.

Setting up SOE Collection in a DeltaV System


By default, the ProfessionalPlus station Event Chronicle collects events from SOE cards. If you want these events
collected in a different workstation, open the Events and Alarms Properties dialog for that workstation and click the
System SOE Collector box. Only one workstation can be designated as the System SOE collector.

Managing Event Chronicle Database Size


You can set the maximum size of each Event Chronicle database through the Alarms and Events Advance Properties
dialog in DeltaV Explorer. The maximum Event Chronicle databases is 500,000 records. The system has two primary
functions for keeping the size of an Event Chronicle database within the maximum limit:
Daily Maintenance - at a user-specified time of day, the system will delete or store records that are older than a userspecified number of days. The Process History Viewer application disconnects prior to this maintenance in order to
give the function full access to the database.
Use the Alarms and Events Advanced Properties dialog to define the parameters for this maintenance. Events that
occur during daily maintenance are spooled and added to the database when the maintenance is complete.
Unscheduled Maintenance (the in-place admin cycle) - when the database reaches the maximum size, in records
stored, this function marks the oldest (10%) of records for deletion. This function does not free any disk space or
reduce the database file size. However, during the next daily maintenance cycle, the file space used by the deleted
records is reclaimed when the database file is compacted.
Although unlikely, it is possible for the number of records to increase so much before the next daily maintenance
function that some event records can go unrecorded. If the size of the database file becomes greater than the file size
limit, the system discards incoming records and attempts to start daily maintenance regardless of the time of day. The
database file size limit is determined as shown in the following table, which allows for a file size limit of
approximately 10 times the normal (post daily maintenance) file size (assuming typical mixes of event records).
Maximum Chronicle Size

Database File Size Limit

500,000 records
.
.
n records
.
.
<=20,000

500,000 Kb
.
.
n Kb
.
.
20,000 Kb

After gaining experience with the typical number of events being recorded in an Event Chronicle database each day,
adjust the Maximum Chronicle size x records and Remove records older than y days values with the goal that upon

Alarms and Events

129

completing the daily maintenance cycle, inserting a typical day's worth of event records will not cause the maximum
chronicle size to be reached before the next daily maintenance cycle. This assures optimum file space management;
avoiding excessive disk storage usage.

130

System Configuration

The Continuous Historian


Inside this topic
The Legacy Historian
Using the Continuous Historian
Continuous Historian Administration Tools
Continuous Historian Excel Add-In
Terminology
The Continuous Historian is a collection of features and applications, well integrated into the DeltaV system, that
provide capture of, access to, and management of time-series parameter values from the run-time DeltaV system. The
Continuous Historian is automatically started by DeltaV services on DeltaV workstations that have had the
Continuous Historian software installed and on which the Continuous History subsystem is enabled. On new DeltaV
systems, the 250-tag Continuous Historian is installed automatically on every local DeltaV workstation type. It may
be scaled up to 20,250 tags on the DeltaV Application Station.
While running, the Continuous Historian supports:

History data capture and storage as determined by the History Collection configuration for that workstation

Any automatic history data management services that have been configured (such as automatic data
discarding, moving to offline storage, etc.)

History data services (browsing/reading/writing) for local and remote client applications

The Legacy Historian


Before the development and release of the Continuous Historian, a third party product, the PI System from OSIsoft,
Inc., was used. This product now has limited availability for use with the DeltaV System and is referred to as the
"Legacy Historian." Existing Continuous Historian client applications are able to work with both Legacy Historian
and Continuous Historian data services on the same system.
On a system upgrade, the user has a choice of installing the Continuous Historian on the Application Station or
keeping an existing Legacy Historian server. (Only one of the historians may exist on a workstation; however, both
historians may exist within a DeltaV system.) See the Workstation information in the topic Setting Up the Continuous
Historian for details on workstation support. For more information on system upgrades and converting history data,
refer to the Continuous Historian Upgrade Planning Guide. The guide is located on the DeltaV installation CD #4 in
the _Support directory.
For additional information on the Legacy Historian requirements, refer to the topic The Legacy Historian. Detailed
information on backing up the Legacy Historian Archives, Sizing Guidelines, and File Security can be found in the
topics under Legacy Historian Archive Backup and Security.

Using the Continuous Historian


There are three main aspects of continuous data collection and presentation:

Definition of history data to be collected in the modules and nodes

Storage and management of the data by a continuous historian subsystem

Presentation of the data through the Process History View application or client applications

The Continuous Historian

131

History Data Collection


History collection is a function used in the DeltaV Explorer and Control Studio to define the module parameters or
node parameters to be monitored and stored in the Continuous Historian. History collection is an integral part of a
module. If you copy a module, the new module includes the defined history collection. Library module templates
include history collection, which can be modified by the user.

History Data Storage


The Continuous Historian allows high-volume data capture of time-associated parameter values and efficient storage
of these values to non-volatile media (hard disks).
Each workstation with a Continuous Historian history server component installed has a primary storage area that
holds a collection of history data sets. One active history data set receives history samples from the real-time history
stream. Zero or more current history data sets may also exist in primary storage. These data sets are former active
history data sets that have been completed by hitting the time or size limit rules. The collection of active and current
history data sets comprise the contiguous recent history data that is still online.
The primary storage area may also contain zero or more extended history data sets that have been placed back online
through the use of the Continuous Historian Administration tools. These data sets may be for any history tags for any
period of time (without continuity with the active and current history data sets). Refer to the topic History Data Sets
and Files for more information about history samples, data sets, and data files.

History Data Presentation (Process History View)


DeltaV Process History View is the application that is used to display real-time and historical data from the
Continuous Historian subsystem as well as from the event chronicle (a subsystem that stores system events and
alarms). Module and node trends are plotted on a graph, and events are displayed in a tabular (grid) format. Refer to
the topic Customizing the Process History View for information about the application.
You must download the setup data for the each workstation that has an enabled Continuous Historian subsystem or
Legacy Historian in order for the Process History View to view the subsystem data.

Continuous Historian Administration Tools


The Continuous Historian Administration subsystem provides a number of tools to help you manage the data
captured and available online. When the volume of online data grows too large, decisions need to be made about how
to handle it. You can define rules to automatically discard selected data or move selected historical data from online
history storage to offline data files. You can also interactively choose the historical data to discard or move to offline
storage. Additional tools are available to let you temporarily bring online the history data from offline storage files.
Refer to the topic Continuous Historian Administration for more information about these tools.

Continuous Historian Excel Add-In


The Continuous Historian provides an Excel Add-In to read online history data. The Add-In provides function
configuration dialogs to help users create detailed worksheets containing historical data read from and interpolated
from the Continuous Historian database. Worksheets can also include timestamp and status information associated
with the historical values. Refer to the topic Continuous Historian Excel Add-In for more information about these
tools.

132

System Configuration

Terminology
Following is a list of terms and their definitions.
Active History Data Set - Holds the most recent history data captured for all history tags configured for the
Continuous Historian. The data set holds the contiguous history record from the time it was created until the present.
Continuous Historian - A collection of features and applications that provide capture of, access to, and management
of time-series parameter values from the run-time DeltaV system.
Current History Data Set - Data set created by rollover of the active history data set in the Continuous Historian. A
current history data set is a former active history data set that has been completed by hitting the time or size limit
rules or by direct creation of a new active data set. A current history data set holds history data for a collection of
history tags within the time span of the data set. One or more current history data sets may exist in primary storage.
Extended History Data Set - A history data set that has been placed back online through the use of the Continuous
Historian Administration tools. Such data sets may be for any history tags for any period of time (without continuity
with the active and current history data sets).
Legacy Historian - A third-party historian product that has been replaced by the Continuous Historian. Use of the
legacy historian is limited to existing users of that historian application.
Primary Storage - A storage area on each workstation with a Continuous Historian history server installed. This area
holds a collection of history data sets, including one active history data set, zero or more current data sets, and zero or
more extended history data sets.

The Continuous Historian

133

Setting up the Continuous Historian


Inside this topic
Workstations
Software Upgrades and History Data Conversion
The Continuous Historian must be enabled on each workstation that will be used to collect or display history data. At
most one Continuous Historian can be enabled on a DeltaV workstation. The Continuous Historian subsystem exists
under the workstation in the DeltaV Explorer.
The steps to set up the Continuous Historian are as follows:
1

Define history collection for module and node parameters. Refer to Configuring History Collection for more
information.

Assign modules to commissioned controllers or Application Stations.

Note If you do not assign the module to an Application Station or a commissioned controller, history will not be
collected for the module.
3

Enable the Continuous Historian subsystem for each workstation that collects history and configure the
Continuous Historian properties. Refer to Configuring Continuous Historian Properties for more information.

Assign specific area folders and nodes to the Continuous Historian subsystem.

Download the workstation.

Note After the initial download of the history collection subsystem there may be a short period of time before the
overall integrity of the subsystem reports GOOD.
On Application Stations, if the Legacy Historian is already installed, there will be a check box for selecting the
Legacy Historian if you wish to continue using that historian on that particular workstation.

Workstations
Continuous Historian data servers are available on all DeltaV workstation types (local or remote). Continuous
Historian performance using slow network connections will not be as fast as when using fast network connections.
The Continuous Historian is the only historian supported on the ProfessionalPLUS workstation and Operator Station
nodes. On Application Stations, existing users are allowed to continue using the Legacy Historian or switch to the
Continuous Historian. The choice is offered only in DeltaV software upgrades and then only if the Legacy Historian
is installed on the workstation being upgraded. (The default selection is the Continuous Historian.) Only the
Continuous Historian is available for use on new DeltaV installations.
Continuous Historian client support is available on DeltaV local or remote workstation nodes (including remote
terminal sessions hosted by a DeltaV workstation). Communications between client application nodes and
Continuous Historian data serving nodes is provided by .Net remoting facilities.

134

System Configuration

The table below summarizes the node support for the Continuous Historian and the Legacy Historian.
Professional
PLUS

Operator
Station

Application Station

Local workstation (Node


is on DeltaV ACN)

Continuous
Historian only

Continuous
Historian only

Users choice of Continuous Historian or


Legacy Historian (only if the Legacy
Historian is already installed). The default
selection is the Continuous Historian.

Remote workstation

---

Continuous
Historian only

Users choice of Continuous Historian or


Legacy Historian (only if the Legacy
Historian is already installed). The default
selection is the Continuous Historian.

Software Upgrades and History Data Conversion


To plan DeltaV software upgrades and conversion of history data, refer to the Continuous Historian Upgrade
Planning Guide, located on the DeltaV installation CD #4 in the _Support directory. This guide provides details on
the history data conversion process and other information about changing from the Legacy Historian to the
Continuous Historian.

The Continuous Historian

135

Configuring the Continuous Historian Properties


To configure the properties for the Continuous Historian, select the Continuous Historian subsystem under the
workstation, right-click, and select Properties from the context menu. The following properties can be configured:

The historian to be used (The Legacy Historian choice will only be available on Application Stations.)

The target maximum historian size for the Primary storage area

Active historian data set creation

Current historian data set expiration behavior

Automatic historian data set export

These properties are explained in more detail in the following paragraphs.

Choose and Enable Historian


On the General tab of the Continuous Historian Properties page, the user must select the check box Enabled to enable
the historian. For Application Stations upgraded from previous DeltaV releases and on which the Legacy Historian is
present, the user has the choice of continuing use of the Legacy Historian or changing to the Continuous Historian.
The choice must match the choice made between the two historians when the DeltaV software was installed on that
node.
For the ProfessionalPLUS and local or remote Operator Stations, the Continuous Historian is the only historian
supported; no choice is offered.

Primary Storage Management


On the Advanced tab, the Historian Storage options determine the automatic actions used to control the amount of
disk space used for primary storage. The maximum history size establishes a target for the maximum amount of disk
storage used in the primary storage area for the combined active and current history data sets. Extended history data
sets do not count against the target. The configurable range is 100 MB to 10000 MB, with a default of 600 MB.
When the primary storage used for active and current history data sets goes above the target size, the historian will
delete the oldest current history data set or sets to reduce storage to within the target. If automatic history data
exporting is enabled, an attempt to export the history data set will be made before it is deleted.
In addition to specifying a target size for the primary storage, the user can specify a maximum historian time span in
days (with a maximum of 9999 days) that current history data sets will remain in primary storage. Once the newest
data in a current history data set is older than the expiration time span, the historian is authorized to automatically
remove the data set. If the data set expires while in primary storage, automatic history data exporting is first attempted
(if configured) before the data set is discarded.

Active History Data Set Creation


Rules exist to determine when an active history data set rolls over to become a current history data set. (A new active
history data set is created when the rollover occurs.) Refer to the topic History Data Sets and Files for more
information about history data sets.
The rules for creation of a new active data set are:
Data set size - This can be configured to trigger an early creation (before the configured period/start configuration) if
the estimated size of the active history data set exceeds this size in MB. The default value is 200 MB. The minimum

136

System Configuration

value is 50 MB. The value is constrained to always be less than or equal to the primary storage current history size
target.
Enable data set time span - The rollover occurs to create a current history data set that represents the desired time
span. Options include:

Calendar month periods - creation occurs at local time midnight on the first day of each month

Weekly periods - creation occurs at local time midnight on each Sunday morning

Daily periods - creation occurs at local time midnight each day

None - creation occurs only when the data set size target is exceeded. This is the default setting.

Automatic History Data Set Export


This property determines if history data should be exported automatically before it is deleted from online storage. If
automatic exporting is enabled, the user specifies the file system path to a directory available to that workstation
where exported history data should be stored. If the maximum historian storage size is exceeded, history data set
deletion will still be performed even if the history data sets cannot be stored in the specified directory. It is
recommended that the export directory be on the same workstation as the Continuous Historian, but outside of the
DeltaV system directory. Using mapped drives is not recommended because a mapped drive may not always be
connected when the Continuous Historian is trying to export data.

The Continuous Historian

137

Configuring History Collection


History collection is the definition of the module parameters or node parameters to be monitored and stored by the
Continuous Historian. History tags are strings that uniquely identify a data source for which continuous history data
can be captured. In the DeltaV system, history tags are the full path string that identifies a DeltaV parameter and field.
There is at most one history collection configuration for any DeltaV parameter/field (history tag). History collection
can be defined using the DeltaV Explorer or Control Studio. Users assign areas to the Continuous Historian
subsystem in the DeltaV Explorer to complete the association to the specific history data server.
History collection configuration "belongs" to the module (or node). If you copy a module, the new module includes
the history collection from the original module. Library template modules also include history collection. Creating a
module from a library template copies the history collection configuration to the new module. You can add to or
modify the history collection configuration.
Since a DeltaV system can contain a mix of Legacy Historians and Continuous Historians, the history collection
configuration for a history tag can be used by both types of historians at the same time.
The steps for configuring the collection of continuous history data in the DeltaV Explorer are as follows:
1

Select an Area or a module, click the right mouse button, and select History Collection from the context menu.

On the History Collection dialog, click the Add button to configure the History Collection for that object. (To
modify or delete an existing history collection, select a parameter and click the Modify or Delete button,
respectively.)

Fill in the Modify History Collection dialog. Use the Help button on the dialog for specific instructions.

Download the workstation.

There are two ways to configure history collection in Control Studio. To add or modify history collection for a
module:
1

Open a module and select History Collection from the File menu.

On the History Collection dialog, click the Add, Modify, or Delete buttons to configure the History Collection
for that object. (To modify or delete an existing history collection, select the parameter and click the Modify or
Delete button, respectively.)

Fill in the Modify History Collection dialog. Use the Help button on the dialog for specific instructions.

Download the module.

Or, to add history collection for a particular parameter:


1

Open a module, select the desired function block and parameter.

Right-click the parameter and select Add History Recorder from the context menu.

Fill in the Add History Collection dialog. Use the Help button on the dialog for specific instructions.

Download the module.

To confirm your entire History Collection configuration in the DeltaV Explorer, select the workstation's Continuous
Historian subsystem, click the right mouse button, and select History Collection from the context menu. This presents
a read-only view of all values to be historically collected for this workstation's Continuous Historian.

Modify History Collection Dialog


The Modify History Collection dialog is used to add or modify history collection. The dialog has two tabs, General
and Advanced, as shown below:

138

System Configuration

The Continuous Historian

139

The following properties are available for adding or modifying history collection:

Parameter field path

Sampling period

Display Representation (Step, Line, or Automatic)

Data Characteristic (Continuous or Manually entered)

Data Compression enabled

Data Compression Deviation (an absolute numeric value)

Data Compression interval (Collect at least every time interval)

For more detailed information on the choices available, refer to the online help for the dialog.

Configuring History Collection for Array Parameters


To add a floating point array item to history, you cannot browse to the level of the array item. The parameter field
path needs to be manually edited to include the array item, using the following format:
ArrayParameterName[row,col].field
For example:
FP_ARRAY[2,1].CV

140

System Configuration

The item will be added to the History Collection list as FP_ARRAY[2,1]. However, when downloaded to the
Continuous Historian, the parameter is specified as FP_ARRAY[2][1].CV. When downloaded to the Legacy
Historian, the parameter is specified as FP_ARRAY(2)(1).CV, because the Legacy Historian does not support the use
of square brackets.
These syntax distinctions are important when you are configuring a Process History View trend for the array
parameter. When configuring a pen in PHV for the Continuous Historian, specify the array parameter path as Module/
ArrayParameterName[row][col]. When configuring a pen in PHV for the Legacy Historian, specify the array
parameter path as either Module/ArrayParameterName[row][col] or Module/ArrayParameterName(row)(col).

The Continuous Historian

141

History Data Sets and Files


Inside this topic
History Samples
History Data Sets
History Data Files
This topic defines some terms relating to history samples, data sets, and data files.

History Samples
When data is collected for a history tag, a "history sample" is produced. A history sample is the basic unit of history
data for a history tag. A history sample is composed of:

a value -- one of the DeltaV data types

a timestamp -- the date-time when the history tag had this value

a parameter status value -- an Ff style (.ST field) status value

a Continuous Historian status value -- with information such as whether the continuous history stream was
broken and the type of break

The Continuous Historian supports the following data types for history sample values:

32-bit float

32-bit signed integer (smaller DeltaV signed integer parameter field are converted to this type)

32-bit unsigned integer (smaller DeltaV unsigned integer parameter field are converted to this type)

UNICODE string -- up to 512 characters

Byte-enum -- holds both number and state name for DeltaV name set parameters

History Data Sets


History data sets are collections of tag history sets that are currently accessible (that is, online) to history client
applications. History data sets in a running Continuous Historian have one of these classifications:

Active

Current

Extended

Active History Data Sets


An active history data set holds the most recent history data captured for all history tags configured for this historian.
It holds the contiguous history record from the time it was started until the present.
An active history data set's content grows as it accumulates history tags and history samples from the real-time data
stream from the data capture system.

142

System Configuration

To assist in data management, the Continuous Historian can be configured to automatically "roll over" the active
history data set. The active history data set is "closed" and becomes a "current" history data set. A new (empty)
active history data set is started. The configuration rules for performing a rollover can be based on:

the approximate history data file size limit (so that the current history data sets will usually fit on long-term
storage media)

calendar/time targets (so that current history data sets will represent convenient time spans; for example,
days starting at midnight, weeks starting on Sundays at midnight, and so forth)

A new active history data set can also be created directly using the Create New Active Data Set tool in the
Continuous Historian Administration application. Refer to the topic Continuous Historian Administration for more
information.
Current History Data Sets
Current history data sets are created by active history data set "rollover" operations. They hold history data for a
collection of history tags within the time span of the data set. They provide a means to manipulate history data
captured in manageable "chunks," while keeping as much of the recently captured data accessible to history client
applications as possible.
For the current history data sets, the user may configure (on the Advanced tab of the Continuous Historian Properties
dialog):

a data set size

a time span

an export destination directory

If a time span is configured, it is applied to each current history data set as it is created. If automatic export has been
configured, once the time span has expired on a current history data set or the size limit has been reached, the
Continuous Historian will perform the export and remove the data set from primary storage.
Users can manually export data from and/or discard current history data sets using Continuous Historian
Administration tools.
Extended History Data Sets
Extended history data sets provide a means to bring history data that has been exported and no longer online, back
online (that is, again made accessible to history data client applications).
Continuous Historian Administration tools provide means to create extended history data sets from history data files.
Once created, history data in the extended history data set is accessible in the same way as the data in the active and
current history data sets. There are no assumptions about continuity of the data in an extended history data set with
any of the other data on-line. The history tags in the extended history data set need not match (nor are they
constrained by) the other history tags available on-line.
The Continuous Historian performs no automatic data management for extended history data sets. They remain
online (and occupy storage) until the user manually removes them.

History Data Files


History data files hold "off-line" history data for long term storage or bulk transfer (including Continuous Historian
software version migration).

The Continuous Historian

143

History Data Set Security


Continuous Historian data set security is part of the overall DeltaV security scheme. Access to individual Continuous
Historian Administration functions, such as exporting or deleting history data sets, is restricted to those users who
have been granted an access key individually or who belong to a group that has been granted a key. In addition, userdefined locks can be created, and Continuous Historian Administration functions can be assigned to the new locks.
All Continuous Historian Administration operations are sitewide, requiring that <Sitewide> be assigned to the
System Admin key in DeltaV User Manager (when assigning keys to a user or user group). However, the specific
administration functions (such as creating a new active data set) still require the appropriate key be granted to the
correct areas. Refer to the Continuous Historian Administration topic for more information on these functions.
Note For more information about locks and keys, refer to the User Manager application online help. For more
information about configuring locks and operation level security, refer to the DeltaV Locks topic.
Continuous Historian Security Keys by Function
Function Name

Controls whether the current


DeltaV user (on this node) can:

HDS_ACTIVE

create a new active data set

HDS_EXPORT

export history data sets

HDS_DELETE

delete history data sets

HDS_EXTENDED

create extended history data sets

HDS_BACKUP

back up all current history data sets to an off-line


directory

HDS_RESTORE

restore current history data sets from an off-line


directory to primary storage

144

System Configuration

History Data Retrieval


Client applications can request that data be retrieved from the history data server in several ways, including:

Read raw samples - This provides access to the individual history samples stored in the history data sets. If
data compression is enabled, the number of samples stored per unit of time could vary a great deal. The
number of raw samples available online for a history tag that has a frequently changing value and with little
or no compression could be quite large.

Read processed data - This tells the server to return information for a history tag, derived by "processing"
the raw history samples; it usually involves a substantial reduction in the volume of data returned, but the
data is still useful for a specific purpose (drawing charts, performing analysis, looking for missing data, and
so forth). Processing involves:
1

Subdividing the time span bounded by the start and end time into one or more, evenly sized subintervals
(for example, 24-hour subintervals for the last month)

Computing one or more "aggregate functions" for each subinterval. Refer to Aggregate Functions for
more information on the aggregate functions supported.

In either type of request, a time span (ultimately resolved as a start time and an end time) is specified in the request to
establish the time boundaries for the request. Timestamps that exactly match the start time are considered within the
time span. Timestamps that exactly match the end time are not within the time span.
Start and end times from a client application will often not exactly "hit" the timestamps for raw samples stored in the
history server, so the following options exist for specifying how the server should handle the boundary sample
situations:

No boundary sample - specifies that no samples should be returned/used outside of the start and end times.
The first sample to be used would be the first raw sample stored after the start time, and the last one used
would be the last raw sample stored before the end time

Outside of span - specifies that the time span should be increased to include the first raw sample beyond the
specified start and/or end time

Interpolate - specifies that a sample should be "derived" for the start and/or end time by interpolation (as
appropriate for the data type) from the raw samples that are immediately before and after the boundary time
specified.

A complicating factor for history data retrieval is that there may be discontinuities (holes) in the history record.
Reading raw samples should return "hole start" samples that indicate the starting time and the reason for the hole (for
example, the parameter cannot be read, the historian shut down, the tag was not configured to collect at that time, and
so forth). Reading processed data should return sufficient information to let the client know if the requested aggregate
was adversely affected by any holes in the history record within each subinterval.
Another kind of discontinuity in the history record involves requesting history data for time spans up to and including
the present. It is usually convenient for clients if the history server would, in this case, return a raw history sample
representing what the history server currently considers "now." It is expected that a client repeating the same request
for a "now" sample some time later would see different, that is, more current, results.

Data Compression
Data compression can be enabled when configuring history data collection for a history data tag, by enabling data
compression and entering a deviation amount. The user can also select the type of display representation (Step, Line,
or Automatic). Step representation displays the values as step changes on the trend and is usually used for discrete
values (such as pumps) and for values that change in a step-like manner (such as setpoints). Line representation

The Continuous Historian

145

displays values with point-to-point connections and is usually used for values such as process data. It is
recommended that either Step or Line be specifically selected when configuring the Display Representation and that
the plot method used to display the data in Process History View be set to the default setting. If the Display
Representation is left as Automatic, then it will set a floating point value to Line, and an integer to Step. Refer to the
Configuring History Collection topic for more information on enabling data compression when configuring history
data collection.
When data compression is disabled for a history tag, a sample (value, status, timestamp) is captured in the history
database for each scan cycle (determined by the configured scan period). Even if the value of the history tag remains
the same, a sample will be stored with the same value/status for each scan cycle.
When data compression is enabled for a history tag, the only samples stored are those that are needed to represent the
history record for the tag to the desired degree of accuracy. Clients reading archived data for a compression-enabled
history tag should expect the request to return a variable number of unevenly spaced samples. Enabling data
compression reduces storage requirements and improves performance when retrieving the history record for tags that
change infrequently or by insignificant amounts.

Viewing Compressed Data in Process History View


As mentioned above, when configuring the history data collection for a tag, the user can select a display
representation of Step, Line, or Automatic. The display representation chosen during configuration is important for
several reasons:

It determines the default behavior for displaying the data in Process History View (PHV)

It affects the interpolation algorithm behavior that determines how to represent a value for a point in time
between raw samples

Along with the data type, it determines the compression technique used

Note The Process History View application allows the user to select a Line or a Step plot method for a given trend,
regardless of the display representation configured for the tag's history collection and regardless of the compression
technique used for gathering the data. Mixing the configured display representation and the PHV trend plot method
can result in misleading trend graphing outputs. For example, if a history tag is configured for Line display
representation, data collection and compression are optimized for producing sloping line rendering of history data. If
the user overrides the default and chooses Step plotting in PHV, the trend may indicate that changes occurred in
abrupt steps, when actually the trended parameter changed gradually (at a nearly constant slope). Conversely, if a
history tag is configured for Step display representation and the user chooses Line plotting in PHV, the trend may
indicate the values of a parameter changed gradually, when they did not.
In summary, optimal rendering results will be achieved when the trend plot method in PHV matches the display
representation configured for the tag history collection. It is therefore recommended that the default plot method be
used in PHV, rather than selecting a plot method that might conflict with the configured display representation.
Changing the display representation and downloading will affect the subsequent behavior of the system, but it does
not change the history data already collected for a history tag. No attempt is made to track changes of display
representation. The current configuration is interpreted as the preferred choice for rendering and interpolating values
in all previous history data stored on-line for the tag.

146

System Configuration

Composite Ff Status Values


Certain aggregate functions used in "read processed" data requests involve picking a single raw sample from each
subinterval as the information returned for the whole subinterval (for example, minimum value, maximum value, first
raw sample, and so forth). In these cases, the Ff status of the raw sample picked is also returned.
Other aggregate functions involve the computation of a result that can involve more than one raw sample (for
example, an interpolated value at start of interval, a time-weighted average). In these cases, a "composite" Ff status is
returned which summarizes the Ff status values for the raw samples involved in the computation.
"Read raw" data requests also return a "composite" Ff status for the boundary samples when the boundary
specification requested is "interpolated."
Ff status values comprise three component values:
Quality

Bad

Uncertain

GoodCascade

GoodNonCascade

Substatus

NonSpecific

(Other values whose interpretation depends on the Quality)

Limits

Constant

HighLimited

LowLimited

NotLimited

The composite Ff status value returned is a value representing the "worst" of individual Ff status values seen.
Specifically, each part of the composite Ff status is computed separately as follows:
Quality - The composite Quality value is the worst of Quality values of all the raw sampled involved. As such:

GoodCascade is "worse" than GoodNonCascade

Uncertain is "worse" than Good Cascade

Bad is "worse" than Uncertain

Substatus - If the Quality value AND the Substatus value of all the raw samples involved are exactly the same, the
Substatus is that same value; otherwise a Substatus value of NonSpecific is returned.
Limits - The composite Limit value is a "Limit value OR" function of all the individual Limit values from the raw
samples involved.

Composite Historian Status Values


The historian (DvCH) status value indicates the validity of history information (involving historian behavior not
covered by the Ff status value.)
Historian values associated with raw history samples usually have at most one historian status bit set. Historian
values returned for history aggregates (involving several raw data samples) are quite likely to have several historian

The Continuous Historian

147

status bits set. Composite historian status values for interpolated history samples or history aggregates are obtained
by bit-ORing the individual historian status values that were involved in computing the interpolated sample or
aggregate.
The individual historian status bits defined are:
History data unavailable (** No Data **) - When set, indicates a type of "hole" in the history record. This status
would let history clients know that the history server has no history data set mounted that includes this history tag for
this point in time. Situations would include the period of time before the oldest history sample currently online for a
history tag or gaps in the online history record due to history data sets being removed.
History collection not configured (Not Configured) - When set, indicates a type of hole in the history record. This
lets history clients know that the hole is intentional, that is, caused by the configuration engineer deciding to no
longer have history captured for this tag on this node, or configuring the historian to be disabled.
Historian/scanner shutdown (Historian shut down) - When set, indicates a type of hole in the history record. This
status lets history clients know that the hole was a temporary outage due to the historian not operating or due to
planned or unplanned DeltaV shutdowns. (It is likely that no other history tags have data available from this server at
this point in time.)
History data unreadable (Not Readable) - When set, indicates a type of hole in the history record. This lets history
clients know that the history tags became unreadable for whatever reason (source node crash, communication
problems, configuration changes partially distributed, and so forth).
Aggregate value invalid (Bad Aggregate) - This status bit is set for aggregate values (requested using "read
processed" calls) that could not be produced. Situations where it is impossible to compute a requested aggregate value
might include:

A minimum, maximum, or average is requested for an interval that is entirely within a hole in raw data
samples, so there are no useful values that can be used in computing the aggregate.

An aggregate is requested that is not supported on a history tag of that type (for example, requesting a timeweighted average for a string type history tag).

Aggregate Functions Supported


The aggregate functions in the table below are supported for all history data types.
Aggregate

Value

Timestamp

Composite Ff
(DeltaV) Status

Composite
DvCH (Archive)
Status

First

Value (if any) of


first raw sample

Timestamp for first


raw sample

Ff status (if any) for


first raw sample

DvCH status for


first raw sample

Last

Value (if any) of


last raw sample

Timestamp for last


raw sample

Ff status (if any) for


last raw sample

DvCH status for


last raw sample

Count

Number of raw
samples (including
holes)

Timestamp for start


of interval

Always constant
value: Bad ,
NonSpecific,
NotLimited (0)

Composite of all
raw samples in
interval

148

System Configuration

Aggregate

Value

Timestamp

Composite Ff
(DeltaV) Status

Composite
DvCH (Archive)
Status

Interpolated

Interpolated value
at start of interval

Timestamp for start


of interval

Composite from the


raw samples used in
interpolation

Composite from the


raw samples used in
interpolation

% Available

% of time in
interval where
history data is
present (0-100)

Timestamp of first
hole (start) in
interval

Composite of all
non-hole samples in
interval and
interpolated
boundary samples

Composite of all
samples in interval
and interpolated
boundary samples

The aggregate functions in the table below are supported for Float, 32-bit signed integer, and 32-bit unsigned integer
history data types.
Aggregate

Value

Timestamp

Composite Ff
(DeltaV) Status

Composite DvCH
(Archive) Status

Minimum

Value from the nonhole raw sample


with the smallest
numeric value

Timestamp
corresponding with
Value

Ff status
corresponding with
Value

DvCH status
corresponding with
value

Maximum

Value from the nonhole raw sample


with the largest
numeric value

Timestamp
corresponding with
Value

Ff status
corresponding with
Value

DvCH status
corresponding with
value

Time-weighted
average

Time-weighted
average of non-hole
raw samples in
interval and
interpolated
boundary samples

Timestamp for start


of interval

Composite of all
non-hole samples in
interval and
interpolated
boundary samples

Composite of all
samples in interval
and interpolated
boundary samples

The Continuous Historian

149

Historian Run-Time Processes


The run-time Continuous Historian history service processes are started automatically when DeltaV services are
started, and the Continuous Historian subsystem has been configured to be active on that workstation. History
collection and history data services for client applications are not available until these processes are started.
These run-time processes terminate when DeltaV services terminate.

Real-time Data Collection


When history tags are configured for collection, the DeltaV workstation hosting the active Continuous Historian
periodically samples the parameter field and Ff status field for storage in the active history data set. The timestamp of
the data sample is attached by the workstation during the sampling/storage process. Heavy ACN communications
loading and /or Continuous Historian workstation loading can decrease the accuracy of the timestamp.

System Clock Adjustments


Most users who are concerned about having accurately time-stamped continuous history data will purchase an NTP
server to ensure accurate time bases in all nodes in the DeltaV system and very small system time adjustment
amounts. If an NTP server is not used, users may cause system time changes on nodes hosting Continuous Historians
of any size--either forward or back in time.
If the system time on a Continuous Historian node is set forward (time increased), the history clients will see history
data as if it had not changed for the time span the clock was set forward. (There will be "flat lines" or gaps between
samples plotted.) No unusual status values will be inserted indicating the time shift.
If the system time is set backward (time decreased), the new data from the "same" time period is added to the history
database. If you plot this in Process History View, you will see that the line "jumps back" in time on the chart. No
unusual status values will be inserted indicating the time shift.

150

System Configuration

Continuous Historian Diagnostics


Only top-level diagnostic information about the health/performance of the Continuous Historian is available as
diagnostic parameters and visible in the Diagnostic Explorer.
Diagnostic parameters expose status Booleans or numeric levels that give users a means to use custom alarm logic to
draw more attention to problems in the historian.

In workstations where the Legacy Historian is installed, the current PHIST subsystem will continue to exist,
unchanged.

In local workstations where the Continuous Historian is installed, a new CHIST subsystem will exist (while
DeltaV services are running).

The Continuous Historian subsystem exposes the following parameters.


Name

Type

Usage

EXIST

Boolean

1 if the Continuous Historian is installed on this workstation.


(Results in a read error otherwise.)

SWREV

String

Standard DeltaV software rev string (e.g. "7.4.0.4197.xr")

OINTEG

Boolean

Composite integrity of the Continuous Historian data collection


and history server. 0 = GOOD, 1 = BAD.
The string value is displayed in Diagnostics.

SERVER

Boolean

History server is available. 0 = NO (not available), 1 = YES


(available).
Forces OINTEG to 1 (BAD) if SERVER = 0 and ITEMS > 0.

ITEMS

Int32

Number of History Collection Tags currently configured.

ONSCAN

Int32

Number of History Collection Tags currently configured that are


on scan (excludes items that are disabled or cannot be read or
stored to history.)

ITEMPSEC

Int32

Number of History Collection Tags currently being scanned per


second.

READPSEC

Int32

Number of history samples sent to history storage per second.


When compression is enabled, only samples for parameters that
have changed are sent to history storage. When compression is
disabled, a sample is sent each scan cycle regardless of a
parameter change being detected.

DCLOAD

Float32

Data Collection loading factor. Percent of time available for


scanning used for scanning; e.g., 20 means that scanning took 20%
of the time available to the scanning process. >100 means that
scanning is not keeping up with the configured scan rates.

BADREAD

Int32

Number of History Collection Tags that should be on scan but


cannot be read for data sampling.

The Continuous Historian

151

Name

Type

Usage

BADWRITE

Int32

Number of History Collection Tags that should be on scan but


cannot be written to history storage. If > 0 forces OINTEG to 1
(BAD).

DCSTOP

Boolean

0=NO, 1=YES. The string value is displayed in Diagnostics.


YES if real-time data collection has been stopped due to:
Data storage (database) could not be opened for writing

Data storage disk has too little free space for normal
operation

NO otherwise. If YES, forces OINTEG to 1 (BAD).


PRIUTIL

Float32

Primary Storage Utilization factor. Percent of the primary storage


target size that is currently consumed by active and current history
data sets.

PRIXSMB

Int32

Excess disk space (in Mbytes = 1024*1024bytes) currently on the


Primary storage drive if the Primary storage area reached the
configured size target. Computed as:
<available disk space on the primary storage drive> - <primary
storage size target> + <primary storage used>
This value will become negative if there is insufficient storage on
the primary storage drive for the primary storage area to reach its
configured maximum size target (that is, likely to run out of disk
space and history data collection will stop). If < 0, forces OINTEG
to 1 (BAD).

EXPFAILS

Int32

Number of failed attempts to export a History Data Set since


DeltaV software and the Continuous Historian were started.
Remains 0 if no Automatic Export directory is configured.

ERLACTIVE

Int32

Number of early Active History Data Set creations since DeltaV


software and the Continuous Historian were started. (Number of
times that the Current History Data Set created was size-limited
rather than corresponding to the desired time period.)

HSLOAD

Float32

History storage process loading factor. Percent of time used in


each history storage cycle. For example, 20 means that, in the last
history storage, 20% of the time was used, and 80% of the time
was waiting for the next storage cycle. >100 means the history
server's memory data cache is filling because storage is not
keeping up with the scanning interface.

HSWRITES

Int32

Number of samples written to history storage during the last


storage cycle.

152

System Configuration

Name

Type

Usage

SILOAD

Float32

Scanning interface loading factor. Percent of time used in each


scanning interface data transfer. For example, 20 means that the
scanned data transfer took 20% of the cycle time, and 80% of the
time was waiting for the next transfer cycle. >100 means the
scanner process in memory data cache is filling because the
scanning interface is not keeping up with scanning.

SIWRITES

Int32

Number of samples transferred by the scanning interface during


the last transfer cycle.

Continuous Historian Data Conversion


Inside this topic
Installing the Data Conversion Utility
Starting the Data Conversion Utility
Converting Data Files
Canceling a Data Conversion
Viewing the Data Conversion Log
Reconverting an Archive
The Continuous Historian Data Conversion utility is a standalone application that runs on Windows NT, NT Server,
XP, 2000 Server, or 2003 Server. (It does not require that DeltaV system software be present.) The utility is used to
convert Legacy Historian data from DeltaV versions 5.3.2, 6.3.4, 7.1, 7.2, and 7.3. The data conversion utility
converts the Legacy Historian archive data to a file format to be used with the Continuous Historian tools. The files
are saved as Exported History Data Sets (with a file extension of .xfc).
IMPORTANT Before attempting to do any conversion of historian data from the Legacy Historian to the
Continuous Historian format, become thoroughly familiar with the document, Continuous Historian Upgrade
Planning Guide. The guide is located on the DeltaV installation CD #4 in the _Support directory.
The Legacy Historian software must be installed on the system and its services must be running in order to use the
data conversion utility. The off-line Legacy Historian archive data must be loaded into the online Legacy Historian
system before the data conversion utility can convert the Legacy Historian archive data. The data conversion utility
presents a list of archive files available for conversion and allows the user to specify where the converted data is to be
stored. The generated files are named after the converted archive name; for example, the archive file piarch.001
would result in a converted file of piarch001_starttime.xfc. The utility indicates the progress of the conversion as it is
being done. After conversion, the files can be brought into the Primary storage area using the Administration tool,
Create Extended History Data Sets. Refer to the topic Continuous Historian Administration for more information.

Installing the Data Conversion Utility


The Continuous Historian Data Conversion utility is available on the DeltaV installation CD #4. Insert Disk 4 into the
computer where the Continuous Historian Data Conversion utility will be installed. Select Continuous Historian
Data Conversion from the Auto-run dialog and follow the prompts. During installation, a new folder,
HistorianDataConversion, is created under Program Files. This folder contains the data conversion utility and other
files.

The Continuous Historian

153

Starting the Data Conversion Utility


As noted above, the Legacy Historian software must be installed on the system and its services must be running
before you start the data conversion utility. In addition, the off-line Legacy Historian archive data that you wish to
convert must be loaded into the on-line Legacy Historian system before data conversion can be done. To start the data
conversion utility, browse to the Program Files\HistorianDataConversion folder and double-click
HistorianDataConversion.exe.

Converting Data Files


On the Continuous Historian Data Conversion dialog, the Legacy Historian archive files that are available for data
conversion are listed, along with their start and end times. (The current archive is not available for conversion.)
Specify the History Data Source Node. The default value is the name of the node on which the conversion utility is
installed. If you are converting legacy historian archive files that were collected on another node, the History Data
Source Node field must be manually changed to that node name before converting those archives.
Select the check box next to each archive you wish to convert. Enter the directory name in the Export directory field,
or click the Browse button. Using the Browse dialog, you can search for an existing directory or make a new folder
for storing the converted files. Click the Convert button to begin the conversion.
During the conversion process, a progress bar indicates the status of the conversion procedure. All the buttons on the
dialog are disabled except for the Cancel button. The status bar shows the current time, the time spent, the tag that is
being processed, and the archive being converted. When the conversion is done, a message displays how many data
samples were converted and the status of the conversion.

Canceling a Data Conversion


If you cancel a data conversion that is in progress, you are asked to confirm that you want to stop the conversion
process. If the response is Yes, the conversion of that file is halted and no conversion file is created. Any file
conversions completed before the Cancel button is clicked are not affected.

Viewing the Data Conversion Log


You can click View Log to see details of the conversion process, including any errors that may have been
encountered. The LogView dialog includes a Print button so that you can print the log details.

Reconverting an Archive
If you select an archive for conversion that has already been converted, you will get a message saying that the
converted file already exists and are given the option to overwrite the existing file.

154

System Configuration

Continuous Historian Administration


Inside this topic
Version Compatibility of Continuous Historian Data Files
Create New Active Data Set
Export History Data Set(s)
Delete History Data Set(s)
Create Extended History Data Set(s)
Backup DeltaV Continuous Historian Data
Restore DeltaV Continuous Historian Data
Display Storage Details
Data Set Properties
Diagnostics
The Continuous Historian Administration application provides tools to manage continuous history data. This
application must be run on the same workstation as the Continuous Historian.
The Primary storage area, highlighted in the left pane below, is used to store active, current, and extended history
data sets. (Refer to the topic History Data Sets and Files for more information about history data sets.) The size and
time span properties of the Primary storage area, data set size and time span properties, and the automatic actions for
data set export are defined on the Continuous Historian Properties dialog in the DeltaV Explorer. (Refer to the topic
Configuring the Continuous Historian Properties for more information on the Properties dialog.) The Automatic
Exports area, shown in the left pane below, lists the data sets that have been automatically exported. One or more of
these data sets can be returned to the Primary storage area as extended data sets using the Create Extended History
Data Set(s) tool.
The Continuous Historian Administration tools are described briefly in this topic. The figure below shows the main
screen for this application.

Version Compatibility of Continuous Historian Data Files


The files created through use of the export and backup features in the Continuous Historian have a file extension of
".xfc" and are saved in a directory of the user's choice. It is recommended that the export directory be on the same
workstation as the Continuous Historian, but outside of the DeltaV system directory. Because of the limited capacity
of online storage, it is expected that users will transfer older .xfc files to a removable medium for permanent offline

The Continuous Historian

155

storage. Files may be brought back online as needed using the Create Extended Dataset or Restore features of the
Continuous Historian Administration application.
When different versions of DeltaV software are used to create these files, users should be aware that, in general, older
.xfc files will be readable by versions of DeltaV software newer than the one that created them. They will not,
however, be readable by versions of DeltaV software that are older than the version that created them. Users who
have more than one DeltaV system operating at different version levels need to take this into consideration if they
plan to move historian data between their systems.

Create New Active Data Set


This feature lets a user force creation of a new active data set. It can be accessed from the Tools menu or the toolbar
icon; it can also be accessed by right-clicking the Primary storage and selecting Create New Active Data Set from the
context menu. The active history data set is closed and becomes a current history data set. A new (empty) active
history data set is started. This feature requires the user to have the DeltaV security key for the HDS_ACTIVE
function.

Export History Data Set(s)


This feature lets a user select one or more current/extended data sets for exporting to a user-defined directory. It is
recommended that the export directory be on the same workstation as the Continuous Historian, but outside the
DeltaV system directory. (Note that automatic exports of current history data sets can be set up using the Advanced
tab of the Continuous Historian Properties dialog in the DeltaV Explorer.)
The user selects the data set(s) to be exported. (When selecting multiple data sets, the standard Windows Ctrl and
Shift features are available.) The user then clicks the Export History Data Set(s) icon (or selects the export option
from the Tools menu or the context menu). A Browse window is opened for the user to browse to the export file
destination directory. If there are no current/extended data sets, this function will not be available. The user can use
the Create New Active Data Set to create a new active data set and convert the existing active data set to a current
data set that can be exported.
The data sets that are exported are not deleted from the Primary storage area. If the data set is again exported to the
same directory, the export is given a unique name (with -n appended to the name); the newly exported data set does
not overwrite the existing one. It is common for the size of exported data sets to be different from the size of the
original data set. If the Export operation is interrupted using the Abort button, any data sets exported before the abort
is confirmed are not affected; export of a data set that is in progress will not be completed.
This feature requires the user to have the DeltaV security key for the HDS_EXPORT function.

Delete History Data Set(s)


This feature lets a user delete any of the current or extended history data sets in Primary storage. After selecting one
or more data sets, the user can press the Delete key, select Delete from the Tools menu or the context menu, or select
the Delete icon.
If the Delete operation is interrupted using the Abort button, any data set in the process of being deleted will be
completely deleted to ensure that there are no "incomplete" data sets.
This feature requires the user to have the DeltaV security key for the HDS_DELETE function.

156

System Configuration

Create Extended History Data Set(s)


This feature is used to bring back into Primary storage one or more data sets that were previously exported to an
archive directory. It can be accessed from the Tools menu or the toolbar icon; it can also be accessed by right-clicking
the Primary storage or Automatic Exports area and selecting Create Extended History Data Set(s) from the context
menu.
A dialog opens to let the user type in a directory path or browse to an archive directory. After the user selects the data
sets, they are listed in the dialog. The user may optionally enter a comment of up to 511 characters. If a data set to be
restored has start and end times that overlap with an online data set, the extended data set will not be created. A
message will be displayed in the progress bar dialog, along with the number of errors. It is common for the size of
extended data sets to be different from the size of the original and exported data sets.
If the Create Extended History Data Set(s) operation is interrupted using the Abort button, any extended data sets
created before the abort is confirmed are not affected. Creation of an extended data set that is in progress will not be
completed; it may take some time to delete the partially created data set.
This feature requires the user to have the DeltaV security key for the HDS_EXTENDED function.

Backup DeltaV Continuous Historian Data


This feature lets users easily export all current history data sets to a subdirectory of a directory chosen by the user. It
can be accessed from the Tools menu or the toolbar icon; it can also be accessed by right-clicking the Primary storage
and selecting Backup DeltaV Continuous Historian Data from the context menu.
It is recommended that the backup directory be outside the DeltaV system directory. The subdirectory will have a
unique name that will be generated based on the date and time. The name format is DvCH_YYMMMDD_hh.mm.
The file names of the backed up data sets are unique within the subdirectory; if the same files are backed up again, the
subdirectory name will change, but the same data sets will have the same archived file names. The resulting export is
a collection of history data files that may be restored as a collection or brought back online individually as extended
history data sets. It is common for the size of exported data sets to be different from the size of the original data sets.
If the Backup operation is interrupted using the Abort button, any exported data sets created before the abort is
confirmed are not affected; creation of an exported data set that is in progress will not be completed.
If there are no current data sets, this function will not be available. The user can use the Create New Active Data Set
to create a new active data set and convert the existing active data set to a current data set that can be backed up.
This feature requires the user to have the DeltaV security key for the HDS_BACKUP function.
The DeltaV Continuous Historian also provides a command line backup utility that can be used from a command
window or batch file to perform scheduled or ad hoc backups. See the topic Continuous Historian Command Line
Backup Utility for more information on this utility.

Restore DeltaV Continuous Historian Data


This feature lets users restore current history data sets in Primary storage from data sets in a specified directory. It can
be accessed from the Tools menu or the toolbar icon; it can also be accessed by right-clicking the Primary storage and
selecting Restore DeltaV Continuous Historian Data from the context menu.
The user types in the directory path or browses to the "restore from" directory. If a data set to be restored has start and
end times that overlap with an online data set, or if a data set name is identical to a current or extended data set
already in the database, that data set will not be restored and a message will be displayed in the progress bar dialog,
along with the number of errors. It is common for the size of restored data sets to be different from the size of both the
original data sets and the backed up data sets.

The Continuous Historian

157

If the Restore operation is interrupted using the Abort button, any data sets restored before the abort is confirmed are
not affected. Restoration of a data set that is in progress will not be completed; it may take some time to delete the
partially restored data set.
This feature requires the user to have the DeltaV security key for the HDS_RESTORE function.

Display Storage Details


This feature provides a summary of the history data sets currently in the Primary storage area. It can be accessed from
the Tools menu or by right-clicking the Primary storage and selecting Display Storage Details from the context menu.
Information available includes the following:

the physical location (directory path) of the storage area

the total size of active and current data sets

the space available for storage of additional data sets

the total amount of storage defined for this storage area

Note that the extended data sets are not included in the storage size. (The user is responsible for creating and deleting
extended data sets, and therefore for managing their storage within the capacity of the disk drive.) The total size of
extended data sets is displayed in the status bar at the bottom of the Continuous Historian Administration window.

Data Set Properties


This feature lets users view the read-only Data Set Properties dialog for a selected data set. It can be accessed by
selecting a data set, right-clicking, and selecting Data Set Properties from the context menu. The properties include
the historian server name, the type of data set (active, current, extended, or exported), the location and size, the start
and end times, the number of tags, and the date it was created. The data set properties of exported data sets are
displayed only for those data sets in the Automatic Exports directory. For extended data sets, the information may
also include the name of the person who created the extended data set and any comments entered at the time it was
created. The date created will be the same as the start time for the active and current data sets, but different for
extended and exported data sets.

Diagnostics
This feature lets a user review the diagnostics for the Continuous Historian. It can be accessed from the Tools menu
or the toolbar icon. It provides information on the historian server such as the last number of writes, the total number
of cache writes, the total number of writes, and the percent busy. It also provides information on the Primary storage
area, such as the current status, whether the disk is full, the percent of the storage area in use, and the free disk space.
It also tells whether early creations of new Active data sets have been done and how many automatic exports have
failed. For early creations of new active data sets, it doesn't show creations initiated by the user or creations initiated
on a timed (for example, Daily) basis.

158

System Configuration

Continuous Historian Automated Backup Utility


Inside this topic
Syntax
Examples
Creating a Log File
Creating a Command File for Windows Scheduler
Unsuccessful Backups
Error Level Codes
The DeltaV Continuous Historian provides an automated backup utility that can be used to perform scheduled
backups of the DeltaV Continuous Historian data from the Windows Scheduler or from a third party application. The
utility may also be run manually from a DOS command prompt. The utility accesses the DeltaV Continuous Historian
Server to extract data from its database and backs this data up safely to local or networked storage.
The DeltaV Continuous Historian Automated Backup Utility includes support for the following:

Backing up all Current data sets to local/networked storage

Backing up all Extended (as well as Current) data sets to local/networked storage

Creating a new Active data set before performing the backup

Limiting the data sets to be backed up according to their age

Deleting backed up data sets in the target directory according to their age

Syntax
The Automated Backup Utility is located in the DeltaV/bin directory on the DeltaV workstation, The filename is
HistorianBackup.exe. The syntax for the Automated Backup Utility is:
HistorianBackup Directory [/CreateNewActive] [/Extended]
[/BackupIfLTDays:n] [/Retries:n] [/DeleteIfGTdays:n] [/OnlyIfModified]
where the parameters in brackets are optional. The parameters are:
Directory

is the directory to which the data sets will be backed up (in either
UNC or drive letter directory format)

/CreateNewActive

creates a new active data set before backing up

/Extended

backs up current and extended data sets

/BackupIfLTDays:n

backs up data sets less than "n" days old

/Retries:n

retries on exclusive use error for "n" retries, where "n" is in the range of 0 to
720; the default is 5 retries

/DeleteIfGTDays:n

deletes off line data sets greater than "n" days old

/OnlyIfModified

backs up modified data sets only

/?, -?, or no parameters

displays a help message with the command syntax

Data sets are backed up in alphabetic order. Oldest data sets are backed up first. Any data set being backed up will
have its "Backup Status" in the Continuous Historian Administration application set to "Backing Up" while the

The Continuous Historian

159

backup is in progress. When the data set is backed up, its status is set to "Backed Up." If the data set is modified
during or after the backup, its status is set to "Modified." If the data set is modified during or after the backup, a
backup file will still exist for the data set; however, the backup file will not be up-to-date.
Note that the Continuous Historian Administration application only updates every 60 seconds, so there may be a
slight delay in the backup status display immediately after a backup is performed.
The results of the backup procedure are recorded in the Windows Event Log.
Examples

The following command backs up all the current data sets to the DeltaVBackups directory on the c: drive. If
the directory does not exist, it will be created as part of the backup process.
HistorianBackup c:\DeltaVBackups

A UNC path may also be defined for the backup directory. The shared folder should have full control
permissions.
HistorianBackup \\server\share

The following command creates a new active data set and backs up all the current data sets to the
DeltaVBackups directory on the c: drive.
HistorianBackup c:\DeltaVBackups

The following command backs up all current and extended history data sets.
HistorianBackup c:\DeltaVBackups

/DeleteIfGTDays:15

The following command backs up all current data sets whose Backup Status is "Modified." If the /Extended
switch had also been used, the same criterion would have been applied to the Extended data sets. In the
Continuous Historian Administration application, the Backup Status field changes from "Modified" to
"Backed Up."
HistorianBackup c:\DeltaVBackups

/BackupIfLTDays:3

The following command backs up all current data sets and deletes all backed up data sets whose end times
are prior to 15 days before the backup and which do not have a corresponding data set still in the Continuous
Historian data base. If the /Extended switch had also been used, the same criterion would have been applied
to the Extended data sets.
HistorianBackup c:\DeltaVBackups

/Extended

The following command backs up all current data sets for which the end times fall within the last 3 days.
HistorianBackup c:\DeltaVBackups

/CreateNewActive

/OnlyIfModified

The following command backs up all current data sets and allows for retries if certain error conditions exist.
The error conditions addressed by the /Retries:n switch include: a) The DeltaV Continuous Historian Server
is not running, b) the DeltaV Continuous Historian Server fails during the backup, or c) the DeltaV
Continuous Historian Server is unavailable due to being locked out by another application's access to the
DeltaV Continuous Historian database. The retry rate is once per minute and must be greater than or equal to
0 and less than 721. If the switch is not specified, Historian Backup defaults to 5 retries. If the database does
not become available during the retry period, an error will be logged stating that the retry period was
exceeded.
HistorianBackup c:\DeltaVBackups

/Retries:20

Creating a Log File


You can create a log file that contains the details of the Continuous Historian backup procedure by adding optional
log file information to the backup command. You must define the location, name, and desired behavior for the log

160

System Configuration

file. The log file may be overwritten or appended each time the backup procedure is run. Using the operator ">"
before the directory path and file name overwrites the current log file, while using the operator ">>" appends the
current log file. For example:
HistorianBackup c:\Backups >directorypath\logfile.log
will create a new log file in the specified directory, or
HistorianBackup c:\Backups >>directorypath\logfile.log
will append the current log information to an existing log file.
If you schedule the backup to create a log file automatically, the first example above will result in the log file being
overwritten each time the scheduled task runs; it may be preferable to use the second format (using >>), which
appends the backup information to the existing file.
To use this option with the Windows Task Scheduler, you must create a batch or command file and add the log file
option to the command file. The log file option is not available if the HistorianBackup.exe file is called directly from
the Windows Task Scheduler. It is also recommended that you specify the full path for the log file; otherwise the log
file will be placed in the same directory as the batch/command file, which may not be the desired location.
For example:
c:\DeltaV\bin\HistorianBackup d:\histbackup >>d:\histbackup\backup.log
will append the backup procedure details to the existing log file backup.log in the d:\histbackup directory (the same
directory as the backup files).

Creating a Command File for Windows Scheduler


The Automated Backup Utility may be scheduled using the Windows Scheduled Tasks feature (Start | Control Panel |
Scheduled Tasks). With the Add Scheduled Tasks wizard, you can create a new scheduled task using the
HistoryBackup.exe file and manually adding the optional parameters, or you can create a batch or command file with
the optional parameters included. The benefit of using a batch or command file is that you can also create a log file to
record the backup activities.
To create a command file, open Notepad (Start | All Programs |Accessories | Notepad) and type the command for the
backup you wish to create, using the syntax described in this topic. Save this file to a local directory with a *.cmd file
extension (for example, CHBackup.cmd). Use the Add Scheduled Tasks wizard to establish a schedule for the
Continuous Historian backup, using the command file as the program you want to schedule.
An example command file may contain the following information:
c:\DeltaV\bin\HistorianBackup
\\SiteServer\CHBackups /CreateNewActive /OnlyIfModified
/DelteteIfGT30Days /Retries:15 >>d:\CHBackups\CHBackup.log
In this example, the Continuous Historian data sets will be backed up with the following conditions:

The data sets will be backed up to a UNC path \\SiteServer\CHBackups.

A new active data set will be created before the backup.

Only data set that are modified will be backed up.

Backed up data sets that are no longer in the Continuous Historian database, that are located in
\\Siteserver\CHBackups, and that are greater than 30 days old will be deleted.

If the backup is unsuccessful, up to 15 retries will be made.

A log file, CHBackup.log, will be created the first time the scheduled backup runs and appended each time
thereafter.

The Continuous Historian

161

Note The user creating the Scheduled Task must have the appropriate Windows and DeltaV security privileges to run
the Scheduled Task, access the Continuous Historian backup feature, and write the log file.

Warning During a Scheduled Task backup, a command line window will open briefly with information about the
backup if the logged on user is one who has privileges to run the Scheduled Task. Do not close this window. If this
window is closed, the backup will be cancelled.

Unsuccessful Backups
If the DeltaV Continuous Historian Database is unavailable due to access by another applications and does not
become available again during the retry period, an error will be logged stating that the retry period was exceeded. The
error message is available for viewing in the Windows Event Viewer or the backup log file (if this option was
selected). The applications that may "lock" the Continuous Historian Database are:

DeltaV Continuous Historian Administration when performing a Backup, Restore, Export, Create Extended,
or Delete operation

DeltaV Continuous Historian Server when performing an Automatic Export or Delete operation

If the operation completes with the retry period, the backup will start and complete normally.

Error Level Codes


The error codes 0 through 7 refer to the error level returned to the batch/command file that called the
HistorianBackup utility. If the backup utility is run from the command line, the error codes are of little use because
the messages accompanying an error or success are self-explanatory. However, if the backup is done using a batch or
command file, you might want to take some action within the batch/command file based on the returned error codes.
The return codes follow standard Microsoft procedures regarding the ERRORLEVEL environment variable. Type
"help if" at the command line prompt for more information.
The ERRORLEVEL environment variable represents an increasing severity level for the error. The codes are:
Error Level

Description

Everything is OK. Normal end.

Multiple instances of Historian Backup utility running. The user should probably try to
run the batch/command file at regular intervals until successful or until a more severe
error occurs.

Invalid parameter. The command line's syntax is incorrect. The user should correct the
problem and rerun the batch/command file.

162

System Configuration

Error Level

Description

Invalid Directory (several possibilities):


The syntax of the directory specified is incorrect. The user should correct the
problem and rerun the batch/command file.

The directory specified is a special folder (such as COM or AUX). Change the
directory name and rerun the batch/command file.

The local directory is one to which the user performing the backup does not
have write access. Change the directory name and rerun the batch/command
file.

The directory specified is a local/separate node's shared folder to which the user
does not have write access. Change the directory name and rerun the batch/
command file.

Wrong History Installed. Either there is no DeltaV Continuous Historian installed or the
legacy Continuous Historian is installed. Contact the System Administrator.

No DeltaV. DeltaV is not installed or the DeltaV service is not running. Contact the
System Administrator.

Can't Create New Active Data Set. The user does not have the privileges necessary to
create a new Active Data Set. Contact the System Administrator.

Backup Exception. Analyze the Exception text shown in the Event Log/batch/command
file output. Contact Emerson Process Management for help.

The Continuous Historian

163

Continuous Historian Excel Add-In


Inside this topic
Installing the Continuous Historian Excel Add-In
Accessing the Continuous Historian Excel Add-In
Worksheet Functions
Storage of Date and Time
Storage and Precision
Conversion Between GMT and Local Time
Conversion Between GMT and GMT Offset
The Excel Add-In provides four functions and associated dialogs that aid in the creation of detailed workbooks
containing historical data read from the Continuous Historian database. The workbooks created can include historical
values read directly or interpolated from the database. Workbooks can also include timestamp and status information
associated with those values.

Installing the Continuous Historian Excel Add-In


The Continuous Historian Excel Add-In can be installed on any DeltaV workstation. The Add-In requires .NET
Programmability Support to be installed before you install the Add-In. See the first procedure below for information
on installing the .NET Programmability Support and the second procedure for installing the Excel Add-In.
To install the .NET Programmability Support
1

In Control Panel, open Add or Remove Programs.

Select Microsoft Office 2003 and click Change.

In the Office 2003 Setup dialog, choose Add or Remove Features and click Next.

In the next dialog, check "Choose advanced customization of applications" and click Next.

Expand Microsoft Office Excel.

Click the down arrow on .NET Programmability Support.

Choose "Run from My Computer" and click Update.

To install the Excel Add-In


1

In the DeltaV bin directory, double-click the file DvCHXLASetup.Office2003.msi, the installer for the
Continuous Historian Excel Add-In. (Alternatively, you can right-click and select Install from the context menu.)

Click Next on the Welcome screen.

On the Select Installation Folder screen, accept the default directory for installation, and select whether the addin is to be available to others who may use the computer or only yourself.

On the Confirm Installation screen, click Next to start the installation.

When the installation is complete, click Close to exit the installer.

The .NET Programmability Support must be installed before Excel is used with the DeltaV Continuous Historian
Excel Add-In. If Excel is started without .NET Programmability Support, you should follow the steps above to add
the required support and then reactivate the DeltaV Continuous Historian Add-In by running the ExcelAddIn.reg file
from the Add-In's installation folder (C:\Program Files\Emerson Process Management\DeltaV Continuous Historian
Excel 2003 Add-In\ by default.)
The Continuous Historian Add-In must be uninstalled and reinstalled with each upgrade of the DeltaV System to a
new version. You can uninstall the Add-In using the Windows Control Panel option Add or Remove Programs. You

164

System Configuration

can also uninstall the Add-In by running the DvCHXLASetup.Office2003.msi installer and selecting the Remove
option.

Accessing the Continuous Historian Excel Add-In


The Continuous Historian Excel Add-In installer adds a top level DeltaV menu item to the Excel worksheet menu bar.
The DeltaV menu item is inserted between the Window and Help menu items. Under the DeltaV menu item, one or
more options may reside. To access the Continuous Historian functions, open Excel and then click DeltaV |
Continuous Historian and the worksheet function you wish to use.

Two other selections are Edit Function, which will bring up the worksheet function dialog for an existing formula for
editing, and Refresh, which will cause all Continuous Historian worksheet functions on the active worksheet to be
refreshed from the historian database.

Worksheet Functions
The Continuous Historian Excel Add-In provides dialogs to help in configuring the worksheet functions. The dialogs
are:

Configure Single Value Function - to configure a worksheet function to retrieve a single sample for a tag at
a specified time (previous sample, next sample, or interpolated)

Configure Raw Data Function - to configure a worksheet function to retrieve available samples for a
single tag within a time period

Configure Interpolated Data Function - to configure a worksheet function to retrieve a number of


interpolated samples for a single tag at regular intervals over a time period

Configure Calculated Data Function - to configure a worksheet function to retrieve calculated data
relating to a single tag over a time period which is broken down into a number of subintervals of equal
duration

For information on using the dialogs to configure the worksheet functions, refer to the topic Using the Worksheet
Function Dialogs. For details on the functions, including the syntax and arguments, refer to the topic Worksheet
Function Reference.

The Continuous Historian

165

Storage of Date and Time


The Continuous Historian stores timestamps using Greenwich Mean Time (GMT). The Continuous Historian Excel
Add-In supports viewing historical data in three ways:

GMT - Dates and times are presented as they were recorded by the Continuous Historian.

Local Time - Dates and times are presented in the user's local time as it applied at the time of the recording.
For example, if the event occurred during daylight saving time, it will be presented showing the daylight
saving local time even when viewed outside daylight saving time.

GMT Offset - Dates and times are presented with a fixed, user-configurable, offset (+/- hh:mm) from GMT.
This offset will be constant, and will disregard daylight saving time. This mode would be useful where data
is viewed in a different locale from where it was recorded. It will allow the data to be viewed in an
approximation of the local time of the plant.

Storage and Precision


In Excel, dates are stored as sequential numbers, called serial values. By default, January 1, 1900 is serial number 1,
and January 1, 2008 is serial number 39448 because it is 39,448 days after January 1, 1900. Times are stored as
decimal fractions because time is considered a portion of a day. Thus 0.5 represents 12:00:00 (noon). Date/time
values are stored in Excel worksheets as floating point numbers: the sum of the date's serial number and the time's
fraction. Using cell formatting, Excel allows times to be displayed with millisecond precision, for example: MM/DD/
YYYY hh:mm:ss.000, although it should be noted that the Continuous Historian records data on quarter-second
boundaries: .000, .250, .500, .750.)
Excel's method of storing times does not handle leap seconds, since in converting from a decimal fraction to a userreadable time format (such as MM/DD/YYYY hh:mm:ss.000) Excel is working on the assumption that there are
86,400 seconds in a day. In a day containing a leap second, there are actually 86,401 seconds. Excel will never
convert a time such that the value for seconds is greater than 59. Hence it is not possible to see the leap second at the
end of 1998 (31 Dec 1998 11:59:60).

Conversion Between GMT and Local Time


In parts of the world where daylight saving time is used, users must be aware of issues arising from conversion
between GMT and local times. Where daylight saving time is never used (for example, Arizona) there is no problem
converting from GMT to local time and back again since there is a one-to-one correlation between GMT and Local
times. The conversion problems arise from the fact that changes to or from daylight saving time affect the length of a
day. In the case of changing to daylight saving time, an hour is skipped altogether in local time, whereas the change
back from daylight saving time leads to certain local times occurring twice.
If you wish to create a report that shows one day's worth of data for your plant, you could do so using the Configure
Calculated Data Function worksheet function dialog, supplying a start time and end time exactly one day apart. These
times would most likely be specified in cells in the worksheet with an array formula referring to them by cell address.
Furthermore, the end time is likely to be expressed by a formula such as StartTime + 24:00:00. Excel ignores
daylight saving time when calculating such formulas, so the end time would show as being the same hour, exactly
one day later than the start time. For 363 days in the year (except for leap years), this array function would return 24
hours worth of data; but for one day each year there would be 23 hours worth of data and for another day there would
be 25 hours worth of data.
You need to be aware that this will occur if you are using local time, and design your worksheets accordingly. That is,
allow extra space in the table to accommodate the extra data as daylight saving time finishes; the table will be shorter
as daylight saving time begins.

166

System Configuration

A similar, though potentially more serious, problem occurs where you wish to find out data relating to an occurrence
around the time that daylight saving time starts.
Consider a plant in a U.S. state that operates under Central Time. At 2:00 a.m. on October 31, 2004 daylight saving
time ends (Central Daylight Time finishes and Central Standard Time is used). The local time thus goes from
01:59:59 to 01:00:00. This is the second time it has been 01:00:00 that day. If anything goes wrong in the plant during
the next hour, it will not be possible to view that data in the DeltaV Continuous Historian Excel Add-In if local times
are used. This is because, in converting to GMT, the first occurrence of times between 01:00:00 and 01:59:59 on
October 31, 2004 is assumed. You would need to choose to use either GMT or GMT Offset when dealing with such
issues.

Conversion Between GMT and GMT Offset


This conversion mode does not take account of daylight saving time. Therefore there are no conversion issues. A
regular offset (which can be any number of hours and minutes, up to 23:59) is applied to the recorded GMT times,
regardless of the recorded or current date.

Using the Worksheet Function Dialogs


The following example illustrates the use of the Configure Calculated Data Function dialog to analyze min, max, and
average values for a single tag and time span.
In this scenario, the user wishes to examine the min, max, and average statistics relating to a single tag (FIC-101.PV)
over a one-hour period. He wishes to break the hour down into 60 one-minute intervals. The table produced will have
the following column headers:
Minimum Value Minimum Timestamp Maximum Value Maximum Timestamp Average Value
To make the worksheet useful for future queries, the tag and time period will be specified in the worksheet. This will
allow the user to change the tag or date/time very easily by changing the contents of cells A1 and B1 in order to see
data for a different tag on a different day.
To create the Excel worksheet
1

Open Microsoft Excel.

In cell A1, enter the tag name, such as CHS250_1S/SGGN1/OUT.CV.

In cell B1, enter the start date and time in the format mm/dd/yyyy hh:mm:ss; for example, 10/20/2004 08:15:00.
(Note that the date format required by Excel is dependent on the user's locale.)

In cell C1, enter the end time using a formula, for example "=B1 + 1/24". This sets the end time for the period to
one hour (1/24 day) from the start time.

Select cell A3 as the cell in which to enter the formula for the worksheet function. This will be the top left cell of
the array in which the results are displayed.

Note A range of 61 rows by 5 columns will be needed for the results. (This includes the header row and 60 rows of
data.) Rather than select the entire range, the user may select the top left cell of the range, for example, A3, and then
use the option "Adjust selection to accommodate results" in the worksheet function dialog to automatically extend the
range to the appropriate size.

The Continuous Historian

167

From the menu bar select DeltaV | Continuous Historian | Configure Calculated Data Function. The Configure
Calculated Data Function dialog appears.

To use the Configure Calculated Data Function dialog


The Connection field is pre-populated with the default Continuous Historian connection details. A browse button is
available if it is necessary to browse to an alternate source.

168

System Configuration

For Tag, click the cell reference button to the right of the tag field

. The Cell Reference dialog appears.

Click on cell A1 in the worksheet to automatically fill in the cell reference, or type A1 or $A$1 in the dialog box.

For Period, leave the Mode as Local Time.

For the Period start time, select Cell Reference and enter B1 (or $B$1) to indicate that the start time is stored in
cell B1 (or click the cell reference button and then click on cell B1 in the worksheet).

For the Period end time, select Cell Reference and enter C1 (or $C$1) to indicate that the end time is stored in
cell C1 (or click the cell reference button and then click on cell C1 in the worksheet).

For Intervals, select Interval, enter 1 and select minute(s) from the drop-down list.

Under Display Data, select Header Row to show the column names for the returned data.

Select the Columns by holding the Control key and selecting Minimum Value, Minimum Timestamp, Maximum
Value, Maximum Timestamp, and Average Value.

Click the right arrow button to add the selected columns to the Selected Columns list.

Note As changes are made to the optional fields, the Worksheet Required Range is updated to show the dimensions
of the array that will be yielded.
10 Under Worksheet, make sure the option to "Adjust selection to accommodate results (if necessary)" is selected.
(By default, this option is selected.)
Note Since there is no data below or to the right of the selected cell, there is no need to check the "Insert rows and
columns" checkbox. Also, since the selected dates do not run across the daylight saving change, there is no need to
check the box for Extra rows.
11 Click the "Try It..." button to preview the results.
Note This button opens a grid containing the actual data as queried from the DeltaV Continuous Historian database.
The Try It window shows the row and column at which the data will be inserted. The dialog can be closed before the
query is complete. While the query is being performed, the title bar indicates that it is working. On completion, the
title bar indicates the number of rows and columns and the time taken to perform the query.

The Continuous Historian

169

12 Close the Try It results window and click OK on the main dialog.

The resulting worksheet, after clicking OK (and reformatting the column widths and the date format) is shown
below:

170

System Configuration

Worksheet Function Reference


Inside this topic
Single Value Function
Raw Data Function
Interpolated Data Function
Calculated Data Function
Most users will want to use the worksheet function dialogs to configure the worksheet functions. However, it is
possible to enter a worksheet function directly into the Excel formula bar. First, select an appropriately dimensioned
array of cells for the expected results. In the formula bar, begin the function with "=" and, after typing in the function
and arguments, end the entry using Ctrl+Shift+Enter to indicate that it is an array formula. (For a single cell, you can
press Enter or Ctrl+Shift+Enter.) Excel encloses the formula in braces, {}, in the formula bar to indicate that it is an
array formula.
A worksheet function entered in this way can be edited with the appropriate worksheet function dialog by selecting
the cell that contains the function formula and then selecting the "Edit Function" option from the DeltaV Excel AddIn menu choices. On the worksheet function dialog, you could then easily resize the array or change the values of one
or more arguments.
Note that it is possible to manually configure a function using advanced Excel features such as cell references and
expressions for any argument--even those that do not support cell references in the worksheet function dialogs. These
formulas can still be edited with the worksheet function dialogs; only if an argument is actually changed in the dialog
will the manually edited cell reference or expression be lost. For example, a Columns argument could be entered as
CONCATENATE ($A$1, ";", $A$2); if A1 contained "timestamp,GMT" and A2 contained "value" then the dialog
would show "timestamp,GMT" and "value" as the selected columns. If any change was made to the selected columns
in the dialog, then the argument would be written back as a single text string enclosed in quotes (that is, in the normal
way). If no change was made to that field in the dialog, the CONCATENATE( ) expression would remain unchanged.
To reduce the length of the formula (which may be necessary if Excel's limit of 255 characters is exceeded), the
Columns argument in the example above could be set to $B$1, with cell B1 holding the following formula:
=CONCATENATE($A$1, ";", $A$2).
The four worksheet functions are:

Single Value Function (DvCHValue) - a worksheet function to retrieve a single sample for a tag at a
specified time (previous sample, next sample, or interpolated)

Raw Data Function (DvCHRaw) - a worksheet function to retrieve available samples for a single tag
within a time period

The Continuous Historian

171

Interpolated Data Function (DvCHInterppolated) - a worksheet function to retrieve a number of


interpolated samples for a single tag at regular intervals over a time period

Calculated Data Function (DvCHIntervals) - a worksheet function to retrieve calculated data relating to a
single tag over a time period divided into a number of subintervals of equal duration

The format for each function, an example, and a description of the function arguments are presented in the remainder
of this topic. Note, in the examples, that some of the arguments (such as strings, column names, tags, dates and times)
must be enclosed in quotation marks, while others (cell references, numbers, and Booleans) are not.
Single Value Function (DvCHValue)
This worksheet function is used to retrieve a single sample for a tag at a specified time. If used to show headers,
timestamps, or status information about the values, this function must be entered as an array formula in a range that
has the appropriate number of rows and columns. Use the DeltaV Continuous Historian "Configure Single Value
Function" dialog to help set up a call to this function.
Syntax
DvCHValue(connection, tag, show_header, columns, time_mode, selection_mode, timestamp)
Example
=DvCHValue("localhost", "DeltaV=MAIN_WORKSTATION CHS250_1S/SGGN1/OUT.CV", TRUE,
"Value;Timestamp", "GMT-06:00", 0, "9/25/04 12:00:00 PM")
Function Arguments
Connection - the node name of the DeltaV Continuous Historian server PC.
Tag - the DeltaV tag for which you want to retrieve data. The tag can be text, such as FIC101.PV, or a cell reference.
In the case of a cell reference (such as $A$1), the contents of the referenced cell must contain a valid tag.
Show_header - A Boolean (TRUE or FALSE) that indicates whether or not you want the returned data to have a
column header row.
Columns - a string that defines the columns that will be included in the results. Column definitions are separated by
semicolons. Each column definition comprises the column name and, optionally, various attributes relating to that
specific column. Column attributes are separated by commas. Supported columns and attributes are as follows:

Column name: Timestamp


-

Mode attribute: Local, GMT, or GMT +/-hh:mm

Column name: Value


-

For INT32, UNIT32, and Float data types, the value stored by Excel is a Variant Double.

For strings, the value stored by Excel is a Variant String.

For enumerations, the value stored by Excel is the state name in a Variant String.

Column name: Parameter Status (that is, FfStatus)


-

Mode attribute. Valid modes are:


Text - which yields a descriptive string, such as GoodNonCascade NonSpecific NotLimited
IsGood - which yields a Boolean: TRUE if the parameter status is good, or FALSE if it is not good (that
is, bad or uncertain)
Number - which yields the raw value as an integer

172

System Configuration

Column name: Collection Status (that is, DvCHStatus)


-

Mode attribute. Valid modes are:


Text - which yields a descriptive string
IsGood - which yields a Boolean: TRUE if the collection status is good (that is, 0) or FALSE if it is not
good (not zero)
Number - which yields the raw value as an integer

Time_mode - indicates how the timestamp argument should be interpreted. The Historian database records all times
in GMT; the time_mode argument specifies what conversion, if any, should be applied to the supplied timestamp in
order to convert to GMT.

Local - the timestamp is treated as being in the client PC's time zone. Conversion to GMT takes into
consideration whether the timestamp falls within daylight saving time.

GMT - no conversion is necessary

GMT+/-hh:mm - the time is adjusted by the specified hh:mm; daylight saving time has no effect.

Selection_mode - indicates how you want to select data in relation to the time(s) specified.

If 0 - the sample immediately previous to the requested timestamp is returned.

If 1 - the sample immediately after the requested timestamp is returned.

If 2 - the value at the supplied timestamp is interpolated.

Timestamp - is a single timestamp for which the DeltaV Continuous Historian database is queried. It may be text or a
cell reference. If the timestamp argument is a reference, the contents of the referenced cell must be a valid timestamp.
Raw Data Function
This worksheet function is used to retrieve available samples for a single tag within a specified time period. The
function must be entered as an array formula in a range that has the appropriate number of rows and columns. Use
the Continuous Historian "Configure Raw Data Function" dialog to help set up a call to this function.
Syntax
DvCHRaw(connection, tag, show_header, columns, time_mode, period_start, period_end, start_boundary,
end_boundary, max_num_values)
Example
=DvCHRaw("localhost", "DeltaV=MAIN_WORKSTATION CHS250_1S/SGGN1/OUT.CV", TRUE,
"Value;Timestamp,Local;Parameter Status,IsGood;Collection Status,Text", "GMT", "10/4/04 3:02:05 PM",
"10/5/04 3:02:05 PM", 1, 1, 50)
Function Arguments
Connection - the node name of the DeltaV Continuous Historian server PC.
Tag - the DeltaV tag for which you want to retrieve data. The tag can be text, such as FIC101.PV, or a cell reference.
In the case of a cell reference (such as $A$1), the contents of the referenced cell must contain a valid tag.
Show_header - A Boolean (TRUE or FALSE) that indicates whether or not you want the returned data to have a
column header row.
Columns - a string that defines the columns that will be included in the results. Column definitions are separated by
semicolons. Each column definition comprises the column name and, optionally, various attributes relating to that
specific column. Column attributes are separated by commas. Supported columns and attributes are as follows:

The Continuous Historian

173

Column name: Timestamp


-

Mode attribute: Local, GMT, or GMT +/-hh:mm

Column name: Value


-

For INT32, UNIT32, and Float data types, the value stored by Excel is a Variant Double.

For strings, the value stored by Excel is a Variant String.

For enumerations, the value stored by Excel is the state name in a Variant String.

Column name: Parameter Status (that is, FfStatus)


-

Mode attribute. Valid modes are:


Text - which yields a descriptive string, such as GoodNonCascade NonSpecific NotLimited
IsGood - which yields a Boolean: TRUE if the parameter status is good, or FALSE if it is not good (that
is, bad or uncertain)
Number - which yields the raw value as an integer

Column name: Collection Status (that is, DvCHStatus)


-

Mode attribute. Valid modes are:


Text - which yields a descriptive string
IsGood - which yields a Boolean: TRUE if the collection status is good (that is, 0) or FALSE if it is not
good (not zero)
Number - which yields the raw value as an integer

Time_mode - indicates how the timestamp argument should be interpreted. The Historian database records all times
in GMT; the time_mode argument specifies what conversion, if any, should be applied to the supplied timestamp in
order to convert to GMT.

Local - the timestamp is treated as being in the client PC's time zone. Conversion to GMT takes into
consideration whether the timestamp falls within daylight saving time.

GMT - no conversion is necessary

GMT+/-hh:mm - the time is adjusted by the specified hh:mm; daylight saving time has no effect.

Period_start - the timestamp of the start of the period. If this is a cell reference, the referenced cell must contain a
valid timestamp.
Period_end - the timestamp of the end of the period. If this is a cell reference, the referenced cell must contain a valid
timestamp.
Start_boundary - defines how the start boundary is handled:

174

If 0 (inside), the first sample returned will be the first sample after (or at exactly the same time as) the
period_start.

If 1 (outside), the first sample returned will be the first sample before (or at exactly the same time as) the
period_start.

If 2 (interpolated), an interpolated sample is created for the period_start time.

System Configuration

End_boundary - defines how the end boundary is handled:

If 0 (inside), the last sample returned will be the first sample before (or at exactly the same time as) the
period_end.

If 1 (outside), the last sample returned will be the first sample after (or at exactly the same time as) the
period_end.

If 2 (interpolated), an interpolated sample is created for the period_end time.

Max_num_values - the maximum number of values you wish to retrieve. Any samples in the database within the time
period in excess of this number will not be retrieved.

If period_start is an earlier time than period_end, then samples are taken forward from the start time toward
the end time.

If period_end is an earlier time than period_start, then samples are taken backward from the start time
toward the end time.

If max_num_values is set to -1, all samples within the time period are retrieved.

Interpolated Data Function


This worksheet function is used to retrieve a number of interpolated samples for a single tag at regular intervals over
a time period. The function must be entered as an array formula in a range that has the appropriate number of rows
and columns. Use the Continuous Historian "Configure Interpolated Data Function" dialog to help set up a call to
this function.
Syntax
DvCHInterpolated(connection, tag, show_header, columns, time_mode, period_start, period_end, samples)
Example
=DvCHInterpolated("localhost", "DeltaV=MAIN_WORKSTATION CHS250_1S/SGGN1/OUT.CV", TRUE,
"Value;Timestamp;Parameter Status,IsGood;Collection Status,IsGood", "Local", "10/6/04 11:04:02 AM", "10/7/04
11:04:02 AM", "60minutes")
Function Arguments
Connection - the node name of the DeltaV Continuous Historian server PC.
Tag - the DeltaV tag for which you want to retrieve data. The tag can be text, such as FIC101.PV, or a cell reference.
In the case of a cell reference (such as $A$1), the contents of the referenced cell must contain a valid tag.
Show_header - A Boolean (TRUE or FALSE) that indicates whether or not you want the returned data to have a
column header row.
Columns - a string that defines the columns that will be included in the results. Column definitions are separated by
semicolons. Each column definition comprises the column name and, optionally, various attributes relating to that
specific column. Column attributes are separated by commas. Supported columns and attributes are as follows:

Column name: Timestamp


-

Mode attribute: Local, GMT, or GMT +/-hh:mm

Column name: Value


-

For INT32, UNIT32, and Float data types, the value stored by Excel is a Variant Double.

For strings, the value stored by Excel is a Variant String.

For enumerations, the value stored by Excel is the state name in a Variant String.

The Continuous Historian

175

Column name: Parameter Status (that is, FfStatus)


-

Mode attribute. Valid modes are:

Text - which yields a descriptive string, such as GoodNonCascade NonSpecific NotLimited


IsGood - which yields a Boolean: TRUE if the parameter status is good, or FALSE if it is not good (that
is, bad or uncertain)
Number - which yields the raw value as an integer

Column name: Collection Status (that is, DvCHStatus)


-

Mode attribute. Valid modes are:


Text - which yields a descriptive string
IsGood - which yields a Boolean: TRUE if the collection status is good (that is, 0) or FALSE if it is not
good (not zero)
Number - which yields the raw value as an integer

Time_mode - indicates how the period_start and period_end arguments should be interpreted. The Historian database
records all times in GMT; the time_mode argument specifies what conversion, if any, should be applied to the
supplied timestamp in order to convert to GMT.

Local - the timestamp is treated as being in the client PC's time zone. Conversion to GMT takes into
consideration whether the timestamp falls within daylight saving time.

GMT - no conversion is necessary

GMT+/-hh:mm - the time is adjusted by the specified hh:mm; daylight saving time has no effect.

Period_start - the timestamp of the start of the period. If this is a cell reference, the referenced cell must contain a
valid timestamp.
Period_end - the timestamp of the end of the period. If this is a cell reference, the referenced cell must contain a valid
timestamp.
Samples - one of the following:

The number of samples required (without quotation marks). The start and end of the period each yield a
sample; therefore, this number must be 2 or greater.

The interval between samples (enclosed in quotation marks). This is a positive number followed by a units
string, which must be one of the following: hours, minutes, or seconds. If necessary, the period_end is
automatically adjusted to extend the overall period such that it is a multiple of this interval.

Calculated Data Function


This worksheet function is used to retrieve calculated data relating to a single tag over a time period divided into a
number of subintervals of equal duration. The function must be entered as an array formula in a range that has the
appropriate number of rows and columns. Use the Continuous Historian "Configure Calculated Data Function" dialog
to help set up a call to this function.
Syntax
DvCHIntervals(connection, tag, show_header, columns, time_mode, period_start, period_end, intervals)

176

System Configuration

Example
=DvCHIntervals("localhost", "DeltaV=MAIN_WORKSTATION CHS250_1S/SGGN1/OUT.CV", TRUE,
"Minimum Value;Minimum Timestamp;Maximum Value;Maximum Timestamp;Average Value", "Local",
"10/6/04 11:33:33 AM", "10/7/04 11:33:33 AM", 50)
Function Arguments
Connection - the node name of the DeltaV Continuous Historian server PC.
Tag - the DeltaV tag for which you want to retrieve data. The tag can be text, such as FIC101.PV, or a cell reference.
In the case of a cell reference (such as $A$1), the contents of the referenced cell must contain a valid tag.
Show_header - A Boolean (TRUE or FALSE) that indicates whether or not you want the returned data to have a
column header row.
Columns - a string that defines the columns that will be included in the results. Column definitions are separated by
semicolons. Each column definition comprises the column name and, optionally, various attributes relating to that
specific column. Column attributes are separated by commas. Supported columns and attributes are as follows:

Column name: Minimum Timestamp


-

Mode attribute: Local, GMT, or GMT +/-hh:mm

Column name: Minimum Value


-

For INT32, UNIT32, and Float data types, the value stored by Excel is a Variant Double.

For strings, the value stored by Excel is a Variant String.

For enumerations, the value stored by Excel is the state name in a Variant String.

Column name: Minimum Parameter Status (that is, FfStatus)


-

Mode attribute. Valid modes are:


Text - which yields a descriptive string, such as GoodNonCascade NonSpecific NotLimited
IsGood - which yields a Boolean: TRUE if the parameter status is good, or FALSE if it is not good (that
is, bad or uncertain)
Number - which yields the raw value as an integer

Column name: Minimum Collection Status (that is, DvCHStatus)


-

Mode attribute. Valid modes are:


Text - which yields a descriptive string
IsGood - which yields a Boolean: TRUE if the collection status is good (that is, 0) or FALSE if it is not
good (not zero)
Number - which yields the raw value as an integer

Column name: Maximum Timestamp


-

Mode attribute: Local, GMT, or GMT +/-hh:mm

Column name: Maximum Value


-

For INT32, UNIT32, and Float data types, the value stored by Excel is a Variant Double.

For strings, the value stored by Excel is a Variant String.

For enumerations, the value stored by Excel is the state name in a Variant String.

The Continuous Historian

177

Column name: Maximum Parameter Status (that is, FfStatus)


-

Mode attribute. Valid modes are:


Text - which yields a descriptive string, such as GoodNonCascade NonSpecific NotLimited
IsGood - which yields a Boolean: TRUE if the parameter status is good, or FALSE if it is not good (that
is, bad or uncertain)
Number - which yields the raw value as an integer

Column name: Maximum Collection Status (that is, DvCHStatus)


-

Mode attribute. Valid modes are:


Text - which yields a descriptive string
IsGood - which yields a Boolean: TRUE if the collection status is good (that is, 0) or FALSE if it is not
good (not zero)
Number - which yields the raw value as an integer

Column name: Average Value


-

For INT32, UNIT32, and Float data types, the value stored by Excel is a Variant Double.

For strings, the value stored by Excel is a Variant String.

For enumerations, the value stored by Excel is the state name in a Variant String.

Column name: Composite Parameter Status (that is, FfStatus)


-

Mode attribute. Valid modes are:

Text - which yields a descriptive string, such as GoodNonCascade NonSpecific NotLimited


IsGood - which yields a Boolean: TRUE if the parameter status is good, or FALSE if it is not good (that is,
bad or uncertain)
Number - which yields the raw value as an integer

Column name: Composite Collection Status (that is, DvCHStatus)


-

Mode attribute. Valid modes are:


Text - which yields a descriptive string
IsGood - which yields a Boolean: TRUE if the collection status is good (that is, 0) or FALSE if it is not
good (not zero)
Number - which yields the raw value as an integer

Time_mode - indicates how the period_start and period_end arguments should be interpreted. The Historian database
records all times in GMT; the time_mode argument specifies what conversion, if any, should be applied to the
supplied timestamp in order to convert to GMT.

Local - the timestamp is treated as being in the client PC's time zone. Conversion to GMT takes into
consideration whether the timestamp falls within daylight saving time.

GMT - no conversion is necessary

GMT+/-hh:mm - the time is adjusted by the specified hh:mm; daylight saving time has no effect.

Period_start - the timestamp of the start of the period. If this is a cell reference, the referenced cell must contain a
valid timestamp.

178

System Configuration

Period_end - the timestamp of the end of the period. If this is a cell reference, the referenced cell must contain a valid
timestamp.
Intervals - one of the following:

The number of intervals required (without quotation marks).

The duration of each interval (enclosed in quotation marks). This is a positive number followed by a units
string, which must be one of the following: days, hours, minutes, or seconds. If necessary, the period_end is
automatically adjusted to extend the overall period such that it is a multiple of this interval.

The Continuous Historian

179

The Legacy Historian


On a system upgrade, the user has a choice of installing the Continuous Historian on the Application Station or
keeping an existing Legacy Historian server. (Only one of the historians may exist on a workstation; however, both
historians may exist within a DeltaV system.) Existing Continuous Historian client applications are able to work with
both Legacy Historian and Continuous Historian data services on the same system. For more information on system
upgrades and converting history data, refer to the Continuous Historian Upgrade Planning Guide, located on the
DeltaV installation CD #4 in the _Support directory.
Differences Between the DeltaV System and the Legacy Historian
Some discrepancies exist between the DeltaV system and the Legacy Historian regarding minimum and maximum
limits for data values. The following table shows the limits for both the DeltaV system and the Legacy Historian and
provides information on how the Legacy Historian stores data that falls outside the valid ranges.
Data Type

DeltaV limits

Legacy Historian
limits

How does the Legacy Historian


store the data?

32-bit
unsigned
integer

Max 4,294,967,295
Min 0

Max 2,147,483,647

All values between 0 and


2,147,483,647 are stored correctly.
Values between 2,147,483,648 and
4,294,967,295 are stored as zero.
If you expect values larger than
2,147,483,647, consider:
storing the integer in a floating point
parameter. (These can handle a larger
range but with some loss of precision.)
scaling the integer to a smaller range
(for example, recording the value as
pounds instead of ounces).

Floating point

Max 3.40282e+38
Min -3.40282e+38

Max 1.70141e+38
Min -1.70141e+38

All values between -1.70141e+38 and


1.70141e+38 are stored correctly.
Values between 1.70141e+38 and
3.4282e+38 are stored as 1.70141e+38.
Values between -1.70141e+38 and
-3.4282e+38 are stored as
-1.70141e+38.

32-bit signed
integer

Max 2,147,483,647
Min -2,147,483,648

Max 2,147,483,647
Min -2,147,450,880

All values between -2,147,450,880 and


2,147,483,647 are stored correctly.
Values between -2,147,483,648 and 2,147,450,880 show as Status -252 in
Process History View.

180

System Configuration

DeltaV OPC Historical Data Access


Inside this topic
References
DeltaV OPC History Server Functional Overview
Properties and Methods
Browser
Performance
Sample Client Applications
Variations from OPC HDA Specifications
The DeltaV OPC Historical Data Access (OPC HDA) server (known as the DeltaV OPC History Server) provides an
OPC Foundation HDA interface to the DeltaV Continuous Historian based on Microsoft's OLE/COM technology.
The OPC HDA interface specification defines custom Microsoft COM interfaces to access continuous historical
data.
The topics in this section are intended to be used as a guide for developers of OPC HDA compliant clients for DeltaV
software. It is assumed that the reader is familiar with Microsoft OLE/COM technology and is generally familiar with
OPC HDA specifications. The DeltaV OPC History Server incorporates a subset of the OPC Foundation OPC HDA
specifications; it includes all the required interfaces and methods and some of the optional methods.
Through this technology, the DeltaV OPC History Server provides programmers with the ability to perform the
following tasks:

Connect to the DeltaV Continuous Historian database

Read DeltaV historical data

Browse for available ItemIDs

Operating details involving the DeltaV OPC History Server (startup, shutdown, client interaction, etc.) are written to
the Windows Event Log.
References
Users should be familiar with the following specifications, available from the OPC Foundation:

OPC Foundation - OPC Historical Data Access Specification - Version 1.20 Released December 10, 2003

OPC Foundation - OPC Historical Data Access Automation Interface Standard - Version 1.0 Released
January 26, 2001

OPC Foundation - OPC Common Definitions and Interfaces - Version 1.0 - October 27, 1998

Users who develop clients using Visual Basic or Excel with VBA may find the Automation Interface Standard most
helpful.
DeltaV OPC History Server Functional Overview
The DeltaV Application Station acts as a gateway between the DeltaV Continuous Historian and other applications
and networks. The DeltaV OPC History Server runs on this workstation, providing DeltaV historical data access to
applications that are running either on the Application Station or on a machine with a network connection to the
Application Station. The DeltaV OPC History Server also runs on the ProfessionalPLUS workstation.

The Continuous Historian

181

Note In order to run an OPC HDA client on a non-DeltaV workstation, first install the OPC Remote application. To
install the OPC Remote application, use the setup file located in the OPC Remote directory on the DeltaV Installation
CD (in the directory DVExtras\OPCRemote). The version must be the same as the installed version of the DeltaV
software.

DeltaV Network Diagram


OPC HDA client applications can use the COM compliant Custom Interface or the OLE Automation Interface of the
OPC HDA server. The custom interface supports clients written in C++. The OLE Automation Interface supports
higher level business applications, such as Excel and Visual Basic.

OPC Interfaces
Properties and Methods
The DeltaV OPC History Server incorporates all the required interfaces and methods of the OPC HDA Specification.
It also incorporates the optional "ReadProcessed" method under the IOPCHDA_SyncRead interface. See "OPC
HDA Custom Interfaces and Methods" in the topic DeltaV OPC History Server for more information on the custom
interfaces and methods.

182

System Configuration

The DeltaV OPC History Server provides a timestamp and quality value associated with each history data value. For
raw data values, the timestamp is the time the value was recorded by the DeltaV Continuous Historian. For processed
data values, the timestamp is the start of the interval, with two exceptions, minimum and maximum, which can be
requested with actual timestamps or interval timestamps. The OPC HDA quality value makes use of the parameter
and collection status quality information that is available from the DeltaV Continuous Historian.
The DeltaV OPC History Server presents time to client applications in UTC. Client applications are responsible to
make any necessary timestamp modifications (such as conversion to local time).
Browser
The DeltaV OPC History Server has a browser that exposes all parameters stored in the DeltaV Continuous Historian.
The browser supports the use of "wild cards" for string filters to assist in finding the stored parameters. A single
character may be filtered using the question mark character (?). For example, requesting TIC-100?/PID1/PV.CV will
return TIC-1000/PID1/PV.CV, TIC-1001/PID1/PV.CV, etc.
Multiple characters may be filtered by the asterisk character (*). For example, requesting TIC-1001/PID1/*.CV will
return TIC-1001/PID1/OUT.CV, TIC-1001/PID1/PV.CV, and TIC-1001/PID1/SP.CV.
In addition, the logical operators equal to (=) and not equal to (!=) may be used with the wild card filters to further
refine the parameter search.
Performance
The DeltaV OPC History Server loading is determined by the client request loading. Client applications should be
designed and tested to ensure that history collection performance is not degraded. The frequency of requests and the
amount of data requested can both affect loading. Each request also imposes a load on the DeltaV Continuous
Historian Server, and care should be taken to avoid loading it to the point that data collection would be affected.
Sample Client Applications
Two client applications are provided that allow browsing the items in the DeltaV OPC History Server and displaying
raw data for individual items for a fixed time span or start/end time with a fixed number of samples. The applications
can write the returned data to a file in a common file format (csv, xml) that can be used by third-party applications.
One sample client application (OPCHDAClient.exe), located in the DeltaV\bin directory, allows the user to create an
XML input script file that is used as a command line argument and writes output to text files. Several example script
files are available in the DeltaV\samples directory. The functions of this client are documented in the topic OPC
Historical Data Access Clients. A second client application, HDAprobe.exe, located in the DeltaV\bin directory, may
be used for testing and troubleshooting purposes and to help understand the operation of the DeltaV OPC History
Server. This client is not documented or supported.
To use the OPCHDAClient.exe sample client provided with the DeltaV software, it is assumed that the user is
familiar with XML and has access to an XML schema tool, such as XML Spy.

The Continuous Historian

183

Variations from OPC HDA Specifications


Several minor variations from the OPC HDA specification are documented in the following table.
Description

OPC HDA Specification


Expected Value

DeltaV OPC HDA


Returned Value

The timestamp of an interpolated value


coincides with that of a raw sample.

0x400C0 "Raw, Good"

0x200C0 "Interpolated, Good"


0x800C0 "Calculated, Good"

The aggregate time interval starts past


the last recorded sample.

0x20040 "Interpolated,
Uncertain"

0x200C0 "Interpolated, Good"

An aggregate value is for a time span


that includes a Bad value.

Bad values are omitted from


calculation of aggregates.

All values are included,


regardless of the FF status.

DeltaV OPC History Server


Inside this topic
Licensing Requirements
DeltaV OPC History Server COM Objects
OPC HDA Custom Interfaces and Methods
The DeltaV OPC History Server provides access to continuous historical data stored by the DeltaV Continuous
Historian.
Licensing Requirements
The DeltaV OPC History Server is available on the ProfessionalPLUS and Application Station. One OPC HDA client
connection is allowed on each DeltaV OPC History Server without the need for a license. The DeltaV OPC History
Server may be licensed for additional OPC HDA client connections on the ProfessionalPLUS and Application
Station.
DeltaV OPC History Server COM Objects
The DeltaV OPC History Server provides the IOPCHDA Server Object, as illustrated below. The ProgID used to
create an instance of the DeltaV OPC History Server is "DeltaV.OPCHDAsvr." An instance of the DeltaV OPC
History Server (DOPCHDA1.exe) runs on each DeltaV node where the DeltaV Continuous Historian has been
enabled if there is a client connected. Each connection to the DeltaV OPC History Server has an instance of an
IOPCHDA Server Object. The IOPCHDA Browser Object may only be created by invoking one of the methods in
the IOPCHDA_Server interface.
The optional IOPCHDA Client Object may be implemented by client applications needing to be notified when the
DeltaV services are stopped. Clients implementing this interface must respond to the ShutdownRequest method in a
timely manner.

184

System Configuration

Historian Server Model

The Continuous Historian

185

Historian Client Model

OPC HDA Custom Interfaces and Methods


Individuals writing programs to access the DeltaV Continuous Historian data using the DeltaV OPC History Server
should be familiar with the OPC Historical Data Access Specification, Version 1.2, Released December 10, 2003.
The DeltaV OPC History Server implements the following OPC HDA custom interfaces and methods.
IOPCCommon
The IOPCCommon interface is defined in the OPC Common Definitions and Interfaces specification, Version 1.0,
Dated October 27, 1998. The following methods make up this interface:

IOPCCommon::SetLocaleID
The only supported locale is English with a sublanguage of US English.

IOPCCommon::GetLocaleID
The value returned from this method corresponds to English with a sublanguage of US English.

IOPCCommon::QueryAvailableLocaleIDs
The available locale is returned by this method.

IOPCCommon::GetErrorString
This method may be used to convert from an HRESULT returned by any of the methods or the HRESULT
for an HDA Item into a user friendly description of the error.

IOPCCommon::SetClientName
This method may be used by a client to set the name of the client. The client name is used in some of the
events recorded in the Windows Event Log.

IConnectionPointContainer
The IConnectionPointContainer is a Microsoft defined interface used to obtain call back interfaces. The DeltaV OPC
History Server implements this interface in support of the client providing an IOPCShutdown interface. The methods
making up this interface are:

IConnectionPointContainer::EnumConnectionPoints
Only the IOPCShutdown interface is included in the IEnumConnectionPoints enumerator.

186

System Configuration

IConnectionPointContainer::FindConnectionPoint
This method may be used to obtain the interface corresponding to the IID_IOPCShutdown.

IOPCShutdown
This is a client-side interface used by the DeltaV OPC History Server to notify clients when the supporting DeltaV
services are shutting down. The single method provided by this interface is:

IOPCShutdown::ShutdownRequest
This method is invoked by the DeltaV OPC History Server to notify the client that the DeltaV services are
shutting down.

IOPCHDA_Server
This interface is the primary interface for the DeltaV OPC History Server. The IOPCHDA_Server interface provides
a method for setting up access to historical data values. The methods that make up this interface are:

IOPCHDA_Server::GetItemAttributes
This method returns the list of attributes supported by the DeltaV OPC History Server. These are:
Data Type
Stepped
ItemID
Maximum Time Interval
Minimum Time Interval
Exception Deviation (expressed in Engineering Units)
Current DeltaV Module Description
Current DeltaV Engineering Units
Current DeltaV Engineering Units 100% Value (default is 100)
Current DeltaV Engineering Units 0% Value (default is 0)

IOPCHDA_Server::GetAggregates
This method returns the list of aggregates supported by the DeltaV OPC History Server. These are:
Interpolative
Time Average
Count
Minimum Actual Time
Minimum
Maximum Actual Time
Maximum
Start
End

IOPCHDA_Server::GetHistorianStatus
This method may be used to obtain the status of the DeltaV OPC History Server.

IOPCHDA_Server::GetItemHandles
This method returns associations between server handles and client handles for specific HDA items.

IOPCHDA_Server::ReleaseItemHandles
This method releases associations between server handles and client handles for specific HDA items.

IOPCHDA_Server::ValidateItemIDs
This method validates that specific HDA Item IDs are known to the server.

The Continuous Historian

187

IOPCHDA_Server::CreateBrowse
This method returns a pointer to an OPCHDA_Browser interface. The Item ID filtering is specified as part
of the creation of a new browser.

IOPCHDA_Browser
This interface provides a method to access the list of OPC HDA Item IDs that pass the filter criteria set when this
browser was created. It should be noted that the DeltaV Continuous Historian provides a flat list of historical
parameters. Thus, the DeltaV OPC History Server provides a flat list of OPC HDA Item IDs.

IOPCHDA_Browser::GetEnum
This method returns an enumeration containing all of the OPC HDA Item IDs provided by the DeltaV
Continuous Historian that pass the filter criteria.

IOPCHDA_Browser::ChangeBrowsePosition
This method may be used to move up and down the list of OPC HDA Item IDs or to move directly to a
particular OPC HDA Item ID.

IOPCHDA_Browser::GetItemID
This method provides a way to obtain the current OPC HDA Item ID.

IOPCHDA_Browser::GetBranchPosition
This method provides the current OPC HDA Item ID.

IOPCHDA_SyncRead
This interface provides access to the data held by the DeltaV Continuous Historian.

IOPCHDA_SyncRead::ReadRaw
This method reads the values, qualities, and timestamps from the DeltaV Continuous Historian database for
the specified time domain for one or more OPC HDA Items.

IOPCHDA_SyncRead::ReadProcessed
This method requests an aggregate value or values to be computed by the DeltaV Continuous Historian for
one or more OPC HDA Items, providing values, qualities, and timestamps. See
IOPCHDA_Server::GetAggregates for a list of supported aggregates.

IOPCHDA_SyncRead::ReadAtTime
This method is not supported by the DeltaV OPC History Server at this time.

IOPCHDA_SyncRead::ReadModified
This method is not supported by the DeltaV OPC History Server at this time.

IOPCHDA_SyncRead::ReadAttribute
This method reads the attribute values and timestamps for the specified time domain for an item. The DeltaV
OPC History Server only supports current values for attributes. See IOPCHDA_Server::GetItemAttributes
for a list of supported attributes.

188

System Configuration

OPC Historical Data Access Clients


Inside this topic
Non-DeltaV Workstations
Copying OPCHDAAuto.dll to the Client
OPCHDAClient.exe Sample Client
Input Script File
<Configuration> Tag
<Execution> Tag
<Steps> Tag
<Step> Tag
This section describes an OPC HDA sample client application for use with the DeltaV OPC History Server. This
client application, OPCHDAClient.exe, is located in the DeltaV\bin directory. It allows the user to create an XML
input script file that is used as a command line argument and writes output to text files. The XML schema file
(DvOpcHda.xsd) for the XML script files is located in the DeltaV\DVData directory, and several example XML
script files are available in the DeltaV\samples directory. A second client application, HDAprobe.exe, is available in
the DeltaV\bin directory. This client is not documented or supported, but users may find it helpful for testing
purposes. Users are also able to write their own OPC HDA client applications based on the OPC HDA specifications
outlined in the topic DeltaV OPC History Server.
To use the OPCHDAClient.exe sample client provided with the DeltaV software, it is assumed that the user is
familiar with XML and has access to an XML schema tool, such as XML spy.
Non-DeltaV Workstations
If an OPC HDA client application (including the DeltaV sample clients) is running on a non-DeltaV workstation,
OPC Remote must be installed on the non-DeltaV workstation in order to connect to the DeltaV OPC History Server.
Copying OPCHDAAuto.dll to the Client
The file OPCHDAauto.dll must be present and registered on any client machine that is to run a VB client for OPC
HDA. After installing OPCRemote, copy OPCHDAauto.dll to the client. To copy and register the file, do the
following:
1

Copy the file OPCHDAauto.dll from the DeltaV workstation to %WINDIR%\SYSTEM32\ on the client
machine.

Change to the %WINDIR%\SYSTEM32 directory.

On the client machine, run the command "regsvr32 OPCHDAauto.dll ."

OPCHDAClient.exe Sample Client


OPCHDAClient.exe is stored in the DeltaV\bin directory and can be accessed from the Windows Run command. The
XML schema file, DvOpcHda.xsd, is in the DeltaV\DVData directory. The client accepts an XML script file name as
the command line argument and writes output to text files. An example of the Run command line is:
OPCHDAClient.exe MyScriptFile.xml
The script file specifies what the client application should perform. It defines one or more steps. Each step retrieves
data from one data item and generates one data output file. A single log file will also be generated that contains the
overall execution procedure and detailed error information.

The Continuous Historian

189

Input Script File


The input script in the command line argument for the OPCHDAClient.exe is an XML file. The XML script file must
conform to the schema defined in the file DvOpcHda.xsd. The schema file, which should never be modified, may be
used to validate the XML script file (including syntax and data types) used as input to OPCHDAClient.exe.
The tags defined in the following are optional or take default values.
The script has two parts, configuration and execution:
<DeltaVOpcHdaClient>
<Configuration></Configuration>
<Execution></Execution>
</DeltaVOpcHdaClient>
All timestamps in the script file are UTC time to be consistent with the OPC HDA standard.
<Configuration> Tag
The Configuration tag defines the execution configuration detailed in its subtags.
<Configuration> has the following single value tags.
Tag Name

Definition

Value/Comment

LogFileDirectory

Execution log file directory

Current directory by default

LogFileName

Execution log file name

OpcHdaLog by default

OutputDirectory

Data output file directory

Current directory by default

OutputFileName

Data output file name prefix

Must be specified

OutputFileFormat

Data output file format

XML(default), TXT, CSV

HostName

Server machine name

Local host by default

TimeSetting

Time format in the output file

LOCAL(default), UTC

<Execution> Tag
The Execution tag defines the data to be retrieved from the DeltaV OPC History Server.
<Execution> has one complex tag:
<Execution>
<Steps> </Steps>
</Execution>
<Steps> Tag
<Steps> contains a list of <Step> tags. The steps will be executed in sequence.

190

System Configuration

<Step> Tag
The <Step> tag defines the configuration of one data item to be retrieved from the DeltaV OPC History Server,
detailed in its subtags.
<Step> has the following single value tags.
Tag Name

Definition

Value/Comment

Interface

The interface pointer to use.

IOPCHDA_SyncRead

Method

The interface method to call.

ReadRaw
ReadProcessed
ReadAttribute

ItemID

Name of the data item

"LOOP/SGGN/OUT.CV". DeltaV specific.

AggregateID

Aggregate ID parameter used in


ReadProcessed method

OPCHDA_Interpolative
OPCHDA_TimeAverage
OPCHDA_Count
OPCHDA_MinimumActualTime
OPCHDA_Minimum
OPCHDA_MaximumActualTime
OPCHDA_Maximum
OPCHDA_Start
OPCHDA_End

AttributeID

Attribute ID parameter used in


ReadAttribute method

OPCHDA_DataType
OPCHDA_Stepped
OPCHDA_ItemID
OPCHDA_Max_Time_Int
OPCHDA_Min_Time_Int
OPCHDA_Exception_Dev

StartTime

The start time of data values. If the string


cannot be parsed by COleDateTime, then it
is in OPC HDA time format or some
conventional date format shown here.

"10-Jan-2001 + 1 MO",
"25 January 1996",
"8:30:00",
"20:30:00",
"July 25, 1996 8:30:00" ,
"8:30:00 Jan 25, 1996",
"1/25/1996 8:30:00"

EndTime

The end time of data values. If the string


cannot be parsed by COleDateTime, then it
is in OPC HDA time format or some
conventional date format shown here.

"10-Jan-2001 + 2 MO",
25 January 1996,
9:30:00,
21:30:00,
July 25, 1996 9:30:00,
9:30:00 Jan. 25, 1996,
"1/25/1996 9:30:00"

NumValues

NumValues parameter used in ReadRaw


method

1, 2, (1 by default)

Bounds

Bounds parameter used in ReadRaw


method

TRUE, FALSE (default)

The Continuous Historian

191

Tag Name

Definition

Value/Comment

ResampleInterval

ResampleInterval parameter used in


ReadProcessed method. In milliseconds.

0 by default

FileSuffix

Appended to OutputFileName defined in


Configuration tag to form the file name for
this step.

Many of these parameters can be understood by reading the OPC HDA specification, Section 4.4.3, for the ReadRaw,
ReadProcessed, and ReadAttribute methods.

OPCHDAClient.exe Sample Input Scripts


Inside this topic
OpcHdaRaw.xml
OpcHdaProcessed.xml
OpcHdaAttr.xml
Output File
Tab/Comma Delimited Output Files
XML Output
Log File
The three sample XML input scripts are in the DeltaV\samples directory for use with the OPCHDAClient.exe sample
client. The three sample script files provide examples of how to read raw, processed, and attribute data from the
DeltaV OPC History Server. The sample script files are named OpdHdaRaw.xml, OpcHdaProcessed.xml, and
OpcHdaAttr.xml.
The script file specifies what the client application should perform. It defines one or more steps. Each step retrieves
data from one data item and generates one data output file. A single log file is also generated that contains overall
execution procedure and detailed error information.
OpcHdaRaw.xml
The OpcHdaRaw.xml sample script provides an example of how to obtain raw data from the DeltaV OPC History
Server. In the following example, the goal is to read one day's raw data of the tag "FIC-101/PID1/SP.CV" before
current time, with bounds. The data is to be read from the local DeltaV OPC History Server, with output to an XML
file named FIC-101.XML.
The script file (OpcHdaRaw.xml) contains the following:
<DeltaVOpcHdaClient>
<Configuration>
<OutputFileName>FIC-101</OutputFileName>
</Configuration>
<Execution>
<Steps>
<Step>
<Interface>IOPCHDA_SyncRead</Interface>
<Method>ReadRaw</Method>
<ItemID>FIC-101/PID1/SP.CV</ItemID>

192

System Configuration

<StartTime>NOW - 1 D</StartTime>
<EndTime>NOW</EndTime>
<NumValues>1</NumValues>
<Bounds>TRUE</Bounds>
</Step>
</Steps>
</Execution>
</DeltaVOpcHdaClient>
OpcHdaProcessed.xml
The OpcHdaProcessed.xml sample script provides an example of how to obtain processed (also known as
interpolated or calculated) data from the DeltaV OPC History Server. In the following example, the goal is to read
one day's interpolated values of "FIC-101/PID1/SP.CV" before current time, at 10-minute intervals. The data is to be
read from the local DeltaV OPC History Server, with output to a tab-delimited text file named FIC-101.TXT.
The script file (OpcHdaProcessed.xml) contains the following:
<DeltaVOpcHdaClient>
<Configuration>
<OutputFileName>FIC-101</OutputFileName>
<OutputFileFormat>TXT</OutputFileFormat>
</Configuration>
<Execution>
<Steps>
<Step>
<Interface>IOPCHDA_SyncRead</Interface>
<Method>ReadProcessed</Method>
<ItemID>FIC-101/PID1/SP.CV</ItemID>
<StartTime>NOW 1 D</StartTime>
<EndTime>NOW</EndTime>
<ResampleInterval>600000</ResampleInterval>
<AggregateID>OPCHDA_INTERPOLATIVE</AggregateID>
</Step>
</Steps>
</Execution>
</DeltaVOpcHdaClient>
OpcHdaAttr.xml
The OpcHdaAttr.xml sample script provides an example of how to obtain attribute data from the DeltaV OPC History
Server. In the following example, the goal is to read current data type and exception deviation of "FIC-101/PID1/
SP.CV". The attribute data is to be read from a remote server machine called PROPLUS, with output to XML files
named FIC-101_CurrentType.XML and FIC-101_ExecDev.XML. T
The script file (OpcHdaAttr.xml) contains the following:
<DeltaVOpcHdaClient>
<Configuration>
<OutputFileName>FIC-101</OutputFileName>
<HostName>PROPLUS</HostName>
</Configuration>
<Execution>
<Steps>

The Continuous Historian

193

<Step>
<Interface>IOPCHDA_SyncRead</Interface>
<Method>ReadAttribute</Method>
<ItemID>FIC-101/PID1/SP.CV</ItemID>
<StartTime>NOW</StartTime>
<EndTime></EndTime>
<AttributeID>0x01</AttributeID>
<FileSuffix>_CurrentType</FileSuffix>
</Step>
<Step>
<Interface>IOPCHDA_SyncRead</Interface>
<Method>ReadAttribute</Method>
<ItemID>FIC-101/PID1/SP.CV</ItemID>
<StartTime>NOW</StartTime>
<EndTime></EndTime>
<AttributeID>OPCHDA_EXCEPTION_DEV</AttributeID>
<FileSuffix>_ExecDev</FileSuffix>
</Step>
</Steps>
</Execution>
</DeltaVOpcHdaClient>
Output File
The following is the table of keywords that are used in the output files. The keywords will be column names in text
output files and tag/attribute names in XML output files.
Data Value
TimeStamp
Quality
AtrtributeValue
Item

XML only

Attribute

XML only

ItemID

XML only

AttributeID

XML only

AggregateID

XML only

Tab/Comma Delimited Output Files


There are two types of text output files, both of which are readable by Excel. The value of TXT for OutputFileFormat
in the script file indicates a tab-delimited text file with a file extension of .txt; the value of CSV for
OutputFileFormat in the script file indicates a comma-delimited text file with a file extension of .csv. The first row of
the data will be column names, which are selected from the keyword list in the table above.

194

System Configuration

The following is a partial output from the OpcHdaRaw.xml sample script in comma-delimited output file format
(*.csv).
DataValue,TimeStamp,Quality
12.345,December 23 2004 8:30:00,192
12.346,December 23 2004 8:31:00,192
12.347,December 23 2004 8:32:00,192
12.348,December 23 2004 8:34:00,192
The following is a partial output from the OpcHdaProcessed.xml sample script in tab-delimited output file format
(*.txt).
DataValue TimeStamp Quality
12.345 December 23 2004 8:30:00 192
12.446 December 23 2004 8:40:00 192
12.547 December 23 2004 8:50:00 192
12.648 December 23 2004 9:00:00 192
The following is the output from the OpcHdaAttr.xml sample script showing a comma-delimited output file of the
current data type:
AttributeValue,TimeStamp
5,December 24 2004 8:30:00
XML Output
The XML output file uses a very simple schema that can be loaded into Internet Explorer or into a Microsoft Word
document using the XML capabilities in MS Office.
Item tag has the following properties:

Item ID - the item ID in DeltaV defined format

Aggregate ID - absent if not an aggregate value

It contains a list of DataValue tags, each of which has the following properties:

TimeStamp - the timestamp of the data in UTC

Quality - the quality as defined in the OPC HDA specifications

Attribute tag has the following properties:

ItemID - the item ID in DeltaV defined format

AttributeID - the attribute ID as defined in the OPC HDA specifications

It contains a list of AttributeValue tags, each of which has a TimeStamp property.


The following is a partial output from the OpcHdaRaw.xml sample script in XML output file format.
<DeltaVOpcHdaData>
<Item ItemID=FIC-101/PID1/SP.CV>
<DataValue TimeStamp=December 23 2004 8:30:00,192
Quality=192>12.345</DataValue>
<DataValue TimeStamp=December 23 2004 8:40:00,192
Quality=192>12.346</DataValue>
<DataValue TimeStamp=December 23 2004 8:50:00,192
Quality=192>12.347</DataValue>

The Continuous Historian

195

<DataValue TimeStamp=December 23 2004 9:00:00,192


Quality=192>12.348</DataValue> </Item>
</DeltaVOpcHdaData>
The following is a partial output from the OpcHdaProcessed.sml sample script in XML output file format.
<DeltaVOpcHdaData>
<Item ItemID=FIC-101/PID1/SP.CV AggregateID=OPCHDA_INTERPOLATIVE>
<DataValue TimeStamp=December 23 2004 8:30:00,192
Quality=192>12.345</DataValue>
<DataValue TimeStamp=December 23 2004 8:40:00,192
Quality=192>12.446</DataValue>
<DataValue TimeStamp=December 23 2004 8:50:00,192
Quality=192>12.547</DataValue>
<DataValue TimeStamp=December 23 2004 9:00:00,192
Quality=192>12.648</DataValue>
</Item>
</DeltaVOpcHdaData>
The following is the output from the OpcHdaAttr.xml sample script showing an XML output file of the current data
type.
<DeltaVOpcHdaData>
<Attribute ItemID=FIC-101/PID1/SP.CV AttributeID=OPCHDA_DATA_TYPE>
<AttributeValue TimeStamp=December 24 2004 8:30:00,192>5</
AttributeValue>
</Attribute>
</DeltaVOpcHdaData>
Log File
The log file will log general steps taken during the execution. If an error occurs, detailed information will be logged
as well.

196

System Configuration

Controller Considerations
Nodes are physical devices or pieces of equipment on the LAN, such as a controller or a console. You control your
process by downloading modules and defining I/O blocks and other configuration elements in the nodes. The
configuration tells the node how to act and what information you want to receive or save from the process.
You can define a node using the Configuration Assistant application or the DeltaV Explorer. To look at the status of a
node, use the Diagnostics application.
Note Unless specifically noted otherwise, all references to a workstation in the Books Online refer to one of these
DeltaV workstation types: Professional, ProfessionalPLUS, Operator or Base.

Auto-Sense Feature
When you connect controllers and I/O cards to an operational DeltaV control network, the system automatically
senses the controller and cards, as well as the card types. You do not have to type in all the I/O card types connected
to a controller because the DeltaV system does it for you.

Commissioning
An automatically sensed controller must be commissioned in order to be fully functional in the system. When the
system first senses a controller on the network, the controller is displayed in the Decommissioned Controllers section
of the Explorer. A decommissioned controller does not have an ID, an address, or a name. It is not bound to any
controller definition in the database. Commissioning is the process of dragging the controller icon from the
Decommissioned Controllers section to the Control Network section within the Explorer. Commissioning a controller
assigns an address and ID to the controller, and prompts you to supply a name and description.

Decommissioning
Decommissioning a controller takes it out of service. When you decommission a controller, all the information in the
controller is erased. You should not unassign modules when you decommission a controller because these
assignments can be restored through a download after you commission the controller.
Note Whenever you need to remove or a controller for service, or to move it to a new location on the control network,
you should decommission the controller.
When you decommission a controller, the controller icon and all its database information remains visible in the
Explorer. Database information includes all the configured cards, card types, channel types, and all the modules
assigned to the controller. You can restore all of this information by commissioning the controller and selecting the
Download Controller Node.

Controller Considerations

197

Note You can potentially lose online data if it is different from the information in the controller. For example, if you
have made online changes to a module from Control Studio, you lose this data when you decommission the controller
unless you first upload that data into the database. Refer to Uploading Recorded Parameter Changes for more
information.

Inter-Controller Communications Guidelines


This section describes controller communication behaviors in order to help you design your system to ensure data
transmission between DeltaV nodes.
Reads - Reads are the preferred method for communications. For example, Controller B has an input parameter
defined as an external reference to a parameter in Controller A. Controller B initiates unsolicited updates with a onetime request for data from Controller A. From then on, Controller A updates Controller B when the exception criteria
are met (a status or data value changes). Any references in Controller B are then reading buffered data that is
automatically updated by the system's communications processes. This is called unsolicited sending.
The unsolicited send occurs at the same priority as low priority modules on the source node. When referencing a
parameter in another node in an expression, you can verify communications with that parameter or node with the
.CST field. The .CST field can be referenced in blocks such as the CALC block or SFC expression.
When verifying the status of a reference in another controller, .CST is recommended instead of .ST. The .ST value is
set by the sending node. As such, if communications is lost, the .ST value does not change and holds its last value.
The CST value is set by the receiving node. Every time the module executes, the .CST value is updated with the
current remote status.
Your configuration should be designed to accommodate occasional, intermittent bad status. It may not be good
practice to immediately trip an emergency shutdown on a single instance of bad status. You can configure timeouts on
bad status as appropriate to avoid unnecessary shutdowns.
Similarly, it may not be appropriate to design control logic with immediate response to unexpected events. On any
interlock or shutdown conditional logic, provide appropriate time delays before the system takes significant action in
response to the event. For example, it may be appropriate in some cases to allow a bad status for several seconds
before shutting down or taking other serious action. Time delays can prevent unnecessary shutdowns in the event of
intermittent events caused by electrical noise, redundant controller switchovers, partial downloads, and so on.
Buffered Asynchronous Writes - When calculation block expressions, action block expressions, and SFC/PLM/
Phase Class actions write to a parameter in another node, the output is buffered. This is followed by an asynchronous
write request to the destination node with the new data. These occur at a priority lower than low priority modules on
the source node. Buffered asynchronous writes are also done for external reference parameters in other nodes.
With these definitions in mind, note the following functionality regarding data exchange between nodes:

198

Buffered writes are processed every 500 milliseconds.

Reading data is preferable to writing data, both for loading reasons and for communications status reasons.
A read operation has the appropriate status, depending on the state of communications. At the destination, a
written value holds the last value and last status and does not indicate communications problems if they
exist. If there is a communication failure between nodes, a written value does not reflect the current value
and status of the source data.

Normal situations occur in which both reads and writes fail. Partial downloads, overload, redundancy
switches, and other operations can all cause a read or write operation to fail (possibly without any indication
of failure) at some instant.

System Configuration

Unsolicited send operations contain a maximum of 2000 parameters per second for the MD controller. This
total is enforced. If the same parameter is being requested by multiple nodes, that parameter is counted
multiple times against this maximum. If there are more than 2000 unsolicited parameters to be sent through
an unsolicited send operation within a second, the excess parameters are held until the next second. This
means that, although the parameter data eventually arrives at the receiving node, the date may be slightly
older than expected. Develop configurations using a limit of 1000 parameters per second for the controller
and remote I/O node. Exceeding these recommended limits may affect system performance. In general, 2000
parameters per second cannot be sustained to another single node due to receive limitations and overhead
and handshaking limitations.

Write operations of either type are recommended to be no more than 20 per second per node.

The scan rate of modules configured with asynchronous writes must be greater than 100 ms to allow
processing time between write operations.

Reading any or all array elements from one controller to another is supported. Write operations of arrays
from node to node are not supported. An error is returned to the caller.

Due to normal system dynamics, a group of buffered asynchronous writes (such as multiple actions in a
single SFC step) does not necessarily act on the destination parameters in a predictable order.

Due to the relative priority of the various read and write operations versus other tasks in each node, in cases
of overload situations, reads and writes may not occur when expected.

A pulse action that writes to a parameter in another controller will retry the write as necessary while the step
is active. With the step active, this continues until the write gets confirmation from the destination node of
success. Possible write failures that will set ERROR and RERROR to TRUE include the write being rejected
due to a wrong mode or the value being invalid for the data type. In these cases, the write will be retried on
the next execution of the module. Between executions of the module, ERROR and RERROR will be TRUE,
but will toggle back to FALSE while the action status is PENDING. If the next attempted write again fails,
the cycle repeats.
In cases of communications failure, the retry mechanism will continue to attempt the write as long as the
step remains active. In a communications failure scenario, feedback is not available from the destination and
ERROR and RERROR will remain false. The write continues to be retried as long as the step is active.
If controllers are heavily loaded, the write may be re-buffered if necessary until there is feedback of success
or failure.
When a write fails, the action gets an error, which rolls up to the step, composite, and SFC level in
parameters called ERROR and RERROR. The phase's failure monitor can examine these parameters at the
run logic level and actions can be taken to inform the operator that a write has failed or other actions can be
performed as appropriate for the users implementation.

Keep inter-module and inter-controller communications to a minimum. Place I/O references within the
control module, not in a separate I/O module. Keep related modules with inter-module references in same
controller.

Controller Redundancy
The DeltaV system supports redundant controllers. A redundant controller consists of a pair of standard controllers
on separate 2-wide power/controller carriers connected together. Each controller requires a separate power supply
mounted on its carrier. One of the controllers in the pair is the active controller. The other controller is the standby
controller. The standby controller contains the same configuration as the active controller. When an active controller

Controller Considerations

199

fails, the standby controller takes over providing uninterrupted control operation without user intervention. The
standby controller gets updates of certain parameter values in the active controller over the redundancy link, but does
not execute control logic. When the switchover occurs, the new active controller reads back I/O data and the modules
begin to execute. A limited amount of re-initialization occurs in order to resume control without disruption. For
example, certain control and output function blocks begin executing in out-of-service mode and climb to their target
mode in order to force handshaking with other blocks. In most cases control actions resume on the first scan after a
switchover. For complex modules, one or a few scans of handshaking may be required. The apparent mode change on
a switchover is expected and has no adverse effect on control.
Even though each controller in a redundant pair does have its own MAC address and node address, a redundant
controller counts as a single node on the DeltaV control network in terms of network capacity.
A redundant controller requires a redundant controller license. Downloading a redundant controller without a license
results in a description of "Redundancy Not Licensed" in Process History View. In addition, the RedEnb diagnostics
parameter has a value of NO if no license is present.
Switchovers
A switchover from the active to the standby controller can occur for the following reasons:

Hardware failure within the active controller

Communications failure between the active controller and the I/O subsystem

Communications failure of both the primary and secondary network connections in the active controller

Removal of the active controller from the carrier

Manual switchover request

Loss of power supply for the active controller

Memory failure (the active controller detects a RAM or ROM failure)

Software watchdog timer trip

When a switchover occurs, the node status area on the Alarm Banner indicates the status change to the operator. The
system regenerates active, unacknowledged and suppressed alarms. The system does not regenerate alarms that are
both inactive and acknowledged. Alarm states are maintained during a switchover but General I/O Failure (IOF)
Alarms may change state momentarily.
The system stores a record of each switchover and the reason it occurred (if known). The switchover is logged in the
Process History event chronicle.
If the standby controller should fail, the software disables switchovers until you replace the failed unit.
Generally, there is no user impact related to a controller switchover. However, there are certain situations that the user
should be aware of when configuring control. These relate to HART digital variables, external references to other
controllers, and forced debug parameter values.
HART digital variables will have a value of zero with Bad status for six or more seconds after a controller switchover.
If you access a HART digital variable in an expression (Calc, Condition, or Action function block; SFC transition or
action), be sure to also consider the status of the variable in the expression. For example, use the value only when the
status is Good. Accessing HART digital variables in AI function blocks or by external reference parameters should be
done for monitoring, not control purposes.
When a controller switches over it can take several seconds to re-establish communication with other controllers.
External reference parameters that reference parameters in another controller will have BadNoCommNUV status
during this brief period following a switchover. Understand how downstream function blocks and expressions will
react to this bad status on a switchover so that your configuration will not create an output disruption. Refer to the
'status handling' subtopic of specific function blocks for this information.

200

System Configuration

A Condition function block that references a parameter in another controller has the potential to change its OUT_D
parameter when the referenced controller switches over. You can prevent this by selecting the 'Abort on Read Errors'
option in ALGO_OPTS. This is recommended unless you want OUT_D.ST to be BadNoCommNUV during the
switchover. In this case leave the Abort option deselected and change ERROR_OPT to 'Use Last'.
Forced debug parameter values (that is, those set in Control Studio's debug mode) are not retained following a
controller switchover. The value of the parameter is set to the default value as configured.
In general, the system regenerates process and device alarms during a controller switchover. This includes all active,
unacknowledged and suppressed alarms. Inactive and acknowledged alarms are not regenerated. General I/O Failure
(IOF) alarms may change state momentarily. The Time In values (displayed in the alarm list) and the alarm states are
not affected by the regeneration. The Time Last values on the alarm list are updated. Alarm strings may not be
maintained.
Manual Switchovers
Users with the Diagnostic Key can initiate a switchover from DeltaV Diagnostics. In Diagnostics, a redundant
controller has a Redundancy subsystem. To perform a manual switchover, select the Redundancy subsystem, click the
right mouse button, and then click Redundancy switchover.
Controllers have three parameters that determine whether a manual switchover can occur:

PExist -- indicates whether the standby controller is physically present

PAvail -- indicates whether the standby controller has received a download and is ready to take over

RedEnb -- indicates whether redundancy has been enabled for the pair. In order for redundancy to be
enabled, the active controller must have received a download.

In order for a manual switchover to occur, all three of the above parameters must have a value of Yes. If not, the
Status parameter provides additional details about why the controller cannot switch over.
Creating a Controller Placeholder
To create a placeholder for a redundant controller in DeltaV Explorer, add a controller node, and then click the
Redundant Controller option on the node's properties.
Installing a Redundant Controller
Installing a redundant controller is as simple as installing a single controller. The auto-sense feature in the DeltaV
system recognizes two controllers on adjacent, connected carriers as a redundant controller.
Refer to Installing your DeltaV Digital Automation System for physical installation instructions.
After installation, drag the controller from the Decommissioned Controllers section to the control network or to a
redundant placeholder. Assign an appropriate redundant license to the controller and download the controllers to
enable redundancy.
Installing a Standby Controller
You can connect a second controller to an existing controller's carrier to introduce redundant control without
interrupting your process. The system automatically commissions a standby controller when you install it. It is not
necessary to remove or decommission the active controller. The active controller continues to operate without
interruption. The system automatically assigns the standby with an address and downloads the standby controller
with the latest download and with any online changes made to the active controller. To install a standby controller
follow these steps:
Caution Follow the steps in the order shown. Do not install a second 2-wide carrier that already has a power supply
and controller installed. Doing so will result in a loss of configuration data for the active controller.

Controller Considerations

201

Using the DeltaV Explorer, assign an appropriate redundant controller license to the controller node that you
want to make redundant in DeltaV Explorer.

Install a second 2-wide carrier to the left of the current 2-wide carrier.

Insert the appropriate Power Supply in the left slot of the 2-wide carrier plug in the power cord.

Connect a controller to the carrier. The version of the controller you connect must match the existing controller's
version.

The DeltaV Explorer displays a redundant controller icon in place of the simplex icon.

If you are changing a simplex controller to a redundant pair, there is a one-time step required. In the DeltaV
Explorer, click the right mouse button on the controller, click Download, and then click Setup Data. This turns on
redundancy for the pair but does not disrupt any existing process control.

Replacing a Failed Controller


When a switchover occurs, remove the failed controller and plug in a replacement. The system automatically
commissions the replacement and makes it the standby controller.
Removing Controllers
The commissioning and decommissioning function in the DeltaV Explorer affects both controllers in the pair. You
can remove one controller in a redundant pair without decommissioning it. For example, if you remove the standby
controller and reinstall it, the address is reestablished, the standby receives a current download and is ready to accept
a switchover. If you remove the active controller without decommissioning, the standby takes over control. When you
reinstall the controller, the address is reestablished and the reinstalled controller becomes the standby controller.
Anytime one controller is removed from a pair, the DeltaV Explorer continues to identify the controller as redundant.
If you want to change a redundant controller to simplex, you must change the properties of the controller in DeltaV
Explorer and download the controller's setup data.
Do not disconnect a carrier and its controller while the controller is powered and operating. If a controller and carrier
must be removed, power down the controller before disconnecting the carrier and its controller.
Note Before removing both the controllers of a redundant pair, decommission the node through the DeltaV Explorer.
Diagnostics
The DeltaV Diagnostics displays a redundant controller icon in place of the simplex icon for redundant controllers
and placeholders. The DeltaV Diagnostics enables you to view diagnostics, MAC addresses, and node (IP) addresses
for both controllers in a pair. Diagnostics also enables you to flash the lights on either controller in the pair
independently using the Identify Controller menu selection. All diagnostic and address information for the standby
controller is accessed through the active controller at the Standby level (below the Redundancy Subsystem).
Diagnostics requires a commissioned communicating controller to be able to flash the lights (unlike Explorer, which
can use the database MAC address when the controller is decommissioned). However, you can Telnet or perform a
TCP/IP PING directly to the primary or secondary network connection node addresses on the standby.
Upgrading Controller Firmware
If the redundant controllers require a firmware upgrade (such as for a DeltaV version upgrade), the controllers
contain flash ROM that allows you to update the firmware while your process is running. Simply upgrade the standby
controller, then perform a manual switchover from Diagnostics. You can then upgrade controller that you recently
switched to standby at your convenience. There is no downtime.

202

System Configuration

Controller Performance
Inside this topic
Module Scan Rate
Execution Order within the Module
Scan Rate Multiplier
Scan Rate of Interacting Modules
The DeltaV controller balances memory and CPU capacity with Device Signal Tag (DST) licensing limits. It is
possible to exceed a controller's memory and CPU capacity even if the controller license supports the number of
DSTs in the control strategy. However, for a typical application in a wet process industry, the configuration engineer
should be able to implement the required control strategies up to and including the DST license limit of the given
controller.
Following are some guidelines to help deliver the maximum controller CPU performance.

Module Scan Rate


The scan rate of control modules affects CPU loading. A newly created module has a default scan rate of 1 second.
The library's module templates have default scan rates between 500 milliseconds and 5 seconds. Before increasing
the scan rate of a module, consider process dynamics, the response times of the transmitters, and final control
elements associated with the module. Faster module scan rates can consume CPU capacity without improving control
performance.
Setting a reasonable scan rate requires an understanding of the process dynamics for analog control modules. When
the controlled variable reacts slowly to changes in the manipulated variable, the module scan rate can be set slower
than when the controlled variable reacts quickly. This means that flow and liquid pressure loops must have a faster
scan rate (500 milliseconds or 1 second) than a temperature loop scan rate (5 or 10 seconds). The scan rate of a level
loop depends on the throughput (versus the size) of the vessel but can often be 2 or 5 seconds. Although it is
customary to overscan analog control modules slightly, running all loops faster than necessary quickly consumes the
CPU.
Monitoring modules, which gather data to display on DeltaV Operate, should have a maximum scan rate of 1 second,
which is the fastest display update rate. These modules can often be executed at a 2 or 5 second rate, based on the
speed of the transmitter to detect process parameters.
Modules that control discrete devices (for example, motors and valves) can usually be scanned at 1 second. At this
rate, outputs are driven soon after the setpoint is changed. When process interlocks are involved, it is sometimes
necessary to speed up the scan rate to 500 milliseconds. If the module needs to sense momentary push buttons in the
field, set the scan rate to 500 milliseconds.

Execution Order Within the Module


An incorrect execution order of module function blocks can make the module appear to scan slower than its actual
scan rate.
Note Input blocks should execute before control blocks or output blocks. The default execution order is based on the
order the blocks are created. Note the execution order of the blocks in the bottom right of each block and change as
needed.

Controller Considerations

203

For example, consider the INTERLOCK_D input of the Device Control function block or the TRK_IN_D input of
the PID function block. These values might be used by the blocks to stop a motor or close a control valve. If the
Device Control or PID block executes before the block(s) that determine the value of the input, the module loses a
scan before acting on the input. For more information, refer to the section entitled Set the Execution Order of
Function Block in the Control Studio help system.

Scan Rate Multiplier


A scan rate multiplier can be applied to a function block so that it executes at a slower rate than the module. Some
modules need a relatively fast scan rate to perform time-critical functions, such as interlocking or push-button
detecting. Apply a scan rate multiplier to blocks that do not need to execute every scan. For more information, refer to
the section entitled Scan Rate in the Control Studio help system.

Scan Rate of Interacting Modules


Control strategies can span multiple control modules. Select scan rates that meet the timing requirements of any
interacting modules but still make efficient use of the CPU.
For example, you use module templates from the library to create several motor modules with interlocks. The
interlock conditions in each of these modules are configured using expressions in Condition function blocks. If the
interlock conditions rely on values of parameters in other modules, the scan rate of those other modules should be at
least as fast as the motor module. The configuration engineer does not set the execution order of control modules.
Only the execution order of blocks within modules is set. So, the user does not control the order of execution of
modules with the same scan rate. Modules that interact with other modules having the same scan rate could
effectively be delayed 1 scan in terms of acting on information from another module. This might lead the
configuration engineer to scan all interacting modules at twice the required scan rate.
If there is a requirement that all discrete devices (for example, motors) interlock to the passive state within 1 second,
then setting the scan rate of all modules involved in interlock conditions or discrete control to 1 second does not
guarantee that the requirement will be met. However, setting the scan rate to 500 milliseconds satisfies the
requirement with the possibility that it might be costly from a CPU loading perspective. A possible alternative when
CPU load is an issue would be to base interlock conditions on values at input channels (via I/O type parameter paths)
where possible, rather than on parameters in other control modules (via module type parameter paths) instead of
overscanning all of the interacting modules. This keeps the interlock information current to within about 25 msecs.

204

System Configuration

Preserving Configuration and Controller Data During Power


Loss
Inside this topic
Preserving Configuration During Power Loss
Setting Controller Restart
Controller Nonvolatile Memory
Cold Restart Versus User Restart
Restart Diagnostic Parameters
If a controller loses power, it also loses all of the modules that have been downloaded to it as well as any online
parameter changes. The controller provides a cold restart feature that preserves some of this data and restarts the
controller automatically. This is accomplished by storing configuration data and optionally storing certain parameter
values in the controller's nonvolatile memory.

Preserving Configuration During Power Loss


Each time you request a total download for a controller, the system downloads the data to the controller's RAM. This
data is used for control. The system also downloads the data to the controller's nonvolatile flash memory (if the Cold
Restart Perform Within option is greater than zero) and to the ProfessionalPLUS workstation. The Cold Restart
Perform Within option is available in the Controller Properties dialog in DeltaV Explorer. The download stored in the
nonvolatile memory is a compressed duplicate of the download sent to the controller RAM. The download stored in
the ProfessionalPLUS workstation is the same script file that is sent to the controller RAM.
In the event of a power failure, the controller can initialize itself using the data in nonvolatile memory. This
nonvolatile memory includes the downloaded values with the exception of parameter values that you designated to be
restored as described in Preserving Parameter Values During Power Loss. The initialization process is relatively fast
and does not require communication with the ProfessionalPLUS workstation. If for some reason the nonvolatile
memory is not present, the system downloads the download scripts from the ProfessionalPLUS workstation.

Preserving Parameter Values During Power Loss


Any parameters that have changed since the download are not part of the download script that is stored in nonvolatile
controller memory or in the ProfessionalPLUS. There are two strategies for preserving these online parameter
changes available after a power loss. First, for tuning parameters that are adjusted periodically, you can upload these
online changes and then download to Controller Cold Restart Memory in DeltaV Explorer to keep the controller cold
restart memory current. However, this strategy is only useful for values that change infrequently.
The Restore parameter values after restart feature enables the user to specify that the values of certain parameters
in controller RAM are also preserved in nonvolatile memory in the event of controller power loss. The selected
parameter values will be preserved if the restart occurs within the user-specified cold restart time.
After a total download, the parameters for which Restore parameter values after restart have been checked are
restored to the values saved in nonvolatile memory (unless the restore parameter feature is disabled in the total
download configuration).
The memory used to store these parameter values does not degrade with use. It is not the same as the memory used
for storing the cold restart configuration download data.

Controller Considerations

205

Valid Module Types


Control modules and equipment modules support the restore parameter values feature.
Valid Parameters
The MCOMMAND and VERSION, module-level parameters support the restore parameter values feature. Userdefined, module-level parameters of the following types also support the restore parameter values feature:

Floating Point

Floating Point W/ Status

Boolean

Boolean W/Status

Discrete W/Status

8 bit signed int

16 bit signed int

32 bit signed int

8 bit unsigned int

16 bit unsigned int

32 bit unsigned int

32 bit unsigned int w/status

Named set (value only)

Mode

Internal Reference Parameters (this functions only when one parameter that supports the restore parameter
values feature directly references another parameter that also supports the feature.

To restore a value for a parameter that is not a user-defined, module-level parameter, you can set up an internal
reference for the parameter and designate that its value be restored on restart.
The following energy metering function blocks (AGA_SI and AGA_US) parameters support the restore feature
automatically:

206

CURR_VOLUME

CURR_ENERGY

CURR_HRS_ON

LAST_VOLUME

LAST_HRS_ON

LAST_ENERGY

VOL_ACCUM

PCT_CURR_VOLUME

PCT_CURR_ENERGY

PCT_LAST_VOLUME

PCT_LAST_ENERGY

PCT_CURR_HRS_ON

PCT_LAST_HRS_ON

PCT_VOL_ACCUM

System Configuration

CURR_VOLUME_GOOD

CURR_ENERGY_GOOD

CURR_HRS_ON_GOOD

VOL_ACCUM_GOOD

Enabling the Restore Parameter Value Feature


In order to enable the restore parameter values feature:
1

Check the Restore parameter value after restart checkbox in the user-defined parameter properties.

Check the Restore parameter values after restart checkbox on the module properties dialog.

Set the controller cold restart feature for the associated controller as described below.

Setting Controller Restart


You can set the restart feature on a controller basis. Not all controllers need to be enabled for a cold restart. In the
controller properties (viewed through the Explorer), use the Cold Restart Perform Within option under the Controller
tab to specify how you want the system to respond when power is restored to a controller. The Cold Restart Perform
Within time is the maximum power failure duration for which the system automatically downloads all lost data to the
controller prior to getting the controller running again. You can specify the time in a combination of days (0 through
30), hours (0 through 24), and minutes (0 through 60). A setting of 0 disables automatic restart. The power must
return within the time specified.
When power is restored before the time elapses, the controller goes into the COLDRESTART state. However, if the
specified time elapses before power is restored, the controller goes into the USERRESTART state. This state requires
you to download the controller node from the Explorer.
Note Set the Cold Restart Time to at least two minutes. In some cases, a time of one minute might not allow for
necessary network messaging to occur before the restart time elapses.

Note The loss of power to a controller and a subsequent cold restart or user restart can be disruptive to the process.
An uninterruptible power supply (UPS) is highly recommended as a means to prevent process disruption during a
short power loss. For example, if you specify 1 hour in the Controller Node properties box and the controller loses
power and regains power in an hour or less, the controller downloads itself using the configuration stored in
nonvolatile memory. However, if the controller regains power after 61 minutes or more, you must perform the
equivalent of a restart by downloading the controller node.

Controller Nonvolatile Memory


The local cold start database (controller nonvolatile memory) is written (that is, made usable) if a non-zero cold
restart time is specified (under controller properties) and one of the following operations is performed:

total download

selection of Download | Controller Cold Restart Memory from DeltaV Explorer

Controller Considerations

207

The local cold start database (controller nonvolatile memory) is cleared (that is, made unusable) by any of the
following operations:

controller upgrade

decommission/commission

partial download

upload

If the local database is unusable and a non-zero cold restart time is configured, the controller receives its download
scripts from the ProfessionalPLUS workstation cold start database in the event of a restart that occurs before the cold
restart time has elapsed.
The hardware used for storing the parameter values supports unlimited write cycles. However, the amount of space
allocated for the restore parameter values after restart feature is 390 kilobytes. Consider the following to avoid
exceeding the 390 kilobyte limit:

Each parameter configured with Restore parameter values after restart uses 8 bytes of controller NVM.

There is an additional overhead of 12 bytes for modules: a module with one parameter uses 20 bytes of
controller NVM.

Function blocks may introduce additional overhead.

To determine how much free NVM is available, check the controller's FreNVM parameter in DeltaV Diagnostics.

Cold Restart Versus User Restart


There are significant factors to consider when deciding to set your controller for a cold restart performed by the
system or a user restart.
Cold Restart
Since the cold restart is an automatic feature, it conveniently restarts a controller without any user intervention.
However, the cold restart configuration in nonvolatile memory will not contain online changes to parameter values
that have not been uploaded and then downloaded. To prevent loss of online changes, you can use the Restore
parameter value on restart feature (described above) in a limited way to preserve certain key values. In addition to
this, it is recommended that you regularly upload online changes to tuning parameters and then download to
Controller Cold Restart Memory in DeltaV Explorer to keep the controller cold restart memory current.
When you perform an upload, the system invalidates the configuration in nonvolatile memory and uses the
configuration in the workstation for any cold restarts until the nonvolatile memory is updated. Downloading to
controller cold restart memory updates the nonvolatile memory without affecting the working configuration in the
controller. To do this, you can either select the controller in the DeltaV Explorer and then right-click Download |
Controller Cold Restart Memory or click Download | Setup Data (if you have changed the Cold Restart Perform
Within option from zero to greater than zero).
User Restart
A user restart downloads the current database configuration. Also, the system informs the user of online changes to
the module prior to the power failure and allows the user to selectively upload these changes so that they may be
included in the download.

208

System Configuration

Restart Diagnostic Parameters


The controller supports the following diagnostic parameters related to power failure and restart. Unless otherwise
specified, they are available through the DeltaV Diagnostics application:

COLDRESTART is true if the node is in the cold restart state.

COLDSTRTSRC is the source from which the controller receives its download data during a cold restart.
The possible values are Controller (that is, controller nonvolatile memory), Workstation (that is,
ProfessionalPLUS download scripts), or Not Configured (if Cold Restart Perform Within is equal to zero).

USERRESTART is true if the node is in the user restart state.

LASTPFDUR is the duration of the last power failure experienced in seconds.

PFCOUNT is the count of power failures since being commissioned or reset.

SECSLASTPF is the number of seconds since restarting from the last power failure.

FRENVM (Free Non-volatile Memory) is the amount of memory (in bytes) that can be allocated to
parameters for which the user has checked the Restore parameter value after restart feature.

COLD RESTART DATA SIZE is the size of the local configuration (that is, the configuration stored in
nonvolatile controller memory). This parameter is only available through the controller maintenance port.

COLD RESTART SPACE REMAINING is the free nonvolatile memory space. This parameter is only
available through the controller maintenance port.

Controller Considerations

209

I/O Configuration
The DeltaV I/O subsystem supports multiple types of I/O cards, including analog and discrete input and output cards,
HART output and input cards, serial cards, the H1 Fieldbus card, AS-Interface card, Profibus DP card, RTD, ohms,
Thermocouple, mV, Multifunction, and the SOE (Sequence of Events) card. The I/O subsystem consists of a terminal
block that snaps onto the carrier to provide screw termination for field wiring and the actual I/O card that snaps over
the terminal block and onto the carrier. The I/O card converts field signals to the appropriate format for control and
communications.

I/O Card and Channel Types


To specify the location and type of channel associated with the field measurement, you configure the channel or port
type and the Device Signal Tag (DST) of the IO_IN or IO_OUT parameter. The following channel types are
available.
Channel Types for I/O Cards
I/O Card

Channel or
Port Types

Description

Function Block Use

Analog Input
Card

Analog Input
Channel

Reports the analog value


present at the channel.

Used with AI and PID function blocks as


input I/O references. Used with AO and PID
function blocks as readback references to
read a 4 to 20 mA signal.

HART Analog
Input Channel

Reports the analog value


present at the channel
and up to four digital
values from a HART
field device.

Used with AI and PID function blocks as


input I/O references. Used with AI and PID
function blocks as readback references to
read a 4 to 20 mA signal.

RS232 port
RS422/485 half
duplex port
RS422/485 full
duplex port

Reports the serial value


present at the port.
Protocol can be RTU or
ASCII. Baud rate options
range from 300 to
115,200.

Used with AI and PID function blocks as


input I/O references.

Serial Card

210

System Configuration

I/O Card

Channel or
Port Types

Description

Function Block Use

Analog Output
Card

Analog Output
Channel

Drives the output to an


analog value written by
the controller and holds
the output at that value.

Used with AO and PID function blocks as


output I/O references when driving a 4 to 20
mA signal.

HART Analog
Output Channel

Drives the output to an


analog value written by
the controller and holds
the output at that value.
This channel type also
sends HART commands
to gather as many as
eight dynamic variables
and four device variables
from a HART field
device.

Used with the AO function block as output I/


O references. Used with AO and Alarm
Detection function blocks as readback
references to read dynamic and device
variables.
The 8 dynamic variables are used in AI
function blocks.

Discrete Input
Channel

Reports the discrete


value present at the
channel.

Used with DI and Device Control function


blocks as input I/O references when reading a
discrete (On/Off) signal. Used with DO
function blocks as a readback I/O reference
for a discrete signal.

Pulse Count Input


Channel

Reports the number of


discrete pulses detected
at the channel. For preSeries 2 cards, maximum
input frequency for
pulses is 125 Hz. For
Series 2 cards, maximum
input frequency for
pulses is 75 Hz.

Used with AI and PID function blocks as


input I/O references to read a pulse count.

Discrete Input
Card

I/O Configuration

211

I/O Card

Channel or
Port Types

Description

Function Block Use

Discrete
Output Card

Discrete Output
Channel

Drives the output to a


discrete value written by
the controller and holds
the output at that value.
Outputs immediately
reflect the output value
that was received. Upon
receiving a configuration
that indicates a change
from one type of output
to another, the outputs
switch to the off state.

Used with DO and Device Control function


blocks as output I/O references when driving
as discrete signal.

Momentary
Output Channel

Produces a momentary
pulse by driving the
output active for a
specified time period
each time the controller
writes a value of TRUE
(1, On). Upon receiving a
new pulse value, the
existing pulse is allowed
to terminate normally
before the new value is
written. Upon receiving a
configuration that
indicates a change from
one type of output to
another, the outputs
switch to the off state.

Used with DO and Device Control function


blocks as output I/O references to output a
fixed-duration pulse whenever the block
writes a TRUE (1) value to the channel.

Continuous Pulse
Output Channel

Produces a continuous
pulse by driving the
output active for a
percentage of a specified
time period. Upon
receiving a new
continuous pulse value,
the existing pulse is
allowed to terminate
normally before the new
value is written. Upon
receiving a configuration
that indicates a change
from one type of output
to another, the outputs
switch to the off state.

Used with AO and PID function blocks as


output I/O references when driving an
actuator requiring discrete pulse input.

212

System Configuration

I/O Card

Channel or
Port Types

Description

Function Block Use

Isolated Input
Card

Thermocouple

Reports the temperature


of the thermocouple and
is Cold Junction
Compensated.

Used with AI function blocks as input I/O


references.

Uncharacterized
thermocouple

Reports the absolute


value of the voltage at
the screw terminals, and
that voltage is
uncompensated for the
local cold junction
temperature.

Used with AI function blocks as input I/O


references.

RTD, ohms

Reports the temperature


of the RTD bulb.

Used with AI function blocks as input I/O


references.

Resistance

Reports the ohms of the


measured element.

Used with AI function blocks as input I/O


references.

mV

Reports the value of the


millivolts at the screw
terminals.

Used with AI function blocks as input I/O


references.

Voltage

Reports the value of the


voltage at the screw
terminals.

Used with AI function blocks as input I/O


references.

RTD Channel

Reports the temperature


of the RTD bulb.

Used with AI function blocks as input I/O


references.

Resistance
Channel

Reports the ohms of the


measured element.

Used with AI function blocks as input I/O


references.

User

Reports the temperature


of the RTD bulb.

Used with AI function blocks as input I/O


references.

Discrete Input
Channel

Reports the discrete


value present at the
channel.

Used with DI and Device Control function


blocks as input I/O references when reading a
discrete (On/Off) signal. Used with DO
function blocks as a readback I/O reference
for a discrete signal.

SOE Discrete
Input Channel

Reports the discrete


value present at the
channel and captures up
to 32 process-upset
events per card and sends
the events to a specified
workstation.

Used with DI and Device Control function


blocks as input I/O references when reading a
discrete (On/Off) signal. Used with DO
function blocks as a readback I/O reference
for a discrete signal.

RTD, ohms
Card

SOE Card
(Sequence of
Events)

I/O Configuration

213

I/O Card

Channel or
Port Types

Description

Function Block Use

Thermocouple,
mV* Card

Thermocouple

Reports the temperature


of the thermocouple and
is cold junction
compensated. This card
does not support open
loop detection.

Used with AI function blocks as input I/O


references.

Uncharacterized
Thermocouple

Reports the absolute


value of the voltage at
the screw terminals, and
that voltage is
uncompensated for
temperature (for
example, mV input).

Used with AI function blocks as input I/O


references.

DI or Pulse Input
(PIN) Channel

Reports the number of


discrete pulses or peaks
of a sine wave detected at
the channel. Maximum
input frequency is
50KHz.

Used with the Pulse Input function block to


read the FREQUENCY parameter of a DST
from a pulse input channel.

DI or Pulse Input
(PIN) Channel for
pulse input gating

Channel 1 can be used as


an external trigger to
enable or disable the
capture of pulses on
channels 2, 3, and 4. To
enable the capture of
pulses, use DeltaV
Explorer to set the
ENABLE_PI_GATING
card-level parameter to
True. Define channel 1 as
DI and channels 2, 3 and
4 as PI. The card status
will be Bad if
ENABLE_PI_GATING
is True, but the channels
are not defined correctly.

Used with the Pulse Input function block to


read the FREQUENCY parameter of a DST
from a pulse input channel.

Multifunction
Card

214

System Configuration

I/O Card

Channel or
Port Types

Description

Function Block Use

AS-Interface
Card

2 ports

Each port functions as an


AS-Interface master. The
AS-Interface master
controls communications
on the network by
polling the slave devices,
issuing commands, and
receiving and processing
replies from the slave
devices. Supports autosensing and autoaddressing of devices.

Same as Discrete Input, and Discrete Output


cards.

H1 Fieldbus

2 ports

Functions as the Link


Active Scheduler (LAS)
and manages the
transmission of messages
across a fieldbus
segment. Each port
connects to one fieldbus
segment. Up to 16
devices are supported for
each segment.

Supports up to 64 Foundation Fieldbus


function blocks.

DeviceNet

one port

Supports polled
communication as the
DeviceNet master and
acts as the interface
between the DeviceNet
network and the DeltaV
system. Supports up to
61 slave devices and
supports the online
addition of devices.

Same as Analog Input, Analog Output,


Discrete Input, and Discrete Output cards.

Profibus DP

one port

Functions as the Profibus


DP master and acts as the
interface between the
Profibus DP network and
the DeltaV system.
Supports up to 64 slave
devices and supports the
online addition of
devices.

Same as Analog Input, Analog Output,


Discrete Input, and Discrete Output cards.

* Note When the Thermocouple, mV card is plugged into a Thermocouple terminal block, it functions as a
Thermocouple card. When it plugs into an I/O terminal block, it functions as an mV card.

I/O Configuration

215

Card Parameters
The properties associated with I/O cards are described by card parameters. These values give you information about
the I/O card; they are not configurable. The following are the card parameters displayed in the DeltaV Diagnostics:
EXIST - Boolean value that shows if a card is physically present at the given path (TRUE = card is present, False =
card is not present).
HWREV - Text string containing the hardware revision level of the card at the given path. The card reports a zero if
it does not support hardware revision reporting.
MODEL - Text description of the card model at the given path.
OINTEG - Represents the overall integrity of the card (0 = Good, 1 = Bad).
SNUM - Text string containing the serial number of the card at the given path. The card reports a zero if it does not
support a serial number.
STATUS - Text description of the current condition of the card.
The conditions are analyzed in the following order and if any of them exist, the appropriate integrity is determined
and the appropriate status is displayed. If none of the below conditions exist, then the integrity is set to 0, and the
status is set to Good.
Condition

Status

OINTEG
Value

No card in slot - unconfigured

No Card

No card in slot - configured

No Card

Card Status - No Communications

No Card

Card Status - Failstate

Bad - Failstate Active

Card Status - Hardware Error

Bad - Hardware Error

Card Status - Configuration Error

Bad - Configuration Error

Card Status - 5% Communications Error

5% Comm Error Rate with Card

Card Status - Not Configured

Good - No Installed Config

Any Channel Integrity Bad

Good

SWREV - Text string containing the software revision level of the card at the given path.

Channel Parameters
The properties associated with the I/O channel types are described by channel parameters. You modify the channel
parameters through DeltaV Explorer. All channels have the following non-configurable parameters:
OINTEG - Represents the overall integrity of the channel (0 = Good, 1 = Bad).
STATUS - Text description of the current condition of the channel.

216

System Configuration

ST_REV - Incremented each time a configuration parameter is modified.


The following channel parameters are available:
Channel Parameters
Channel Type

Channel Parameter

Can
Configure?

Description

Analog Input
Channel

FIELD_VAL_PCT

No

The last value reported by the card (in


percent of range) and the current status of the
channel.

FILTER

Yes

Controls the filtering performed on the I/O


card. You should consider the execution rate
of the control modules using the channel
when you configure FILTER.

NAMUR_ENA

Yes

Controls whether NAMUR alarming is


performed on the channel. If enabled and if
the transmitter supports it, an analog value
that is outside the NAMUR limits (106.25%
and -2.5%) for four seconds has its status
marked as Bad: Sensor Failure.

OVERRANGE_PCT

Yes

The percent value at which the analog value


is considered overrange. If the signal is above
this limit, the status of the parameter
associated with this channel is HighLimited.

UNDERRANGE_PCT

Yes

The percent value at which the analog value


is considered underrange. If the signal is
below this limit, the status of the parameter
associated with this channel is LowLimited.

HART_FIELD_VAL

No

The 4 to 20 mA signal of the HART


transmitter, scaled in the range and
engineering units of XD_SCALE or
OUT_SCALE, depending on L_TYPE.
HART status is applied.

FIELD_VAL_PCT

No

The 4 to 20 mA signal of the HART


transmitter, in percent of range. HART status
is not applied.

HART Analog
Input Channel:
Analog Process
Values

I/O Configuration

217

Channel Type

Channel Parameter

Can
Configure?

Description

HART Dynamic
Variables

HART_PV

No

The Primary Variable returned by the HART


transmitter, in engineering units. This value is
read digitally.

HART_SV

No

The Secondary Variable returned by the


HART transmitter, in engineering units. This
value is read digitally.

HART_TV

No

The Tertiary Variable returned by the HART


transmitter, in engineering units. This value is
read digitally.

HART_FV

No

The 4th Variable returned by the HART


transmitter, in engineering units. This value is
read digitally.

NO_COMM

No

Set to True (1) if digital communication with


the HART instrument has stopped or was
never started. If digital communication is
successful, this parameter is set to False (0)
immediately.

HART Analog
Input Channel:
System Status
Values

218

System Configuration

Channel Type

Channel Parameter

Can
Configure?

Description

HART Analog
Input Channel:

DEV_MALFUNC

No

Set and cleared by tracking Field Device


Malfunction (HART status bit #7) from the
HART instrument. If the HART instrument
detects a malfunction within itself, this
parameter is set to True (1).

DEV_CFG_MISMATCH

No

Indicates if the physically installed device


does not match the configured device.

MORE_STATUS

No

Set and cleared by tracking More Status


Available (HART status bit #4) from a HART
instrument. This indicates that there are
additional details that the devices can return.
If this is set use AMS Device Manager or
HART hand-held device to get additional
information.

NPV_PAST_LIM

No

Set and cleared by tracking the Non-Primary


Variable Out of Limits (HART status bit #1)
from a HART instrument. If one of the
measured non-primary variables is outside its
sensor operating limits (high or low), this
parameter is set to True (1).

PV_FIXED

No

Set and cleared by tracking the Process


Variable Analog Output Fixed (HART status
bit #3) from a HART instrument. If the
HART device analog output value is fixed to
a requested value, this parameter is set to
True (1).

PV_PAST_LIM

No

Set and cleared by tracking the Primary


Variable Out of Limits (HART status bit #0)
from a HART instrument. If the measured
primary variable is outside the sensor
operating limits (high or low), this parameter
is set to True (1).

PV_SAT

No

Set and cleared by tracking the Primary


Variable Analog Output Saturated status from
a HART instrument. If the analog output
from the HART device is out of range (high
or low), this parameter is set to True (1).

HART Field
Device Status
Values

I/O Configuration

219

Channel Type

Channel Parameter

Can
Configure?

Description

HART Analog
Input Channel:
Other Values

FILTER

Yes

Controls the filtering performed on the I/O


card. You should consider the execution rate
of the control modules using the channel
when you configure FILTER.

HART_ERRORS

Yes

Selects which HART status error values are


ignored. This parameter acts as a mask to
hide HART status error notifications that you
select as unimportant to your operation.

NAMUR_ENA

Yes

Controls whether NAMUR alarming is


performed on the channel. If enabled and if
the transmitter supports it, an analog value
that is outside the NAMUR limits (106.25%
and -2.5%) for four seconds has its status
marked as Bad: Sensor Failure.

OVERRANGE_PCT

Yes

The percent value at which the analog value


is considered overrange. If the signal is above
this limit, the status of the parameter
associated with this channel is HighLimited.

UNDERRANGE_PCT

Yes

The percent value at which the analog value


is considered underrange. If the signal is
below this limit, the status of the parameter
associated with this channel is LowLimited.

HINTEG

No

For HART analog input and output channels,


HINTEG indicates that a HART error is
present (0=Good, 1=Bad) even if
HART_ERRORS is configured to ignore the
error. When HART_ERRORS is configured
to ignore one or more HART errors, a
corresponding active HART error does not
contribute to Bad OINTEG on the channel;
however, it does contribute to Bad HINTEG
on the channel. HINTEG is always Bad when
OINTEG is Bad.

220

System Configuration

Channel Type

Channel Parameter

Can
Configure?

Description

Analog Output
Channel

FAIL_ACTION_MODE

Yes

Controls the behavior of the channel when


the card goes into failure action condition due
to lost communication with the controller.
You can configure the channel to hold the
value at the start of the failure action
condition (select Hold last value) or to go to
the failure action value
(FAIL_ACTION_VAL).

FAIL_ACTION_VAL

Yes

The value the channel transitions to when the


card goes into failure action condition, in
percent. This value is used only if
FAIL_ACTION_MODE is configured to set
the value to FAIL_ACTION_VAL.

INIT_VAL

Yes

The value the channel goes to upon initial


download before any function block action,
in percent.

OUT

No

The current value driven to the card, in


percent, and the fieldbus status of the output
channel.

HART_PV

No

The primary variable returned by the HART


transmitter, in engineering units. This value is
read digitally.

HART_SV

No

The secondary variable returned by the


HART transmitter, in engineering units. This
value is read digitally.

HART_TV

No

The tertiary variable returned by the HART


transmitter, in engineering units. This value is
read digitally.

HART_FV

No

The fourth variable returned by the HART


transmitter, in engineering units. This value is
read digitally.

HART Analog
Output Channel:
Dynamic Variables

I/O Configuration

221

Channel Type

Channel Parameter

Can
Configure?

Description

HART Analog
Output Channel:
Device Variables*

HART_DV_SLOT0

No

The slot 0 device variable value. This value is


read digitally.

HART_DV_SLOT1

No

The slot 1 device variable value. This value is


read digitally.

HART_DV_SLOT2

No

The slot 2 device variable value. This value is


read digitally.

HART_DV_SLOT3

No

The slot 3 device variable value. This value is


read digitally.

DV_SLOT_CONFIG

Yes

The mask that determines which slot codes


are enabled.

DV_SLOT0_CODE

Yes

The slot 0 device variable code sent digitally


from the AO card.

DV_SLOT1_CODE

Yes

The slot 1 device variable code sent digitally


from the AO card.

DV_SLOT2_CODE

Yes

The slot 2 device variable code sent digitally


from the AO card.

DV_SLOT3_CODE

Yes

The slot 3 device variable code sent digitally


from the AO card.

NO_COMM

No

Set to True (1) if digital communication with


the HART instrument has stopped or was
never started. If digital communication is
successful, this parameter is set to False (0)
immediately.

HART Analog
Output Channel:
System Status
Values

222

System Configuration

Channel Type

Channel Parameter

Can
Configure?

Description

HART Field
Device Status
Values

DEV_MALFUNC

No

Set and cleared by tracking Field Device


Malfunction (HART status bit #7) from the
HART instrument. If the HART instrument
detects a malfunction within itself, this
parameter is set to True (1).

NPV_PAST_LIM

No

Set and cleared by tracking the Non-Primary


Variable Out of Limits (HART status bit #1)
from a HART instrument. If one of the
measured non-primary variables is outside its
sensor operating limits (high or low), this
parameter is set to True (1).

PV_FIXED

No

Set and cleared by tracking the Process


Variable Analog Output Fixed (HART status
bit #3) from a HART instrument. If the
HART device analog output value is fixed to
a requested value, this parameter is set to
True (1).

PV_PAST_LIM

No

Set and cleared by tracking the Primary


Variable Out of Limits (HART status bit #0)
from a HART instrument. If the measured
primary variable is outside the sensor
operating limits (high or low), this parameter
is set to True (1).

PV_SAT

No

Set and cleared by tracking the Primary


Variable Analog Output Saturated status from
a HART instrument. If the analog output
from the HART device is out of range (high
or low), this parameter is set to True (1).

I/O Configuration

223

Channel Type

Channel Parameter

Can
Configure?

Description

HART Analog
Output Channel:
Other Values

HART_ERRORS

Yes

Selects which HART status error values are


ignored. This parameter acts as a mask to
hide HART status error notifications that you
select as unimportant to your operation.

FAIL_ACTION_MODE

Yes

Controls the behavior of the channel when


the card goes into failure action condition due
to lost communication with the controller.
You can configure the channel to hold the
value at the start of the failure action
condition (select Hold last value) or to go to
the failure action value
(FAIL_ACTION_VAL).

FAIL_ACTION_VAL

Yes

The value the channel transitions to when the


card goes into failure action condition, in
percent. This value is used only if
FAIL_ACTION_MODE is configured to set
the value to FAIL_ACTION_VAL.

INIT_VAL

Yes

The value the channel goes to upon initial


download before any function block action,
in percent.

OUT

No

The current value driven to the card, in


percent, and the Fieldbus status of the output
channel.

HINTEG

No

For HART analog input and output channels,


HINTEG indicates that a HART error is
present (0=Good, 1=Bad) even if
HART_ERRORS is configured to ignore the
error. When HART_ERRORS is configured
to ignore one or more HART errors, a
corresponding active HART error does not
contribute to Bad OINTEG on the channel;
however, it does contribute to Bad HINTEG
on the channel. HINTEG is always Bad when
OINTEG is Bad.

224

System Configuration

Channel Type

Channel Parameter

Can
Configure?

Description

Discrete Input
Channel

FIELD_VAL_D

No

The last Boolean value reported by the card


and the current status of the channel.

FILTER

Yes

Use the filter to eliminate false detection of


events in the presence of noise or contact
bounce from the source. Set FILTER to
None, Fast, or Slow.
NONE: Use NONE when the source for the
channel is bounceless and noise will not be
coupled into the signal wiring because of the
proximity of the source and/or the routing of
the wiring. Bounceless sources are typically
solid state, not mechanical, contacts. If the
response time is not critical, it may be more
appropriate to use one of the other choices.
FAST: Use FAST when the source is a
mechanical contact with relatively quick
settling time (generally small relay contacts
or snap switches). This setting should remove
most noise coupled into the signal wiring.
The response is slower than the NONE
setting and faster than the SLOW setting.
SLOW: Use SLOW when response time is
not critical, in electrically noisy
environments, or when interfacing to large
mechanical relay contacts. The response is
very slow in comparison to the other two
options.
The filter behaves like a low-pass filter
driving an input. The break frequency is 5 Hz
for FAST and 0.43 Hz for SLOW. This
should eliminate changes of state due to noise
or contact bounce.

LINEFAULT_DETECT

Yes

Enables the card to detect open and short


circuit, if a user has added external resistors
to the wiring.

COUNTER_IN

No

The last counter value reported by the card


and the status of the channel. At 65535, the
counter rolls to zero.

LINEFAULT_DETECT

Yes

Enables the card to detect open and short


circuit, if a user has added external resistors
to the wiring.

Pulse Count Input


Channel

I/O Configuration

225

Channel Type

Channel Parameter

Can
Configure?

Description

Pulse Input
Channel

COUNTER_IN

No

Tracks the number of pulses on this channel.


The parameter value rolls over to zero when
the counter reaches its limit.

FILTER

Yes

Controls the filtering performed on the I/O


card. The value you select depends on the
frequency range of the signal, the desired
response time, and the desired accuracy. If
the channel is operating in the high end of the
specified frequency range of the card, you
can configure relatively small filters and still
meet the card's accuracy specification. If the
channel is operating in the low end of the
card's frequency range, then larger filters are
required to meet the accuracy specification.
The larger filters have better accuracy but
slower response time. Smaller filters have
quicker response time but can lose some
accuracy.

FREQUENCY

No

Pulse frequency input.

RESET_COUNT

Yes

Resets the counter to zero when a value of


one is written to the parameter.

FAIL_ACTION_MODE

Yes

Controls the behavior of the channel when


the card goes into failure action condition due
to lost communication with the controller.
You can configure the channel to hold the
value at the start of the failure action
condition (select Hold last value) or to go to
the failure action value
(FAIL_ACTION_VAL).

FAIL_ACTION_VAL

Yes

The Boolean value the channel transitions to


when the card goes into failure action
condition. This value is used only if
FAIL_ACTION_MODE is configured to set
the value to FAIL_ACTION_VAL.

INIT_VAL

Yes

The Boolean value the channel goes to upon


initial download before any function block
action. The initial value is configurable; the
default value is zero.

LINEFAULT_DETECT

Yes

Enables the card to detect open and short


circuit, if a user has added external resistors
to the wiring.

OUT_D

No

The current Boolean value driven to the card


and the status of the output channel.

Discrete Output
Channel

226

System Configuration

Channel Type

Channel Parameter

Can
Configure?

Description

Continuous Pulse
Output Channel

FAIL_ACTION_MODE

Yes

Controls the behavior of the channel when


the card goes into failure action condition due
to lost communication with the controller.
You can configure the channel to continue to
output the current pulse at the start of the
failure action condition (select Hold last
value) or to go to the failure action value
(FAIL_ACTION_VAL).

FAIL_ACTION_VAL

Yes

The Boolean value the channel transitions to


when the card goes into failure action
condition. This value is used only if
FAIL_ACTION_MODE is configured to set
the value to FAIL_ACTION_VAL.

INIT_ON_TIME

Yes

The percentage of the PULSE_PERIOD the


channel is on during initial download before
any function block action. You set
INIT_ON_TIME to zero for no pulse.

LINEFAULT_DETECT

Yes

Enables the card to detect open and short


circuit, if a user has added external resistors
to the wiring.

ON_TIME

No

The current percentage of the


PULSE_PERIOD the channel drives its
output TRUE (1, On) and the status of the
channel.

PULSE_PERIOD

Yes

The length of time between pulses of the


channel, from 0.1 to 100 seconds. The
module should execute at some multiple of
the PULSE_PERIOD.

I/O Configuration

227

Channel Type

Channel Parameter

Can
Configure?

Description

Momentary Output
Channel

FAIL_ACTION_MODE

Yes

Controls the behavior of the channel when


the card goes into failure action condition due
to lost communication with the controller.
You can configure the channel to complete
the current pulse at the start of the failure
action condition (select Hold last value) or to
go to the failure action value
(FAIL_ACTION_VAL).

FAIL_ACTION_VAL

Yes

The Boolean value the channel transitions to


when the card goes into failure action
condition. This value is used only if
FAIL_ACTION_MODE is configured to set
the value to FAIL_ACTION_VAL.

LINEFAULT_DETECT

Yes

Enables the card to detect open and short


circuit, if a user has added external resistors
to the wiring.

OUT_D

No

Controls the pulse for the channel. The


channel outputs a pulse of specified duration
each time OUT_D is one. OUT_D also
includes the current status of the channel.
Note that when the channel is configured as
momentary external references and function
blocks always interpret OUT_D as zero.

FIELD_VAL

No

The value of the sensor or analog signal


scaled in the range and engineering units of
XD_SCALE or OUT_SCALE, depending
upon L_TYPE.

FIELD_VAL_PCT

No

The last value reported by the card (in


percent of range) and the current status of the
channel.

FILTER

Yes

Controls the filtering performed on the I/O


card. You should consider the execution rate
of the control modules using the channel
when you configure FILTER.

OVERRANGE_PCT

Yes

The percent value at which the analog value


is considered overrange. If the signal is above
this limit, the status of the parameter
associated with this channel is HighLimited.

UNDERRANGE_PCT

Yes

The percent value at which the analog value


is considered underrange. If the signal is
below this limit, the status of the parameter
associated with this channel is LowLimited.

All RTD,
Thermocouple,
Voltage, and mV
Channel Types

228

System Configuration

Channel Type

Channel Parameter

Can
Configure?

Description

RTD Channel
Types Only

COMPENSATION

Yes

Resistance in ohms of the length of the


wire(s) for 2-wire RTD.
Although this parameter is available for 3 and
4 wire RTD channels, it is only useful in 2wire RTD channel type configurations.

NUM_WIRES

Yes

Number of wires in the RTD sensor

CHATTER_CONTROL

Yes

Controls whether chatter control is enabled or


disabled. When CHATTER_CONTROL is
enabled, the card stops reporting events that
occur repeatedly at intervals less than 100
milliseconds and DeltaV Diagnostics reports
a status of CHATTERING for the channel.

FIELD_VAL_D

No

The last Boolean value reported by the card


and the current status of the channel.

FULLSCALE

Yes

Maximum temperature.

ALPHA

Yes

RTD sensor alpha coefficient.

DELTA

Yes

RTD sensor delta coefficient.

ZERO

Yes

RTD resistance in ohms at 0 degrees Celsius

SOE Discrete Input


Channel

User-defined RTD
Channel Type

* When using the DV_SLOT variables to read the instrument mode from a HART output device, the DeltaV
system treats these values as floating point values. Therefore, the DV_SLOT variable associated with the
instrument mode contains the following values for instrument mode:
Out of service = 0
In service = 1.4013E-045
When using an AI function block to reference these values, the scale of the block must be set appropriately to
prevent seeing a 0 value for both instrument modes.
The DeltaV system also treats the control mode read from the HART output device as a floating point value. Each
HART output device has its own definition for control mode. Following are the DV_SLOT values that correspond
to the possible control mode integer values:
0 (Test) = 0
1 = 1.4013E-045
2 (Digital) = 2.8026E-045
3 (Analog RSP) = 4.2039E-045
When using an AI function block to reference these values, the scale of the block must be set appropriately to
handle these values.

I/O Configuration

229

DeltaV Redundant I/O


The following DeltaV Series 2 I/O cards support redundancy. (Follow the links for specifications and wiring
diagrams.)

DI, 8-Channel, 24 VDC, Dry Contact

DO, 8-Channel, 24 VDC, High-Side

AO, 4-20 mA with HART

AI, 4-20 mA with HART

Serial

Fieldbus H1

Series 2, redundant capable cards are configured, auto-sensed, upgraded, and operated just like the Series 1 cards.
Series 2 simplex cards can function as drop-in replacements for Series 1 simplex cards of the same type. With the
exception of the Series 2 simplex H1 card, which requires the Series 2 H1 terminal block, no wiring change is
required to replace a Series 1 card. Series 2 cards report their operating mode (simplex or redundant) to the DeltaV
controller based on the type of terminal block on which they are installed. New redundant terminal blocks provide
wiring terminations for the redundant cards. If a card is installed on a redundant terminal block, it reports itself as
operating in redundant mode; otherwise, it reports itself as operating in simplex mode. If all cards are redundant, the
controller can support up to 32 redundant pairs.
Refer to Example Switchover Situations for some scenarios that are intended to help you to know when a switchover
has occurred and to diagnose and solve the problems that caused the switchover.

Important Considerations for Using Redundant I/O Cards


Rules You Must Follow

The lower slot number in a redundant pair must be an odd number, and the upper slot number must be the
next higher even number. For example, you can install redundant pairs in slots 1 and 2, 3 and 4, and 9 and
10. You cannot install redundant pairs in slots 6 and 7 or 24 and 25. In this example from DeltaV Explorer,
the redundant pair, C07, occupies slots 7 and 8. Notice that the next available slot, C06, was not used; this is
because the lower slot number in a redundant pair must be odd.

Redundant Terminal Blocks

230

Other than redundant terminal blocks, no additional software or hardware is required to support redundancy.
A redundant terminal block spans two adjacent slots on the I/O carrier. A redundant I/O card consists of two
Series 2 cards installed in a redundant terminal block. Both cards access the same set of channels in the
terminal block.

System Configuration

The double-wide redundant terminal blocks require only a single set of wires for each redundant channel or
fieldbus segment. (The exception is the Redundant Interface terminal block that uses two sets of wires for
the Series 2 Serial card. One set of wires is for each interface, such as a computer.) The redundant terminal
blocks contain screw terminals appropriate for the card type, and signals from the screw terminals are
connected to both cards in a redundant pair.

Line Fault Detection

The Series 2 DI, 8-Channel, 24 VDC, Dry Contact and the Series 2 DO, 8-Channel, 24 VDC, High-Side
cards support line fault detection. (For DI cards, modify the wiring to include a series and parallel resistor at
the sensor.) This capability can be enabled or disabled by configuration changes.

After resolving line fault errors, use the Clear Saved Fault Information command in DeltaV Diagnostics to
re-enable switchovers if the same problems are detected again. Refer to the information on clearing saved
fault information in the Identifying and Troubleshooting Series 2 Redundant Cards topic for more
information.

Manual Switchovers

Always use the DeltaV Diagnostics program to perform a manual switchover. Removing the active card in a
redundant pair can cause a disruption in the output signal. To perform a switchover in Diagnostics, select the
card, click the right mouse button, and select Redundancy Switchover.

Installing and Connecting Redundant Terminal Blocks and Series 2


Cards
The DeltaV system supports the following redundant terminal blocks. (Follow the links for specifications and
channel and port assignments.)

Redundant Analog Input

Redundant Analog Output

Redundant Discrete

Redundant H1

Redundant Interface

To install a redundant terminal block


1

Make sure that 24 VDC field power is provided to the carrier.

Check the key settings on the corresponding Series 2 cards and set the keys on the terminal block to match. Refer
to I/O Interface Keying for information on key settings.

Locate the assigned slot location on the I/O interface carrier. Remember that the lower slot number must be odd,
and the upper slot number must be the next higher even number. Place the tabs on the back of the redundant
terminal block through the slots on the carrier and push the terminal block up to lock it into place.

Connect the field wiring for the redundant terminal blocks. as shown in the Series 2 card wiring diagrams and
redundant terminal block figures. Click the above links for terminal block port and channel assignment and click
the links in Redundant I/O Cards for wiring diagrams for the Series 2 cards in redundant mode.

To install a redundant I/O card


A redundant I/O card consists of two Series 2 cards installed in a redundant terminal block.
1

Make sure that 24 VDC field power is provided to the carrier.

Locate the assigned slots on the I/O interface carrier.

I/O Configuration

231

Align the connectors on the Series 2 card with the connectors on the I/O carrier and the redundant I/O terminal
block and push to attach.

Tighten the mounting screws.

Switchover Causes
The DeltaV controller constantly scans both the active and standby cards and directs a switchover from the active to
the standby card when a failure occurs. Switchover is very smooth and occurs in a matter of milliseconds. The last
known good values of the output are held during switchover. A redundancy switchover can occur under the following
circumstances:

Open and short circuit faults in the channels during installation or operation

Card errors due to external noise near the system or noise on the carriers, cards, or channels

Improper grounding that might cause some channels to draw huge currents and high voltages

Momentary loss of field power

Fatal condition on the active card (for example, the active card cannot communicate with the controller)

Non-fatal condition on the active card. These conditions are dependent upon the card type (for example, a
failure of the A/D converter on an AI card)

Refer to Example Switchover Situations for some scenarios that are intended to help you identify when a switchover
has occurred and diagnose and solve the problems that caused the switchover.

I/O Redundancy, Parameters and DSTs


To the DeltaV system, a redundant pair is one logical redundant card. In parameter paths and Device Signal Tags
(DSTs), the DeltaV system references the pair as a single item composed of two cards. The DeltaV system uses the
standard I/O prefix, Cxx, to access information about the pair where xx is the lower (odd) slot number occupied by
the pair. For example, the DeltaV system references redundant cards in slots 1 and 2 as C01 in paths and in default,
DST names. Use the Cxx prefix (such as C01) in a path to access information about the pair of cards. For example, to
return overall status information about a redundant pair in slots 1 and 2 on controller CTLR-1A, use the path: CTLR1A/IO1/CO1/STATUS.
DSTs are associated only with the pair, not with an individual card within the pair. For example, an AI block would
use the following path to reference a value from a redundant pair in slots 1 and 2: C01/CH01/FIELD_VAL_PCT.
Similarly, configuration parameters for cards, ports, and channels reference the pair. There is no configuration for a
specific card in the pair. To access the value for the FILTER parameter for channel 1 of a redundant pair in slots 1 and
2, use the following path:C01/CH01/FILTER.
However, some diagnostic parameters permit access to an individual card within the pair. The path to these
parameters consists of the path identifier for the pair, such as C01, plus the physical card to be accessed. For example,
to read the overall integrity of the standby card, use the path: CTLR/IO1/C01/STBY_OINTEG.
To determine which slot contains the active and standby cards, use the paths: CTLR/IO1/C01/ACT_SLOT and
CTLR/IO1/C01/STBY_SLOT.

232

System Configuration

Auto-Sensing and Configuring Series 2 Cards


Inside this topic
The Enable Auto Switchback Parameter
Like existing I/O cards, you can add Series 2 cards to the database by auto-sensing redundant pairs already present on
the control network and configuring redundant pairs offline.
Auto-Sensing Series 2 I/O
The auto-sense command returns information about any redundant pairs present on the control network. If you autosense a Series 2 card that is connected to a redundant terminal block, the card reports itself as operating in redundant
mode. If you auto-sense a Series 2 card that is installed on a simplex terminal block or not installed on a terminal
block, the card reports itself as operating in simplex mode. A card's redundancy status is known even if its redundant
partner is not present at the time of auto-sensing because the card detects that it is connected to a redundant terminal
block. In the case of a missing redundant partner, the Auto-Sense Cards dialog indicates a redundant pair and states
that a card is not installed. In this example, the Auto-Sense Cards dialog shows that the card in slot 10 is not installed.

Note The Auto-Sense Cards dialog presents information about installation errors in red text and informational
messages in blue text. However, auto-sense cannot always detect an incorrectly installed terminal block when at least
one of the cards is in the correct slot. (For example, auto-sense will not detect a problem if a terminal block is
incorrectly installed in slots 3 and 4 and a card exists in slot 3 but no cards are in slots 2 and 4.) For this reason, it is
recommended that you verify your installation with DeltaV Diagnostics.
Configuring Series 2 Cards Offline
Adding and configuring Series 2 I/O offline in the DeltaV Explorer is performed in much the same way as pre-Series
2 I/O. The Add Card dialog box includes a Card class selection field (such as the Discrete Input class of cards), a
Card type field (such as 24 VDC, Dry Contact), and a Card series field (Series 1 or Series 2 if Series 2 is supported by
the card class and type). Click the down arrows to expand the list boxes and make your selections for card class, type,
and series.

I/O Configuration

233

Change Card Series Without Replacing Card


A useful feature of this dialog is the ability to change the card series without first deleting the card from your
configuration and re-entering all the card information. As long as the original card class and type support Series 2
cards, you can change from Series 1 to Series 2 simplex or redundant; or from Series 2 simplex or redundant to Series
1. Simply click the down arrow in the Card series field and select Series 1 or Series 2 as required and then select the
Card is Redundant checkbox if you want the Series 2 card to operate in redundant mode. Be sure that you download
your changes.
The Features area shows the supported card features based on the selections for card class, type, and series. In the
above example, the card selected has the basic features, plus line fault detection and redundancy. The Card is
redundant check box is active when the selected card type supports redundancy and is cleared by default. Select this
box to enable redundancy for this card. The Card is redundant check box controls the information displayed in the
Slot position field. The Slot position field displays only valid and applicable slots depending upon the card selection
and redundancy settings. The context-sensitive help provides complete descriptions for all the fields in this dialog
box.

234

System Configuration

The Enable Auto Switchback Parameter


Redundant Series 2 cards have an enable automatic switchback (ENABLE_AUTO_SWBK) parameter that controls
whether or not the active and standby cards switch over more than one time when faults are detected. The default is
enabled (True).
Note ENABLE_AUTO_SWBK cannot be disabled for Redundant Series 2 Serial and H1 cards. For these cards, it is
always True.
To enable or disable the parameter, select the redundant card in DeltaV Explorer, right-click
ENABLE_AUTO_SWBK, and then select Properties.

When ENABLE_AUTO_SWBK is True and:

a fault occurs, the active card switches over.

the same fault occurs, the new active card does not switch over. (If both cards detect the same problem, it is
probably a field error.)

a different fault occurs, the new active card switches over.

When ENABLE_AUTO_SWBK is False and:

a fault occurs, the active card switches over.

a subsequent fault occurs, the cards do not switch over until the saved fault information command is issued.
Refer to the information on clearing saved fault information in the Identifying and Troubleshooting Series 2
Redundant Cards topic for more information.

Note If ENABLE_AUTO_SWBK is False and the controller detects a new card in the redundant pair, a switchover
will be allowed to the new card if the active card has a fault. For example, if you replace the standby card or if
communications is lost and then reestablished with the standby card, a switchover can occur even if
ENABLE_AUTO_SWBK is False.
The decision to enable or disable automatic switchback depends on the requirements of your process and the
importance of the card. Disabling ENABLE_AUTO_SWBK requires manual intervention for switchovers to occur

I/O Configuration

235

but prevents cards from frequently switching over. On the other hand, enabling ENABLE_AUTO_SWBK causes
cards to switch over but, under certain circumstances, can result in frequent switchovers.

Identifying and Troubleshooting Series 2 Redundant Cards


The redundant card icon,
, makes it easy to identify redundant Series 2 cards in DeltaV Explorer, and the card's
LEDs and DeltaV Diagnostics program provide troubleshooting and diagnostic information.
DeltaV Explorer
The redundant card icon,
, appears on the odd slot number in DeltaV Explorer. The odd slot is the first slot on
which the terminal block is installed. In this example from DeltaV Explorer, the redundant pair, C07, occupies slots 7
and 8. Notice that the next available slot, C06, was not used; this is because the lower slot number in a redundant pair
must be odd.

The procedure for enabling and disabling ports or channels on redundant Series 2 cards is the same as that for preSeries 2 cards: select the channel or port, click the right mouse button, select Properties, and then select Enabled. To
enable multiple channels or ports, select the I/O subsystem, click the right mouse button, and then select Configure
I/O.
LEDs
The LEDs on the Series 2 cards show basic operating data. The correct operating conditions for the green Power/
Active LED is solid for the active card and flashing for the standby card. The red LED (continuous on or flashing)
indicates fault conditions. Refer to the LED checklists in the Checking the LED Indicators on Each Device topic for
complete information on each Series 2 card. Use DeltaV Diagnostics to diagnose problems. (Scroll through the topic
and find the appropriate table for your card.)
Diagnostics
The left pane in DeltaV Diagnostics presents a redundant pair of cards slotwise. In the following image, a redundant
AI, 8-channel, 4-20 mA HART card is installed in slots 7 and 8 (C07 and C08).

236

System Configuration

The active card is depicted with the black half of the image in the foreground (C07), and the standby card is depicted
with the grey half of the image in the foreground (C08).
Diagnostic Parameters
The right pane in DeltaV Diagnostics shows diagnostic parameters for the selected card in the redundant pair. The
following image shows the diagnostic parameters for a standby redundant Series 2 Serial card.

I/O Configuration

237

The online help for the Diagnostics program provides descriptions of all the parameters. To access the help, select the
parameter, click the right mouse button, and then select What's this. Following are descriptions of the SwitchAvail,
Pstatus, POInteg, and State parameters:

SwitchAvail (Switchover Available) - Indicates if the redundant pair is available for switchover. Possible
values include:

Unavailable - Missing Cards

Available

Disabled

Available - common faults (resolve problem and clear saved fault information)

Unavailable - missing standby

Unavailable - standby faulty

Unavailable - switchback disabled

Unavailable - both cards faulty (resolve problem and clear saved fault information)

PStatus (Pair Status) - Shows the status of the redundant pair. Possible values are:

No Card

Good

Integrity Error

Termination Block Incorrectly Installed

No Communication Between Cards

No Communication With Partner

Active Card Problem

Standby Card Problem

Standby Card Not Present

Both Cards Report Problem

Switchover Occurred, Possible Field Problem

Possible Loss of Field Power

Not Operational

POInteg (Pair Integrity) - Overall integrity (good or bad) of the redundant pair

State (Redundant cards) - Indicates whether or not the selected card is active. A state of Standby means not
active; it does not mean that the card is necessarily available to take over as active.

To view parameter values for channels or ports, select the active card. The values are shown for the active card only;
Diagnostics displays "Not Available on Standby" if the standby card is selected. If the channels or ports are disabled,
Diagnostics shows "@@@@@" for the channel or port's Value parameter and "No installed configuration" for the
Status parameter.
Clearing Saved Fault Information on Redundant Cards
Use the Clear Saved Fault Information command in DeltaV Diagnostics after any problems reported by the redundant
card pair are identified and resolved. Redundant cards hold back previous error information to prevent switching back
and forth. Users must acknowledge the problem and then clear the saved fault information. The Clear Saved Fault
Information command re-enables switchovers if the same problems are detected again. One way to determine if you
need to use this command is to look at the card's SwitchAvail parameter. If the value for the SwitchAvail parameter
reads "Available common fault" or "Unavailable - both cards faulty," send the Clear Saved Fault Information
command.

238

System Configuration

For example, suppose a wire becomes loose on an Analog Input termination block. As soon as the active card detects
the open loop, the controller records the fault, and the redundant pair switches over. Then, the new active card detects
the open loop, and the controller records the fault again. In such a situation, detection of the same open loop will not
cause a switchover. Once you find and secure the loose wire, use the Clear Saved Fault Information command to
enable switchover if the condition is detected again.
Note If switchovers are not occurring as expected, be sure that the ENABLE_AUTO_SWBK parameter is enabled.
Refer to The Enable Auto Switchback Parameter topic for more information.
To access the Clear Saved Fault Information command:
1

Select the redundant I/O card that is reporting either of the above values in the SwitchAvail parameter.

Click the right mouse button and select Clear Saved Fault Information.

Example Switchover Situations


Inside this topic
Redundancy link chip failure
Communication failure due to open or bent pin
Brief loss of field power
Electrical noise on the carrier
Open channel fault on DO card
Excessive current withdrawal
The scenarios described in this section are example situations that could cause redundant Series 2 cards to switch
over. They contain guidelines to help you understand what can cause a switchover and what you can do to remedy the
fault. Seven situations are presented:

I/O Configuration

239

For each situation, read the information in the table and then click the link in the Possible Problem column for
suggestions of how to fix the problem.
Card type and LED
indications

Diagnostics shows an
integrity error on the card and the
following parameter values:

All Series 2 cards


Power/Active LED on the
former standby card goes to
solid green indicating it is now
the active card. Power/Active
LED on the former active card
goes to flashing green indicating
it is now the standby card. Red
LED is off.

Status = No communication with


partner

All Series 2 cards


Power/Active LED on the
former standby card goes to
solid green indicating it is now
the active card. Power/Active
LED on the former active card
goes to flashing green indicating
it is now the standby card. Red
LED is off.

Status = No communication with


partner

All Series 2 cards that use field


power
Flashing Red LEDs

PStatus = Possible loss of field power

Possible Problem

Redundancy link chip failure

PStatus = No communication between


cards

Communication failure due to


open or bent pin

PStatus = No communication between


cards

Brief loss of field power

Status = Bad - Hardware error

Power/Active LED on the


former standby card goes to
solid green indicating it is now
the active card. Power/Active
LED on the former active card
goes to flashing green indicating
it is now the standby card.

240

System Configuration

Card type and LED


indications

Series 2 redundant Serial


cards (Can affect other cards
depending upon card's noise
level tolerance)

Diagnostics shows an
integrity error on the card and the
following parameter values:
PStatus = No Card

Possible Problem

Electrical noise on the carrier

Status = No Card

Flashing Red LEDs on serial


cards
Power/Active LED on the
former standby card goes to
solid green indicating it is now
the active card. Power/Active
LED on the former active card
goes to flashing green indicating
it is now the standby card.
Series 2 redundant DO, 8Channel, 24 VDC, High-Side
Flashing Yellow LEDs
Power/Active LED on the
former standby card goes to
solid green indicating it is now
the active card. Power/Active
LED on the former active card
goes to flashing green indicating
it is now the standby card.

I/O Configuration

Channel Status = Bad Hardware


Error

Open channel fault on DO card

Channel OInteg = Bad, Pair Status


Possible Field Problem

241

Card type and LED


indications

Series 2 redundant AI, 420mA, Hart


Flashing Red LED on the
former active card

Diagnostics shows an
integrity error on the card and the
following parameter values:
PStatus = Termination Block
Incorrectly Installed

Possible Problem

Excessive current withdrawal

Status = Bad Configuration Error

Power/Active LED on the


former standby card goes to
solid green indicating it is now
the active card. Power/Active
LED on the former active card
goes to flashing green indicating
it is now the standby card.
Series 2 redundant H1
Power/Active LED on the
former standby card goes to
solid green indicating it is now
the active card. Power/Active
LED on the former active card
goes to flashing green indicating
it is now the standby card. Red
LED is off.

PStatus = Standby Card Problem

Open pin fault

Redundancy Link Chip Failure


Series 2 redundant cards contain a microchip that enables redundancy. If the chip fails, the redundant cards stop
communicating, and a switchover occurs instantaneously. To correct this issue:
1

Replace the faulty card.

Open DeltaV Diagnostics (click Start | DeltaV | Operator | Diagnostics).

For each card, select the card, click the right mouse button, and then select Clear Saved Fault Information.

Communication Failure due to Open or Bent Pin


Some of the pins that connect the card to the carrier can become bent or broken during installation or through
improper handling. An open or bent pin shorts to the adjacent pin and causes the redundant cards to stop
communicating and a switchover to occur. To correct this issue:
1

Remove the redundant cards and check for bent or broken pins.

Straighten any bent pins and re-insert the card into its slot on the carrier. Replace the card if a pin is broken or
bent beyond repair.

Open DeltaV Diagnostics (click Start | DeltaV | Operator | Diagnostics).

For each card, select the card, click the right mouse button, and then select Clear Saved Fault Information.

242

System Configuration

Brief Loss of Field Power


A brief loss of field power to the DeltaV system (for example, a few seconds) causes all cards that operate on field
power to switch over. (Most cards operate on field power.) To correct this issue:
1

Reset the cards by removing each card from the carrier and then re-inserting it into its slot.

Open DeltaV Diagnostics (click Start | DeltaV | Operator | Diagnostics).

For each card, select the card, click the right mouse button, and then select Clear Saved Fault Information.

Electrical Noise on the Carrier


Electrical noise on the carrier affects the communication between Series 2 redundant serial cards and causes them to
switch over. To correct this issue:
1

Determine if there is any electrical noise near the carrier and, if so, remove the noise source.
Flashing red LEDs and loss of communication between the card and the carriers indicate the existence of noise.
Noise can be caused by electrical activity (such as welding), the use of devices (such as 2-way radios), or natural
causes (such as lightning), occurring close to the DeltaV installation.

Reset the serial cards by removing each card from the carrier and then re-inserting it into its slot.

Open DeltaV Diagnostics (click Start | DeltaV | Operator | Diagnostics).

For each card, select the card, click the right mouse button, and then select Clear Saved Fault Information.

Open Channel Fault on DO Card


Occasionally, during setup or normal operation of the DeltaV system, one or more channel wires can become loose
and cause an open channel fault. Open channel faults cause a switchover in Series 2 redundant DO cards. To correct
this issue:
1

Open DeltaV Diagnostics (click Start | DeltaV | Operator | Diagnostics).

Select the card from the I/O subsystem in the left pane in Diagnostics.

In the right pane, read the Status and OInteg parameter values for all channels to determine if there is an open
connection. Look for values, such as Status = Bad Hardware Error and OInteg = Bad, Pair Status Possible
Field Problem.

Fix any wiring problems on the card.

In Diagnostics, select each card, click the right mouse button, and then select Clear Saved Fault Information.

Excessive Withdrawal of Current Causes Hardware Error


Providing a constant 24 VDC without current limit protection to the inputs of a redundant AI card for long periods of
time during normal operation of the DeltaV system can cause a hardware error on the card. The excessive current
damages the card's internal components. To correct this issue:
1

Replace the card with the blinking red LED as it is probably damaged.

Use a multimeter or other measurement device to determine if any of the channels are drawing 24 VDC without
current limit protection and fix this problem.

Reset the cards by removing each card from the carrier and then re-inserting it into its slot.

Open DeltaV Diagnostics (click Start | DeltaV | Operator | Diagnostics).

For each card, select the card, click the right mouse button, and then select Clear Saved Fault Information.

I/O Configuration

243

Open Pin Fault on Series2 Redundant H1 Card


Some of the pins that connect Series 2 redundant H1 cards to the terminal block can bend or break during installation
or through improper handling and cause an open pin fault. An open pin can cause problems on one or both of the
ports. To correct this issue:
1

Open DeltaV Diagnostics (click Start | DeltaV | Operator | Diagnostics).

Scroll through the parameters for the standby card and determine if there is a port problem.

Remove the redundant cards and check for bent or broken pins.

Straighten any bent pins and re-insert the card into its slot on the carrier. If a pin is broken or bent beyond repair,
replace the card.

For each card, select the card, click the right mouse button, and then select Clear Saved Fault Information.

244

System Configuration

DeltaV Remote I/O


Inside this topic
Remote I/O Capacity Limits
Supported Cards
Configuring a Remote I/O Card's Scan Rate
Using the Goto Card Assignment Command
Downloading Remote I/O Cards
Troubleshooting Remote I/O
Browsing to Remote I/O Parameter References
Special Considerations for Configuring Output Channels for Failsafe
Remote I/O Nodes are installed in Zones 1 and 2 and bring I/O from cards installed in these locations into the DeltaV
system. Remote I/O Nodes perform no control and have no assigned modules. Remote I/O cards are added to the I/O
subsystem under Remote I/O Nodes and the cards are assigned to a DeltaV controller. It is possible to assign all cards
under a Remote I/O Node to a single controller or assign individual cards under one Remote I/O to multiple
controllers. Refer to Capacity Limits for Remote I/O Nodes for more information on assignment limits. Refer to the
DeltaV Explorer help for instructions on how to add Remote I/O Nodes and cards and assign Remote I/O to a DeltaV
controller.
Remote I/O must be enabled as a DeltaV System Preference before it is available to the DeltaV system. To enable
Remote I/O, click Start | DeltaV | Engineering | System Preferences. Once Remote I/O is enabled, the Remote I/O
Network appears under the Control Network in the DeltaV Explorer. The following image shows a DeltaV Explorer
hierarchy with Remote I/O Nodes installed in Zones 1 and 2, remote I/O cards, and a controller with a Zone 2 Remote
I/O Node assigned.

Remote I/O Network Structure in DeltaV Explorer

Configuring a Remote I/O Card's Scan Rate


Configuring a Remote I/O Node is very similar to configuring a DeltaV controller. Select Properties from the
Remote I/O Node's context menu to configure the Remote I/O Node. Use the dialog box's "What's This" help for

I/O Configuration

245

information on the configuration options. Similarly, configuring a Remote I/O card is similar to configuring standard
DeltaV I/O cards. However, Remote I/O cards have a configurable scan rate. The scan rate controls how often the
card data is moved between the controller and the Remote I/O Node. Valid scan rates are 100 ms, 200 ms, 500 ms,
and 1 second. The default value is 500 ms. Increasing the scan rate increases the loading on the network, controller,
and Remote I/O Node.
Note Do not confuse a remote I/O card's scan rate, the rate at which the card data is moved between the controller
and the Remote I/O node, with a module's scan rate (also called module execution time). A module's scan rate is the
rate at which the module executes. For modules configured to read signals from remote I/O channels, the module's
scan rate should be twice as slow as the Remote I/O scan rate. For example if the Remote I/O scan rate is 100 ms, the
module's scan rate should be 200 ms; if the Remote I/O scan rate is 200 ms, the module's scan rate should be 500 ms.
(Remember that valid scan rates are 100 ms, 200 ms, 500 ms, and 1 second.) A module scan rate of 100 ms is not
supported by remote I/O cards and will negatively affect the card's performance.

Using the Goto Card Assignment Command


The Goto Card Assignment command provides a fast and easy way to find an assigned Remote I/O card's location in
the controller's hierarchy. This command is accessed through the card's context menu and is available only when a
Remote I/O card has been assigned to a controller. When this command is selected, the controller hierarchy is
expanded, and card is selected.

Remote I/O Capacity Limits


Refer to Capacity Limits for Remote I/O Nodes for information.

Supported Cards
Zone 1
A Remote I/O Node installed in Zone 1 supports the following types of I/O cards:

Zone 1 Analog Input and Output

Zone 1 Discrete Input and Output

For card specifications refer to the HART Analog Input Channel Specifications, HART Analog Output Channel
Specifications, Discrete Input Channel Specifications, and Discrete Output Channel Specifications topics in the
Installing Your DeltaV Zone 1 Hardware manual.
Zone 2
A Remote I/O Node installed in Zone 2 supports the following types of I/O cards. For card specifications refer to the
I/O Cards topic in the Installing Your DeltaV Digital Automation System manual.
Note Only HART Passthrough for use with AMS Device Manager and Valvelink is available for Remote I/O. No
other HART functionality is supported.
Analog Input Cards

246

AI, 8-channel, 1-5 VDC

AI, 8-channel, 4-20 mA

AI, 8-channel, 4-20 mA HART and Series 2

System Configuration

AI, 16-channel, 4-20 mA HART

Millivolt, 8-channel

RTD, 8-channel

Thermocouple, 8-channel

Analog Output Cards

AO, 8-channel, 4-20 mA

AO, 8-channel, 4-20 mA HART (Series 1 and 2)

Discrete Input Cards

DI, 32-channel, High Density

DI, 8-channel, 120 VAC, Dry Contact

DI, 8-channel, 120 VAC, Isolated

DI, 8-channel, 230 VAC, Dry Contact

DI, 8-channel, 230 VAC, Isolated

DI, 8-channel, 24 VDC, Dry Contact (Series 1 and 2)

DI, 8-channel, 24 VDC, Isolated

Discrete Output Cards

DO, 32-channel, High Density

DO, 8-channel, 120/230 VAC, High Side

DO, 8-channel, 120/230 VAC Isolated

DO, 8-channel, 24 VDC High Side (Series 1 and 2)

DO, 8-channel, 24 VDC, Isolated

Downloading Remote I/O Cards


There are two download options for Remote I/O cards:
Download physical card and card assignment this option downloads the physical card to its Remote I/O Node
and downloads the card's assignment to the controller.
Download physical card only this option downloads the physical card to the Remote I/O Node.
Note If the configuration has not changed since the last download, either the physical card or the physical card and
card assignment can be downloaded. However, if the configuration has changed since the last download, the physical
card and card assignment are downloaded even if Download physical card only is selected.

Troubleshooting Remote I/O


Use the DeltaV Diagnostics application to troubleshoot Remote I/O. Diagnostic information is available for the
Remote I/O Network, Remote I/O Nodes, and cards as well as a controller's assigned remote I/O. Use the Diagnostics
online help for descriptions of the diagnostic parameters which provide useful information for maintaining system
integrity.

I/O Configuration

247

Browsing to Remote I/O Parameter References


To browse to a remote I/O parameter using Process History View or Control Studio, use the form:
controller/REMIO/RIOid/Cnn/CHnn/param
where:
controller the name of the controller to which the Remote I/O is assigned
REMIO a fixed system name designating the assigned Remote I/O subsystem under the controller
RIOid the system string RIO followed by the device ID of the Remote I/O Node
Cnn the system string C followed by the card number in the Remote I/O carrier
CHnn the system string CH followed by the channel number on the card
param the parameter name
For example:
CTLR1/REMIO/RI01/C04/CH03/FIELD_VAL_PCT

Special Considerations for Configuring Output Channels for Failsafe Action


Like Profibus, DeviceNet, and AS-interface devices, remote output channels configured for failsafe action can
require additional configuration to track the failsafe action so that outputs are not driven back to the last good state
when communications with the remote node are restored. Refer to Special Considerations for Writing Output Signals
for more information.

248

System Configuration

Device Signal Tags and SCADA Tags


Inside this topic
Device Signal Tags (DSTs)
DST Counting for Classic I/O, Profibus DP, AS-Interface I/O, and DeviceNet I/O
DST Counting with Foundation Fieldbus
DST Counting with Serial I/O
DST Counting in Application Stations
DSTs and the Advanced Unit Management License
Enforcement of System-Wide Licensing for Controllers
SCADA Tags
This section defines the differences between Device Signal Tags (DSTs) and SCADA tags. It also defines the
distinction between AO, AI, DO, and DI DSTs used for control, monitoring, and advanced unit management.

Device Signal Tags (DSTs)


Device Tags represent instruments, valves, and other field devices. A DST consists of a Device Tag and a specific
signal from that device. The licenses purchased with the system determine the number and types of DSTs allowed by
the system.
DSTs in DeltaV controllers are identified based on the manner in which the application is configured. Function
blocks are grouped into modules. Inputs and outputs from Classic I/O, Serial I/O, Profibus I/O, AS-Interface I/O, and
DeviceNet I/O referenced by the function blocks are DSTs.

DST Counting for Classic I/O, Profibus DP, AS-Interface I/O, DeviceNet I/O, and
DeltaV SIS I/O
For licensing, DSTs are counted in the following ways:

Each output from a function block to the I/O subsystem counts as one DO DST if it is a discrete signal, or
one AO DST if is an analog signal.

An input referenced by one or more function blocks in a module counts as one DI DST if it is a discrete
signal, or one AI DST if it is an analog signal.

An input signal referenced by function blocks in multiple modules, counts as a DI DST or an AI DST in
each module.

Any input that is referenced in a graphic or a history collection and is not referenced in a function block is
not counted as a DST instead, it is counted as a SCADA value.

The total number of DSTs in a controller is equal to the total number of DSTs in all of its modules. In the figure, the
controller has two modules and five DSTs: three input DSTs (either discrete or analog depending on signal type) in
Module 1 and one input and one output DST (either discrete or analog depending on signal type) in module 2 adding
to a total of five DSTs.

I/O Configuration

249

The DSTs were counted in the following way:

Input A is referenced by one function block and is therefore counted as one input DST (either analog or
discrete depending on signal type).

Input B is referenced by two function blocks, but the function blocks are in the same module so it is counted
as one input DST, either analog or discrete depending on signal type.

Input C is referenced by function blocks in two modules so it is counted as two input DSTs.

Output D is counted as one output DST, either analog or discrete depending on signal type.

DST Counting with Foundation Fieldbus


In contrast to the I/O types discussed elsewhere, with Foundation Fieldbus I/O, a DST is added to the count when
certain function blocks are added to a controller module. The type of DST depends on the function block.
Specifically, each instance of the following function blocks adds to the DST count as shown:
Function Block

DSTs

FFAI

FFAI_RMT

250

System Configuration

Function Block

DSTs

FFAO

FFAO_RMT

FFDI

FFDO

Each occurrence of the following blocks adds to the DST count as shown:
Function Block

DSTs

FFMAI

FFMAI_RMT

FFMDI

FFMDO

For example, two FFAI blocks, contained in the same module and referencing the same transmitter signal, count as
two AI DSTs. Similarly, two FFMDI blocks, contained in the same module and referencing the same device, count as
16 DI DSTs.

DST Counting with Serial I/O


The serial card in the I/O subsystem supports datasets. A dataset can contain up to 100 values of either analog in,
analog out, discrete in, or discrete out signals (a value can be a discrete value, setpoint value, register value, and so
on). Datasets that contain Boolean or discrete values are discrete datasets. Datasets containing anything else are
analog datasets. Each port on a serial card supports up to 16 datasets. Therefore, a serial card supports up to 3,200
values.
Each dataset counts as one DST as long as a single module references all values in the dataset. If multiple modules
reference values in a dataset, the DST count for the dataset is equal to the number of modules referencing the dataset.
Values referenced only in graphics or a history collection count as SCADA values, not DSTs.

DST Counting in Application Stations


The Application Station contains many of the same function blocks that exist in DeltaV controllers. The primary
difference is that the Application Station does not contain function blocks specifically for control such as PID.
Another difference is the manner in which DSTs are defined and counted. In an Application Station, a DST is counted
each time certain function blocks are used. The following are the function blocks that create DST counts.

AI Analog Input: One AI DST

ALM Alarm Detection: One AI DST

AO Analog Output: One AO DST

CALC Calculation: One AI DST

DI Discrete Input: One DI DST

DO Discrete Output: One DO DST

I/O Configuration

251

MDI Multiple Discrete Input: Eight DI DSTs

MDO Multiple Discrete Output: Eight DO DSTs

PIN Pulse Input: One DI DST

DSTs and the Advanced Unit Management License


The system-wide Advanced Unit Management (AUM) license allows the creation of class-based units typically used
for batch control. Class-based units provide the phase logic structure and the embedded interface to the batch
executive.
The figure provides a logical representation of class-based units and controller modules. Each class-based unit takes
on the total DST count of all the modules assigned to it. Class-based unit 1 has a DST size of 300 (a total of 250 DI,
DO, AI, and AO DSTs in one controller module plus 50 total DSTs in another module). Class-based unit 2 has 400
DSTs, and class-based unit 3 has 200 DSTs.
The AUM license that allows the creation of these class-based units must be equal to or greater than the sum all DSTs
assigned to class-based units. In this example, the sum of all DSTs assigned to classed-based units is 900. A 900-DST
AUM license is required.

Enforcement of System-Wide Licensing for Controllers


System-wide controller licenses reside in the ProfessionalPLUS station. The system checks the entire configuration
database at the time of download to determine if the configured DST counts are within the sizes of the system-wide
licenses. DSTs are in a hierarchy with AO DSTs as the highest type, then AI DSTs, DO DSTs, and DI DSTs as the
lowest type in the hierarchy.
The system does not permit a download if either:

252

the total system DST count exceeds the ProfessionalPLUS license size, or

the number of any of the DSTs categorized as AO, AI, DO, or DI exceeds the system-wide Control license
size for that type of DST and enough unused DSTs of a higher type are not available to make up the
difference.

System Configuration

If the system contains class-based units, one more check is made before download is permitted. This check counts
DSTs configured and associated with class-based units and compares this quantity with the DST size of the systemwide Advanced Unit Management license. A download will not occur if the DST count exceeds the size of the
Advanced Unit Management license.
License Enforcement Example
A configuration has 20 AO DSTs and 27 AI DSTs. The system is licensed for 25 AO DSTs and 25 AI DSTs. Though
the configuration exceeds the licensed AI DST limit, the download is permitted because there are enough licensed,
but unused, AO DSTs to make up the difference.

SCADA Tags
Many values brought into a DeltaV system by way of OPC and Serial are used for monitoring purposes. Because of
this, the DeltaV system allows you to host these values as SCADA (Supervisory Control and Data Acquisition) tags
instead of DSTs. SCADA tags are values that come into the DeltaV system by way of OPC and Serial and are not
used in a control strategy. They are inexpensive, lightweight values that can be passed around the system quickly and
efficiently. SCADA tags can be easily displayed to the operator, saved in the historian, or displayed in a trend.
To get SCADA tags from OPC into the DeltaV system you must create modules that contain input parameters and
assign these modules to the Application Station. You can then use OPC mirror to map the incoming OPC values from
a third party interface to the input parameters in the modules running in the Application Station. These modules are
considered SCADA tags and are not counted as DSTs.
You can also have modules running in the Application Station with input parameters referencing parameters in a
module running in a controller. These input parameters are also considered SCADA tags and are not counted as
DSTs.

I/O Configuration

253

Foundation Fieldbus Technology Overview


Inside this topic
Physical Layer
Communication Layer
User Application Layer
Fieldbus is an all digital, serial, bi-directional communication protocol that interconnects devices such as actuators,
sensors, discrete devices, and controllers in the field. It is a Local Area Network (LAN) for instruments that enables
basic control and I/O to be moved to the field devices.
In the DeltaV system, the H1 fieldbus card connects to the fieldbus segment and interfaces with fieldbus devices. The
H1 card connects to any vacant slot in an I/O Interface Carrier. The H1 card has two ports and each port can connect
to one fieldbus segment. Up to 16 devices are supported for each segment.
Foundation Fieldbus is a specific fieldbus technology developed and supported by Emerson Process Management and
the other members of the independent Fieldbus Foundation. Foundation Fieldbus technology uses Device
Descriptions and function blocks to enable intelligent field devices to execute control functions traditionally
performed by a distributed control system.
The Foundation Fieldbus H1 technology is modeled on the Open Systems Interconnect (OSI) model and consists of
three parts:

Physical Layer - receives messages from the Communication Layer (Stack) and converts them into signals
on the fieldbus segment; receives signals on the fieldbus segment and converts them into messages

Communication Layer - (Communication Stack made up of the Data Link Layer, Fieldbus Access Sublayer,
and Fieldbus Message Specification). The Data Link Layer controls transmission of messages on the
fieldbus segment.

User Application Layer - DeltaV applications, such as Control Studio and Explorer

Note The User Application Layer is not defined by the OSI model. The Fieldbus Foundation specified a User
Application Model that Fisher-Rosemount used to develop DeltaV software applications.

Physical Layer
Refer to the Fieldbus Installations in a DeltaV Digital Automation System manual for information on installing the
H1 card, wiring the fieldbus segment, and cabling and power requirements.

Communication Layer
The transmission of messages across the fieldbus is managed through a deterministic centralized bus scheduler called
the Link Active Scheduler (LAS). The H1 card functions as the LAS. Some of the Link Active Scheduler's
responsibilities are:

254

Managing scheduled transfers

Managing unscheduled transfers

Maintaining the Live List

System Configuration

Note The H1 card is the only primary Link Master allowed on the fieldbus segment. No other Link Master is allowed
on the segment or unpredictable results can occur. DeltaV software supports one backup Link Master device on each
fieldbus segment.
Scheduled Transfers
Scheduled transfers are typically used for the regular, cyclical, exchange of control loop data between devices on the
fieldbus segment. The LAS maintains a schedule called the Compel Data schedule, which is a list of transmit times
for all the data buffers that need to be cyclically transmitted. The data buffers are in the fieldbus devices. When it is
time for a fieldbus device to send a data buffer, the LAS issues a message called a Compel Data message to the
device. When the fieldbus device receives the Compel Data message, it broadcasts or publishes the data in the buffer
to all devices on the fieldbus and any device that is configured to receive the data receives it. The devices that are
configured to receive the data are called subscribers. Although scheduled transfers are the highest priority activity
performed by the LAS, it requires the smallest portion of a macrocycle. (A macrocycle is a single iteration of a
schedule.)
A link, or Virtual Communication Relationship (VCR), is defined as a connection between a fieldbus parameter in
one device on the segment and a fieldbus parameter in another device on the segment. Some devices support
publisher and subscriber VCRs and other devices support Free VCRs.
Publisher and Subscriber VCRs
A subscriber VCR is an output from a fieldbus device to an input in another device on the segment. The input device
can be another fieldbus device or a DeltaV controller. A publisher VCR is an output from a DeltaV controller to the
input of a parameter in a fieldbus device. Here are a few examples of publisher and subscriber VCRs:

The link between a function block running in a controller to a function block running in a device is a
publisher VCR.

The link between a function block running in a device to a function block running in a controller is a
subscriber VCR.

The link between a function block running in a device to a function block running in another device is a
subscriber VCR

The H1 card supports as many as 35 H1 publisher VCRs and 50 fieldbus device subscriber VCRs per port as long as
the total number of VCRs does not exceed 50. For example, the card can support 35 H1 publisher VCRs and 15
fieldbus device subscriber VCRs per port or five H1 publisher VCRs and 45 fieldbus device subscriber VCRs. Refer
to the VCR Specifications topic for the maximum number of subscriber and publisher links supported by fieldbus
devices that use these types of links.
Note: Many backup Link Master devices cannot support these limits. This means that the configuration can exceed
the capacity of the backup Link Master device. If communication is lost between the H1 card and the segment, the
backup Link Master device may be unable to handle the segment scheduling and the schedule download may fail. If
the backup Link Master device indicates Schedule Download Failure in DeltaV Diagnostics, the device cannot
function as a backup Link Master. If an H1 card configuration has more than 25 publisher/subscriber VCRs per port,
test the configuration before going online to ensure that the backup Link Master device can support the configuration.
To avoid a Schedule Download Failure due to lack of capacity in the backup Link Master consider the following
options:
Upgrade to a backup Link Master that supports the segment's publisher and subscriber VCRs.
Do not configure any device as a backup Link Master.
Reduce the number of publisher and subscriber VCRs on the segment.

I/O Configuration

255

Free VCRs
A Free VCR can function as a publisher link, a subscriber link, or a device alarm. Device alarms require one VCR.
For example, if a device can support a maximum of five VCRs, and one VCR is used for a device alarm, the
remaining four VCRs can be used for any combination of publisher and subscriber links. Each port on the H1 card
can support a maximum of 50 input links and 35 output links as long as the total number does not exceed 50 VCRs.
Refer to the VCR Specifications topic for the maximum number of Free VCRs supported by devices that use these
types of links.
Unscheduled Transfers
Unscheduled transfers are typically used for user initiated changes such as setpoint changes, tuning changes, and
downloads and uploads. Unscheduled transfers require the greatest portion of a macrocycle. The LAS gives all
devices on the fieldbus a chance to send unscheduled messages between transmissions of scheduled messages. The
LAS grants a device permission to use the fieldbus for unscheduled messages by issuing a Pass Token (PT) message
to the device. When the device receives the PT, the LAS allows it to send unscheduled messages until it has finished
or until the maximum token hold time has expired; whichever is the shorter time. The device can send unscheduled
messages to a single destination or it can multicast the message to multiple destinations. The LAS maintains a list of
the devices that are properly responding to the PT message. This list is called the Live List.
Live List Maintenance
New devices can be added to the fieldbus at any time. Between the times it sends out Compel Data messages, the
LAS sends out Probe Node (PN) messages to the addresses not in the Live List. If a new device is present at that
address, it receives the PN and answers with a Probe Response (PR) message. When the LAS receives the PR
message from the device, it adds the device to the Live List. Whenever a device is added or removed from the Live
List, the LAS broadcasts the change to all devices. This allows each device to maintain a current copy of the Live
List.

User Application Layer - Fieldbus in the DeltaV System


The DeltaV system connects to the fieldbus segment through an H1 card. The DeltaV system enables you to
graphically configure your fieldbus devices and H1 cards, establish communication between fieldbus and
conventional devices, and monitor the performance of the control loops operating in the fieldbus devices. In the
DeltaV Explorer, the H1 cards are under the I/O subsystem for the controller associated with the fieldbus device.
Each fieldbus card has two ports and each port can connect to one fieldbus segment. Fieldbus ports are indicated by
the
icon in the DeltaV Explorer. Up to 16 devices are supported for each segment. The H1 card and the ports
associated with the card manage the fieldbus device behaviors.
For specific information refer to the following:

256

Foundation Fieldbus Function Blocks

Using Fieldbus Function Blocks in the Control Strategy

Deciding Where to Run Control Function Blocks

Changing Function Block Parameters in Fieldbus Devices

System Configuration

Fieldbus Devices General Information


Inside this topic
Device Descriptions and Methods
Accessing Methods from DeltaV Operate
Autosensing Fieldbus Devices
Commissioning and Decommissioning Fieldbus Devices
Diagnosing Fieldbus Devices
Fieldbus Device Status Conditions
Suppressing Device Alarms
Device Audit Trail
Fieldbus devices are field instruments, such as transmitters and valves, with processors that monitor device
performance and state. Fieldbus devices use a digital, rather than analog, connection to a host system such as the
DeltaV system. Function blocks reside in the fieldbus devices and enable the devices to execute control in the field.
Fieldbus devices notify the control system of standard operating parameters and are self-diagnosing and capable of
reporting device problems such as instrument out of calibration to the control system.
Each fieldbus device must have a unique physical device tag and a corresponding network address. The device tag is
assigned to the device when it is commissioned and (for most device states), the device retains the tag in its memory
when it is disconnected. The device does not retain the tag when the device is made Spare. When the device is made
Spare, the tag information is lost. The network address is the current address that the fieldbus is using for the device.
The Fieldbus Foundation uses addresses in the range 0-255. Group addresses and DLLs use addresses 0 - 15,
commissioned devices use addresses 20-35, standby devices use addresses 232-247, and offline and spare devices use
addresses 248-251.
Fieldbus supports four device classes:

Unknown - the fieldbus device class is not known at this time.

Basic device - sends and receives messages on the fieldbus but does not control when devices have access to
the fieldbus.

Link Master - controls when devices access the fieldbus and executes the link schedule which synchronizes
communications with function block execution on the fieldbus. Link Master devices are capable of taking
over as LAS if the Primary Link Master device fails. The backup Link Master must use address 20.

Bridge - links multiple fieldbus segments. This device class is not currently supported. The DeltaV system
supports one backup Link Master on each segment.

Note Link Master devices should always be Commissioned. Unpredictable behavior could occur if a Link Master
capable device is in Standby or Offline and the Primary Link Master device fails. Any temporary device should only
be connected to the fieldbus as a Basic device.
For more information, refer to the Commissioning and Decommissioning Fieldbus Devices topic.

Device Descriptions and Methods


A Device Description is similar to a driver for the device. For fieldbus devices, the Device Description includes the
calibration procedures, parameter procedures, and other information required by the control system to communicate
with the fieldbus device. Standard Device Descriptions are provided by the Fieldbus Foundation and optional,
incremental Device Descriptions are provided by the device manufacturer. Device Descriptions are written in the
Device Description Language (DDL) and the host system such as the DeltaV system uses library functions called
Device Descriptions Services to read the Device Descriptions. Device Description technology enables

I/O Configuration

257

interoperability among fieldbus devices. Interoperability, a key benefit of fieldbus technology, is the ability of a host
system to operate multiple devices, independent of manufacturer, on the same fieldbus segment without loss of
minimum functionality.
The DeltaV system supports a number of fieldbus devices from different manufacturers. The device description files
necessary to support these devices are included in the DeltaV install image. If a fieldbus device is not included in the
DeltaV install image, you must install the device description for that device. The device description is specific to the
device type and revision. Download the device description files from www.easydeltav.com The device description
files must include a file with an .fhx extension to work with the DeltaV system. You can download the device
description files to a disk, CD, or directory on your system and then use the DeltaV Explorer to add the device
descriptions to the DeltaV Explorer library. Install the device description files on the ProfessionalPLUS workstation
and the DeltaV system will automatically synchronize the device descriptions on the other workstations. To install a
device description:
1

Click Start | DeltaV | Engineering | DeltaV Explorer to open DeltaV Explorer.

Insert the device description disk or CD into the drive. (The device description can also be on a local shared hard
drive.)

Navigate to the Fieldbus Devices (Library/Fieldbus Devices).

Click the right mouse button and select Add Device Definition.

Browse for the location of the drive or directory where the device definition files are stored and click OK. You
are not required to select each file individually. The device definition files are automatically selected when you
select the drive. (If the directory contains more than one file of a needed file type, an error is displayed. The
duplicate file types must be removed before attempting to add the device.)

Read the Warning message. If you want to proceed with the installation, click Yes.

Follow the instructions to install the device description files.

Methods
Device Descriptions can also include a set of processing routines called Methods. Methods provide a way to access
and manipulate parameters within a device. For example a DD for a Valve Controller might include methods for
automatically calibrating valve travel, manually calibrating travel, restarting a device, and calibrating the internal
pressure sensor information for display. In the DeltaV system, the methods reside in the Transducer and Resource
blocks. Some methods, such as calibration methods are available through the context menus for the Transducer block.
Other methods such as the restart method, are available through the context menu for the Resource block.
To access a calibration method for a Digital Valve Controller, perform the following steps:
1

Click Start | DeltaV | Engineering | DeltaV Explorer to open the DeltaV Explorer.

Select the device from the All Containers pane.

Select the device's Transducer block from the Contents of pane, right-click, select Calibration, and then select the
desired calibration method.

258

System Configuration

To access the restart method for a Digital Valve Controller, perform the following steps:
1

Open DeltaV Explorer.

Select the device from the All Containers pane.

Select the device's Resource block from the Contents of pane, right-click, and then select Restart DVC.

I/O Configuration

259

Accessing Methods from DeltaV Operate


You can provide access to device methods from DeltaV Operate pictures using scripting that call the AMSMenu
application included with DeltaV software. The AMSMenu application opens a menu that contains device methods.
The command line for the AMSMenu application has two forms which take different command line parameters:
AMSMenu <dev tag> -bi <blk index>
AMSMenu -n <dev tag> -m <mfg id> -t <dev type id> -r <rev num>
-i <phys dev id> -bt <blk tag> -bi <blk index>
where
dev tag is the tagname of the field device in the database,
blk index is the block or object index of the device's Resource or Transducer block listed in DeltaV Explorer,
mfg id is the identifier code for the device manufacturer,
dev type id is the identifier code for the device type,
rev num is the device's revision number,
phys dev id is the unique identifier for this device type,
blk tag is the tagname of the resource or transducer block of the device,
blk index is DeltaV Explorer object index for the device's Transducer or Resource block.
Note: The mfg id and the dev type id must be the hexadecimal values.
With the first form, the AMSMenu application connects to the DeltaV database to get the manufacturer, type, and
revision of the device, then passes this information to the same AMS Device Manager interface that DeltaV Explorer
uses.

260

System Configuration

In the second form, the command line provides all the device information so the AMSMenu application does not
connect to the DeltaV database and is therefore faster.
For example, if your configuration includes a device named FY-101 that has the following characteristics:

Manufacture ID: 5100 (hex)

Device Type ID: 5900 (hex)

Revision Level: 7

Physical Device ID: 0051000100FisherDVC0112461319931

Block Tag: TRANSDUCER

Block Index: 450

The following script opens a menu when the object the script is attached to is clicked:
Private Sub Rect1_Click()
frsruntask "AMSMenu", "-n FY-101 -m 5100 -t 5900 -r 7 " _
& "-i 0051000100FisherDVC0112461319931 -bt TRANSDUCER -bi 450"
End Sub
The menu that it opens is:

These are the same methods that appear if you right click the device's Transducer block in DeltaV Explorer.
See Working with Other Applications in the DeltaV Operate manual for more information.

Autosensing Fieldbus Devices


When the H1 fieldbus cards are plugged into the I/O carrier, the fieldbus devices are connected to the H1 cards'
terminal block, the Device Descriptions loaded, the H1 card automatically detects the fieldbus devices, recognizes the
device types, and makes this information available to the DeltaV system.
Note The DeltaV system autosenses the H1 cards.
As with other cards and devices, you can add H1 cards and fieldbus devices as placeholders in the DeltaV Explorer. A
placeholder device matches the manufacturer and model of a device that has not been connected and holds the device
tag and address. When you are ready to commission the device, move it to Standby, and drag the device to the
placeholder. The device connects to the segment with the device tag and address that was specified for the
placeholder.

I/O Configuration

261

Commissioning and Decommissioning Fieldbus Devices


Commissioning and decommissioning fieldbus devices is done in the DeltaV Explorer and involves moving the
devices through several device states. The online help for the DeltaV Explorer explains how to commission and
decommission fieldbus devices. Fieldbus devices have five stable states in the DeltaV system:
Commissioned - For a fieldbus device that is at its assigned address. To move a commissioned device to the Off-line
or Spare state, you first decommission the device.
Caution It is recommended that if you intend to keep a fieldbus device in the Off-line or Spare states
(decommissioned) for any length of time, you remove the device from the segment. A decommissioned fieldbus
device is given a temporary address and failure to remove it from the segment could prevent normal commissioning
on the segment.
Off-line - For a fieldbus device that you want to disconnect for maintenance and then return to the segment at the
same address. For example, you would take a device offline to recalibrate it. If an off-line device is reconnected, it
automatically uses a standby address. You must commission the standby device by dragging and dropping it onto the
appropriate placeholder. After the device is commissioned, download the device in order to make it function as it did
prior to being decommissioned.
Spare - For a fieldbus device that you want to disconnect and no longer use in your DeltaV system. Each device has
a device tag that designates the role the device performs in the DeltaV system. If you decide that you no longer want
to use the device, you should clear its tag. To clear the tag, make the device spare. A spare device is part of your
inventory of spare devices, not an instrument with a specific purpose. If, at some time, you decide to put a spare
device back into service, the system moves it to Standby automatically when you attach the device to the segment.
Standby - A safety feature for fieldbus devices. The device is moved to a standby address until it is commissioned. A
device comes to standby from the Off-line and Spare states.
Mismatch - The fieldbus device was commissioned on another control system and then connected to a DeltaV
system. When the H1 card finds a device in the assigned address range that has not been commissioned for this
particular segment, it designates it as a mismatched device. A mismatch device can be commissioned.
Device Class Mismatch - The attached field device is not the same class for which the device was commissioned.
Schedule Download Failed - The LAS Schedule could not be downloaded to this field device.
The following figure shows state transitions in fieldbus devices.

State Transitions

262

System Configuration

A commissioned device is decommissioned to Spare. The device is usually removed from the segment after
doing this. A Spare device loses its address and device tag. Note that a commissioned device automatically
changes to a Spare if its placeholder is deleted.

A decommissioned device that has not been removed from the segment is placed in Standby. This might occur if
a Mismatch device had been made Spare and you want to put it in Standby without taking it off the segment.

A Standby device is dragged to an available placeholder that matches the manufacturer, device type and device
revision and is commissioned. Another way to commission a Standby device is to select Commission from the
device's context menu.

A commissioned device is taken Off-line - the device retains its tag and address. This is normally done when the
device is to be temporarily removed from the segment and reattached in the same service. The device must be
removed from the segment after it is taken Off-line.

A device can transition from Off-line to Standby when it is attached to a segment other than the one from which
it was removed.

A commissioned device is removed from a segment and attached to a segment other than the one from which it
was removed. The device might have been inadvertently attached to the wrong segment.

A Mismatch device is made Spare.

An Off-line device is made Spare. This is done if a device is placed on a segment with another device with the
same tag as this device. Making the device spare allows you to clear the device tag without removing the device
from the segment.

A Standby device can transition to Spare if it was previously in the Spare state before it was in the Standby state.

10 A Standby device can transition to Off-line if it was previously in Offline state before it was in the Standby state.
11 A device can transition from Mismatch to Off-line.
12 A Mismatch device is dragged to an available placeholder that matches the manufacturer, device type and device
revision and is commissioned. Another way to commission a Mismatch device is to select Commission from the
device's context menu.
Fieldbus devices can also go through the following transitional states:
Comm Initializing - The H1 card is establishing communications with the field device.
Unrecognized - The field device has not been commissioned at this address.
Unknown - The field device is transitioning between states.
Typically, a device will be in one of the above states for only a few seconds. If it remains in one of these states it
indicates a problem. Additionally, if a device goes into the Comm Fail state it indicates that the device is
communicating on the bus (it is in the live list) but communications between the H1 card and the device is currently
disrupted.
If a device remains in the Comm Initializing or Comm Fail state, cycle the device power. If a device remains in the
Unrecognized state, it either has not been commissioned or has been attached to the wrong segment. If a device is in
the Schedule Download Failure state, then the segment currently does not have a functional backup LAS. If a device
shows a Device Class Mismatch, there is something wrong with the device.

Diagnosing Fieldbus Devices


The DeltaV Explorer, Control Studio, and Diagnostics programs as well as the H1 card itself provide a great deal of
diagnostic information on fieldbus devices.

I/O Configuration

263

H1 Fieldbus Card
Communication information between the card and fieldbus devices is available from a visual inspection of the H1
card. The bottom two LEDs on the H1 card reflect communication between the port and fieldbus devices on that port.
A blinking yellow LED indicates that the port is communicating with fieldbus devices but either a communication
problem exists with an attached fieldbus device or no function blocks are configured on the segment. If the LED is
off, either the port is disabled or the H1 card is not communicating with any fieldbus devices on the port. Use the
DeltaV Explorer to enable and download the port and Control Studio to create and download configuration. A solid
yellow LED indicates good communication between the port and devices on that port and at least one function block
is configured on the segment.
DeltaV Explorer
Indicators in the DeltaV Explorer tell you if an H1 port or a fieldbus device needs to be downloaded or
commissioned.

The
on an H1 port or device means that the port or device needs to be downloaded. Select the port or
device, click the right mouse button, and then select Download to open a dialog box that lists the fieldbus
configuration information to be downloaded.

The
on a device means that the device needs to be commissioned. To commission the device, select it
from the Decommissioned device list and drag it to either the port or device placeholder.

Control Studio
Use Control Studio in online mode to diagnose problems with modules running in fieldbus devices. You must assign
and download a module before viewing it in online mode.
1

Open the module in Control Studio.

Click View | On-line to create an online (or debug) session in which you can examine module and block
parameters. A red X on a function block parameter indicates a problem with the function block.

Caution Any online changes affect your process because the changes are made to downloaded modules in the
controller. Use extreme care when changing values or stopping the execution of an algorithm.
3

Select the block with the red X. The Parameter View window in Control Studio displays a full list of parameters
for that block.

Double-click a parameter in Parameter View to open the Parameter Properties dialog for that parameter.

Diagnostics
Use DeltaV Diagnostics to perform the following tasks:

determine if the device is commissioned

check integrity on the H1 card, backup Link Master device, and ports

check overall port statistics and communication statistics for each device

Open DeltaV Diagnostics and click View | Details or View | Compare to quickly see the device state. If the device is
not commissioned, open the DeltaV Explorer and commission the device. Then, download the port and the device. If
the device is commissioned, check integrity on the port and then check port and device communication statistics.
Port Integrity
Typically, integrity problems originate below the node and then rise to the node level. Integrity problems are
indicated by the

264

overlay. Start by looking for a controller with the

overlay and, if found, expand the controller

System Configuration

hierarchy until you find the root cause of the problem. If a fieldbus card has an integrity problem, expand the card to
see which port has the problem. Select each port and look at the port's status. Possible port status values are:

Good - Good basic communications with all devices on this port

No Termination on Link - This port is not terminated. Check attached cable.

Link Error - PCMCIA Card problem exists. Replace the H1 card.

Duplicate Address on Link - Another device is currently communicating at this port's address.

No Communications on Link

H1 Card Problem - Replace the H1 card.

One or more function block problems on link or device problem - Expand the port and check the state of
each fieldbus device on the port. Any state other than Commissioned indicates a potential problem with that
fieldbus device.

Port Communication Statistics


The Port Statistics command provides a broad view of communication activity on the port. Click the right mouse
button on the port and then click Port Statistics. In the Port Statistics dialog look for the following:

Retries

Invalid responses

Stack errors

Timeouts

Note If any of the port statistics and communication statistics are continually increasing, a potential communications
problem could exist on this port. To isolate the problem, investigate the communication statistics on each fieldbus
device. Refer to the following section for information.
Next, look at detailed port statistics. Click the right mouse button on the port and then click Display Port Detail
Statistics. In the Detailed Port Statistics dialog, look for the following:

Identifies

Initiates

Aborts

Tip Clicking the Reset Stats button resets all values to 0 and makes it easier to read the statistics.
Device Communication Statistics
Finally, look at communication statistics for each device. Click the right mouse button on each device, click Display
Communication Statistics, and look for the following:

Aborts received and sent

Initiates received and sent

Pcr Timeouts

Livelist appearances - the number of times the device showed up as new

Fieldbus Device Status/Conditions


Fieldbus devices can be configured to detect and report specific device alert conditions directly to the DeltaV system.
These conditions can range from potential problems (such as hardware failures within the device, loop problems, and

I/O Configuration

265

misconfigured parameters) to proactive reporting of upcoming maintenance needed. To view Foundation Fieldbus
device conditions in DeltaV Explorer, right-click the device and select Status/Conditions.
Optionally, device alarms can be enabled on a Fieldbus device. When a device detects a condition, it will generate an
alarm, in addition to setting the appropriate condition on the status or conditions screen. The alarm is reported in the
Event Chronicle, is displayed in alarm summaries, and may be displayed in the DeltaV Operate alarm banner,
depending on user configuration (Series 2 H1 card required). A standard device faceplate shows the active alarms for
a fieldbus device. The detail button on the faceplate accesses the same screen as the Status/Conditions selection in the
DeltaV Explorer.
Device condition functionality is dependent on the device. Foundation Fieldbus devices support either standard
Foundation Fieldbus alerts or PlantWeb alerts.
Standard Foundation Fieldbus alerts - Devices report alerts in a single alarm: abnormal. This alarm is based on the
standard Block Alarm definition.
PlantWeb alerts - Devices report alerts in one of three alarms: failed, maintenance and advisory. The device alerts
have been organized into one of these alarms based on the importance of the alert condition to the health of the
device.
With the DeltaV system, all Foundation Fieldbus devices also have a communications failure alarm. This alarm is
generated when the DeltaV software recognizes that a device is no longer communicating on the H1 segment.

Fieldbus devices that support PlantWeb alerts also allow you to suppress conditions from the Status/Conditions
screen. Suppression from the Status/Conditions screen prevents the device from reporting the condition to the DeltaV
system. It is also possible to prevent reported alarm conditions from appearing in the alarm banner and alarm list.
This type of alarm suppression is described in the Suppressing Device Alarms topic.

266

System Configuration

Suppressing Device Alarms


You can suppress device alarms from several places in the DeltaV system:

For an alarm category (failed, maintenance, advisory), use the alarm's faceplate in DeltaV Operate.

For conditions of an alarm category, use the Status/Conditions dialog from the device's context menu.

Because alarms contain multiple conditions, suppressions at the alarm category level will always override
suppressions at the condition level.
Example:
A fieldbus device reports that it is due to be calibrated. The Calibration Due condition appears as a Maintenance
alarm in the Status/Conditions dialog, the DeltaV alarm banner, and Event Chronicle. Because regular service is
scheduled for the following week, the user might choose to suppress all Maintenance alarms from that device using
the Details faceplate. Alternatively, the user could choose to suppress only the Calibration Due condition from
appearing in the alarm banner and the Event Chronicle by checking the box above the condition in the Status/
Conditions dialog for that device. In both cases, the Status/Conditions dialog continues to display the condition as
active.

Viewing the Audit Trail


Device Audit Trail software enables the DeltaV system to maintain an audit trail of historical records, called events,
for fieldbus devices. Device Audit Trail records changes to a device's configuration, such as changes made from a
resource or transducer block's properties screen or context (right-click) menu. When a user changes a device's upper
or lower sensor trim, for example, Device Audit Trail records the changes. An audit trail is maintained for all standby
and commissioned fieldbus devices.
The Device Audit Trail is not installed with the DeltaV software. The setup file is located in the DV_Extras directory
on disk 3 of the DeltaV installation CDs . Refer to the DeltaV Release News for Device Audit Trail upgrade
procedures.
Once the software is installed and licensed, you can view events for a device by selecting the Resource or Transducer
block and right-clicking Audit Trail. The events displayed are associated with the selected block.
The audit trail display includes the following information for each event:

date and time of the event

user who made the change

event type (configuration change in the current version)

reason the event was recorded

application affecting the change

Foundation Fieldbus Blocks


Foundation Fieldbus has defined a standard user application based on blocks. Blocks are representations of different
types of application functions. The blocks in a user application are: resource blocks, function blocks, and transducer
blocks. The arrangement and interconnections of the blocks determine the function of the fieldbus devices.
Resource Block
The resource block describes the characteristics of the fieldbus device such as device name and type, manufacturer,
serial number, amount of free memory, and free time. There is only one resource block in a device. You can access the
resource block in the DeltaV Explorer to perform the following:

I/O Configuration

267

examine the status of the fieldbus device

view and change resource configuration

initiate a master reset or self-test of the fieldbus device

Function Blocks
Function blocks provide the control system behavior. The input and output parameters of the function blocks can be
linked over the fieldbus segment. For example, a simple temperature transmitter contains an AI function block; a
control valve might contain a PID function block as well as the AO block. As with other function blocks, you
configure these function blocks in Control Studio and then assign them to run in the fieldbus devices. During a
download, the function block tag that is configured in the DeltaV Explorer is downloaded to the device and the
function block tag in the device is overwritten. Refer to the section "Configuring Fieldbus Function Block Tags" in
Using Fieldbus in the Control Strategy for more information on fieldbus function block tag names.
Transducer Block
The transducer block performs front end processing of data signals received from the I/O and offloads this work from
the function block. For example, a transducer block might read a signal from a sensor and convert the signal to
Engineering Units, thus relieving the function block of the conversion task. The transducer block contains
information, such as calibration date and sensor type. There is usually one transducer block for each AI and AO
function block.
You can access the transducer block in the DeltaV Explorer to do the following:

display status of the sensors

view and change configuration such as transducer block parameters

change the sensor upper, lower, and zero trim

Fieldbus Device Configuration Procedures


Inside this topic
Create a Device Placeholder
Commission a Device
Replacing a Commissioned DeviceComparing Fieldbus Device Configurations
Uploading Fieldbus DevicesInstalling Generic Fieldbus Devices
This document explains how to use the DeltaV applications to perform common procedures on fieldbus devices, such
as creating device placeholders and commissioning devices. This is not a comprehensive resource as requirements for
a host system, such as the DeltaV system, differ between devices but, rather, a starting point. For complete
information, refer to the device's user manuals, the online help for the DeltaV applications, and related Books Online
topics.

Create a Device Placeholder


Device support files must be installed before you can add a device to the segment or create a device placeholder. The
DeltaV system includes built-in support for a number of fieldbus devices from different device manufacturers. The
files necessary to support these devices are included in the DeltaV install image and are available in the DeltaV
Explorer library (DeltaV System / Library / Fieldbus Devices). If a fieldbus device is not included in the DeltaV
install image, you must install a set of device support files for that device. Many device files that have been tested
with the DeltaV system are available from the website www.EasyDeltaV.com/fda. If the device files that you require
are not available on the website, contact the device manufacturer. Refer to the Device Descriptions and Methods topic
for information on how to install device support files.

268

System Configuration

About Device Placeholders


A device placeholder is an electronic representation of a device that exists in the DeltaV database with no associated
physical device. You can use a placeholder to configure block parameters offline and have your control strategy in
place prior to attaching the device to the segment. When you are ready, you can attach the device to the segment and
use the DeltaV system to reconcile any differences between the placeholder and the device when you commission the
device.
Note The use of placeholders is optional and depends on the size and requirements of your fieldbus application.
However, it is recommended that you use placeholders for large applications. If you do not want to use placeholders,
you can attach your devices directly to the segment.
1

Click Start | DeltaV | Engineering | DeltaV Explorer to open DeltaV Explorer.

Navigate to the fieldbus ports. The ports are under the fieldbus H1 card. The card is under the I/O subsystem.

Right-click the port to which you want to attach the device placeholder and select New Fieldbus Device. The
Fieldbus Device Properties dialog opens.

Enter the appropriate information about the device in the dialog box. The DeltaV system selects an address. You
can customize this field, but it is not necessary. Select the device type and revision based on the type of device
you want to add. The device properties must match the properties of the device you will commission later.

I/O Configuration

269

Remember that DeltaV Explorer has extensive online help. Click the Help button on this dialog box for help on
any of the fields.
Fieldbus devices often provide error detection for a variety of device conditions. Refer to Device Alarms
Overview and Configuring Device Alarms for more information. Select the Alarms and Displays tab in the
Fieldbus Device Properties dialog to enable Device Alarms to be reported by the device.
Note The alarms and displays tab is only shown when supported by the DeltaV hardware. Device alerts are supported
by Series 2 H1 cards.
Each device can also be configured with a primary control display and faceplate. DeltaV software includes a
standard device faceplate.
5

Click OK to add the device placeholder to the segment. The device appears as a decommissioned device on the
segment.

When device alarms are enabled, alarms become visible in the right pane in DeltaV Explorer when you select the
Fieldbus Device Alarms icon for the device. Select an alarm and right-click properties to enable or disable it or to
change the alarm's priority.

Commissioning a Device
Commissioning a device assigns it an address on the segment and makes the device available to the DeltaV system.
You use the DeltaV Explorer to commission devices. You can reconcile any differences between the device and the
placeholder during the commissioning process. After commissioning a device, you download.

270

System Configuration

Attach the device to the segment.

Click Start | DeltaV | Engineering | DeltaV Explorer to open the DeltaV Explorer.

The device should appear under Decommissioned Fieldbus Devices. It may take a minute for the device to
appear. Tip: Press the F5 key to update the list.

The device must be in the Standby state before you can commission it. To determine if a device is in Standby,
select Decommissioned Devices, click View | Details from the menu bar, and be sure that the words "Standby
Fieldbus Device" appear under Type in the right pane.

If the device is not in Standby, select the device in the right pane, click the right mouse button, and select
Standby. It may take a minute or so for the device to transition to Standby.
5

Now be sure that the decommissioned device's properties, Device Type, Manufacturer, and Device Revision,
match the placeholder properties. To check the properties, select the item, click the right mouse button, and select
Properties. If necessary, edit the placeholder properties to match the device properties. (For information about
how to create a placeholder, refer to the Create a Device Placeholder topic.)

Select the device from the Decommissioned Fieldbus Devices list and drag it to the placeholder.

The Device Commissioning Wizard - Start opens.

I/O Configuration

271

Read the information on the Device Commissioning Wizard - Start dialog and click Next to open the Device
Commissioning Wizard Reconcile Device dialog.

We will use this dialog to reconcile any differences between the placeholder and the device.
8

272

Click the Reconcile Device button. (If you do not click this button and click Next instead, the parameters in the
device will remain as they are and will overwrite the parameters in the placeholder when you commission the
device.) The Reconcile Device dialog shows two sets of fieldbus device configuration parameters: parameters in
the placeholder and parameters in the device. This dialog allows you to transfer parameters from a placeholder to
a device and edit parameters in the device. The following figure shows the dialog for reconciling resource block
parameters.

System Configuration

Click the Help button and read about reconciling device parameters. Click the Transducer block in the
upper left corner of the Reconcile dialog to reconcile the transducer block parameters. Read the device
documentation before reconciling transducer block parameters.

Click OK when you are finished reconciling parameters and then click Finish to commission the device.

It may take a little while to commission the device. Several factors contribute to the time it takes to
commission. Among these are the number of function blocks and devices and the time it takes for devices to
move through the various device states.

Replacing a Commissioned Device


The Fieldbus Device Replacement Wizard guides you through the process of replacing a commissioned fieldbus
device. In DeltaV Explorer, select Replace from the device's context menu to open the Fieldbus Device Replacement
Wizard.

I/O Configuration

273

The wizard:

Checks for configuration changes since the last download

Uploads function block parameter changes from the existing device if it is still on the network

Uploads AMS data in the existing device

Decommissions the existing device

Commissions and downloads the replacement device

Follow the instructions on the wizard to proceed through the replacement process.
Here are a few guidelines for using the wizard:

274

You must have the key to the lock associated with the VC_DEVICE_CHECKOUT_CHECKIN and
REPLACE_DEVICE functions. By default, these functions are associated with the Can Calibrate lock.

The replacement device must be of the same type and manufacturer as the existing device. The device
revisions can differ as long as the same function blocks are supported between revisions.

The replacement device, which may or may not be physically connected to the fieldbus segment, must be in
Standby or Mismatch.

The existing device, which may or may not be physically connected to the segment, must be commissioned.

If the existing device is connected, it must be disconnected before the new device is selected to replace it.

System Configuration

Comparing Fieldbus Device Configurations


You can compare the configurations of two fieldbus devices. The devices can be two physical or placeholder devices
(or one of each), but must be the same device type and revision. You can compare (and copy, depending on device
state and configuration selected) parameter information between:

Two configurations of a single fieldbus device (current to historical or historical to another historical)

Two commissioned fieldbus devices (current to current, current to historical, historical to current, historical
to historical)

A placeholder and a standby fieldbus device during commissioning of the standby device

A placeholder and a commissioned fieldbus device

Two placeholders

Reconciling is the process of comparing configurations before commissioning. When you drop a device onto the
fieldbus port, you are commissioning it. If the configuration differs from the current values, you have the opportunity
to reconcile the values in either configuration to the other. A wizard steps you through the process.
Configuration and configuration comparisons are available from the device context menu.
Uploading Fieldbus Devices
You can upload parameter values from function blocks running in a commissioned fieldbus device to the database.
This is useful if you want to ensure that factory-set parameter values are maintained in the database or that values
modified by a technician in the field are uploaded to the database. Parameter changes to the following function blocks
can be uploaded to the database: AI, AO, DI, DO, Fieldbus Multiplexed AI, Fieldbus Multiple DI, Fieldbus Multiple
DO.
Unlike controllers where the system detects a need to upload changes, the system does not detect a need to upload
changes to fieldbus device parameters. To upload a fieldbus device, select the device in the DeltaV Explorer, and
select Upload Function Blocks. There is no need to download the device after an upload.
Installing Generic Fieldbus Devices
The DeltaV system requires a set of device definition files for each fieldbus device type and device revision. Many
fieldbus device definition files are pre-installed with the DeltaV system. However, when you install a generic fieldbus
device, you must first install the device's definition files from the ProfessionalPLUS workstation. After you install the
device definition files from the ProfessionalPLUS workstation, you synchronize the device definitions on the other
DeltaV workstations in order to make the other workstation's device definitions current with those on the
ProfessionalPLUS workstation.
Use the DeltaV Explorer on the ProfessionalPLUS workstation to load the device definition files. Refer to the DeltaV
Explorer online help for information on installing fieldbus device definition files.
Note Fieldbus devices that are supported on the DeltaV system have been tested for interoperability with the DeltaV
system. Non-supported devices have not been tested for interoperability with the DeltaV system and may not operate
properly.

I/O Configuration

275

Serial Devices and the DeltaV System


Inside this topic
Configuring a Serial Card
Configuring Port Properties
Configuring a Serial Device
Configuring a Dataset
The standard DeltaV Serial Card supports serial devices that use the Modbus RTU or ASCII protocol. The
programmable Serial Card supports custom protocols. Both cards communicate through RS232, RS422/485 half
duplex, or RS422/485 full duplex signals. The Serial Cards support both master and slave modes of communications.
Master mode is normally used to communicate with a PLC or other third party device supporting the Modbus
protocol. In this mode, the Serial Card is the master device on the serial communications link and controls the
requesting of data from the other device. Slave mode is used for connection to a Modbus master device. In slave
mode, the Serial Card acts as a slave to the connected device responding to data read and write requests issued by the
master. The card is capable of emulating up to 16 slave devices on each port. You configure the devices on the port
and set them to different slave addresses. If you want a serial card to have one slave address, configure a port with
only one device object and create all the datasets under that device. Datasets are described in more detail below.

Configuring a Serial Card


The Serial Card is one of the card types in the DeltaV Explorer. You configure it as you would any other card. For
example, you can plug in the card and have the system auto-sense it, or you can configure a placeholder for the card
before connecting the actual card.
Each Serial Card has two ports. Each port can support as many as 16 serial devices.
The DeltaV Explorer help describes how to add Serial Cards to your I/O subsystem.

Configuring Port Properties


Once you have configured a Serial Card, you can set the serial port properties and add serial devices to the ports. The
following table describes the configurable serial port properties.
Serial Port Properties
Property

Valid Values

Description

Baud rate

300, 1200, 2400, 4800,


9600, 19200, 38400,
57600, or 115200

Determines the baud rate for serial data exchange.

Data bits

7 or 8

Determines the number of data bits. Use 7 for ASCII and 8 for RTU
mode.

Description

As many as 256
characters

Describes the use of the port. This description only appears when
you view the port properties from the DeltaV Explorer.

Enabled

Checked or not checked

Enables the port. If the port is not enabled, the Serial Card does not
scan for input data or transmit output when in master mode and does
not respond to Modbus messages when in slave mode.

276

System Configuration

Property

Valid Values

Description

Message
timeout (ms)

100 ms through 25.5


seconds in 100 ms
increments

Determines the amount of time the Serial Card waits for a response
from the serial device after sending a request message. More
specifically, this indicates the time from when the Serial Card sends
the last character of the request message until the time the last
character of the response message is received. This property is only
applicable when in Modbus master mode.

Mode

Master or Slave

Determines whether the port acts as a Modbus master or slave.

Parity

Even, Odd, None

Determines the parity.

Port type

RS-232, RS-422/485
Full Duplex, RS-422/
485 Half Duplex

Determines the port type to be used for the serial connection.

Retry count

0 through 255

Determines the number of times the Serial Card retries a failed


message. This is only applicable when in master mode. When the
Serial Card issues a Modbus request to a device, it expects a
response message to be returned. If no response or an error response
is returned, the Serial Card retries the failed message the number of
times configured in the Retry count property.

Send outputs
on startup

Checked or unchecked

Determines whether the Serial Card sends all current output values
to the serial devices on power-up, reset, switchover or after a
download. This property is only applicable when in Modbus master
mode.

Stop bits

1 or 2

Determines the stop bits.

Transmit
Delay (ms)

100 ms through 25.5


seconds in 100 ms
increments

Determines the amount of time the Serial Card delays between


requests for input data and/or requests to write output data to the
Modbus Device. This value is used to slow down Modbus master
requests being transmitted to slave devices that require a time delay
between requests. The default Transmit Delay value is 0 since most
Modbus devices do not require any delay. This value can also be
used when in slave mode to delay the response to a Modbus master
request.

Note RS-485 Full Duplex is not supported when the card is


configured as a Modbus slave in a multidrop configuration.

Configuring a Serial Device


To set a port to a specific modbus address, configure a device on the port and set the device address to the desired
slave address. The DeltaV Explorer help provides step-by-step instructions for adding serial devices.
For example, the following steps describe how to configure two serial devices (a multi-port configuration) connected
to port 1 of a serial card.
1

Select port 1 (PO1) of the serial card.

Right-click and select New Serial device.

Set the device address to match the address of the physical device connected to the serial card.

Repeat steps 1 through 3 for the second device. Set the address of the second device to match the address of the
physical device connected to the serial card.

I/O Configuration

277

Configuring a Dataset
In master mode, the Serial Card exchanges data with the serial device through a dataset. A dataset is a collection of
parameters associated with a serial device. The parameters in the dataset hold data values that correspond to registers
or data in a serial device.
The dataset defines the type and amount of data being sent to or received from the serial device. All the data values
for a dataset have the same properties. Properties include the data type, data direction, and so on. The data values in a
dataset map to a contiguous series of serial device registers or data.
In slave mode, the Serial Card emulates sets of data through datasets. The datasets are used to define the data that the
Serial Card and DeltaV system are to emulate. The dataset in the slave mode defines the type and amount of data the
Serial Card supports. All the data values for a dataset have the same properties.
You can create as many as 16 datasets for each Serial Card port. These 16 datasets can be allocated to the serial
devices in several ways. For example, you can configure one serial device with 16 datasets, or you can have 16
devices on the port with one dataset each.
The DeltaV Explorer help describes how to add a dataset for a Serial Card. Basically, you define the dataset through
the Serial Dataset properties dialog. The following table defines the fields in the dialog.
Serial Dataset Properties
Property

Card Type

Valid Values

Description

Data direction

Standard,
Programmable

Input or output

Defines whether this dataset sends DeltaV data


to a serial device (output) or receives data
from a serial device (input). The Data
Direction indicates whether this data set is
input data from the slave device or output data
to be sent to the slave device when in master
mode. The Data Direction is not needed when
in the slave mode. The default value for Data
Direction is Input.

Dataset Tag

Standard,
Programmable

An existing Dataset Tag or


a new Dataset Tag you
create by typing in a name.

Identifies the Dataset Tag associated with this


dataset. You use the Dataset Tag when
configuring a module that reads from or writes
to a serial device.

DeltaV data
type

Standard,
Programmable

Boolean; discrete; 8-bit,


16-bit, and 32-bit signed
integers; 8-bit, 16-bit, and
32-bit unsigned integers;
floating point; and string

Determines the type of data this dataset


contains (Boolean, discrete, integer, floating
point, and so on). This field value creates
storage space for the dataset and determines
how the DeltaV System accesses the data. The
String data type is only valid if the PLC data
type is input registers or holding registers.

DeltaV start
address

Programmable

0 to 65535

Indicates to which device address this dataset


corresponds.

Description

Standard,
Programmable

As many as 256 characters

Describes the use of the dataset. This


description only appears when you view the
properties of the dataset from the DeltaV
Explorer.

278

System Configuration

Property

Card Type

Valid Values

Description

Number of
values

Standard,
Programmable

Standard cards: dependent


on the PLC data type and
the DeltaV data type.
Refer to the table entitled
Maximum Number of
Values for Datasets for
details.

Standard cards: the number of Modbus values


(registers or coils) to be read or written when
in master mode. When in slave mode, the
Number of Values defines the size (in registers
or coils) of the data set used to emulate
Modbus data.

Programmable cards: 0 to
100.

Programmable cards: the number of data


values to be read from or written to the custom
device.

Output mode

Standard,
Programmable

Complete block or single


value

The Output Mode controls how output data is


transmitted to the Modbus slave when the
Serial Card is in master mode. If the Output
Mode is set to Block, then the entire data set is
output when any value in that set changes. If
the Output Mode is set to Single Value, then
the outputs are set to the Modbus device one
value (register or coil) at a time when the
values are changed. The Output Mode is only
configurable if the Data Direction is set to
output. The default value for the Output Mode
is Block.

Output read
back

Standard,
Programmable

Checked or unchecked

Determines whether the output dataset should


be read back during the Serial Card's input
scan. If this box is checked, the Serial Card
reads back the values during the card's next
input scan. The values that are read back
update the current output values. If this box is
not checked, no output read back will be
performed. You can only configure this field if
the Data direction is set to output. This field is
not applicable when in slave mode.

PLC data type

Standard

For outputs: coils or


registers
For inputs: coils, input
status, input registers,
holding registers,
diagnostic data
For slave mode: coils,
input status, input
registers, or Holding
Registers

For master mode, defines which data table to


read from or write to in the serial device.
For slave mode, defines which data table
(type) the Serial Card is to emulate.

PLC register
offset

Standard

An integer from 0 to 9999

Identifies the starting register that maps to the


first dataset parameter.

I/O Configuration

279

Property

Card Type

Valid Values

Description

PLC start
register
address

Standard

Read only

Indicates the PLC register address


corresponding to the first value in the Modbus
device or configured data type.

Special Data

Programmable

0 to 65535

Special Data fields can be used for any


purpose not covered by the standard fields.

For example, the user needs a dataset with the following parameter values:

Output mode: Output

DeltaV datatype: floating point

PLC datatype: holding registers

Number of values: 2

The following steps describe how to configure the values:


1

Select the device (for example, Dev01 under port PO1).

Right click and select New Dataset.

On the General tab select output in the Data direction field.

On DeltaV tab select Floating point with status in the DeltaV data type field.

On PLC tab select holding registers and set Number of values to 2.

Maximum Number of Values for Datasets


The following table defines the number of values supported in a dataset depending on the PLC data type and the
DeltaV data type defined for the dataset.
When mapping serial device register data to 32-bit signed or unsigned integers or floating point values, the Serial
Card maps two consecutive serial device registers to one of these 32-bit data values. Therefore, when calculating the
actual number of DeltaV parameters associated with a dataset of these types (32-bit signed or unsigned integer or
floating point), the number of DeltaV parameters is half the number of values configured for the dataset.
If the data type is string, the Serial Card reads one string from the serial device. The size of the string is defined by the
Number of values field. The size is the number of values * 2. The default value for the number of values field is 1.
Maximum Number of Values for Datasets
Serial Device Data
Type

DeltaV Data Type

Maximum
Number of
Values

Coils, Input Status

All except 32-bit signed and unsigned


integer and floating point

100

Coils, Input Status

32-bit signed and unsigned integer


and floating point

50

280

System Configuration

Serial Device Data


Type

DeltaV Data Type

Maximum
Number of
Values

Input Registers, Holding


Registers

All data types

100

Diagnostics

All data types

17

Modbus Function Codes Supported


The Serial Card uses the following Modbus Communications Protocol function codes to read and write values to and
from the Modbus Device when acting as a Modbus master device. These same Modbus function codes are supported
in slave mode to allow the master device to read and write data to and from the Serial Card.
Supported Modbus Function Codes
Code

Meaning

Description

Read Coil Status

Obtains current status (on/off) of a group of logic coils

Read Input Status

Obtains current status (on/off) of a group of discrete inputs

Read holding registers

Obtains current binary value in one or more holding registers

Read input registers

Obtains current binary value in one or more input registers

Force Single Coil

Forces logic coil to a state of ON or OFF

Preset Single Register

Writes a single binary value into a holding register

Diagnostics

In master mode, Subfunction 2 is used to retrieve the Diagnostic


Register of a PLC.
In slave mode, Subfunction 0 is supported to allow remote masters to
check the Communications link.

15

Force Multiple Coils

Forces a series of consecutive logic coils to defined ON or OFF states

16

Preset Multiple Registers

Writes specific binary values into a series of consecutive holding


registers

17

Report Slave ID

Obtains the Run (on/off) state of a PLC

Using Serial Data in Control Strategies


Inside this topic
Reading or Writing an Operator Display's Serial Data Using a Serial Dataset DST
Writing an Operator Display's Setpoint to a Specific Dataset Register
Writing an AI Value to a Specific Dataset Register
Reading a Dataset Value Using an Internal Read Parameter
Reading a Dataset Value Using an AI Block
Creating Alarms for Dataset Registers

I/O Configuration

281

Serial device data can be read or written from the Operator Display by referencing the DST/register number
parameter associated with the containing data set in an Operator Display Data Link.
Reading or Writing an Operator Display's Serial Data Using a Serial Dataset DST
1

Open a display for editing.

Click the Data Link tool from the graphics toolbox.

Drag the Data Link to the desired location on the display and click the left mouse button.

Enter the dataset's DST name followed by the register number in the tagname field (for example:
CTLR101010101/R40101). You can also use the Parameter Browse feature to browse for the DST and register
name.

Set the other Data Link parameters to their desired values and click OK.

You can use serial device data in control modules. For example, use serial data as the I/O reference in standard
function blocks or create module-level parameters that reference the Dataset Tag and parameter associated with the
register with which you want to work.
The following specific examples describe how to read from and write to serial devices using a control module and a
control module reference.
Writing an Operator Display's Setpoint to a Specific Dataset Register
1

Create a module containing an Internal Write parameter (located on the Special Items palette).

Modify the Internal Write parameter properties by selecting a parameter type of External Reference.

For the External parameter path field, click Browse. Click Device Tags in the Type field and All Device Tags in
the Look in field. The list includes dataset tags.

Double-click the dataset tag that contains the parameter (register) that corresponds to the dataset value that you
want to write to.

Double-click the parameter. This parameter can be linked to a display's input data field. The result in Control
Studio looks like this:

Writing an AI Value to a Specific Dataset Register


1

Create a module containing an Analog Input block.

Double-click the IO_IN parameter and then click Browse to select a specific analog input channel.

282

System Configuration

If desired, scale the analog input value using the XD_SCALE, OUT_SCALE, and L_TYPE parameters.

Add an Internal Write parameter to the diagram. The Internal Write parameter is on the Special Items palette.

Modify the properties of the Internal Write parameter by selecting a parameter type of External Reference.

For the External parameter path, click Browse. Select Device Tags in the Type field and All Device Tags in the
Look in field. The list include dataset tags.

Double-click the dataset tag that contains the parameter (register) that corresponds to the dataset value to which
you want to write.

Wire the AI block's Out parameter to the Internal Write parameter. The result in Control Studio looks like this:

Note Any value that is on the Output side of the AI block is written to the serial device regardless of the status of the
AI block.

Reading a Dataset Value Using an Internal Read Parameter


1

Create a module containing an Internal Read parameter (located on the Special Items palette).

Modify the properties of the Internal Read parameter by specifying a parameter type of External Reference.

To select an External parameter path, click Browse. Click Device Tags in the Type field and All Device Tags in
the Look in field. The list include dataset tags.

Double-click the dataset tag containing the parameter (register) that corresponds to the dataset value that you
want to read from.

Double-click the parameter. This parameter can be linked to a display. The result in Control Studio looks like
this:

Reading a Dataset Value Using an AI Block


1

Create a module containing an Analog Input block.

Double-click the IO_IN parameter.

To select a device tag, click Browse. Click All Device Tags in the Type field. This shows all the Device Tag
names including the dataset tag name you want to read.

Double-click the Device Tag that contains the parameter (register) from which you want to read.

Double-click the parameter.

If desired, scale your input value using the Analog Input block's XD_SCALE, OUT_SCALE, and L_TYPE
parameters. The result in Control Studio looks like this:

I/O Configuration

283

Creating Alarms for Dataset Registers


The Monitor Wizard creates a module containing alarms for each register in a dataset that you specify. You access the
wizard through the DeltaV Explorer in one of two ways: Either click the area where you want the module to reside
and then right-click Monitor Data Wizard or drag the dataset to the area. Refer to the DeltaV Explorer help for the
specific procedure.
For floating point values, the wizard creates alarms using the Alarm Limit function block. For discrete values, the
wizard creates module-level alarms. In either case, external reference parameters bring in the dataset register values.

Serial Card Outputs


The following sections describe how output data is handled by the Serial Card.
Send Outputs on Startup
Each port on the Serial Card contains a configuration item called Send Outputs On Startup that controls how outputs
are handled on initial configuration of the Serial Card and during switchover for Series 2 redundant Serial cards. This
feature applies only to output datasets. If this configuration item is not enabled in the serial port configuration, initial
output values are not sent out to the Modbus devices connected to the port under any circumstances.
If Send Outputs on Startup is set then, in most cases, the card sends the current outputs to the serial devices on powerup, reset, download, and switchover. If a dataset is being configured for the first time, it is transitioning from the
unconfigured to the configured state. In this case, the card sends initial values to the serial devices instead of current
values.
If a Serial Card that was previously configured is downloaded again or partially downloaded, the initial values are not
sent to the Modbus devices even if the Send Outputs On Startup configuration item is enabled. If a new output dataset
is added to a Serial Card configuration and the card is downloaded again, initial output values for the newly
configured dataset are sent to the Modbus Device, but any other datasets that were previously configured do not send
out their initial values.
Specify the initial output values through the dataset registers. To access the register values, click the dataset in
Explorer. The registers are displayed in the right pane with names like R1, R2, and so on. Right-click a register to
enter an initial value.
Redundant Serial Card Switchovers
When Send Outputs on Startup is enabled for Series 2 redundant Serial cards, the last output value is sent to the
Modbus devices connected to the serial port when the cards switchover. If the values in your Modbus devices change
frequently, it is recommended that you enable Output Readback on the output datasets to ensure that the Modbus

284

System Configuration

devices maintain their values. Refer to the following topic, Using Outputs in Control Modules, for more information
on this option.
Using Outputs in Control Modules
When using serial output data in control modules, remember that the output values are only sent to the Modbus
devices when the value changes. This might cause problems if there is a program running in the Modbus device (for
example, a PLC) that could overwrite a register being used for output data by a DeltaV control module. The DeltaV
control module might think that the output register has one value in it when it actually contains a different value
written by a third party. The control module does not send the output value to the Modbus device until the output
value changes. To prevent this situation, enable the Output Readback option for any output datasets that could be
changed by a third party. When the Output Readback option is enabled, the Serial Card reads the output values from
the Modbus device during its normal input scan and updates the corresponding values in the DeltaV system if they
change. This ensures that the output register values in the DeltaV system always match what is actually in the
Modbus device.

Serial Card Data Mapping


Inside this topic
Mapping of Modbus Coils and Input Status
Mapping of Modbus Input Registers and Holding Registers
Mapping of Modbus Diagnostics
Mapping of DeltaV Data to Modbus Coils and Input Status
Mapping of DeltaV Data to Modbus Input and Holding Registers
Mapping of Modbus Coils and Input Status
Modbus coils and input status values are both single bit values. The Serial Card treats both types of values the same
with regard to data mapping. The mapping details for each data type are described in the following table.
Mapping Coil and Input Status Data to DeltaV Data Types
DeltaV Data Type

Mapping Method

Boolean

The card maps each coil or input status value directly to


a single Boolean value with no data conversion.

Discrete, signed integer,


unsigned integer, and floating
point

The card sets the integer or floating point value to 0 if


the coil or input status bit has a value of 0 or to 1 if the
coil or input status bit has a value of 1.

String

Not supported.

Mapping of Modbus Input Registers and Holding Registers


Modbus input registers and holding registers are both 16 bit values read from or written to the Modbus device. The
Serial Card treats both register types the same with regard to data mapping.

I/O Configuration

285

Mapping Input and Holding Register Data to DeltaV Data Types


DeltaV Data Type

Mapping Method

Boolean

The card sets the Boolean value to 0 if the Modbus register has a value of 0
and to a value of 1 if the Modbus register has a value other than 0.

Discrete, 8 bit signed integer and


8 bit unsigned integer

The card maps the lower 8 bits of the Modbus register to the DeltaV value
with no additional conversion.

16 bit signed integer and 16 bit


unsigned integer

The card maps all 16 bits of the Modbus register directly into the DeltaV
integer value.

32 bit signed integer and 32 bit


unsigned integer

The card maps two consecutive Modbus registers to the DeltaV value. The
first register is the least significant word, and the second register is the most
significant word.

Floating point

Floating point values are stored on Modbus PLCs in IEEE format in two
consecutive registers where the first is the least significant word and the
second is the most significant word. The Serial Card maps the two
consecutive Modbus registers to the DeltaV floating point value using the
first register as the least significant word and the second as the most
significant word.

String

The Number of values field indicates the size of the string. The Serial Card
maps the specified registers to a single DeltaV string with a length equal to
number of values * 2. The first register specified contains the first two
characters of the string where the high order byte of the register contains
the first character and the low order byte contains the second character. The
remaining registers contain the rest of the string characters in the same
order.

Mapping of Modbus Diagnostics


The Modbus diagnostics supported by the Serial Card contain the PLC diagnostic register contents and the PLC run
indicator. The Serial Card treats this data as 17 discrete bits of data. The first 16 bits correspond to the PLC
diagnostics register information, and the seventeenth bit is the PLC run indicator. This information is retrieved from
the Modbus device using function codes 8 and 17. For data mapping purposes, the Serial Card treats this data as if it
were 17 coils or input status values. Therefore, the data is mapped to DeltaV data types exactly like coil and input
status data are mapped.
Mapping of DeltaV Data to Modbus Coils and Input Status
Modbus coils and input status values are both single bit values and are treated the same for data mapping purposes by
the Serial Card.

286

System Configuration

Mapping DeltaV Data Types to Coil and Input Status Data


DeltaV Data Type

Mapping Method

Boolean

The card maps each DeltaV Boolean value directly to a single


Modbus coil or input status value with no data conversion.

Discrete, signed integer, unsigned


integer, and floating point

The card sets the coil or input status to a value of 0 if the DeltaV
value is 0 and to 1 if the DeltaV value is anything other than 0.

String

Not supported.

Mapping of DeltaV Data to Modbus Input and Holding Registers


Modbus input registers and holding registers are both 16 bit values read from or written to the Modbus device. The
Serial Card treats both register types the same with regard to data mapping.
Mapping DeltaV Data Types to Input and Holding Registers
DeltaV Data Type

Mapping Method

Boolean

The card sets the Modbus register to 0 if the Boolean has a value of 0 and to 1
if the Boolean has a value of 1.

Discrete, 8 bit signed integer


and 8 bit unsigned integer

The card maps the DeltaV value to the lower 8 bits in the Modbus register and
sets the upper 8 bits to 0.

16 bit signed integer and 16


bit unsigned integer

The card maps all 16 bits of the DeltaV integer directly into the Modbus
register.

32 bit signed integer and 32


bit unsigned integer

The card maps the DeltaV value to two consecutive Modbus registers. The
first is the least significant word, and the second is the most significant word.

Floating point

Floating point values are stored on Modbus PLCs in IEEE format in two
consecutive registers with the first being the least significant word and the
second being the most significant word. Therefore, the Serial Card maps
DeltaV floating point values to two consecutive Modbus registers. The first
register contains the least significant word, and the second contains the most
significant word.

String

The Number of values field indicates the size of the string. The Serial Card
maps the string to consecutive Modbus registers starting with the start register
configured for the dataset. The first Modbus register contains the first two
characters of the string with the high order byte containing the first character
and the low order byte containing the second character. The card maps the
remaining characters in the string to ascending Modbus registers with the
characters in the same order in the registers.

I/O Configuration

287

HART Devices and the DeltaV System


The DeltaV system provides the capability to interface to HART devices. The HART information is communicated
digitally and is very helpful for device diagnostics. This information can be used in the DeltaV system to affect
control strategy or to alert operators to a transmitter malfunction.
The DeltaV system communicates with HART devices through the following channels:

HART analog input

HART analog output

The HART analog input channel communicates the following values:

Analog - raw 4 to 20 mA signal, Card and channel status are applied, no HART status is applied.

Hybrid - 4 to 20 mA signal, Card, Channel, and HART status are applied.

Field value, in percent (FIELD_VAL_PCT)


Field value, in engineering units (HART_FIELD_VAL)

HART Dynamic Variables - digital signal, Card, Channel, and HART status are applied.

Primary Variable, in engineering units (HART_PV)

Secondary Variable, in engineering units (HART_SV)

Tertiary Variable, in engineering units (HART_TV)

4th Variable, in engineering units (HART_FV)

The HART analog output channel communicates the following values:

Hybrid - 4 to 20 mA signal, Card, Channel, and HART status are applied.

Field value, in engineering units (OUT)

HART Dynamic Variables - digital signal, Card, Channel, and HART status are applied.

Primary Variable, in engineering units (HART_PV)

Secondary Variable, in engineering units (HART_SV)

Tertiary Variable, in engineering units (HART_TV)

4th Variable, in engineering units (HART_FV)

HART Device Variables - digital signal, Card, Channel, and HART status are applied.

Slot 0 device variable, in engineering units (HART DV SLOT0)

Slot 1 device variable, in engineering units (HART DV SLOT1)

Slot 2 device variable, in engineering units (HART DV SLOT2)

Slot 3 device variable, in engineering units (HART DV SLOT3)

Some multivariable devices have a predefined set of Dynamic Variables; in others, you can assign process values to
the Dynamic Variables through an external device or application. Refer to the vendor's documentation for your HART
device for specific information. Refer to the Link Initialization topic for information on setting up the devices to
communicate correctly with the DeltaV system.
When DeltaV (version 3.3 or later) and AMS Device Manager (version 1.4 or later) are communicating with the same
HART instruments, AMS Device Manager works through the DeltaV system's software and wiring.

288

System Configuration

Scaling HART Values


Note The scaling for AOUT is the same as for AIN, except that it does not have LTYPE or OUT_SCALE.
If the units selected are Special Units ("", "-", "no units"), then the scale and the units information are uploaded from
the device and saved in the function block.
Once the function block is running and the units have been synchronized between the DeltaV system and the device,
anytime the units or scale information is changed in the device by AMS Device Manager or a handheld, the units are
uploaded to the controller.
An exception to this occurs if, during scaling, the controller receives a non-recoverable error from the device, in
which case it continues attempting to recover the error indefinitely by reinitializing the HART link. During this time,
it must ignore configuration change flags from the device (It might have already changed the units but not the scale,
so we cannot read the device's values and replace the controller's.). Therefore, the user cannot change the scaling
information in the device and expect it to be uploaded to the controller. The user must recover the error by changing
the scale information in the function block. The user can use one of the Special Units to upload the scaling
information from the device if needed.
When the IO_IN parameter of an Analog Input function block references the HART_FIELD_VAL parameter, the AI
function block downloads scaling values and units to the HART transmitter to provide the correct translation between
transmitter units and process units. You select the type of scaling by configuring the linearization type parameter
(L_TYPE):
Direct signal conditioning - The values for 0% and 100% of OUT_SCALE are downloaded to the transmitter and
the Analog Input function block OUT parameter is scaled using these values.
Indirect signal conditioning - The values for 0% and 100% and the units of XD_SCALE are downloaded to the
transmitter. The channel input value is scaled using a linear interpolation between the range values of XD_SCALE
and the range values of OUT_SCALE.
Indirect square root signal conditioning - The values for 0% and 100% and the units of XD_SCALE are
downloaded to the transmitter. The normalized channel input value has a square root applied before it is scaled using
a linear interpolation between the range values of XD_SCALE and the range values of OUT_SCALE.
For example, if you have a transmitter with a range of xC to yC and you want to use the range 100C to 300C for
control, configure L_TYPE = Direct and OUT_SCALE = 100C - 300C. The range 100C to 300C is downloaded to
the transmitter, and the channel input value of 100C to 300C is displayed in the HART_FIELD_VAL parameter.
If you have a transmitter with a range of x inches to y inches and you want to use the range 0 inches to 150 inches for
the transmitter and the range of 0 gallons to 3000 gallons per minute for control, configure L_TYPE = Indirect square
root, XD_SCALE = 0 - 150 in., and OUT_SCALE = 0 - 3000 gallons per minute. The range 0 to 150 inches is
downloaded to the transmitter, and the channel input value of 0 to 150 inches is displayed in the HART_FIELD_VAL
parameter.
Because these values are downloaded to the transmitter during link initialization, make sure you configure the correct
values in XD_SCALE and OUT_SCALE. Many HART devices have different rules on initialization values. Refer to
the Link Initialization topic for information on setting up the devices to communicate correctly with the DeltaV
system.

I/O Configuration

289

Error Conditions
HART field devices report internal self-test status information and indications of signal integrity. This information is
sent in a status byte that is sent with each HART message. The error conditions affect the status associated with
channel data, the channel integrity parameter (OINTEG), and the status text visible in the diagnostics application
(STATUS).
Effect of Error Conditions on Channel Data Status
When an Analog Input function block references a HART channel, error conditions affect the statuses of the OUT
parameter in the Analog Input function block. The following table describes the effect of HART and system-derived
errors on the status of the OUT parameter. (If multiple errors are present, the worst case status is reported.)
HART Error Conditions
Parameter

Effect of HART Error Conditions on Parameter Status (Part 1)


PV Fixed

Field Device
Malfunction

Analog Output
Saturated

NPV Out of
Limits

COLD_START

No effect

No effect

No effect

No effect

CONFIG_CHANGE

No effect

No effect

No effect

No effect

HART_PV

BadNonSpecific(1)

BadDeviceFailure(1)

BadNonSpecific(1)

No effect

HART_SV

No effect

BadDeviceFailure(1)

No effect

BadNonSpecific(1)

HART_TV

No effect

BadDeviceFailure(1)

No effect

BadNonSpecific(1)

HART_FV

No effect

BadDeviceFailure(1)

No effect

BadNonSpecific(1)

HINTEG

True

True

True

True

DEV_MALFUNC

No effect

True

No effect

No effect

MORE_STATUS

No effect

No effect

No effect

No effect

NO_COMM

No effect

No effect

No effect

No effect

NPV_PAST_LIM

No effect

No effect

No effect

True

OINTEG

Bad(1)

Bad(1)

Bad(1)

Bad(1)

PV_FIXED

True

No effect

No effect

No effect

PV_PAST_LIM

No effect

No effect

No effect

No effect

PV_SAT

No effect

No effect

True

No effect

STATUS

Analog Output
Current Fixed

Device Malfunction

Analog Output is
Saturated

Non-Primary
Variable Out of
Limits

BadNonSpecific(1)

BadDeviceFailure(1)

BadNonSpecific(1)

No effect

Only AI
HART_FIELD_VAL

290

System Configuration

Parameter

Effect of HART Error Conditions on Parameter Status (Part 1)


PV Fixed

Field Device
Malfunction

Analog Output
Saturated

NPV Out of
Limits

No effect

No effect

No effect

No effect

OUT

BadNonSpecific(1)

BadDeviceFailure(1)

BadNonSpecific(1)

No effect

HART_DV_SLOT0

No effect

No effect

No effect

No effect

HART_DV_SLOT1

No effect

No effect

No effect

No effect

HART_DV_SLOT2

No effect

No effect

No effect

No effect

HART_DV_SLOT3

No effect

No effect

No effect

No effect

Parameter

Effect of HART Error Conditions on Parameter Status (Part 2)

FIELD_VAL_PCT
Only AO

PV Out of Limits

Config Changed

Cold Start

More Status
Available

COLD_START

No effect

No effect

True

No effect

CONFIG_CHANGE

No effect

True

No effect

No effect

HART_PV

BadNonSpecific(1)

No effect

No effect

No effect

HART_SV

No effect

No effect

No effect

No effect

HART_TV

No effect

No effect

No effect

No effect

HART_FV

No effect

No effect

No effect

No effect

HINTEG

True

No effect

No effect

No effect

DEV_MALFUNC

No effect

No effect

No effect

No effect

MORE_STATUS

No effect

No effect

No effect

True

NO_COMM

No effect

No effect

No effect

No effect

NPV_PAST_LIM

No effect

No effect

No effect

No effect

OINTEG

Bad(1)

Bad

No effect

No effect

PV_FIXED

No effect

No effect

No effect

No effect

PV_PAST_LIM

True

No effect

No effect

No effect

PV_SAT

No effect

No effect

No effect

No effect

STATUS

Primary Variable
Out of Limits

Device Configuration
has Changed

Device has been


reset

More status
available (via
Remote Monitor)

I/O Configuration

291

Parameter

Effect of HART Error Conditions on Parameter Status (Part 2)


PV Out of Limits

Config Changed

Cold Start

More Status
Available

HART_FIELD_VAL

BadNonSpecific(1)

BadConfigError

No effect

No effect

FIELD_VAL_PCT

No effect

No effect

No effect

No effect

OUT

BadNonSpecific(1)

BadConfigError

No effect

No effect

HART_DV_SLOT0

No effect

No effect

No effect

No effect

HART_DV_SLOT1

No effect

No effect

No effect

No effect

HART_DV_SLOT2

No effect

No effect

No effect

No effect

HART_DV_SLOT3

No effect

No effect

No effect

No effect

Only AI

Only AO

Derived Status Error Conditions


Parameter

Effect of Derived Status Error Conditions on Parameter Status


Scaling Errors

Unconfigured or
Unsupported
Digital Var

Loss of
Digital
Comms

5% Digital
Comm Error
Rate

Burst
Mode

COLD_START

No effect

No effect

No effect

No effect

No effect

CONFIG_CHANGED

No effect

No effect

No effect

No effect

No effect

HART_FIELD_VAL

BadConfigError(2)

No effect

No effect

UncertainNonSpecific

No effect

FIELD_VAL_PCT

No effect

No effect

No effect

UncertainNonSpecific

No effect

HART_PV

No effect

BadConfigError(3)

BadNoCommLUV

UncertainNonSpecific

No effect

HART_SV

No effect

BadConfigError(3)

BadNoCommLUV

UncertainNonSpecific

No effect

HART_TV

No effect

BadConfigError(3)

BadNoCommLUV

UncertainNonSpecific

No effect

HART_FV

No effect

BadConfigError(3)

BadNoCommLUV

UncertainNonSpecific

No effect

HART_DV_SLOT0

No effect

BadConfigError(3)

BadNoCommLUV

UncertainNonSpecific

No effect

HART_DV_SLOT1

No effect

BadConfigError(3)

BadNoCommLUV

UncertainNonSpecific

No effect

HART_DV_SLOT2

No effect

BadConfigError(3)

BadNoCommLUV

UncertainNonSpecific

No effect

HART_DV_SLOT3

No effect

BadConfigError(3)

BadNoCommLUV

UncertainNonSpecific

No effect

HINTEG

No effect

No effect

True

No effect

No effect

DEV_MALFUNC

No effect

No effect

No effect

No effect

No effect

NO_COMM

No effect

No effect

True

No effect

No effect

292

System Configuration

Parameter

Effect of Derived Status Error Conditions on Parameter Status


Scaling Errors

Unconfigured or
Unsupported
Digital Var

Loss of
Digital
Comms

5% Digital
Comm Error
Rate

Burst
Mode

MORE_STATUS

No effect

No effect

No effect

No effect

No effect

NPV_PAST_LIM

No effect

No effect

No effect

No effect

No effect

OINTEG

Bad

No effect

Bad

No effect

No effect

OUT

BadConfigError(2)

No effect

No effect

UncertainNonSpecific

No effect

PV_FIXED

No effect

No effect

No effect

No effect

No effect

PV_PAST_LIM

No effect

No effect

No effect

No effect

No effect

PV_SAT

No effect

No effect

No effect

No effect

No effect

STATUS

Refer to "Effect of
Error Conditions on
Diagnostics Status
Text"

No effect

"Not
Communicating
with Device"

"5% Comm Error


Rate with Device"

"Burst
Mode
Enabled" (4)

Table Footnotes
(1) Unless ignored by the configuration.
(2) Unless ignored by the configuration; not all scaling errors can be ignored.
(3) Only the digital variable that is unconfigured or unsupported will have bad status.
(4)Only detected on HART Passthroughs (for example AMS, Scaling).
Non-HART Error Conditions
Parameter

Effect of non-HART Error Conditions on Parameter Status


Card Status:
No Railbus Comms,
Hardware Error, Fault
State, Config Error, or
Not Configured

Channel Status:
Hardware Error,
Config Error, or
Not Configured

Card Status: 5% Railbus


Comm Error

COLD_START

No effect

No effect

No effect

CONFIG_CHANGED

No effect

No effect

No effect

HART_FIELD_VAL

BadDeviceFailure

BadConfigError

UncertainNonSpecific

FIELD_VAL_PCT

BadDeviceFailure

BadConfigError

UncertainNonSpecific

HART_PV

BadDeviceFailure

BadConfigError

UncertainNonSpecific

HART_SV

BadDeviceFailure

BadConfigError

UncertainNonSpecific

HART_TV

BadDeviceFailure

BadConfigError

UncertainNonSpecific

HART_FV

BadDeviceFailure

BadConfigError

UncertainNonSpecific

HART_DV_SLOT0

BadDeviceFailure

BadConfigError

UncertainNonSpecific

HART_DV_SLOT1

BadDeviceFailure

BadConfigError

UncertainNonSpecific

I/O Configuration

293

Parameter

Effect of non-HART Error Conditions on Parameter Status


Card Status:
No Railbus Comms,
Hardware Error, Fault
State, Config Error, or
Not Configured

Channel Status:
Hardware Error,
Config Error, or
Not Configured

Card Status: 5% Railbus


Comm Error

HART_DV_SLOT2

BadDeviceFailure

BadConfigError

UncertainNonSpecific

HART_DV_SLOT3

BadDeviceFailure

BadConfigError

UncertainNonSpecific

HINTEG

No effect

No effect

No effect

DEV_MALFUNC

No effect

No effect

No effect

MORE_STATUS

No effect

No effect

No effect

NO_COMM

No effect

No effect

No effect

NPV_PAST_LIM

No effect

No effect

No effect

OINTEG

Bad

Bad

No effect

OUT

BadDeviceFailure

BadConfigError

UncertainNonSpecific

PV_FIXED

No effect

No effect

No effect

PV_PAST_LIM

No effect

No effect

No effect

PV_SAT

No effect

No effect

No effect

STATUS

Refer to "Effect of Error


Conditions on Diagnostics
Status Text"

"Good - No Installed
Config" or "Bad
Configuration Error"

"5% CommErrorRate with


Card" or "Stale Data"

Analog Out HART Error Conditions


Parameter

Effect of Analog Out HART Error Conditions on


Parameter Status
Valve Diagnostics in Progress

COLD_START

No effect

CONFIG_CHANGED

No effect

HART_FIELD_VAL

No effect

FIELD_VAL_PCT

No effect

HART_PV

No effect

HART_SV

No effect

HART_TV

No effect

294

System Configuration

Parameter

Effect of Analog Out HART Error Conditions on


Parameter Status
Valve Diagnostics in Progress

HINTEG

No effect

MORE_STATUS

No effect

SLOT0

No effect

SLOT1

No effect

SLOT2

No effect

SLOT3

No effect

HART_FV

No effect

DEV_MALFUNC

No effect

NO_COMM

No effect

NPV_PAST_LIM

No effect

OINTEG

Bad

OUT

BadDeviceFailure

PV_FIXED

No effect

PV_PAST_LIM

No effect

PV_SAT

No effect

STATUS

Diagnostics in Progress

Effect of Error Conditions on the Channel Integrity Parameter


The channel integrity parameter (OINTEG) is True (1) when one or more of the following conditions are True:

HART card detects a problem with itself.

An open or short is detected on a HART channel input.

An analog NAMUR high or low level is detected (AI only).

DEV_MALFUNC is True and not ignored via the HART_ERRORS parameter.

PV_FIXED is True and not ignored via the HART_ERRORS parameter.

There has been a problem configuring the HART instrument during initialization.

If any of the conditions below exist, OINTEG will be True (1) except for Good and Good - No Installed
Config.

Effect of Error Conditions on Diagnostics Status Text


Error conditions trigger text information in DeltaV Diagnostics to help you troubleshoot problems. The following
status text strings might appear:
Good - No problems detected, data is valid.
Good - No Installed Config - Channel has not been configured.

I/O Configuration

295

No Card - There is no card in the slot.


Not Enabled - The channel is currently disabled.
A/D Converter Error - The HART channel detected an error in its A/D converter (AI only).
Sensor Bad - The HART channel detected an open or short or a NAMUR high or low limit alarm (AI only).
Open Loop Detected - The HART channel has detected an open loop.
Short Circuit - The HART channel has detected a short circuit.
Stale Data - The controller detected that the AI-HART channel is not updating data (AI only).
Not Communicating with Device - The HART channel is unable to digitally communicate with the attached HART
instrument.
Bad - Configuration Error - The channel encountered an error while configuring the channel.
Device Malfunction - The HART instrument detected a problem with itself or with one of its associated sensors.
Analog Output Current Fixed - The HART instrument is reporting that its analog output value is configured to a
fixed value.
Primary Variable Out of Limits - The HART instrument is reporting that the primary measurement is outside the
sensor limits.
Analog Output is Saturated - The HART instrument is reporting that the analog output value is saturated.
Non-primary Variable Out of Limits - The HART instrument is reporting that one of the non-primary
measurements is outside the associated sensor limits.
Device Configuration Access is Restricted - The HART channel attempted to write the analog output scale
information to the attached HART instrument, and the instrument reported that it has restricted access.
Device Configuration Units Invalid - The HART channel attempted to configure the analog output scale
information of the attached HART instrument and the instrument reported that the units specified are not valid for this
instrument.
Device Configuration Both Ranges Out of Limits - The HART channel attempted to configure the analog output
scale information of the attached HART instrument, and the instrument reported that both the upper and lower range
values were outside valid limits.
Device Configuration Upper Range Too High - The HART channel attempted to configure the analog output scale
information of the attached HART instrument, and the instrument reported that upper range value was too high.
Device Configuration Upper Range Too Low - The HART channel attempted to configure the analog output scale
information of the attached HART instrument, and the instrument reported that the upper range value was too low.
Device Configuration Lower Range Too High - The HART channel attempted to configure the analog output scale
information of the attached HART instrument, and the instrument reported that the lower range value was too high.
Device Configuration Lower Range Too Low - The HART channel attempted to configure the analog output scale
information of the attached HART instrument, and the instrument reported that the lower range value was too low.
Device Configuration Range Span Too Small - The HART channel attempted to configure the analog output scale
information of the attached HART instrument, and the instrument reported that the difference between the high and
low range values was too small.
Device Configuration Cannot be Changed - Device is Busy (Other Master Has Taken Out of Service) - The
HART channel attempted to configure the analog output scale information of the attached HART instrument, and the
instrument reported that it was busy (AOUT only).

296

System Configuration

Device Configuration Cannot be Changed - Device is Busy - The HART channel attempted to configure the analog
output scale information of the attached HART instrument, and the instrument reported that it was busy (AI only).
Device Configuration Cannot be Read - Device is Busy - The HART channel attempted to read the analog output
scale information of the attached HART instrument, and the instrument reported that it was busy.
Device Configuration Cannot be Read - The HART channel attempted to read the analog output scale information
of the attached HART instrument, and the instrument reported a problem.
Device Configuration Units or Range Invalid - The HART channel attempted to configure the analog output scale
information of the attached HART instrument, and the instrument reported that the units or one or both range values
are invalid.
Device Configuration Set to Nearest Possible Value - The HART channel attempted to configure the analog output
scale information of the attached HART instrument, and the instrument reported that it set one or both of the range
values to the nearest possible value.
Configuration Does Not Match Device - The HART channel has not yet attempted to configure or read the analog
output scale information of the attached HART instrument.
Diagnostics in Progress - The HART channel is performing Valve Diagnostics (Valve Stimulus Testing) on a Fisher
Controls valve (AOUT only).
Device is Write Protected - The Analog Input HART channel attempted to write the analog output scale information
to the attached HART instrument and the instrument reported that it is write protected.
Device is Write Protected (In Service) - The Analog Output HART channel attempted to write the analog output
scale information to the attached HART instrument and the instrument reported that it is write protected. For Fisher
Controls DVC valves, this indicates the valve is "In Service".
Device Configuration Access is Restricted (In Service) - The Analog Output HART channel attempted to write the
analog output scale information to the attached HART instrument and the instrument reported that it is write
protected. For Fisher Controls DVC valves, this indicates the valve is "In Service".
Device Configuration Cannot be Read - The Analog HART channel attempted to read the analog output scale
information from the attached HART instrument and the instrument reported that HART command 15 is not
supported.
Device Configuration Cannot be Changed - The Analog HART channel attempted to read the analog output scale
information from the attached HART instrument and the instrument reported that HART commands 35 or 44 are not
supported.
Device Configuration Cannot be Changed (In Service) - The Analog Output HART channel attempted to write the
analog output scale information to the attached HART instrument and the instrument reported a bad instrument status.
For Fisher Controls DVC valves, this indicates that the valve is "In Service".
Reconfiguration in Progress - The HART instrument is in the process of being rescaled.
Configuration Range Does Not Match Device - The HART channel determined there was a lower or upper range
value mismatch between the function block and HART instrument.
Non-HART Device Failure Error STATUS Text Strings
"No Card"
"Bad - Hardware Error"
"Bad - Failstate Active"
"A/D Converter Error"
"Open Loop Detected"

I/O Configuration

297

"Short Circuit Detected"


"Namur High Limit Detected"
"Namur Low Limit Detected"

Using Error Conditions for Control Strategy


In addition to the status associated with the Analog Input function block OUT parameter, you can reference the
possible error conditions directly in a control module by linking an Internal Read Parameter via an External
Reference to one of the HART channel Boolean parameters. This reference counts as a DST. The following are the
HART channel Boolean parameters:
Field Device Malfunction (DEV_MALFUNC) - True when the HART instrument detects a problem with itself or
associated sensors.
PV Fixed (PV_FIXED) - True when the HART instrument has been in test loop mode or is in multidrop mode. In
test loop mode, the HART instrument's analog output value is held at the configured value and does not reflect the
process.
PV Saturated (PV_SAT) - True when the analog output of the HART instrument is saturated.
PV Past Limits (PV_PAST_LIM) - True when the primary measurement is outside the sensor operating limits. In
this case, the analog parameters (FIELD_VAL_PCT and HART_FIELD_VAL) and the digital parameter
(HART_PV) are not reliable; this is reflected in their associated status values.
NPV Past Limits (NPV_PAST_LIM) - True when one of the non-primary measurements is outside the sensor
operating limits. There is no indication of which non-primary measurement is bad.
No Communications (NO_COMM) - True when the HART channel cannot communicate digitally with the attached
HART instrument.
Overall Integrity (OINTEG) - True when one or more of the following conditions are True:

AI-HART card detects a problem with itself

An open or short is detected on a HART channel input

An analog NAMUR high or low level is detected

DEV_MALFUNC is True

PV_FIXED is True

There has been a problem configuring the HART instrument during initialization

If any of the conditions related to the diagnostic status text strings listed above exist, OINTEG will be True
(1) except for Good and Good - No Installed Config.

Customizing Control on Error Conditions


In some cases, you might want to use HART data even though the instrument is reporting certain error conditions.
The HART_ERRORS parameter allows you to select which HART status error values are ignored in your control
strategy.
The HART_ERRORS parameter masks HART error conditions that you determine are not required for your
application. For example, you might have a measured variable that is outside limits occasionally but is not a problem
for the process. You can select the Ignore PV Out of Limits for All PV Status option in the HART_ERRORS
parameter to disregard this error condition.
You modify the HART_ERRORS parameter by selecting the channel properties and checking one or more of the
following actions:

298

System Configuration

Ignore PV Out of Limits for All PV Status - Primary variable (PV) values that are higher or lower than the
configured limits are ignored when determining PV statuses.
Ignore NPV Out of Limits for All NPV Status - Non-primary variable (NPV) values that are higher or lower than
the configured limits are ignored when determining NPV statuses.
Ignore PV Output Saturated for All PV Status - PV values that are output saturated are ignored when determining
PV statuses.
Ignore PV Output Fixed for All PV Status - PV values that have a fixed output are ignored when determining PV
statuses.
Ignore FLD Device Malfunction for All Status - Values determined during a field device malfunction are ignored
when determining statuses.
Ignore Loss of Digital Comms for FV_PCT Status - Values determined during the loss of digital communications
are ignored when determining the field value in percent (HART_FIELD_VAL) status.
Override Unsupported Device Scale - If a HART device returns Not a Number (NaN) for the signal's Upper or
Lower Scale, the DeltaV system ignores the scale returned by the device and uses the scale configured in the I/O
block's HART_FIELD_VAL parameter.
Note The default value for these actions is disabled (False). That is, these status conditions are not ignored. When you
enable these actions, the block ignores the specified statuses.

Link Initialization
In order for the HART field device to be compatible with the DeltaV system, it must be able to communicate using
the HART commands listed in this section.
In the DeltaV system, HART link initialization is performed by the DeltaV AI-HART card and the controller function
block.
I/O Card Initialization
When a HART card is plugged in, it assumes that all channels are analog only. When you configure the card, you can
set the channel to HART_ANALOG_INPUT (AO also).
The card then tests for an open circuit. If no open circuit is detected, the card sends out HART Command 0 (Read
Manufacturer and Device Type) followed by Command 59 (Write Number of Response Preambles).
Controller Function Block Channel Initialization
The DeltaV Controller also performs HART channel initialization. As soon as the controller is notified that an AIHART card configuration is complete, it sends Command 0 to each HART channel.
If a function block is linked to the HART_FIELD_VAL parameter (for AI) or OUT parameter (for AOUT) of the
HART channel, the first time the function block executes, it sends scaling information (high and low range and units)
to the HART instrument for its analog output signal. The units code is sent via HART Command 44 (Write Primary
Variable Units). The high and low range information is sent via HART Command 35 (Write Primary Variable Range
Values). At this time, the HART instrument sets a bit saying that it has changed its configuration to the new values.
The controller sends HART Command 15 (Read Primary Variable Output Information) to read the range and units
information. This is followed by Command 38 (Reset Configuration Change Flag) to clear the change flag in the
instrument. Note that if command 44 is not supported, command 15 is inserted before command 35 in the description
above.

I/O Configuration

299

There are other scenarios that affect link initialization, including:

You might connect a hand-held device to an instrument in the field to change its scale values. The controller
detects this change in the instrument and sends Command 15 to read the new values followed by command
38.

During loop tuning, you can change the range values in an AI function block. These changes are sent to the
HART instrument.

You might specify range values to a high level of precision and some HART instruments might not be able to
support that precision. The controller sends Command 15 to detect the actual range precision the instrument
is using in the process.

If a HART instrument does not support the HART Commands 44 and 35 (used to set the scale values), the values read
by HART Command 15 are compared to those specified by the function block. If the values are the same, they are
accepted and the link initialization continues. If the values are not the same (or if the HART instrument is writeprotected or blocking access to that configuration information), the controller stops the HART link initialization for 5
seconds, restarts it with cmd 0, and the initialization repeats.
HART Special Units Handling
The HART protocol allows units that might be unique to a particular HART instrument and unknown to the DeltaV
system. To deal with this for a specific function block, select one of the following values for the Engineering unit
descriptor: hyphen (-), blank space ( ), or no units. The DeltaV system then uses the units and scale information that
are currently configured in the HART instrument. If the type of units are known to the DeltaV system, the units are
displayed in the XD_SCALE parameter of the function block. However if they are unknown to the DeltaV system,
the units field in XD_SCALE is blank.
HART Scan Update Rate (AI)
After this card's initialization phase, the card sends out Command 3 (Read Dynamic Variables and Primary Variable)
repeatedly to each HART channel. The HART scan update rate for each input channel configured for HART is 600800 ms. The analog values for each input channel are scanned in much faster than the HART scan update rate.
Passthrough messages sent by AMS Device Manager can cause a card's HART scan rate to be twice the rate without
AMS Device Manager running.
HART Scan Update Rate (AOUT)
After this card's initialization phase, the card sends out Command 3 (Read Dynamic Variables and Primary Variable)
repeatedly to each HART channel. The HART scan update rate for each output channel configured for HART is 600800 ms.
If device variables (DV_SLOT) are configured for a channel, the card sends command 33 to read the configured
device variables. The HART scan update rate for each channel configured for device variables is an additional 600800 ms.
Passthrough messages sent by AMS Device Manager can cause a card's HART scan rate to be as much as twice the
rate without AMS Device Manager running.
If valve diagnostics is running on a channel, the card's HART scan rate can be as much as twice the rate without
diagnostics running.
As an example:
The scan rate for an 8 channel analog output card with all channels configured for HART is 4.8 to 6.4 seconds:

300

If device variables is also running, the scan rate can be 9.6 - 12.8 seconds.

If AMS Device Manager and device variables are running, the scan rate can be 19.2 - 25.6 seconds.

If AMS Device Manager, device variables, and valve diagnostics are running, the scan rate can be 38.4 -51.2
seconds.

System Configuration

Accessing AMS Device Manager from the DeltaV Explorer


From the DeltaV Explorer, you can launch AMS Device Manager in context from a HART device, if you have also
been configured as an AMS Device Manager user. You can use AMS Device Manager commands to:

Open AMS Device Manager from a HART device

View device status and conditions

View device configurations

Compare device configurations

View the Audit Trail

The AMS Device Manager software is not installed with the DeltaV software. It is a stand-alone client/server system
that is installed and licensed separately from the DeltaV software. The license file specifies the allowed number of
concurrent users. The AMS Device Manager Audit Trail is installed with AMS Device Manager. Refer to the AMS
Device Manager Installation Guide for complete information.
Note Once AMS Device Manager is launched either from the DeltaV Explorer or the Start menu, only one instance of
it runs on the DeltaV workstation.
Prerequisites for Launching AMS Device Manager from DeltaV Explorer
There are some prerequisites for launching AMS Device Manager from the DeltaV Explorer:

AMS Device Manager must be installed on the same workstation as the DeltaV software.

The user must be logged onto the DeltaV system.

The user must have an AMS Device Manager user name and password.

If accessing a HART device, the user must be connected to a HART-enabled channel.

The DeltaV DSTs (Device Signal Tags) and the AMS tags must match for each device.

To access AMS Device Manager from a HART device in DeltaV Explorer:


Be sure that the prerequisites listed above have been met.
1

Click Start | DeltaV | Engineering | DeltaV Explorer to open the DeltaV Explorer.

Navigate to the HART channel and ensure that it is enabled. (Select the channel, click the right mouse button,
and select Properties to see if it is enabled.) Refer to the DeltaV Explorer online help if you need assistance in
navigating to an object.

Auto-sense the HART device to create the device tag. (Select the channel, click the right-mouse button, and
select Auto-sense HART device.) The tag appears beneath the channel in the Explorer hierarchy.

Select the device, click the right-mouse button, and select the desired AMS Device Manager command from the
context menu.

Enter your AMS Device Manager user name and password and wait for the AMS Device Manager Tag Search
dialog to open. Once AMS Device Manager is opened, you do not have to re-enter your user name and password.
You remain logged on to AMS Device Manager until you exit the application.

AMS Device Manager displays device information in the Tag Search dialog and then opens the dialog associated with
the selected menu command. Use the Help menu in AMS Device Manager for complete help.
Tip You can access AMS Device Manager commands from the AMS Device Manager Tag Search dialog. Select the
device in the Tag Search dialog, click the right mouse button, and select a command from the context menu.

I/O Configuration

301

AS-Interface - General Information


Inside this topic
The AS-Interface Network
Communication on the Network
The AS-Interface is a communications protocol that interconnects simple binary devices such as actuators, sensors,
and discrete devices in the field. A single, AS-Interface yellow cable replaces the traditional cable cluster and
provides simple cabling and fast connection and disconnection for devices.
The AS-Interface Network
An AS-Interface network comprises an AS-Interface master and up to 31 slave devices such as actuators, sensors, and
display devices. Slave devices with a built-in AS-Interface chip connect directly to the AS-Interface network. Other
slave devices act as an interface between conventional devices (actuators or sensors without the AS-Interface chip)
and the AS-Interface network.
The DeltaV AS-Interface card has two ports and each port functions as an AS-Interface master. The AS-Interface
master controls communications on the network by polling the slave devices, issuing commands, and receiving and
processing replies from the slave devices. There can be only one AS-Interface master on the network. An ASInterface network can support up to 124 inputs and 124 outputs. (Each slave can support up to four inputs and four
outputs.) The maximum cable length anywhere between repeaters and extenders on an AS-Interface network is 100m.
Communication on the Network
Communication begins when the new AS-Interface master port configuration is downloaded and consists of three
phases. In the first phase, the master polls each slave device and requests the slave's profile (I/O configuration and
Identification code). This is a fixed-format description of the device that is referred to as the AS-Interface Device
Type in the DeltaV software. For more information on the AS-Interface Device Type, refer to the AS-Interface Slave
Configuration topic. In the second phase, the master sends a four bit parameter value to each slave. The parameter
value controls specialized, non-standard functions of the device such as dark-on rather than the standard light-on for a
photosensor. In the third phase, the master sends each slave its output values and receives each slave's input values.

AS-Interface in the DeltaV System


Inside this topic
AS-Interface Master Configuration
AS-Interface Slave Configuration
Diagnostics
To properly operate the devices on the AS-Interface network, the DeltaV AS-Interface card conforms to the ASInterface master specifications for device configuration, addressing, and data exchange. You use the DeltaV Explorer
to configure the AS-Interface master and slave devices and the DeltaV Diagnostics application to view diagnostic
information on the AS-Interface master and slave devices. Refer to the DeltaV Explorer's online help for complete
information on configuring the AS-Interface master and slave devices.
AS-Interface Master Configuration
AS-Interface master configuration consists of specifying the action that the AS-Interface master takes if the controller
fails, and enabling or disabling the Auto Address feature. In the event of a controller failure, the AS-Interface master

302

System Configuration

can reset devices (turn the devices' outputs off and disable data exchange) or continue polling the slave devices. Auto
addressing specifies how an address is assigned when a device is replaced. For more information, refer to the
Communication on the Network topic.
AS-Interface Slave Device Configuration
Device configuration consists of assigning an AS-Interface Device Type to the device and assigning the device
address. An AS-Interface Device Type is a fixed-format description of the device that the AS-Interface master uses to
communicate with the slave device. You create your own AS-Interface Device Type from the device's data sheet. The
AS-Interface Device Type consists of an Identification code and I/O Configuration (taken together these are defined
by the AS-Interface Specification as the device Profile) the Parameters for the device, and the inputs and outputs
supported by the device. (In the DeltaV Explorer, the Profile appears in the format S-[I/O
Configuration].[Identification Code] as defined by the AS-Interface Specification. For example, S-2.0.) The
Identification code and I/O Configuration are designated by the device manufacturer. The Identification code
identifies the type of device and the I/O Configuration identifies the device's input and output bits. The four bit
Parameters are used to customize the device behavior.
Note An AS-i port status value of Mismatch in DeltaV Diagnostics means that the profile for one or more of the
actual devices on the segment does not match that of the configured device.
When a new AS-Interface slave device is created in the DeltaV Explorer, each input and output for the device is
assigned a channel label and a Device Signal Tag (DST). The labels and DSTs appear under the device in the Explorer
hierarchy. A Device Signal Tag is a unique name that represents a specific signal from the device. The signal is used
in the control strategy and counted for licensing. A default DST name is assigned by the system when the device is
created but you can rename it at any time. The channel label is taken from the device's AS-Interface Device Type and
can be modified through the AS-Interface Device Type's property page. Refer to the Port Downloads section for
information on downloading the AS-Interface ports.
Modifying Devices
Use the device's Properties page to modify the description, address, and to enable and disable the device. Select the
device in the DeltaV Explorer and select Properties from the device's context menu to access the Properties page. The
Add New Type button on the Properties page is functional only when adding a new device to the DeltaV system; not
when viewing the properties of an existing device. Use the online help for help on the fields in the Properties dialog.
Addressing
Each slave device connected to an AS-Interface network has an address between 1 and 31. All AS-Interface devices
are shipped from the manufacturer with address 0 a temporary address that prohibits data exchange. A new ASInterface slave device is assigned an address when it is created in the DeltaV Explorer. When a device is replaced, it
can have its address assigned through a hand-held device or it can be automatically set to the original address through
the Auto Address feature on the AS-Interface master.
Auto-Sensing
The auto-sense feature aids in AS-Interface device configuration. Auto-sensing lists the slave devices existing in the
database and those sensed on the port and shows each device's address, name, I/O configuration, and Identification
code. This feature can be used to add devices to the configuration, and to clear and set addresses. You must download
the port to activate slave devices.
Tip Turn off the Auto-address enable feature before attempting to clear an address.

I/O Configuration

303

Port Downloads
The action that the AS-Interface master takes following a new port download depends on the changes included in the
new configuration. Changes to port properties: Auto address enable and Action in the event of controller failure are
copied to the master and there is no effect on the slave devices on the network.
Warning If a slave device is added or removed from the configuration or if a slave address or profile is changed, the
AS-Interface master must restart the port. Restarting the port consists of the master transitioning to the offline state
where it resets all slave devices and reactivates the slaves. Resetting the slave devices causes the slaves to deactivate
their outputs. Once the port restarts, slave outputs return to the controller-driven state.

Diagnostics
Diagnostics displays the slave devices, DSTs, and values and provides advanced diagnostic information that is
supported by the AS-Interface master. Refer to the Diagnostics online help for complete information on diagnosing
AS-Interface slave devices and the AS-Interface master port.

304

System Configuration

Profibus DP - General Information


Inside this topic
The Profibus DP Network
Communication on the Network
Profibus DP GSD Files
Profibus DP is a communications protocol that provides an interface for discrete devices such as actuators and
sensors in the field. Twisted pair shielded copper cable is used for data transmission. The high speed, easy to install,
RS485 transmission technology that is often used by Profibus DP is referred to as H2.
The Profibus DP Network
A Profibus DP network consists of a Profibus DP master and Profibus slave devices. The DeltaV Profibus card
supports up to 64 slave devices on a Profibus network. A Profibus slave can support both process input and output
data on a host system such as the DeltaV system or it can support only process input or only process output data. A
maximum of 244 bytes of input values and 244 bytes of output values are allowed.
There are two types of Profibus slave devices: compact and modular. The difference between a compact and modular
device is based partly on how Profibus modules (referred to as Slots in the DeltaV system) are used in the device's
configuration. A Profibus module is a function such as analog input or analog output or discrete input or discrete
output, that can be added to a Profibus device's configuration. The configuration for a compact device is generated
based on a fixed number of modules in a particular order. The configuration for a modular device is generated based
on the number and order of modules that the user selects. A Device Definition, identified by the revision level for the
device, is available for every Profibus slave device. The Device Definition is used to identify the Profibus device and
contains information that makes it possible for manufacturer-independent configuration tools such as the DeltaV
Explorer to configure Profibus slave devices. The Device Definition is described in a manufacturer-supplied text file
with a .GSD extension. For more information, refer to the Profibus DP GSD Files topic.
The port on the DeltaV Profibus DP card is the Profibus DP master and acts as the interface between the Profibus
network and the DeltaV system. You use the DeltaV Explorer to add the DeltaV Profibus DP card and configure your
Profibus slave devices. For more information on configuring devices in the DeltaV system, refer to the Profibus DP in
the DeltaV System topic.
Communication on the Network
Communication is cyclical and begins when the port is downloaded. The Profibus master starts communication by
sending parameter values to the slave devices. The parameters are associated with the device and the device's
modules. The Profibus module parameters are transmitted in the order of the module configuration. Then, the
Profibus master sends a copy of the device configuration to the device, the device verifies that there is a match in
configuration data, and data exchange begins.
Profibus DP .GSD Files
The Profibus DP protocol specifies that the device manufacturer provide a text file for every Profibus slave device.
Generally, this file has a .GSD extension although language-specific versions (.GSG for German, .GSE for English,
.GSF for French, and so on) might be available. This file contains the maximum number of Profibus modules in the
device configuration, the parameter values specified for each module, and the number of input and output bytes in the
data exchange messages. The parameter values customize the device behavior. The Device Definition also contains
the supported baud rates, timing information, fail safe behavior, and diagnostic error codes. The Device Definition is
added to the DeltaV Library to add a new Profibus Device to the DeltaV system. The Device Description describes
how the device communicates, it does not describe the data semantics or data type. For each Profibus module the user

I/O Configuration

305

configures signals that describe the I/O that the Slot (Profibus module) provides to the DeltaV system. For more
information, refer to the Profibus Module Signals topic.

Profibus DP in the DeltaV System


Inside this topic
Configuring the Profibus Master
Adding and Creating Device Definitions
Profibus Module Signals
Configuring Slave Devices
Adding and Configuring Slots
Modifying and Assigning Device Tags
Using Profibus DP with DeltaV Function Blocks
The DeltaV Profibus DP card conforms to the Profibus specification as an interface to a control application such as
the DeltaV system and provides some diagnostic information on slave devices. There is one port on the DeltaV
Profibus DP card.
You use the DeltaV Explorer to:

Add and configure the Profibus master (the Profibus card's port)

Add Device Definitions (.GSD files) to the DeltaV Explorer Library

Configure Profibus slave devices and Profibus Slots

Specify parameter values for the Profibus Slot

Create Profibus module signals

Refer to the DeltaV Explorer online help for detailed information on adding and editing Device Definitions and
configuring Profibus devices.
Configuring the Profibus Master
Profibus master configuration consists of specifying the action the Profibus master takes if the controller fails, setting
the baud rate for all devices on the network, setting the master's address, and specifying network properties. The
supported baud rates, in bits per second (bps), for Profibus devices are 9.6K 19.2K, 93.75K, 187.5K, 500K, and
1.5M. The address for the Profibus master is usually 1. The DeltaV Explorer online help on the port properties dialog
provides detailed information on all the configuration properties for the Profibus master.
Adding and Creating Device Definitions
Adding the Device Definition creates a hierarchy of categories (Profibus Family, Manufacturer, Model, Device
Revision, and modules) under Profibus Devices in the DeltaV Library. You can change the device and module
parameter values and overwrite the default values specified by the manufacturer. You can also create Profibus module
signals in the Library. For more information, refer to the Profibus Module Signals topic.
Tip It is recommended that you change a module or device parameter value at the Library level rather than at the Slot
level to ensure that future instances of the module or device inherit that parameter value.
If you change a device parameter value at the Library level, existing instances of that device are not changed but
future instances of the device inherit the new parameter value. If you change a module parameter value or signal at
the Library level, existing instances of that module are not changed but future instances of the module (Slots) inherit

306

System Configuration

the new parameter value or signal even if the module is added to an existing device. If a device is associated with a
particular Device Definition in the Library, the DeltaV Explorer will not allow you to delete or re-add that Device
Definition. This ensures that the Device Definitions in the Library are consistent with existing devices.
Profibus Module Signals
The Device Definition contains information about data length, it does not contain information about the data itself.
For each Profibus module in the Library, you add Profibus module signals that contain information such as signal
direction, data type and the location of the signal value within the modules data.
You can configure module signals at the library level and at the physical network level.
Library Configuration - To save engineering time for similar devices, create default signals in the library. Configure
the signals that are common to all instances of a module type. When you add a slot for that module type to a device, it
is created with the signals defined for it in the library. (You can also create module signals at the physical device.)
Physical Network Configuration - Complete the configuration of the signal at the physical configuration level.
Provide a description of the signal and associate it with a specific Device Signal Tag (DST). For more information on
DSTs, refer to the Modifying and Assigning Device Tags topic.
Configuring Slave Devices
The Configuration steps vary depending upon whether the slave device is compact or modular. However for both
device types, you can specify if the device is enabled or disabled, assign an address, and set the device's Watchdog
Timer. The Watchdog Timer specifies the amount of time before the device goes into its fail safe mode if
communication on the network stops. The address is automatically assigned for both device types when the device is
created however, you can change the device address. Slave devices can have an address between 2 125. It is
recommended that address 1 be reserved for the Profibus master. Addresses are unique; no two devices, slave or
master, can have the same address on a port.
Configuring a compact device consists of adding the slave device to the Profibus master port and setting the device
properties (enable and Watchdog Timer). When a compact device is added to the Profibus master port, the slots and
parameters defined for that device are automatically created below the device in the DeltaV Explorer hierarchy.
Remember that configuration for a compact device is generated based on a fixed number of Profibus modules in a
particular order. Be aware that you cannot delete compact device slots in DeltaV Explorer; you must delete the device
in order to delete the slot.
Configuring a modular device consists of adding the device to the Profibus master port and setting the device
properties (enable and Watchdog Timer). However, because the configuration for a modular device is generated based
on the number and order of its modules, you configure the device by adding modules (called Slots in DeltaV) in the
correct order. Depending on the type of module, you may have to add signals or adjust parameter values. Unlike
compact devices, modular device slots can be deleted.
Parameters values can affect diagnostics, ground fault detection, failure actions and many other device
characteristics. For devices that have configuration parameters at the device and or the slot level, it is important to
provide parameter values for proper operation of the device.
Note When entering parameter values, note that the values you enter are always in decimal format for Profibus
devices.

Adding and Configuring Slots


A new Slot for a slave device is created with the module parameter values and signals specified for that Device
Definition in the Library. These values can be overwritten at the Slot level but new instances of the device or module

I/O Configuration

307

will not inherit this value. For more information on inheritance, refer to the Tip in the Adding and Creating Device
Definitions topic. Slots can be added until the maximum number of bytes and slots specified by the device
manufacturer for that device have been met. When you add a new Slot, the dialog box displays the manufacturer's
limits and shows you the number of used and available bytes and slots.

The .GSD file specifies the number for the first slot. The default is 0. You must number the Slots contiguously to
successfully download the device. The Profibus protocol specifies that there can be no gaps in Slot numbers. The Slot
types and Slot order of the physical device must match the configuration in the DeltaV configuration database or the
device can not establish communication with the master.
Modifying and Assigning Device Tags
When you create a Slot from a Profibus Library module to which a signal was added, the signal and a DST are created
below the Slot in the DeltaV Explorer hierarchy. The DST is marked with a yellow tag. A default DST name (for
example PDT2S000AL1 in the following figure) is automatically assigned but it can be renamed so that it is
meaningful in your control strategy.

A DST is a unique name that represents a specific signal from the device. The signal is used in the control strategy
and counted for licensing. At the Slot level, you can customize the DST name and modify the signal properties for
that device. Remember that any modifications made to the signal at the Slot level do not affect the Profibus Library
module that contains that signal. If you have previously configured a DST, you can browse for it and assign it to a
signal.
Using Profibus DP with DeltaV Function Blocks
Refer to Using Profibus DP, DeviceNet, and AS-Interface with DeltaV Function Blocks for more information.

308

System Configuration

DeviceNet - General Information


Inside this topic
DeviceNet Network
DeviceNet is a low-cost communications protocol that connects devices such as motor starters and variable speed
drives to a network. It is a networking solution that reduces wiring costs and provides for interoperability among
multiple vendors. Refer to the Open DeviceNet Vendor Association's (ODVA) website at www.odva.org for complete
information.
DeviceNet Network
The port on the DeltaV DeviceNet card acts as the DeviceNet master and can support up to 61 devices. The port is the
interface between the DeltaV system and the DeviceNet network. Device configuration is done through Electronic
Data Sheet (EDS) files. These files are specially formatted ASCII files, provided by the device manufacturer, that are
required for configuring a device with the DeltaV Explorer. The EDS file contains all the parameter information for a
device. Refer to the DeviceNet EDS Files topic for more information.
The following table shows the recommended DeviceNet trunk lengths at various baud rates:
Baud Rate

Maximum Trunk Length for


Series 1

Maximum Trunk Length for


Series 2

125 k

500 m (1640 ft.)

500 m (1640 ft.)

250 k

250 m (820 ft.)

250 m (820 ft.)

500 k

61 m (200 ft.)*

100 m (328 ft.)

* ODVA specifications allow for a maximum trunk length of 100 m (328 ft.) at 500 k baud; however, testing indicates
that a few device types experience unstable operation at these limits. Emerson Process Management recommends a
maximum trunk length of 61 m (200 ft.) at 500 k baud to maintain a stable DeviceNet system with a wide variety of
devices.
Communication on the DeviceNet Network
Data exchange using polling is the normal method of communication and begins when the port is downloaded. The
port uses the polling connection configured in the device. The port verifies the device's Vendor ID, Device Type, and
Product Code, and I/O polling size attributes and then begins exchanging data with the device. The data is mapped by
the user to signals. Refer to the Adding DeviceNet Signals topic.
Note The change-of-state and strobe methods of communication are not supported by the DeltaV system.

DeviceNet EDS Files


The DeviceNet protocol specifies that the device manufacturer provide a text file for every device. This file, called an
Electronic Data Sheet (EDS), contains all the parameter information for a device: number of parameters, parameter
groupings, parameter name, minimum, maximum, and default values, units, data format, and scaling. The EDS file
may also specify the default I/O polling sizes. When the EDS file is imported into the DeltaV Library, it creates a new
DeviceNet revision. When the revision is added to the port, it creates a new DeviceNet device.

I/O Configuration

309

DeviceNet in the DeltaV System


Inside this topic
Configuring the DeviceNet Master
Importing and Modifying Electronic Data Sheets
Modifying Input/Output Sizes
Modifying Parameter Values in the Library and Setting Parameter Download Preferences
Using DeviceNet with DeltaV Function Blocks
The DeltaV DeviceNet card conforms to the DeviceNet specification as an interface to a control application such as
the DeltaV system. There is one port on the DeltaV DeviceNet card. In the DeltaV system, you use the DeltaV
Explorer to perform the tasks described in this section.
Note The DeltaV system supports only DeviceNet devices that support I/O polling.

Configuring the DeviceNet Master


Configuring the DeviceNet master consists of adding the card to the DeltaV Explorer's I/O subsystem and
configuring the port. In the Add Card dialog, select Bus Cards in the Card class field and then select DeviceNet as the
card type. Port configuration involves specifying the card's behavior if it can't communicate with the DeltaV
Controller (Stop Scanning or Continue Scanning) and specifying the baud rate (125kb, 250kb, or 500kb). Remember
that the baud rate for each device must match the baud rate set for the DeviceNet master. Refer to Setting the Baud
Rate for more information. The DeltaV Explorer online help on the port properties dialog box provides detailed
information on all the configuration properties for the DeviceNet card.
Importing and Modifying Electronic Data Sheets
Importing an EDS file into the DeltaV Explorer Library creates a hierarchy of categories (Vendor Name, Device
Name, Major Revision) under DeviceNet Devices in the DeltaV Explorer Library. Once you import an EDS file into
the library, you can modify device input/output sizes, select the parameters to download, and modify parameter
values. Right-click on the revision in the library and select Properties to see the revision properties (Vendor ID,
Device Type, and Product Code, other device information, and default values for the input/output sizes).
Note Any changes that you make to a revision at the Library level (modifying parameter values, input/output sizes,
signal values) other than parameter download options will affect future instances of the device but existing instances
of the device are not affected. Changes made to device parameters, I/O sizes, or signals at the device level affect only
that device.

Modifying Input/Output Sizes


The input/output sizes for the device are configurable. The DeltaV system uses the default input/output sizes if
available in the EDS file; otherwise, it sets the input/output sizes to 0. Refer to the device documentation to determine
the input/output sizes and to determine how to map the data to DeltaV signals.

310

System Configuration

Modifying Parameter Values in the Library and Setting Parameter Download Preferences
There are two types of parameters for DeviceNet devices:

Read only parameters that are used to monitor the current status of devices. Read only parameters are not
configurable and are not downloaded.

Configurable parameters that can be modified and downloaded.

You can view and modify default parameters and select the parameters that you want to include in the download at
the DeltaV Explorer Library level. Any changes made to default parameters at the Library level affect the selected
revision and all devices of that type subsequently created from that revision. Follow these steps to modify default
parameters in the Library:
1

Select the revision.

Click the right mouse button.

Select Default Parameters.

Use the Default Parameters dialog box to modify the default parameters and to open the Download Preferences dialog
box. Use the Download Preferences dialog box to select the parameters that you want to include in the download and
to deselect the parameters that you want to exclude from the download. Refer to the DeltaV Explorer online help for
complete help on the fields in this dialog box. It is highly recommended that you refer to the device documentation
and select for download, only those parameters that are needed for the device. In addition, deselect parameters that
have potential side effects such as MAC ID and baud rate. When you click OK in the Download Preferences dialog,
you will see your changes in the Default Parameters dialog box.
Using DeviceNet with DeltaV Function Blocks
Refer to Using Profibus DP, DeviceNet, and AS-Interface with DeltaV Function Blocks for more information.

Configuring DeviceNet Devices


Inside this topic
I/O Polling
Setting the Device Address
Setting the Baud Rate
Modifying Parameter Values at the Device Level
Downloading Devices
Uploading Parameter Values
Adding DeviceNet Signals
Configuring a DeviceNet device involves adding the device to the port, enabling or disabling I/O polling, setting the
device address, setting the baud rate, modifying parameter values and input/output size, and adding signals.
To add a new DeviceNet device, drag a revision from the DeltaV Explorer Library to the port under the DeviceNet
card, or right-click the port, select New DeviceNet Device, and browse for the revision. When you add or delete a
device placeholder, or change its address, you must download the port. Use the device properties dialog (right-click
on the device and select Properties) to enable I/O polling, add a device description, set the device address, and modify
the input/output sizes for this device only. Refer to the Modifying Input/Output Sizes topic.
Enabling I/O Polling
Select the Enable I/O Polling option to exchange I/O data between the device and the DeviceNet master. In order for
data exchange to occur, the VendorID, Device Type, Product Code, and input/output sizes must match.

I/O Configuration

311

Note If there is no match, the connection breaks, and no data is exchanged. Also, the VendorID, Device Type,
Product Code, and input/output sizes cannot be read from the device. The verification only identifies a match in these
items, it does not read back the values. Disable I/O Polling and download the device, and then read back Vendor ID,
Device Type, Product Code, and input/output sizes using DeltaV Diagnostics to troubleshoot communication
problems.

Setting the Device Address


An address configured for a DeltaV Explorer placeholder must match the MAC ID of the device you intend to place
on the network. (Address 63 is reserved for new devices and address 62 is reserved for diagnostic purposes. Do not
use these addresses.) You can set the address:

On the device using switches and device specific parameters.

With DeltaV Diagnostics if the device supports the standard method of addressing through setting the MAC
ID parameter of the DeviceNet Object.

Follow these steps to set the device address:


1

Disable I/O Polling for the device in DeltaV Explorer and download the DeviceNet card.

Open DeltaV Diagnostics.

Right click on the device in the left pane, select Set Device Address, and enter an address.

Enable I/O Polling and download the card in DeltaV Explorer to resume data exchange.

Note Set the address before you put the device on the network if the port is operational. Do not attach the device if
you do not know the address or baud rate.

Setting the Baud Rate


The baud rate for each device must match the baud rate set for the DeviceNet master. Do not attach a device if you do
not know the baud rate and be sure that the baud rate is correct before attaching a device to the network. The manner
in which the baud rate is set depends upon the device type:

Some devices use switches on the front of the device to configure the baud rate. Consult the device
documentation for information.

The EDS file for some devices supports a baud rate parameter for configuration through DeltaV software.

Some devices support the use of the DeviceNet Object's baud rate attribute to set the baud rate. (Consult the
device's conformance documentation.) Use DeltaV Diagnostics to set the baud rate for this type of device.
Be sure to disable I/O Polling for the device and to reset or power cycle the device for the baud rate to take
effect.

If the device supports neither switches nor the baud rate parameter, use a diagnostics tool to configure the
baud rate. Consult the device documentation for information.

The EDS file for some devices supports an autobaud rate parameter for configuration through DeltaV
software. Enable this parameter and attach the device to the network.

Modifying Parameter Values at the Device Level


You can read and modify parameters in online and offline devices.
Online Devices
You can read and modify parameter values in an online device. When you modify parameter values for an online

312

System Configuration

device, the value is stored in both the device and in the configuration database. (The value is written to the device and
read back from the device. If the write and read are successful, the value is stored in the database.) Remember that
any parameter modifications made at the device level affect only that device. Any new devices of the same type
inherit the parameter values specified in the device revision. To modify parameters, select the device, click the right
mouse button, and select Modify Parameters.
Offline Devices
If you attempt to modify parameters in an offline device, you will receive a message that the DeltaV system cannot
communicate with the device and you are given the option of modifying parameters offline. When you modify
parameter values in an offline device, the values are stored in the database only. Later, you can download to
synchronize the values in the database with the values in the device. Refer to the Downloading Devices topic for
more information.
NVRAM Button
Some devices require an explicit command to save parameter values in non-volatile memory. If you are modifying
parameter values for a device with this requirement, the NVRAM button is enabled on the Modify Parameters dialog
box. Click this button to save the parameter values to non-volatile memory. If you download the parameters to a
device with this requirement, the save command is sent automatically if the parameter download is successful.
Downloading Devices
You have four download options at the device level: Device, Properties and Signals, Parameters, and Update Device
Download Status. Select download to download the device as well as properties and signals and parameters. Select
Properties and Signals to download these options only and select parameters to download parameters only.
Note If you decide to download a device and during the download you notice a parameter value that is incorrect in the
database, you can deselect the parameter for download, download the device, and then modify the value online. You
cannot modify a value during the download.

Uploading Parameter Values


Uploading parameters reads all configurable parameters from the device and stores the values in the database. To
upload parameters, select the device, click the right mouse button, and select Upload Parameters.
Adding DeviceNet Signals
The EDS file may contain information about the data length, but it does not contain any information about the data
itself. The user maps the data to signals which have no semantic meaning to the system. For each signal you can
specify signal direction, data type, byte offset, scaling, and the bit pattern.
You can configure a device's signals at the DeltaV Explorer library level and at the physical network (I/O) level.
Library Configuration - To save engineering time for similar devices, create default signals in the library. Configure
the signals that are common to all the instances of the device. When the default information is complete, drag the
device revision to a DeviceNet port on the network.
Physical Network Configuration - Select the device at the I/O level, select New DeviceNet Signal from the right
mouse menu, configure the signal, and then assign a Device Signal Tag (DST) to the signal. (Select the signal, and
select Assign Device Tag from the right mouse menu.)

I/O Configuration

313

Using Profibus DP, DeviceNet, and AS-Interface with DeltaV


Function Blocks
The following sections provide information for configuring Profibus DP, DeviceNet and AS-Interface devices with
AI, AO, DO, PID and DC function blocks.

Analog Signal Scaling for AI and AO Function Blocks


If you check Use Scaling in the Properties dialog for a Profibus and DeviceNet analog signal, the associated AI or AO
function block ignores its XD_SCALE parameter during block execution and the system uses the scaling values
defined for the signal. If the Use Scaling box is not checked in the signal's Properties dialog, the corresponding
function block uses the scaling values defined in its XD_SCALE parameter. For an AI function block, set the
L_TYPE parameter to Indirect and configure the OUT_SCALE parameter's range and units configured accordingly.

Special Considerations for Writing Output Signals


If you are writing output signals to a Profibus, DeviceNet, and AS-Interface device that has been configured for
failsafe action, be sure your control module is configured to track the failsafe action in the device should it occur. For
example, if communication between the DeltaV system and the device is disrupted the device itself may drive its
outputs to a failsafe state. The DeltaV system must know this has occurred and take appropriate action so that outputs
are not driven to the last good state by the DeltaV system when communication with the device is restored. Configure
your control module so that this happens, because the Profibus, DeviceNet, and AS-Interface standards do not
support readback of output values.
Profibus DP, DeviceNet, and AS-Interface output signals should be written in control modules by means of an
external reference parameter, which writes the value to the I/O card even when signal status is Bad. If you use a
Profibus DP, DeviceNet or AS-Interface DST reference in function blocks such as AO, DO, PID, and DC the value is
not written when signal status is Bad. It is important for the control module to be able to write the failsafe value to the
I/O card when the Profibus DP, DeviceNet, or AS-Interface device is in the failsafe state, to prevent a bump when the
failsafe state has cleared.

Using an Analog Output DST with the PID Function Block

314

System Configuration

If your Profibus DP, DeviceNet, or AS-Interface device goes to a failsafe state due to a failure in the device or a loss
of communication with the DeltaV system, the status of its DSTs in the DeltaV system is Bad. The following shows a
technique for analog outputs using a DeltaV PID function block. A condition function block detects Bad status in the
output DST and, after the failsafe time duration, causes the PID block output to track the failsafe value in the device.
After the failsafe state in the device clears, the PID block initializes from the failsafe value.
The following figure shows a similar technique for a discrete output using the Device Control function block. The
condition block is used in the same way as in the figure. In this case the DC block becomes interlocked to the 0
(passive) state when the device goes to failsafe state. When the failsafe state clears, SP_D and CAS_IN_D are in the
passive state, and can be written to the active state at the appropriate time.

Using a Discrete Output DST with the DC Function Block

Using a Discrete Output DST with Boolean or Expression Logic

I/O Configuration

315

The previous figure illustrates using the condition block when you are writing the discrete output with boolean or
expression logic. Whether the output is maintained or pulsed, the idea is to be sure the output is the device failsafe
value when the device is in the failsafe state.

Anti-Aliasing Filtering
Hardware and software signal filtering is supported in the DeltaV system:
The analog input card contains hardware filtering that limits the frequency of the input signal seen by the digital-toanalog (D/A) converter to about 3 Hz.
In addition, you can define software filtering to be applied at the analog card when you configure the analog input
channel properties (FILTER channel parameter). This feature prevents aliasing of the signal if the module execution
rate is set slower than twice the highest frequency component of the input signal.
The default setting for the software filter is Filter Disabled. If an input signal is relatively free of process noise and is
contained in a module executing a moderately fast rate, you might not need to apply additional software filtering at
the card.
If you choose to modify the filter, you see a selection of filter time constants in the Named State list. If you follow the
module execution rate guideline (period of control) that is shown in parentheses next to the filter time constant you
select, no aliasing will occur, even if the signal has significant noise.
Note If you modify the filter on an input channel, you might need to retune any control block that uses the channel for
its controller variable.

Overrange and Underrange Detection


Overrange and underrange detection is provided on each channel input obtained through the 4-20 mA signal and the
FIELD_VAL_PCT and HART_FIELD_VAL parameters. The detection point is specified in percent of scale through
the I/O channel properties OVERRANGE_PCT and UNDERRANGE_PCT parameters. When the channel signal
exceeds the overrange or underrange values, the status of the analog input block PV parameter is set to high- or lowlimited, respectively. If you set these limits to 131% and -25% on a channel, the overrange and underrange detection
is disabled.

NAMUR Limit Detection


You can enable NAMUR limit detection for the analog input value by configuring the I/O channel properties
NAMUR_ENA parameter. When this feature is enabled (TRUE) and the IO_IN type is FIELD_VAL_PCT or
HART_FIELD_VAL, the status of the input is set to Bad if the signal level is above 21 mA or below 3.6 mA for more
than four seconds. The Bad status is cleared when the signal returns within these limits. You can use this feature
when the transmitter is designed to flag a device failure by setting its current signal outside the normal 4-20 mA
range.

316

System Configuration

Failure Action Settings


All I/O cards in the DeltaV I/O subsystem support failure action operation. The failure action depends upon the card
type. After the controller downloads a configuration to an I/O card, it enables a 2-second RailTimeOut Period in the I/
O cards. After the timeout period is enabled, if communications to the controller are lost for more than 2 seconds, the
I/O cards will enter the failure action mode. Once a card is in the failure action mode, it requires an exit failure action
mode from the controller to resume normal operations. This 2-second timeout period is not configurable by the user,
nor can it be disabled.

What Causes a Card to Enter Its Failure Action Mode?


A card enters its failure mode when communications with the controller are lost for more than 2 seconds. Among the
conditions that cause configured I/O cards to enter the failure action mode are:

A simplex controller is removed.

A simplex controller is upgraded.

A hardware or software failure in the controller that interrupts communications for more than 2 seconds.

Note I/O cards must be receiving DeltaV power and field power to enter the configured failure action mode.

Failure Action by Card Type


While all DeltaV I/O cards support failure action, a card's failure action operation depends upon its type. All
configured I/O cards turn on the red Error LED, but only output cards take any further failure action. The following
failure action configuration options are available for configured OUTPUT channels:

Failure Action Mode Designates if the channel should HOLD LAST VALUE or OUTPUT FAILURE
ACTION VALUE.

Failure Action Value Specifies the value used if the channel is configured to OUTPUT FAILURE
ACTION VALUE

I/O Configuration

317

.
Card

Failure Action Mode Options

Analog Output

Hold Last Value: The output is held at the last value received from the controller before the
failure action condition occurred.
Use Configured Failure Action Values: The output is driven to the configured failure action
value when the failure action condition is entered.
Note All outputs values below 1 mA (including failure action values) are clamped to 1mA to
ensure that the open loop detection mechanism of the D/A converter is always operable.

Discrete
Output

Hold Last Value: The outputs continue with the latest configuration and output values. This
applies to all channel types. If the channel is configured to be continuous pulse output type, it
continues with the latest period and duty cycle. If the channel is configured to be a momentary
pulse output type, it continues to process the current pulse. No additional pulses can be
generated.
Use Configured Failure Action Values: In this mode, failure action forces the outputs to go to
predefined levels. If the channel is configured as momentary or continuous pulse output type,
the pulse is aborted for the failure action value.

Redundant Cards
For redundant Series 2 cards, loss of controller communication with both cards causes both cards to take their failure
action, but with slight differences. Both cards illuminate their red Error LEDs, but only the active card drives the field
outputs. Removing the active card will NOT cause failure action output values to remain, since a switchover cannot
occur when a card is removed.

Isolated Input Channel Error Detection


The Isolated Input card's RTD and Thermocouple channels support full error detection for open loops and short
circuits. MilliVolt and Voltage channels support partial error detection. For RTD and Thermocouple channels, use the
channel Status parameter in DeltaV Diagnostics to diagnose errors. For MilliVolt and Voltage channels, use the Value
and Status parameters to diagnose errors.
The following table shows how DeltaV Diagnostics reports short circuits and open loops in Isolated Input card
channels.
Channel Type

Error Condition

Value in DeltaV Diagnostics

RTD - 2 Wire

Short
Open Wire to Terminal 2
Open Wire to Terminal 3

Sensor Out of Range


Sensor Out of Range; then Sensor Bad
Sensor Out of Range; then Sensor Bad

RTD - 3 Wire

Short
Open Wire to Terminal 2
Open Wire to Terminal 3
Open Wire to Terminal 4

Sensor Out of Range


Sensor Out of Range; then Open Sensor or A/D Converter error
Sensor Out of Range
Sensor Out of Range; then Open Sensor or A/D Converter error

318

System Configuration

Channel Type

Error Condition

Value in DeltaV Diagnostics

RTD - 4 Wire

Short
Open Wire to Terminal 1
Open Wire to Terminal 2
Open Wire to Terminal 3
Open Wire to Terminal 4

Sensor Out of Range


Sensor Out of Range; then Open Sensor
Sensor Out of Range
Sensor Out of Range; then Open Sensor
Sensor Out of Range

Thermocouple

Short
Open Wire to Terminal 2
Open Wire to Terminal 3

Shows the Cold Junction Compensation temperature.


Value drifts upward; then goes out of range.
Value drifts upward; then goes out of range.

mV - Bipolar

Short
Open Wire to Terminal 2
Open Wire to Terminal 3

Value is approximately 50%.


Value is approximately 50%.
Value is approximately 50%.

Volts - Unipolar

Short
Open Wire to Terminal 2
Open Wire to Terminal 3

Value near zero; Status may or may not be Bad.


Value near zero; Status may or may not be Bad.
Value near zero; Status may or may not be Bad.

Volts - Bipolar

Short
Open Wire to Terminal 2
Open Wire to Terminal 3

Value is approximately 50%.


Value is approximately 50%.
Value is approximately 50%.

Outputs After a Self-Test Failure


DeltaV output cards perform a power up self-test as well as a periodic online self test once the cards are running.
Each card type has a unique behavior.

Analog Output Cards


All Power-Fail, RAM, ROM, Database Integrity, and other self-test failure errors can initiate a restart of the card.
During a restart, the outputs are off (zero current) while all the self-tests are performed. After the card successfully
completes all the power-up self-tests, the outputs are driven to 1 mA and wait for the system to download the
configuration and enable the channels. The download and channel enabling are performed automatically.
Note Analog output card outputs cannot be driven below 1 mA except when in an error condition.

Discrete Output Cards


Cold Restart - A cold restart turns off the outputs. After a successful completion of self-tests, the outputs remain off
until a valid configuration has been received. All self-test errors are treated as Cold Restart Errors.
Note Upon receiving a configuration that indicates a change from one type of output to another, the outputs switch to
the off state.

I/O Configuration

319

Integrating PROVOX and RS3 I/O


The DeltaV Interface to PROVOX I/O and DeltaV Interface to RS3 I/O enable you to use existing PROVOX and
RS3 I/O with a DeltaV system. Support for PROVOX and RS3 I/O is integrated into the DeltaV Explorer,
Diagnostics and Control Studio applications.
Documentation for these interface products is in the following locations:

320

DeltaV Disk 4 \_Support\DeltaV Interface for PROVOX IO

DeltaV Disk 4 \_Support\DeltaV Interface for RS3 IO

System Configuration

Customizing the Process History View


Inside this topic
Process History View Command Line Interface
Design
Specifying the Filename
Specifying a New Document Type
Specifying the Area Name
Specifying the Device (Node) Name
Specifying the Module (Tag) Name
Specifying the Event Type
Specifying the Category
Specifying the Start Time
Specifying the Time Interval
Specifying the End Time
Specifying the Comparison Time
Specifying the Parameter Reference Names
Specifying Parameter Reference Substitution String
Prompting for Parameter Reference Substitution String
Specifying a Comparison Time
Specifying a Parameter
Specifying a State
Specifying a Level1
Specifying a Desc1
Specifying a Desc2)
Process History View Command Line Interface
The Process History View Command Line Interface (CLI) allows you to customize the initial startup of the DeltaV
Process History View from DeltaV Operate. Its primary purpose is to enable you to create Operator Interface toolbar
buttons or other pictures to launch Process History View in context with the picture currently displayed in Operator
Interface.
Design
The CLI for the Process History View is designed to support different initial startup situations for the Process History
View application. You can start the Process History View application with an Events, Charts, or E+Charts document
and then modify it to display the desired result. In order to support the startup situations, the command line has
arguments for specifying:

filename - (filename)

new document type - (/new)

area name - (/area)

device name - (/device or /dev or /node)

module name - (/module or /tag)

event type - (/type)

category - (/category or /cat)

start time - (/starttime)

time span - (/span or /hour or /hours)

Customizing the Process History View

321

end time - (/endtime)

comparison time - (/starttime2 or /comparetime)

parameter reference names - (/trend or /trends)

parameter reference replacement name - (/sub)

module selection (/prompt) (opens the DeltaV Browser)

Note You can use a hyphen (-) in place of a forward slash (/). Therefore, you can enter /area as area. If there is a
filename, it must be the first argument. After each parameter, there must be a space followed by the value for that
parameter.
The startup command is CHS. This example starts the Process History View application and opens a saved file called
Reactor.phvc. If you do not provide a specific directory, the Process History View application searches for the file in
the default charts subdirectory (DeltaV/Dvdata/Charts). In this example, Process History View opens the file
Reactor.phvc, which resides in the default charts subdirectory (DeltaV/Dvdata/Charts):
CHS Reactor.phvc
The arguments are order independent and uncoupled (except for time options). However, some only affect a specific
type of display. For example, if displaying a Chart, the event-specific arguments are ignored. If a filename is
provided, it must be the first argument after the CHS command.
Avoid combining mutually exclusive searches. For example, you can only pair the event type ALARM with the
category PROCESS. Similar pairings occur for the event types CHANGE and DOWNLOAD.
Note If you combine mutually exclusive options, remember that when you specify the event type ALARM, you can
only specify the category PROCESS. Any other value results in records not being found. Instead, the CLI accepts
these currently mismatched pairs with the result being that records are not found in the chronicle.
Arguments (parameters and qualifiers) are indicated by either a hyphen (-) or forward slash (/) and are not case
sensitive.
Wildcards
You can use the wildcard characters * or ? when specifying an Event Filter argument (area, device, and so on). The
wildcard character '*' represents zero or more of any printable character, and the wildcard character '?' represents a
single printable character. Both wildcard characters can appear multiple times in an argument, and there are no
restrictions on the placement of the wildcard characters. (Wildcard characters can appear at the beginning, end, or
anywhere in an argument.)
The following sections provide details for each argument.
Specifying the Filename
To open a document that was saved using the Process History View application, provide the filename in the command
line. The filename must be the first parameter after the executable name, CHS. If the file exists in the default
directory for Process History View documents (DeltaV/Dvdata/Charts), supply only the filename and .phv_
extension on the command line (FIC101.phvc). If the file exists in a subdirectory (DeltaV/Dvdata/Charts/reactors),
include the subdirectory with the filename and extension (reactors/FIC101. phvc).
In the first example, Process History View opens the file Motors.phvc, which resides in the default directory
(DeltaV/Dvdata/Charts). In the second example, Process History View opens the file MyChart.phvc, which resides
in the subdirectory ../lib.

322

System Configuration

Examples:
CHS Motors.phvc
CHS lib/MyChart.phvc
Specifying a New Document Type
Flag name : new
Type : New Document
Applies to : Events, Chart, and EChart
Acceptable values : One of the character strings (Event, Chart, EChart). Not case sensitive.
Description : This argument opens a new document of the specified type (Chart, EChart, or Events). Chart opens a
new empty document that shows only a graph. EChart opens a new empty document that shows both the graph and
events grid, and Events opens a new empty document that shows only the events grid.
This parameter creates a new Process History View document. Typically, the /new argument can be combined with
other arguments.
Examples:
CHS /new events
CHS /new Chart
CHS /new EChart
Specifying the Area Name
Flag name : area
Type : Event Filter
Applies to : Events and E+Chart
Acceptable values : One or more character strings. Enclose in parentheses or double quotes. If more than one value,
separate with a comma.
Description : This parameter is used to add entries to the Area filter list. The search string can be a single area name,
a list of area names, or the string thisUser. The string thisUser can also appear in a list of areas. If an area name is
repeated in the list, only one instance of it is retained.
If the option is not present on the command line, no filtering of areas is performed.
Example :CHS /new events /area (AREA_1, AREA_2)
Specifying the Device (Node) Name
Flag names : device , dev , node
Type : Event Filter
Applies to : Events and E+Chart
Acceptable values : One or more character strings. Enclose in parentheses or double quotes. If more than one value,
separate with a comma.

Customizing the Process History View

323

Description : This parameter is used to add entries to the Node filter list. The search string can be a single Node name
or a list of Node names. If a node name is repeated in the list, only one instance it is retained.
If the option is not present on the command line, no filtering of node names is performed.
Examples:
CHS /new events /node (CTLR1, CTLR2)
CHS /new events /dev (CTLR1)
Specifying the Module (Tag) Name
Flag names : module, tag
Type : Event Filter
Applies to : Events and E+Chart
Acceptable values : One or more character strings. Enclose in parentheses or double quotes. If more than one value,
separate with a comma.
Description : This parameter is used to add entries to the Module filter list. The search string can be a single Module
name, or a list of Module names. If a Module name is repeated in the list, only one instance of it is retained.
If the option is not present on the command line, no filtering of Module names is performed.
Examples:
CHS /new events / Module (InletFlow, OutletFlow)
CHS /new events / Module (OneFlow)
Specifying the Event Type
Flag name : type
Type : Event Filter
Applies to : Events and E+Chart
Acceptable values : One or more of the character strings (EVENT, ALARM, CHANGE, STATUS and
DOWNLOAD). Enclose in parentheses or double quotes. If more than one value, separate with a comma.
Description : This parameter is used to add entries to the Type filter list. The search string can be a single Type, or a
list of Types. If a Type is repeated in the list, only one instance of it is retained.
If the option is not present on the command line, no filtering of Types is performed.
Examples:
CHS /new events /type (EVENT, ALARM)
CHS /new events /type (EVENT)
Specifying the Category
Flag names : category , cat
Type : Event Filter
Applies to : Events and E+Chart

324

System Configuration

Acceptable values : One or more character strings (USER, PROCESS, DEVICE, and SYSTEM). Enclose in
parentheses or double quotes. If more than one value, separate with a comma.
Description : This parameter is used to add entries to the Category filter list. The search string can be a single
Category or a list of Categories. If a Category is repeated in the list, only one instance of it is retained.
If the option is not present on the command line, no filtering of Category is performed.
Example :CHS /new events /Category (USER, PROCESS)
Specifying the Start Time
Flag name : starttime
Type : Time specification
Applies to : Events, Chart, and E+Chart
Format : Same formats as the endtime argument. There are two valid formats. For specifying the absolute start time,
either use the format specified for the workstation ( Start | Control Panel | Regional Settings ) or Continuous
Historian format.
Description : The start time is treated differently for Event displays than it is for Charts and E+Charts.
In Event displays, specifying the start time results in the display of the most recent events, beginning at the specified
time, and ending at the current time. The default display is the most recent hour if not otherwise defined. This
argument is not to be used with the time span arguments for Events. If you provide both a start time and a time span,
the start time is ignored. The start time must be in the format specified in Regional Settings (available in the Control
Panel).
Example :CHS /new events /starttime 10:00
For Charts and E+Charts, the default time range is 8 hours, ending at the current time. If creating a new Chart or
E+Chart with the /new qualifier, use the /starttime argument to select a specific start time. If opening an existing file,
you can use this parameter to change the configured value in the file. If using the Process History View application,
this is the same as clicking Chart | Configure Chart, clicking the Time Scale tab, and entering the value in the Time
Start field.
For Charts and E+Charts, you can use the starttime argument with the other time specification arguments, span or
endtime . The start time argument can be either of the two following types:
1

Same format as defined in the Date and Time tabs of the Regional Settings dialog (available in the Control
Panel).

A valid Continuous Historian time format:

Absolute :DD-MMM-YY hh:mm:ss


Relative :+- D, h, m, s
Valid code :SUNDAY, TODAY, JULY,
Current time :*
Combination of * or a Valid code with a relative offset: YESTERDAY+8h
Examples:
CHS /new chart /starttime 10:00 /endtime 14:00
CHS /new E+Chart /starttime Monday+8h /span 12

Customizing the Process History View

325

Note The keyword today means today's date at 00:00, and the keyword yesterday means yesterday's date at 00:00.
Other keywords are the days of the week (Monday, Tuesday, Wednesday) and months of the year (January, February,
March). You can also use a format such as Tuesday+14h to mean 2 PM of the most recent Tuesday. Since the time
string can contain forward slashes (12/05/97 08:00:00 PM), enclose the string in double quotes or parentheses.

Specifying the Time Interval


Flag names : span , hour , hours ( recommended usage : span )
Type : Time span specification
Applies to : Events, Chart, and E+Chart
Format : if span: #days #hours:#minutes
if hour or hours: #hours
Acceptable values : If using the /span argument, the day must be a positive integer (it is not required for spans of less
than one day). For example, specify two days as "2 00:00" . The hour is an integer between 0 and 23. The minute is an
integer between 0 and 59. If just a single integer is supplied, it is considered that number of hours. For example,
specify five hours as either "5" or "5:00".
Note The hour (and hours) flags support of previous versions but are not recommended.
Description : The time interval is treated differently for Event displays than it is for Charts and E+Charts.
In Event displays, specifying the time interval results in the most recent specified interval of events to be displayed.
The default is for no time filtering. Also, do not use the time span with the StartTime argument. By design, arguments
display only the most recent events, and the end time is always the current time. Therefore, provide either a start time
or a time interval to specify a smaller time span. If you provide both a start time and a time span, the start time is
ignored.
For Charts and E+Charts, you must specify the time interval with the span argument. For any new chart, the default
time range is 8 hours, ending at the current time. If creating a new Chart or E+Chart with the /new qualifier, use the /
span argument to modify the value from its default 8 hours. If opening an existing file, you can use this parameter to
change the configured value in the file. If using the Process History View application, this is the same as clicking
Chart | Configure Chart, clicking the Time Scale tab, and entering the value in the Span field.
For Charts and E+Charts, you can use the span argument used with the other time specification arguments, starttime
and endtime.
Examples:
1

In this example, the Process History View application opens a new events document that displays events that
occurred four hours prior to the current time.
CHS /new events /span 4

In this example, the Process History View application opens an existing file, and modifies the time span to 2
hours.
CHS motor.phvc /span "2:00"

326

System Configuration

Specifying the End Time


Flag name : endtime
Type : Time specification
Applies to : Chart, and E+Chart
Format : As specified in Regional Settings, or a valid Continuous Historian time.
Description : For Charts and E+Charts, the default time range is 8 hours, ending at the current time. If creating a new
Chart or E+Chart with the /new qualifier, use the /endtime argument to select a specific end time other than current
time ('*'). If opening an existing file, you can use this parameter to change the configured value in the file. If using the
Process History View application, this is the same as clicking Chart | Configure Chart, clicking the Time Scale tab,
and entering the value in the Time End field.
You can use the endtime argument with the other time specification arguments, span or starttime. The endtime
argument can be either of the two following types:
1

Same format as defined in the Date and Time tabs of the Regional Settings dialog (available in the Control
Panel).

A valid Continuous Historian time format:

Absolute :DD-MMM-YY hh:mm:ss


Relative :+- D, h, m, s
Valid code :SUNDAY, TODAY, JULY,
Current time :*
Combination of * or a Valid code with a relative offset: YESTERDAY+8h
Examples:
CHS /new chart /starttime 10:00 /endtime 14:00
CHS /new E+Chart /starttime Monday /endtime TODAY
Note The keyword today means today's date at 00:00, and the keyword yesterday means yesterday's date at 00:00.
Other keywords are the days of the week (Monday, Tuesday, Wednesday) and months of the year (January, February,
March). You can also use a format such as Tuesday+14h to mean 2 PM of the most recent Tuesday. Since the time
string can contain forward slashes (12/05/97 08:00:00 PM), enclose the string in double quotes or parentheses.
If endtime is an asterisk (current time), the chart shifted left 20% of the time window when it initially opens. If you
want the chart to start with a relatively full screen and still update in real time, configure the start time and the time
span so that the current time is in the window near the right portion of the screen. For example, if you want a time
window of 8 hours, set the Span to 7:59 and set the Starttime to *-8h. Data updates for 1 minute before the time scale
is shifted to keep the current time visible. Using the values 8:00 for Span and * for Endtime displays the most recent
6 hours and 24 minutes (80% of 8 hours), and updates for 1 hour and 36 minutes before shifting the time scale.
In these examples (one showing the starttime and endtime arguments and the other showing the starttime and span
arguments), the Process History View application opens an existing file (Motors.phvc) with a time range that starts
yesterday at 00:00 and ends today at 00:00:
Examples:
CHS Motors.phvc /starttime YESTERDAY /endtime TODAY
CHS Motors.phvc /starttime YESTERDAY /span 24:00

Customizing the Process History View

327

Specifying the Comparison Time


Flag names : starttime2, comparetime
Type : Comparison time specification
Applies to : Chart, and E+Chart
Format : As specified in Regional Settings, or a valid Continuous Historian time.
Description : Identical to format for endtime (and starttime for Charts and E+Charts):
1

Same format as defined in the Date and Time tabs of the Regional Settings dialog (available in the Control
Panel).

A valid Continuous Historian time format:

Absolute :DD-MMM-YY hh:mm:ss


Relative :+- D, h, m, s
Valid code :SUNDAY, TODAY, JULY,
Current time :*
Combination of * or a Valid code with a relative offset: YESTERDAY+8h
The comparison time creates a chart that compares all defined trends with a duplicate trend starting at a different
point in time. The point in history is specified by the starttime or comparetime option. If you open an existing file,
each defined trend is copied to the first available location, and the trend specific start time is updated with the value
sent with this parameter. If you create a new Chart or E+Chart, all defined trends are copied in a similar way.
In the first example, the Process History View application opens a new trend document and compares data for the
parameter reference REACTOR1/PID1/PV.CV, starting from 00:00 today with itself at 00:00 yesterday.
In the second example, the Process History View application opens a previously created file and requests comparison
information starting at 2:00 am.
Examples:
CHS /new chart /trend (REACTOR1/PID1/PV.CV) /starttime
Today /span 24 /starttime2 Yesterday
CHS Reactor1.phvc /starttime2 2:00
Specifying the Parameter Reference Names
Flag names : trend, trends
Type : Parameter Reference Names
Applies to : Chart, and E+Chart
Acceptable values : Any valid parameter reference in the system. For any values collected historically, the full
pathname is required (include the .CV, .ST, and so on). For points not available historically, but available in OPC,
enter the parameter reference with or without the extension.
Description : There can be up to 8 parameter reference names specified per Chart or E+Chart. Enclose the parameter
name list in parentheses or double quotes. If specifying more than one parameter reference, separate the individual
elements of the list with commas.
In this example, Process History View shows data for the last hour for the two trends, MTR101/PID1/PV.CV and
MTR201/PID1/PV.CV:

328

System Configuration

Examples:
CHS /span 1:00 /trend (MTR101/PID1/PV.CV,
MTR201/PID1/PV.CV)
Specifying Parameter Reference Substitution String
Flag name: sub
Type : Substitution string
Applies to : Chart and E+Chart
Acceptable values : A single character string. If the string contains a hyphen (-) or a forward slash (/), you must
enclose the entire string in parentheses or double quotes.
Description : The argument sub is used to modify the parameter reference strings already defined in an existing
chart, such that the module name portion of the defined parameter reference is replaced with the substitution string. A
parameter reference (such as FIC-101/PID1/PV.CV) is in the form:
MODULE NAME/BLOCK/PARAMETER.FIELD
All characters in the parameter reference up to the first forward slash (/) are replaced by the string sub. For example,
if a document contains the configured parameter references FIC-101/PID1/PV.CV and FIC-101/PID1/SP.CV, and sub
MTR101 is specified on the command line, the chart automatically changes the two parameters to MTR101/PID1/
PV.CV and MTR101/PID1/PV.CV.
If a parameter reference is blank, it will remain blank. If a parameter reference contains no forward slash, the entire
string is replaced with the substitution string.
If a Chart or E+Chart is called with a substitution string, then it is not possible to save the chart. However, it is
possible to modify the existing configuration before exiting.
In this example, the chart Motors.phvc contains the parameter references FIC-101/PID1/PV.CV and FIC-101/PID1/
SP.CV, which are replaced by MTR101/PID1/PV.CV and MTR101/PID1/PV.CV.
Example :CHS motors.phvc /sub MTR101
Note You must supply a filename with the sub argument.

Prompting for Parameter Reference Substitution String


Flag name : prompt
Applies to : Chart and E+Chart
Acceptable values : A single character string. If the string contains a hyphen (-) or a forward slash (/), enclose the
entire string in parentheses or double quotes.
Description : The argument prompt is identical to sub except that it starts the DeltaV Browser to select a module.
Then, like sub, it replaces modules existing in the chart with the module selected in the browser.
The string following the prompt flag is the starting location for the browser. This can be any string but is typically the
area where the expected module resides (for example, AREA_A). If the area is unknown, enter any string that does
not match an existing area (for example, /prompt NONE). It is also a good idea to put a default value with the /prompt
argument. If the user presses the Cancel button while browsing, the default value is used in the substitution.

Customizing the Process History View

329

Specifying a Comparison Time


Flag name : starttime2 or comparetime
Type: Chart StartTime2 entry
Applies to : Events and E+Chart
Acceptable values : Any valid time string.
Description : Copies every Parameter Reference configured in a chart and sets the StartTime2 parameter for each of
the copied items to the time parameter entered with this command.
Example : CHS chart1.phvc/starttime2 2:00
Specifying a Parameter
Flag name : parameter
Type: Event Filter
Applies to : Events and Echart
Acceptable values : Any string. Wildcards can be used in the string (* is a multi-character wildcard and ? is a single
character wildcard.)
Description : Places the associated string into the Parameter field of the Other Columns page of the Event Filters..
Example : CHS /new events/parameter ALARM*
Specifying a State
Flag name : state
Type: Event Filter
Applies to : Events and Echart
Acceptable values : Any string. Wildcards can be used in the string (* is a multi-character wildcard and ? is a single
character wildcard.)
Description : Places the associated string into the State field of the Other Columns page of the Event Filters.
Example : CHS /new events/state ACTIVE
Specifying a Level1
Flag name : level1
Type: Event Filter
Applies to : Events and Echart
Acceptable values : Any string. Wildcards can be used in the string (* is a multi-character wildcard and ? is a single
character wildcard.)
Description : Places the associated string into the Level1 field of the Other Columns page of the Event Filters.
Example : CHS /new events/level1 2-LOW

330

System Configuration

Specifying a Desc1
Flag name : desc1
Type: Event Filter
Applies to : Events and Echart
Acceptable values : Any string. Wildcards can be used in the string (* is a multi-character wildcard and ? is a single
character wildcard.)
Description : Places the associated string into the Level1 field of the Other Columns page of the Event Filters.
Example : CHS /new events/desc1 HIGH
Specifying a Desc2
Flag name : desc2
Type: Event Filter
Applies to : Events and Echart
Acceptable values : Any string. Wildcards can be used in the string (* is a multi-character wildcard and ? is a single
character wildcard.)
Description : Places the associated string into the Level1 field of the Other Columns page of the Event Filters.
Example : CHS /new events/desc2 LOW

Customizing the Process History View

331

Downloading Data
Inside this topic
What Happens during a Download
When To Download
What To Download
The workstations and controllers in your DeltaV system require configuration data from the DeltaV database in order
to operate. Initially, the DeltaV database stores all of the configuration data. You make changes to the configuration in
the database without affecting the operation of the controllers and workstations. When the configuration is complete,
you download that information to the workstations and controllers.
The data that you download allows the DeltaV system to manage your control strategy. For example, workstations
need to know all of the other nodes in the system as well as which areas to monitor and where to record events.
Likewise, controllers must have their assigned modules downloaded so that the modules can run in the controller.
You must also download the I/O card data so that the controller knows the type and enabled status of the channels and
the Device Tag associated with each channel.
You can download any data from within the DeltaV Explorer application. It is possible to download the entire
configuration (entire database) or small parts of the configuration by making the appropriate selections within
Explorer. For example, the Explorer lets you download a single controller, setup data, I/O card, or module by
selecting the icon for that item and choosing Download on the context menu (the menu that appears when you click
the right mouse button). In addition, you can download individual modules from within Control Studio.
A download temporarily disrupts the part of the operation of the controller or workstation that is being downloaded.
Care must be taken to determine if the process can withstand this temporary disruption. To ensure the safety of the
process, it might be necessary to delay the download of the configuration changes until the process can be shut down.
To minimize the effects of such disruption, it is recommended that only those parts of the configuration that have
changed be downloaded. This is particularly important in the case of controllers.
Download Physical Network
To download the entire configuration, perform the following steps:
1

Download the physical network.

Select the Physical Network icon and then right-click Download | Physical Network.
The workstation downloads all of the configuration data for all of the nodes in the system.

Note Downloading using the Object | Download | Physical Network command also downloads the configuration data.
Download Control Network
Downloading the control network is the same as downloading the physical network. To download the control
network, click the Control Network icon and then right-click Download | Control Network. The workstation
downloads all of the configuration data for all of the nodes in the system.
Note Downloading using the Object | Download | Control Network also downloads the configuration data.
Full (Total) Download (Workstation or Controller)
To download the entire configuration of a workstation or controller, select the item you want to download, right-click,
and then click the Download option from the menu. This downloads the entire configuration for the node selected
(workstation or controller) and is called a full (total) download.

332

System Configuration

Use a full download when the node has not yet been downloaded or has no configuration. Total controller downloads
should be avoided when the process is running. If there is already configuration present in the controller, a total
download will generally cause parameter values in the controller to be replaced with those from the configuration
database. There are some exceptions where matching behavior occurs, such as in controller function blocks directly
connected to output channels and for fieldbus shadow blocks. Depending on your configuration you could experience
an output disruption on a total controller download.
Refer to Preserving Configuration and Controller Data During Power Loss for more information on Restore
parameter values after restart feature.
Partial Download
If only part of the configuration has changed since the last full (total) download, a partial download may be the best
download option. A partial download minimizes disruption to control strategies that are currently running. A partial
download occurs when you select one or more modules and initiate a download.
When you initiate a partial download, the system sends the module changes to the appropriate controller. However,
the new modules will not execute until the running module completes its execution scan. When the scan of the current
module is complete, the controller copies the parameter value/function blocks combinations, as defined in the
following table. For MODE parameters the system copies the target mode field to the new module. The block
calculates the actual mode field when it begins to execute. Output and control blocks generally start in OOS mode on
the first execution after a download (partial and total, and on the first execution after a controller switchover), then
climb to their target mode. This provides proper re-initialization and handshaking with other blocks. The mode
change is expected and has no adverse effect on control.
On a partial download loops initialize to the current setpoint value regardless of whether setpoint ramping is on.
If the partial download fails because of a controller switchover, the controller that becomes the standby due to the
switchover will have a status of No configuration.
The partial download function matches function block parameters (in the old and new versions) by function block
name and type. User-defined parameters are matched by name and type. The partial download copy function supports
module-level, user-defined parameters for both modules and composites.
You can determine partial download behavior on a module-by-module basis using the Parameter download behavior
field on the General tab of the Module Properties dialog. Select one of the following options:

Preserve critical block values The controller copies critical function block values from the executing
module to the new module during a download. This selection typically minimizes disruption to the process.
Critical function block parameters are defined in the table below.

Preserve user-defined and critical block values The controller copies user-defined parameter values from
the completed scan of the current module to the new version of the module during a download. When the
new module executes its first scan, it uses the copied values in order to minimize process disruption. As
shown in the table, only a single field is copied for some of the function block parameters. This is the case
because the other fields (for example, Actual Mode or Target) are recalculated on block execution. For userdefined parameters, the entire parameter is always copied.

Use configured values The controller does not copy any parameter values from the executing module but
uses the values from the configuration database.

Instances when the Parameter Copy function does not occur:

The function block type is changed.

The data type of the user-defined parameter is changed. For example, the INPUT1 parameter is changed
from type float to type integer.

The dimension of an array parameter is changed.

Downloading Data

333

There is no matching parameter or function block.

Empty dynamic reference - $REF string is empty.

Types of user-defined parameters that do not support the copy behavior:

External/Internal references These are always set to the configured value.

User-defined parameters that are not at the top-level of modules or composites (for example, user-defined
parameters that are associated with SFCs or phases inside PLM, SFC, and unit modules).

SFCs do not support the copy behavior for user-defined parameters.


Critical Function Block Parameters Preserved During Partial Download
Function Block

Parameters and Fields

Analog Input
Pulse Input

OUT, MODE.TARGET

Analog Output

MODE.TARGET, PV, SP, SP_WRK, OUT

Bi-directional Edge Trigger


Negative Edge Trigger
Positive Edge Trigger

LAST_IN

Bias/Gain
Ratio

MODE.TARGET, OUT

Calculation/Logic

OUT[x]

Condition

DISABLE

Counter

COUNT, RESET_IN, IN_D, OUT_D

Device Control

MODE.TARGET, OUT_D, LASTOUT_D, FV_D,


FAIL_ACT, LASTPV_D, PV_D, LASTSP_D, SPWRITE,
DC_STATE, RESET_D, ACCEPT_D, SP_D,
LASTOUT_D(1-4)

Discrete Input

OUT_D, MODE.TARGET

Discrete Output

LAST_OUT_D, MODE.TARGET, OUT_D, PV_D,


READBACK_D, SP_D

Flow Metering (AGA_SI and AGA_US)

CURR_VOLUME, CURR_ENERGY, CURR_HRS_ON,


LAST_VOLUME, LAST_ENERGY, LAST_HRS_ON,
VOL_ACCUM, PCT_CURR_VOLUME,
PCT_CURR_ENERGY, PCT_CURR_HRS_ON,
PCT_LAST_VOLUME, PCT_LAST_ENERGY,
PCT_LAST_HRS_ON, PCT_VOL_ACCUM

Fuzzy Logic Control


PID

MODE.TARGET, PV, SP, OUT, SP_WRK, FIELD_VAL,


LASTOUT

Integrator

MODE.TARGET, SP, OUT, SABSTOTAL, ABSTOTAL,


STOTAL, RTOTAL, SRTOTAL, SSP, IN_1, IN_2,
REV_FLOW1, REV_FLOW2, RESET_IN

Inspect

ENABLED, PERFORMANCE, UTILIZATION

334

System Configuration

Function Block

Parameters and Fields

Input Selector

MODE.TARGET, OP_SELECT, OUT, SELECTED

Lab Entry

MODE.TARGET, OUT, DELAY

Model Predictive Control

BKCALIN[x], CNSTR[x], DSTRB[x], MNPLT[x],


MODE.TARGET, OUT[x], SP[x]

Model Predictive Control Professional (MPCPro)

BKCALIN[x], IN[x], PROC_IN[x], PROC_OUT[x], SP[x]

Neural Network

MODE.TARGET, OUT, FUTURE

Splitter

MODE.TARGET, BKCAL_OUT, SP, SP_WRK, OUT_1,


OUT_2

On-Delay Timer
OFF-Delay Timer

ELAPSED_TIMER, IN_D, OUT_D

Retentive Timer

ELAPSED_TIMER

Reset/Set Flip-flop
Set/Reset Flip-flop

OUT_D

Signal Characterizer

MODE.TARGET, OUT_1, OUT_2

Timed Pulse

ELAPSED_TIME, IN_D, OUT_D

Refer to the topics When to Download and What to Download for more details.
Setup Data Download
You also download a subset of configuration data that is not directly related to a module. This data is called setup
data. Setup data includes named sets, parameter security, cold restart information, redundancy information, alarm
preferences, and event chronicle definitions. A download of the setup data sends these changes to all the workstations
and controllers.
You can download setup data alone or with the configuration data. To download setup data alone, select the object in
DeltaV Explorer (for example, a controller) in the left pane. Then, click Object | Download | Setup Data. To download
setup data along with all other configuration data, click Object | Download | Selected Object.
Delete Unused Card Configuration
When you delete an I/O card using DeltaV Explorer, you must download this change to the controller. The Delete
Unused Card Configuration command downloads the deleted card information to the controller configuration without
disrupting control or requiring a download of the I/O subsystem. To use this command, select the I/O Subsystem for
the controller in DeltaV Explorer and then right-click Download | Delete Unused Card Configuration.
Resending Successful Downloads
The Resend Last Known Good Download function sends the last successful total download to a node without going
to the database. If you have performed a total download followed by one or more partial downloads, this function
resends all of the information contained in the total download as well as the partials. For controllers, the function
sends the same download script that would be sent to a controller that restarts after a power failure.
This function is especially useful for situations where a workstation fails due to a disk error. It enables you to bring
the new or repaired node up to the previous operational status without downloading recent edits to the configuration.
Do not use the Resend Last Known Good Download function after decommissioning a controller. Perform a full
download after recommissioning a controller.

Downloading Data

335

Downloading Values Referenced from OPC Mirror


Control modules support references to values derived from OPC Mirror. If a module references a value from OPC
mirror (for example, using an external reference parameter), the parameter value may change to the default
configured value after a download rather than using the value from OPC Mirror. To prevent this, make sure that the
Parameter download behavior on the module properties is set to Preserve user-defined and critical block values.
Otherwise, you must refresh the associated OPC Mirror pipe in order to restore the value in the module.
What Happens During a Download
When you select a download option, the system evaluates the data in the database for possible errors or omissions to
determine if it can be downloaded. For example, if you have a module referencing I/O from a different controller
node, the system displays a dialog that informs you of that fact. In the same way, the system displays a dialog if
function blocks in a Fieldbus module have not been assigned to fieldbus devices. The dialog box has the following
buttons: Download Anyway, Print, Cancel. The user selects one of these in order to cancel or proceed with the
download.
Note When you download a controller or a module for a controller, if the DeltaV system detects that parameter
changes have been made to the module online a popup appears asking if you want to select online parameter changes
to upload.
The popup has three buttons:

Yes -- Click this button to select the parameter changes to upload before downloading.

No -- Click this button to upload all parameter changes before downloading.

Cancel -- Click this button to avoid uploading any parameter changes and proceed to the Download
Confirmation dialog.

For more information on uploading parameters, refer to the Uploading Recorded Parameter Changes topic.
Note It is possible for a DeltaV user to make online changes between the time a user requests the download and the
time the system transfers the data. Online changes made within this window of time are not displayed as uploadable
parameter changes. For this reason, it is important for users performing downloads to coordinate the downloads with
those who have permission to make online parameter changes.
If you decide to continue downloading, the system downloads the data to the appropriate nodes and stores a copy of
the data on the ProfessionalPLUS workstation in the Powerup directory (DeltaV\DVData\Powerup). If the download
is a total download involving controllers, the system also stores a compressed version of the relevant portions of the
download in the controllers' nonvolatile memory. This enables the controller to perform a cold restart and download
itself if power fails and is restored. Refer to the topic entitled Preserving Configuration and Controller Data During
Power Loss for more information on how cold restart works.
The download progress log is saved to DeltaV\DVData by default for workstations in the control network. It is saved
to DeltaV\DVData\RemoteSystems\identifier for remote operator stations.
Caution A download can potentially bump the I/O. To prevent accidentally bumping the I/O, place the block
producing the outputs in manual mode before you download. Care must be taken to determine if the process can
withstand this temporary disruption. To ensure the safety of the process, it might even be necessary to delay the
download of the configuration changes until the process can be shut down.
Alarm parameter fields all get initialized to their default (or configured) value as is appropriate, the first execution
cycle of the module establishes the initial alarm state for it's alarms. In practice, this means that inactive,

336

System Configuration

unacknowledged alarms appearing in the alarm list prior to a download will not be in the list after the download
because they are initialized to acknowledged by the download.
Downloading large modules to a controller can use a large amount of system resources. Exact amounts vary
depending on the module being currently run by the controller and the size of the module being downloaded. To
ensure that you do not have a problem with system resources, place the running block in manual mode before you
download.
Large databases require significant amounts of free disk space in order to download successfully. Make sure that there
is a least half the size of the database in free disk space before downloading the database.
When to Download
The DeltaV Explorer marks the physical objects that require a download with the

symbol (blue triangle).

However, if you are making changes to the setup data, you see the
symbol (blue triangle) next to the
ProfessionalPLUS workstation (at the node level only). The setup data are global data. The changes you make to the
setup data affect all of the controllers and workstations. You must download ProfessionalPLUS setup data (or
changed setup data) in order for the setup data to be distributed to all workstations and controllers.
Caution A download can potentially bump the I/O. To prevent this from occurring, place the block producing the
outputs in Manual mode before you download. Care must be taken to determine if the process can withstand this
temporary disruption. To ensure the safety of the process, you might even need to delay the download of the
configuration changes until the process can be shut down.
Refer to the following table for a complete list of changes that require you to download.
Note A full download of each controller node must be performed before any partial download is allowed.
The following table lists changes you can make in the Explorer that would require a download.
Database Changes and Their Corresponding Downloads
When you make this change
in the database:

You must perform this download functions:

Assign a module to a controller.

Download the module to the controller node. This updates the local
module table in the ProfessionalPLUS station.

Unassign a module from a


controller.

1. Select the module in the Assigned Modules subsystem of the


controller. Delete the assignment.
2. Click the Update Download Status command for the controller.
This results in a blue triangle on ProfessionalPLUS station.
3. Click the Download Changed Setup Data command for the
ProfessionalPLUS. This downloads module table.

Assign a module from one


controller to another.

Download the module to the destination controller node. This


removes that module from the source node.

Add a workstation node.

Create the workstation node, export the workstation configuration


data to a floppy disk, run workstation configuration on the new node,
and then download the new workstation.

Downloading Data

337

When you make this change


in the database:

You must perform this download functions:

Add a controller node.

Download the new controller.

Add a card to a controller.

Download the I/O Card.

Modify a card.

Download the I/O Card. For serial cards, also download control
modules that reference the card.

Modify a channel.

Download the I/O Card.

Edit a module.

Download the modified module to the controller node.

Add an alarm type.

Download the ProfessionalPLUS setup data.

Modify an alarm type.

Download the ProfessionalPLUS setup data.

Modify an alarm priority.

Download the ProfessionalPLUS setup data.

Modify parameter security or field


security.

Download the ProfessionalPLUS setup data.

Add a new named set.

Download the ProfessionalPLUS setup data.

Modify a named set.

Download the ProfessionalPLUS setup data.

Add a named state to a named set


used by a command-driven or statedriven module.

Perform a partial download of the effected module within the


controller.
Perform a download of the setup data for the controller in which the
module resides.

Assign an area to a workstation.

Download the workstation node.

Unassign an area from a


workstation.

Download the workstation node.

Commission a controller.

Download the controller node. If other controller nodes were


downloaded prior to commissioning this controller, download the
setup data for those controllers. Until the setup data has been
download, modules in those controllers cannot communicate with
modules in the recently downloaded controller.

Add or remove a key from a user or


group.

Download the ProfessionalPLUS station.

Add or remove a user.

Download the ProfessionalPLUS station.

Add or remove a user from a group.

Download the ProfessionalPLUS station.

Add or remove a group.

Download the ProfessionalPLUS station.

338

System Configuration

When you make this change


in the database:

You must perform this download functions:

Add a second (redundant)


controller to a simplex controller.

Redundancy detection is automatic and does not require


decommissioning. After installing the standby controller, open
DeltaV Explorer. Select the newly redundant pair icon, right click and
select Download | Setup Data. This turns on redundancy for the pair
but does not disrupt any existing process control.

Remove a node from the DeltaV


network.

Download the setup data to all nodes. Also, stopping and restarting of
services such as the Batch Executive may be required.

Note There are other times when you must download that are not signaled by a change in the database. You only need
to perform a full download for the affected node. A power outage requires that the node without power be
downloaded again after power returns. Refer to the Preserving Configuration and Controller Data During Power Loss
topic for more information. Also, replacing a controller requires a download for the replaced controller. Refer to the
Auto-Sense Feature topic for more information.

What to Download
Controller and I/O
To minimize process disruption, download I/O components at the lowest level that downloads the desired changes.
For example, if you add or modify a card, download only the card rather than downloading the whole I/O subsystem
or the whole controller. By referencing the hierarchy in DeltaV Explorer, you can determine the lowest level object to
download. Expand the hierarchy (click the + next to an object) and download the lowest level object with a
to it.

next

To preserve outputs during a download, a module-level download that includes AO, DO, Loop, and Device Control is
partial.
Caution A download can potentially bump the I/O. To prevent this, place the block producing the outputs in manual
mode before you download. Care must be taken to determine if the process can withstand this temporary disruption.
To ensure the safety of the process, it might be necessary to delay the download of the configuration changes until the
process can be shut down.
Downloading loaded Phases or an SFC that has undergone a structural change can cause the controller memory to
fragment. In this situation FREMEM remains constant but the largest contiguous portion of memory decreases.
Typically, controller performance is not significantly affected unless several downloads of this type are performed. To
prevent any impact on controller performance, do not download to loaded phases.
Workstation
When downloading a node, the other workstations on the network must wait until the download is complete. The
DeltaV system attaches application locks and does not permit any other workstation to modify the data.

Downloading Data

339

Uploading Recorded Parameter Changes


You can change the parameter values in a module online (in a running controller) either through Control Studio or
through DeltaV Operate. As soon as you make one change to a module online, the database module and the online
module no longer match. You could examine the CHANGE records in Event Chronicle to find the changes that have
been made, but there is an easier way to assess the online changes that have been made.
The configuration host workstation in your system monitors all recorded parameter changes (anything that would
appear in any of the Event Chronicle databases in your system). The Upload command opens a dialog that
summarizes this list of recorded parameter changes.

If you are uploading multiple modules, the dialog appears as shown. If you are uploading a single module, the dialog
title includes the module name and the Node Name and Modules columns do not appear. The most recent value set
for each parameter (and field) and the user who made the change appears in the list. If two or more changes were
made to the same parameter and field within two seconds, the Same Time column includes a question mark (?).
The present controller configuration, operating parameters and I/O is not necessarily included in the upload process.
Any parameter changes made by the control algorithms in the controller, as is done in SFC processing, are not
included in the upload. You select which parameter values you want to write to the database modules. The Upload
command is available in the DeltaV Explorer and in Control Studio.
Note Upload before download does not capture the present configuration and operating parameters in the controller.
Only manual operator changes from the workstations are recorded. Any settings automatically performed by the
controller are not included in the upload. Use with caution, major process interruption could result from using this
feature if the specific implementation of the users configuration is not taken into account.
When an upload operation is interrupted before it completes, the values that it uploads before the interruption are
retained by the database.

340

System Configuration

Caution Select only the parameter changes that represent desired configuration changes to the module in the
database. Normally, changes to operating parameters (setpoints or operating state parameters that are initialized or
written by the module and many phase logic module parameters as well) would not be selected for upload.

Caution When you request an upload, make sure you select all of the values you want. Parameter changes that are
not selected are discarded, and not uploaded to the database. The download replaces the online values with the values
in the database and discards any recorded parameter changes for the downloaded module.

Note For remote workstations, downloading (total download) the RDS (Remote Data Server) Application Station
sends the configuration, setup data, displays, and charts to all the Remote Workstations (1st and 2nd hop) under that
RDS.

Uploading Recorded Parameter Changes

341

Referencing Documents
The integration feature enables you to launch a document from any description field in DeltaV Explorer, Control
Studio, or Recipe Studio. For example, you can enter a field such as C:\Procedures\MainShutdown.htm to point to a
specific HTML file that your organization has created.
To open the document, right-click the address in the Description field and then click Launch. When you click Launch,
the appropriate application opens and loads the file. For html and Microsoft Word documents, if the application is
already open, the control loads the document in the open application. If the document is a text document, the control
opens a new instance of Notepad for each referenced file.
Other examples of valid entries are:
C:\Spreadsheets\reactor1.xls
C:\ModuleDescriptions\FIC101.doc
This feature is only supported on the ProfessionalPLUS station. All referenced documents must be on the
ProfessionalPLUS station as well. The browser used must be the version of Internet Explorer that is included with the
Windows operating system.

342

System Configuration

System Preferences
Inside this topic
Defining System Preferences
Advanced Unit Management Preference
Batch Preference
Fieldbus Preference
P