Atoms Ch01 Introduction

Function Blocks Programmer's Ref. & User's Guide 278589

Metso Automation 1- 1

Introduction ................................................................................................................................................................. 1-3 Overview ................................................................................................................................................................... 1-3

Understanding Atomic Blocks and Buffers ....................................................................................................... 1-3 Configuring Atomic Blocks and Buffers ........................................................................................................... 1-3 Using maxDPUTools ......................................................................................................................................... 1-3 Using the Graphical Configurator ...................................................................................................................... 1-4

Atomic block Categories ....................................................................................................................................... 1-5 Atomic block/Buffer Overview by Category ......................................................................................................... 1-6

Alarm Tag Atomic Blocks ................................................................................................................................. 1-6 Analog Math Function ....................................................................................................................................... 1-7 Buffers ............................................................................................................................................................... 1-7 Modulating Control Logic ................................................................................................................................. 1-7 Discrete Logic .................................................................................................................................................... 1-7 Grouping Atomic Blocks ................................................................................................................................... 1-8 State Logic ......................................................................................................................................................... 1-8 Steam Compensation ......................................................................................................................................... 1-8

Understanding Attributes ....................................................................................................................................... 1-8 Attribute Categories ........................................................................................................................................... 1-8

Using Referencing to Interconnect Controls ........................................................................................................ 1-10 Referencing by Attribute Category .................................................................................................................. 1-10 Reference Subscriptions .................................................................................................................................. 1-10 Reference Syntax ............................................................................................................................................. 1-11

Understanding Data Types................................................................................................................................... 1-12 Boolean ............................................................................................................................................................ 1-12 Integer .............................................................................................................................................................. 1-12 Enumerated ...................................................................................................................................................... 1-13 Float ................................................................................................................................................................. 1-13 String ............................................................................................................................................................... 1-13 Absolute Time ................................................................................................................................................. 1-13 Relative Time................................................................................................................................................... 1-13

Commands ........................................................................................................................................................... 1-13 COMMAND function blocks .......................................................................................................................... 1-14 Edge Trigger function block command outputs ............................................................................................... 1-14

Complex Data Type ............................................................................................................................................. 1-14 Standard Complex Data ................................................................................................................................... 1-14 Forceback ......................................................................................................................................................... 1-14 Incremental Control Data................................................................................................................................. 1-14 Family Ties ...................................................................................................................................................... 1-15

Using Buffers to Define Hardware ...................................................................................................................... 1-15 I/O Addressing ................................................................................................................................................. 1-16 Creating or Editing the I/O Inventory .............................................................................................................. 1-16

I/O Module Types and Associated Signals .......................................................................................................... 1-16 Digital Input Modules ...................................................................................................................................... 1-16 Digital Output Modules ................................................................................................................................... 1-17 High Level Analog Input Modules .................................................................................................................. 1-17 Thermocouple/Millivolt Analog Input Module ............................................................................................... 1-17 Resistance Temperature Detector (RTD) Input Module .................................................................................. 1-17 Analog Output Modules................................................................................................................................... 1-17 Four-channel Position Adjusting Type (PAT) ................................................................................................. 1-18 Counter/Timer (Pulse) Module ........................................................................................................................ 1-18 Positioning Modules ........................................................................................................................................ 1-18 HART capable Modules .................................................................................................................................. 1-18

Using Buffers to Create Simulated I/O Environment .......................................................................................... 1-19 Using Hierarchical Groups .................................................................................................................................. 1-19

Copying and Pasting Groups ........................................................................................................................... 1-20



Group Attributes .............................................................................................................................................. 1-20 Setting Atomic block and Group Execution Rates and Priorities ........................................................................ 1-20

Selecting Execution Rate ................................................................................................................................. 1-21 Selecting Execution Priority ............................................................................................................................ 1-21 Executing Blocks Using Priority Order ........................................................................................................... 1-22 Executing Blocks Using Hierarchical Order .................................................................................................... 1-23 Using Hierarchical Scheduling with Absolute Priorities ................................................................................. 1-24 Using the DpuAtomList Utility ....................................................................................................................... 1-25

Using Custom blocks To Create Custom Applications........................................................................................ 1-26 Understanding Standard Objects ......................................................................................................................... 1-26

Objects That Monitor Functions ...................................................................................................................... 1-27 DPU Battery Related Object (DPU4E Only) ................................................................................................... 1-27 DPU Fan Related Object (DPU4E Only) ......................................................................................................... 1-28 Alarm Related Objects ..................................................................................................................................... 1-29 Security Related Objects .................................................................................................................................. 1-29 _timesync Object ............................................................................................................................................. 1-29 SBPLimit Object .............................................................................................................................................. 1-29

Using Alarm-Related Atomic Blocks and Buffers to Configure Alarming ......................................................... 1-35 Buffer Alarming............................................................................................................................................... 1-35 Viewing Alarms in a maxSTATION ............................................................................................................... 1-36

Base Attributes .................................................................................................................................................... 1-36 Table 1-5. Common Abbreviations Used in Attribute Tables ......................................................................... 1-38



Introduction

Overview Understanding Atomic Blocks and Buffers This reference guide provides descriptions for more than 60 atomic blocks and buffers available with maxDPU based systems. Use atomic blocks and buffers to create point databases implementing specific process control strategy.

Use atomic blocks for control and data acquisition. Use buffers to define the I/O inventory and specify signal conditioning and linearizations or create a simulation database.

An atomic block is a software object that encapsulates specific engineering functionality, such as a PID, an Auto/Manual toggle switch, or an AND gate. Atomic Blocks are normally grouped into larger objects to encapsulate increased functionality. Groups of atomic blocks constitute a custom function block object. Custom function blocks can be applied in hierarchical levels (HID levels) to form increasing levels of control system functionality. These HID levels can then be assigned to a particular DPU.

Atomic Blocks, buffers, and custom function blocks are part of a DPMS (Distributed Point Management System), a Microsoft Access-style database and client/server that composes a Distributed Processing Unit (DPU). The DPMS manages its point database, provides master scheduling, and executes the objects composing its database, among its various functions. A large process control application may be composed of multiple DPMS residing in as many DPUs.

Configuring Atomic Blocks and Buffers Use two maxDNA software products to create a point database incorporating atomic blocks and buffers, maxDPUTools and the Graphical Configurator.

maxDPUTools is a software utility that allows you to create a Microsoft Access-style database in offline mode. To configure points in an online environment, use the maxVUE Graphical Configurator, a separate software product available with the maxVUE Editor software.

Using maxDPUTools Use maxDPUTools to:

Create one or more configurations consisting of points and buffers Install the configuration(s) and load them into their respective DPUs



Use maxDPUTools to install an entire configuration at one time (full installation) or to install any part of the configuration down to a single atomic block, an incremental installation. See Publication 278595, maxDPUTools User's Guide.

Using the Graphical Configurator The Graphical Configurator, available through the maxVUE Editor, allows you to represent a point database graphically in the form of logic diagrams positioned on printable sheets. Use the Graphical Configurator application to:

Create graphical representations of point databases Make online edits to a configuration Edit tagnames Add and delete atomic blocks and groups online Document and print graphical representations of configurations A point configuration, represented graphically, consists of diagrams representing all or portions of groups associated with a selected configuration. Groups are drawn on A size (8.5 in x 10 in) (21.6 cm x 25.4 cm) or B size (11 in x 17 in) (27.9 cm x 43.2 cm) sheets, which can be printed on any default printer accommodating these two paper formats.

Logic diagrams appearing on sheets consist of a collection of boxes representing atomic blocks or custom blocks. In a point configuration, atomic blocks and custom block elements are connected or wired to attributes associated with other controls (atomic blocks, groups, custom blocks) using reference pointers. To show referencing graphically, logic diagrams show interconnecting lines entering and leaving boxes. Lines entering a box on the left are inputs and lines leaving a box on the right are outputs. An output emerging from one control may become another control's input.

You may use the Graphical Configurator to make online changes to a configuration as you experiment with new wiring schemes. As you rearrange the objects, add, delete or otherwise change wiring, their positions are stored back into the DPMS.

You may also make changes to the DPMS point configurations. Select individual controls, such as atomic blocks, groups, and elements within custom blocks to change attribute values. Other configurator tools let you add and delete atomic blocks and groups in a configuration on line.

These become permanent parts of the online DPMS but are not part of the offline database unless uploaded. To retain any online edits or organization changes, the DPMS must be uploaded to the offline database using maxDPUTools or the next install will return the DPMS to its unorganized state.

The current release of Graphical Configurator cannot be used to:



Copy and paste atomic blocks Upload and download a DPU Create a custom block (molecule/block)

Consult the most current maxDPU release notes.

Atomic block Categories This reference guide describes more than 60 individual atomic block and buffer types using descriptive text and tables. Atomic Blocks are organized by chapter under the following eight broad categories:

Analog math functions; see Chapter 2. Buffers; see Chapter 3 Modulating control logic; see Chapter 4 Discrete logic; see Chapter 5. Groups; see Chapter 6. – include with Tagging and Alarming State logic; see Chapter 8. Steam compensation; see Chapter 9. Tagging and alarming; see Chapter 7.

In addition to these eight general categories, the analog math functions, modulating control logic and discrete logic categories contain subcategories. The following table lists atomic blocks by categories and subcategories.



Table 1-1. Atomic Blocks Table

Analog Math Functions (AnlFunc) Subcategory Math ABS ADD MUL DIV MOD EXP POW SQRT Subcategory Special functions TOTL CALC SIGSEL LEADLAG

Buffers (Bufs) AIB AOB CB DIB DOB EB FB OD PB PLSIO QPAT RTD TC

Modulating Control Logic (ModLog) Subcategory: Basic AUTOMAN LIMITER PID FEEDFWD Subcategory Participation PARTMEM PARTMSTR CTLCOMB Subcategory PATOUT PATOUT Forceback Subcategory Special: CTLSEL CTLADD CTLMUL CTLDIV1 CTLDIV2 FUNCGEN Subcategory Test CMPT QUALFRCE

Discrete Logic (DesLog) Subcategory Basic Gates NOT AND OR XOR Subcategory Comparisons GT LT EQ NE Subcategory Flip Flops RESETDOM SETDOM NODOM Subcategory Timers TON TOFF TPULSE Subcategory Triggers EDGEANY EDGEFALL EDGERISE Subcategory Pack/unpack Bitpack Bit/unpack

Device Logic (DevLog) DEVLOG SEQMSTR SEQSTEP FSTOUT

Steam STMPROP FLOWCOMP LVLCOMP

AlarmTag related ATAG DTAG Group ALMREP GRP USROBJ

Atomic block/Buffer Overview by Category The chapters that follow this introductory chapter describe atomic blocks and buffers by the categories listed in Table 1-1. Refer to this section for brief descriptions of each category.

Alarm Tag Atomic Blocks Tagable atomic blocks consist of

Analog Tagger (ATAG) Digital Tagger (DTAG)



Use the Analog Tagger (ATAG) atomic block to assign a tagname, scaling, alarming, and value forcing capability to any analog point, and use the Digital Tagger atomic block to apply similar capabilities to digital points.

These atomic blocks are typically used to assign tagnames and alarming capabilities to individual signals entering buffers and to points related to PID-related atomic blocks. See Chapter 3, "Atomic block Category: Buffers," and Chapter 4, "Atomic block Category: Modulating Control Logic."

Chapter 7 discusses key features of each atomic block, such as value forcing using the Mode and ForcedVal parameters, configuring a snooze alarm, creating custom alarm text, and other features. Parameters included with this atomic block allow you to assign a tagname to a point, set alarm and range high and low limits, range clamping, and various alarm behaviors.

Analog Math Function Use the math related atomic blocks to perform basic mathematical operations, consisting of addition, (Add atomic block), multiplication, (Mul atomic block), Division, (Div atomic block), absolute value, (Abs atomic block), exponential (Exp atomic block), power (Pow atomic block), square root (SQRT atomic block) and (MOD atomic block). See Chapter 2.

Buffers Use buffers to define the I/O inventory and specify signal conditioning and linearizations. Most currently available I/O modules are represented by an associated buffer type. See also, "Using Buffers to Define Hardware."

Modulating Control Logic These consist of complex atomic blocks that are central to most process control strategies. Atomic Blocks discussed in this chapter are grouped by the following subcategories: Basic, Pulse Adjusting Type Output, Participation, and Special:

Basic AUTOMAN LIMITER PID FEEDFWD

Pulse Adjusting Type Output PATOUT

Participation PARTMEM PARTMSTR CTLCOMP

Special CTLSEL CTLADD CTLMUL CTLDIV2 CTLDIV1 FUNCGEN

Test CMPT

See Chapter 4 for a full discussion of complex atomic blocks.

Discrete Logic This chapter defines six sets of general purpose discrete logic atomic blocks and two special purpose atomic blocks. Most of these atomic



blocks use boolean parameters that are set to true or false to derive the expected results. See Chapter 5.

Grouping Atomic Blocks This chapter discusses atomic block types used for grouping other atomic blocks. Atomic Blocks in this category are used to define hierarchical structures (Group atomic block), to create custom atomic block groups (User Object), or to alarm similar elements within a custom control group (Alarm Reporter atomic block). See Chapter 6.

State Logic This consists of atomic blocks that provide controls for on/off devices and sequence operation.

Steam Compensation This consists of atomic blocks that provide steam property values or apply steam properties for process measurement compensations. (The flow compensation atomic blocks also provide compensation for air and gas flows.)

Understanding Attributes The data stored in an atomic block is organized as a set of attributes. For each atomic block and buffer, this reference guide presents a collection of tables listing attributes. Tables are organized by various attribute categories, such as inputs, output, parameters, and so forth. See next section.

The tabular detail shows three informational columns, listing the name of each attribute, data types associated with each attribute, and a brief description of the attribute.

All atomic blocks have some attributes in common. All attributes have subattributes. Subattributes include category, description, reference, and several others. Some of the others are attrwriteable, attrreadable attrminval etc.

Attribute Categories Attributes may be divided into the following categories:

General All atomic blocks have required foundation attributes.

Inputs Inputs are values that are usually obtained by referencing another attribute.

Parameters Parameters are similar to inputs except it is expected that referencing other attributes is unlikely and that the local



value is used. They are predominantly used to configure the atomic block.

Outputs Outputs are values that are the result of the function or operation with which they are associated. They are predominantly used to generate data for other atomic blocks to use.

Status These are similar to outputs except it is not expected that these are connected to inputs. They are predominantly used to monitor the atomic blocks’ execution.

Custom When defining a user object you are free to define your own attributes. They can be categorized as any of the above or you may define your own categories for your own purposes.

Quality All attributes have the sub-attribute Quality. The behavior of atomic blocks may be based on the Quality of its inputs. Use the QualityForce atomic block to force a quality change on a value as it is passed through. 0 = good data quality 1 = doubtful data quality 2 = substitute data quality 3 = bad data quality

Methods Methods direct an atomic block to perform a special function. Methods include commands to change mode or target value, etc. Because pure method values do not exist after the method is executed, they cannot be read back.

Commands Attributes that are used to receive commands from the HMI that will initiate some action within the atomic blocks’ algorithm.

Table 1-2 lists attribute categories listed in this publication for each atomic block. Categories, such as General and Quality, are common to all atomic blocks and are not listed with each atomic block type. The table lists information about referencing, read/write characteristics and configuration information. Most of these attribute categories are viewable in configuration utilities, such as maxDPUTools, Graphical Configurator, and Point Browser.

Table 1-2. Attribute Categories and Characteristics

james.r.johnson

Note

The view drop box filters what categories are shown based upon the character prefix. X is only displayed in Expert or All. New filters exist in 4.3 and newer. S=Operator, E=engineer and others

lanjohnsja

Sticky Note

Quality is a sub-attribute, not a classification of attributes. It can be read by using the reference TagName.attribute_name.quality. The result is an integer.



Attribute Categories

Has Reference Is Referenced Optimized Subscription

Read Write Seen in Point Browser

Shown in Graphical Configurator

Input Normally does Normally is not Yes Yes Yes Yes When Referenced* Output No for atomic

blocks, Normally Does for groups

Normally is Yes Yes No Yes When Referenced

Parameter Normally does not Normally is not Normally Not Yes Yes Yes When Referenced Status No for atomic

blocks, Normally Does for groups

Normally is not Normally Not Yes No Yes When Referenced

Command Normally does not No Yes Normally Not

Yes Normally Is Not When Referenced

*Attribute is shown on the Graphical Configurator as a quill protruding from the atomic block bit map in “Detail Mode” before any attributes are referenced or exposed.

Using Referencing to Interconnect Controls Use references to connect (or "soft wire") a control with other controls within a single configuration or across multiple configurations. Enter a reference in a control to read attributes data. The referenced attribute is normally an output, but may, under certain circumstances, be a parameter, or status of a DPMS object. See Table 1-2 and the next section.

Referencing by Attribute Category Input: Input attributes are intended to be wired most of the time

and receive data from a source outside the atomic block. They are predominantly used to get data from other atomic blocks for use in the internal algorithm.

Output: Output attributes are intended to be wired most of the time and receive data from the algorithm within the atomic block. They are predominantly used to generate data for other atomic blocks to use.

Parameter: Parameter attributes are not intended to be wired most of the time. They are normally static values configured and/or tuned to set the system’s operational performance.

Status: Status attributes are not intended to be wired most of the time and receive data from the algorithm within the atomic block.

Use referencing:

to read an attribute within the same control containing the reference to read attributes within other controls to read attributes within controls located in other configurations

Reference Subscriptions

james.r.johnson

Note

Category selection also impacts security for the point.attribute. See also the security schemes configuration in 278609_System Resources (vol. 2)



All inputs have several sub-attributes to represent their data. The local (default) value and the reference pointer fields are configurable. The working value is always retrieved by following the reference pointer. The following three cases apply to input references:

1. When a reference pointer is not specified, the default for the pointer is to point to the local value.

2. Optimized subscriptions use the reference pointer to pick a value in the DPU database (local memory) eliminating the need to subscribe to the Software Backplane. This takes the same amount of processor time as retrieving a local value. See Table 1-2.

3. Unoptimized subscriptions use the pointer to pick a value from a location, which must be interpreted. These would include - points outside the DPMS (including peer to peer communication), - references to attributes of a different type (e.g. time type input referenced to a floating point value), - some status type attributes that are not stored, and - (at least at present) sub-attributes of input attributes. Values by unoptimized subscriptions may not update every scan during periods of high DPU activity.

Reference Syntax The meaning of the following characters describes the construction of a reference field entry. See Publication 278597, maxDPUTools User’s Guide, “Using Referencing to Interconnect Controls,” for a more extensive discussion of reference syntax.

Character Character Description

Meaning

/ Slash Hierarchical level separator

# Number Sign

Designates the beginning of a relative ID number

. Single Dot My child (also designates the beginning of an attribute name)

.. Double Dot Sibling (child of my parent) (note that ../../ designates an “aunt/uncle” (child of my grandparent))

^ Caret The next hierarchical level above with a child whose name matches the generic name following the next slash (/)

Follow Follow the reference of the attribute referenced. This reference construct is not recommended because it resolves on download



only, does not reconstruct the connection for any subsequent edits in the DPU database.

Understanding Data Types To configure an atomic block, you must assign a value (or reference) to each atomic block attribute you intend to use. While it is more efficient for the DPU to process all values in real or floating point data, by necessity, atomic blocks and their attributes use a variety of data types. For example, logic gate-related atomic blocks, by their nature, tend to use many Boolean values. Additionally, virtually all atomic blocks use attributes that require text string entries.

The Type column appearing for each atomic block's tabular detail display indicates which data type must be used for a specific attribute. Single value data is often passed down the line without regard to source, use, or range. An associated attribute to such data is quality, which is, in fact, associated with all data. Value data functions in several formats:

Boolean Integer Complex Enumerated Float Long Relative time Text Time

Boolean Boolean data can only have the values True and False. It represents two state conditions such as: active/not active; on/off; alarm/no alarm.

Integer Integers are whole numbers with no fractional component. They may be range-restricted according to use.



Enumerated Enumerated data is another variation of Integer or Boolean where there is a meaning assigned to a list of values, which is severely restricted to those having special meaning to the function.

Example: mode in the auto/manual atomic block may be set to 0=manual 1= auto

Float Real or floating point data is used to represent a value in a continuum of a range of possible values. They are not restricted to whole values and may differ from other floats by very small increments. (Behind the scenes, most data is actually stored in this format. Consequently, you may occasionally see fields where integer and even Boolean values are sometimes misrepresented as floats).

String Generally used for text.

Absolute Time Absolute time is a special type of data, displayed in a standard time format. It is derived from the local clock, synchronized to the system master clock.

Relative Time Relative time is another variation of float that enables it to be read by a standard input reference.

Commands Commands are a special type of input to a function block that causes an action by the block when the command is written. To initiate this one time (scan) action, the command value is time stamped. The value represents an enumerated input to command one of a set of actions or a floating input to set a value entry (the input determines the application of the value). Normally the “input” is written by maxVUE functions (that includes the time stamp for the write event). But the input could be referenced to a COMMAND function block output (.OUT01 - .OUT16) or an edge trigger (EDGEANY, EDGEFALL, EDGERISE) function block command output (.CMDOUT).

james.r.johnson

Note

An example please? 10/11/06 20:52:31 GMT

james.r.johnson

Note

An example please? 520.899841 MINUTES. Inconsistent usage Rel Time and RelTime. Neither finds this page for definition.



COMMAND function blocks The COMMAND function block combines (up to four command inputs) and translates the commands to values that match the requirements of the inputs that reference its outputs while passing the time stamp of the active input command. Its inputs are also normally written by maxVUE functions but could also be referenced.

Edge Trigger function block command outputs The command outputs of the edge trigger function blocks are for commands generated by maxDPU logic (not written by maxVUE). The output is the configured command value with a time stamp related to the “edge” for a single scan (of the “edge” detection).

Complex Data Type It is often necessary to provide supplementary data along with a principle value. Such supplements are in themselves values (with quality). This need is met by special hybrid data types referred to as complex data. Three types of complex data share a common structure of six basic values: Aref, Rhi, Rlo, Rst, Stat, and Val. No one type uses all of them.

Standard Complex Data Standard requirement of data associated with a range. The primary components are Range Hi, Range Lo, and the Value. These attributes are used in all complex variables.

RHI RLO VAL

Forceback To avoid having upstream components run away (wind up) when the downstream components are unable to respond a concept called forceback is used to impose limits on the master source. The special value Status is used to describe the limit being imposed.

RHI RLO VAL STAT

Incremental Control Data This is a special case of data coming from a PID representing the requested output change for the drive unit. The data is actually the increment or delta by which the output is to be changed. Two special values of Reset component and auctioneering reference are useful in special situations.



RHI RLO VAL RST AREF

Family Ties Two special connections of atomic blocks require a special means of complex and even bi-directional communication.

Participation master and members must be able to keep tabs on one another that they do through the master demand connection.

Sequence master and steps have to pass status and active state information to one another, which they do through the chain--complex connection.

Using Buffers to Define Hardware The DPU processes analog and digital input/output signals via the family of parallel input/output modules. These modules provide the physical connection point for the input/output wiring of signals to and from a process. All plant data signals and control signals pass through these units. Use maxDPUTools to assign I/O modules to the Distributed Processing Units.

As noted, buffers are used to define the desired input or output modules. Each module has 1 to 16 channels, each corresponding to a signal. Use Atag and Dtag atomic blocks to assign tag names to each signal.

Analog inputs to I/O modules may represent thermocouple and resistance temperature detector (RTD) readings, among others. Digital signals may represent AC or DC signals derived from contact closures or voltage level outputs from devices such as pressure switches and pushbuttons.

I/O modules provide varying levels of signal conditioning, data conversion, and alarming (with validity, limit, and error checking) before passing information onto the high-speed parallel I/O bus for further processing by a DPU.

Use digital and analog buffers to configure digital and high level analog signals coming from I/O modules. Use thermocouple and RTD buffers to specify linearizations.

Atomic Blocks may be configured to point to analog and digital I/O buffers or to input modules to obtain conditioned signals as input data. Atomic Blocks, in turn, may output processed data to other atomic blocks or to an output buffer or to an output module connected to a field device.



I/O Addressing Up to 45 I/O Modules or up to 255 I/O addresses may be assigned to each DPU. I/O addresses are used to access I/O modules or channels of I/O modules. Each digital I/O module supports 16 bits with one address. Analog modules generally use one address per channel. I/O Analog and Digital Modules and associated signals are defined and configured and become part of a DPU I/O inventory list.

Creating or Editing the I/O Inventory The number of channels associated with a module varies from one, for an Output Driver, to 16, for DI and DO modules. The number of channels created need not be a multiple of a module count; when the channels are allocated to modules, the spares may be left unnamed.

For DPUs configured as a backup pair, I/O may be shared or redundant to each DPU. The default is for the I/O modules to be entered as shared. If you require redundant I/O, select the redundant option appearing in buffers. Some modules can be specified to be redundant while other modules connected to a DPU backup pair can be specified as shared. A hardware device called a Parallel I/O Backup Adapter provides this functionality; it is not configured as part of the I/O Inventory.

I/O Module Types and Associated Signals Refer to the following for a list of I/O module types that you may define along with their associated signal types.

Digital Input Modules 16 discrete inputs per module

Four voltage input types

24 VAC/VDC 48 VAC/VDC 120 VAC/VDC 240 VAC/VDC Solid-state inputs can be scanned 1000 times per second for 1 ms SOE applications



Digital Output Modules 16 discrete outputs per module unless otherwise noted

Four voltage output types

24/48 VDC 120 VAC 125 VDC 240 VAC

Two relay output types

240 VAC, 130 VDC Form A relay 10 channel 240 VAC, 130 VDC Form C relay

High Level Analog Input Modules 16 inputs per module

Three input ranges

4 to 20 mA 0 to 6 VDC 0 to 10 VDC

Thermocouple/Millivolt Analog Input Module 16 inputs per module

Inputs isolated from each other, from ground, and from module logic

Each input individually configurable as thermocouple or millivolt

Type B, C, D, E, G, J ,K, N, R, S, T, Platinel II thermocouples 10, 25, 60, 100, 250, +600/-250 mV spans Automatic RJ compensation on field wiring terminal board

Resistance Temperature Detector (RTD) Input Module 8 inputs per module

Inputs isolated from each other, from ground, and from module logic

Three-wire or four-wire RTDs

Each input individually configurable

10, 50, 100 Ω CU 25 Ω NI 10, 25, 100, 1000 Ω PT

Analog Output Modules



Eight-channel Current Adjusting Type (CAT) 4 to 20 mA or 0 to 16 mA outputs Two-wire or three-wire outputs

Four-channel Position Adjusting Type (PAT) Solid-state switched single phase outputs for 120 VAC reversing

motors Slidewire (1 to 5 volt) or two-wire (4 to 20 mA) position feedback

signals

Counter/Timer (Pulse) Module Can be used as an input or output module

Eight-channels with two inputs/outputs per channel

Uses adjacent DI or DO modules for signal conditioning

16 configurable counting and timing functions

Simple and up/down pulse counting Simple and up/down pulse timing Pulse width and pulse interval measurements Frequency and frequency ratio measurements (both single and two-

phase inputs) Pulse train and timed outputs Duration outputs Frequency outputs (both single and two-phase outputs)

Positioning Modules Customizable control via program language.

Each module has 8 digital inputs, 8 digital outputs, 4 analog inputs, and 4 analog outputs, along with a selection of termination module types available for various types of signal conditioning. Refer to the maxPAC Positioning Module Programming Guide and the maxPAC Hardware Reference Guide for additional details.

HART capable Modules HART (Highway Addressable Remote Transducer) communications protocol is a standard for communication between a control system and intelligent field instruments. HART is a registered trademark of the HART Communications Foundation.

The HART communication interface was developed as a means to get additional information from 4-20 ma field devices without requiring additional wiring. A Frequency Shift Keyed (FSK) signal is super imposed on top of the 4-20 ma signal allowing both the control current and higher-level communications to share the same pair of wires. Technology improvements allowed the transducers to maintain more and



more information such as maintenance data or environmental conditions. This data is now readily available to the users with the advent of the HART interface.

Metso Automation has several versions of maxPAC I/O cards that support the HART interface:

- Analog Input Card – has the ability to receive 4-20 ma field signals, as well as, HART Communications on each of 8 channels.

- Analog Output Card – has the ability to drive 4-20 ma field signals, as well as, HART Communications on each of 8 channels.

- Transceiver Card – performs HART Communications on each channel. The eight channels on this card can be connected in any order to various 4-20 ma field signals that are connected to a HART field device.

Refer to the maxPAC Hardware Reference Guide – 278596 for more detail of the hardware interface and interconnection. Refer to the HART Configuration Guide – 278715 for more details of the communications programming.

Using Buffers to Create Simulated I/O Environment While buffers are normally used to define real I/O for a real working process control environment, buffers may also be used to create a simulated I/O environment for logic and control strategy checkout.

Use buffers to create a simulation database that runs on virtual DPUs. A virtual DPUs runs as an application in a Windows workstation, simulating the functionality of a real DPU. Actual DPU hardware and physical connection to actual I/O are not required. Multiple virtual DPUs may run in a single workstation to simulate plant operation.

To create a simulation database, configure the simulation attributes available with each buffer type. Simulation related points begin with the character string sim. Buffers feature a SimST attribute, which when set to 1, causes the DPU to use entered simulated point values rather than actual values from attached I/O. SimStatus, another simulation parameter, is used to simulate hardware problems.

Using Hierarchical Groups DPMS composed of large point databases are normally organized in a multi-level hierarchical structure. Use the Group atomic block to define a node in the hierarchical structure. See Chapter 6, "Adding a Group."



A hierarchical organization may contain up to eight levels. The highest level of organization, which may represent an overall area of a control environment, may be labeled Unit1. Unit1 may have a subgroup called Control. Control may have subgroups, such as Boiler Control, Generation Control, etc.

Using a configuration tool, such as maxDPUTools, it is best to define group hierarchies before defining individual atomic blocks. When you open maxDPUTools and define a configuration name, you may begin to establish desired group hierarchies under the DPU tab.

The left pane of maxDPUTools shows a configuration tree structure similar to Windows Explorer. Each time you add a group, the new group appears in the tree structure. A group is placed at the level of the hierarchy that is currently selected. The selected level is the “parent." When you add a group to the parent level, a new child group is placed under the parent. Controls placed in the same group are called siblings.

Groups may be referenced by relative index number. When you add a group, the relative index is selected incrementally by default, which you may manually change The Relative index for each group or control must be unique within a group. See Publication 278595, maxDPUTools User's Guide.

Copying and Pasting Groups All or part of a hierarchical structure may be copied and pasted elsewhere. For example, a power plant containing three coal pulverizers could be configured by building the first pulverizer as, say, Unit1/Pulverizer#1 then copying it as a starting point for the other two. The Pulverizer group would be renamed Pulverizer#2, etc. See Publication 278595, maxDPUTools User's Guide, Chapter 2,"Tree View Editing Features."

Group Attributes The Group atomic block uses only parameter and general attributes. The Gname parameter is already configured when you open the newly created atomic block, showing the name you entered when you created the group. You may also give the group a tagname and description.

Setting Atomic block and Group Execution Rates and Priorities Function Blocks include a scheduling capability that controls their execution rate (ServiceTimeBase attribute) and their order of execution (ServicePriority and ScheduleType attributes). For a discussion of execution rate, see the next section, “Selecting Execution Rate.”

Configurations may use one of two execution orders, hierarchical or priority-based. Configurations created using Release 2.0 or later software use a hierarchical scheduling order. Configurations created prior to



Release 2.0 use a priority-based execution order. See “Selecting Execution Priority.”

Scheduling attributes are configured with default settings that you may change in maxDPUTools during database configuration or online using Point Browser.

These attributes taken together create a point database scheduling table. Changing the service priority, service time base, schedule type or committing a Function Block causes the schedule tables to be rebuilt. All Atomic Function Block execution is halted while the schedule tables are re-built (20 to 70 milliseconds). Atomic Function Block execution resumes immediately after the schedule tables are rebuilt.

Use the DpuAtomList utility, accessible from the maxSTATION, to read the schedule tables from a DPU, present them on screen and save them to a file. The utility lists Atomic Function Blocks in execution order for each time class. This tool only works with DPU version 2.0 or later. See “Using the DpuAtomList Utility.”

Selecting Execution Rate The ServiceTimeBase attribute lets you configure a three-tier execution rate for each group and each atomic block within a group, consisting of Normal, High, and Critical. The default schedule rates are 500ms, 100ms, and 40ms, respectively. You may also configure a fourth category, inherent. A Custom or Atomic Function Block with inherit time base will use the time base of its parent when instantiated.

Time base is configurable from 20 milliseconds to 500. The critical time class must less than or equal to the high time class that must be less than or equal to the normal time class. The three time classes execute independently of one another.

Atomic Function Block execution gets a configurable percentage of available CPU time to insure that processing time is available to handle SBP requests. Overloading a time class will cause slower execution of that time class.

The following table shows the attributes that control the schedule times:

Schedule Queue ServiceTimeBase Default Period Settable DPMS Attribute Normal 3 500 msec NormalTimer High 2 100 msec HighTimer Critical 1 40 msec CriticalTimer Inherit 0 Inherits parent HID Level’s time base

Selecting Execution Priority Use the ServicePriority attribute to establish an execution order for groups and individual atomic blocks within groups. DPMS Function Block scheduling consists of two execution orders: priority and hierarchical. Execution order is hierarchical by default in version 2.0. To



change the execution order set the ScheduleType attribute in the DPMS object to 0 for priority order or 1 for hierarchical order.

With either execution order, you may set the ServicePriority attribute to 0 to remove a group and all of its children from the schedule tables. Additionally, setting an Atomic Function Block to priority 0 causes it to be removed from the schedule table. This may be useful when you need to disable a part of a configuration temporarily while adding new functionality to an active DPU. maxDPUTools will no longer default group priority to zero.

Executing Blocks Using Priority Order With priority execution order, all Atomic Function Blocks in the DPU are executed in service priority order with priority 1 Atomic Function Blocks executed first and priority 100 Atomic Function Blocks executed last. To establish an execution order, enter a number for the ServicePriority attribute associated with a Function Block from 1 to 100. The ServicePriority setting for group nodes and Custom Functions is ignored.

All of the Atomic Function Blocks of a group with a high priority will be executed before all of the Atomic Function Blocks of a group with lower priority. All of the Atomic Function Blocks of a Custom Function Block will be executed together (in priority order within the Custom Function Block.



Executing Blocks Using Hierarchical Order Hierarchical execution uses the ServicePriority attribute in combination with HID structure to determine an execution order. Additionally, hierarchical execution may also incorporate absolute priorities that take precedence over the hierarchical position. See next section, “Using Hierarchical Scheduling with Absolute Priorities.”

Hierarchical execution looks at all of the Atomic Function Block children and group children one level down from the parent. Groups and Atomic Function Blocks with a higher priority are executed before groups and Atomic Function Blocks with a lower priority. All branches of the tree are scheduled in this manner. The result is that a group with high priority will have all of its children execute before the children of a lower priority group.

Hierarchical execution is illustrated in the following figure and the accompanying table. See Figure 1-1 for an illustration of a configuration using absolute priorities.

Note: all groups and Atomic Function Blocks are assumed to be in the normal time class.

Figure 1-1. Illustration depicts a configuration using hierarchical execution. See figure 1-for an illustration depicting a configuration using absolute priorities.

Table 1-3. Execution order of this configuration DPMS Pri 1 Atomic Function Block 3 Pri 70 Group B Pri 20 Atomic Function Block 4 Pri 40 Atomic Function Block 5 Pri 41 Group C Pri 40 Atomic Function Block 2 Pri 20 Atomic Function Block 1 Pri 21 Group A Pri 50 Root Pri 50

Root Priority 50

Group C Priority 40

Group B Priority 20

Group A Priority 50

Atom 2 Priority 20

Atom 1 Priority 21

Atom 3 Priority 70

Atom 4 Priority 40

Atom 5 Priority 41



Note that DPMS always runs first in the normal time class. Children of a group always execute before the group. This example shows the importance of the group priority attribute. In pre-2.0 versions of the DPU the group ServicePriority attribute was ignored.

Using Hierarchical Scheduling with Absolute Priorities In the hierarchical schedule mode, priorities 1 to 10 and 90 to 100 are absolute. Absolute priorities take precedence over the hierarchical position. Priorities 1 to 10 are always executed first. Priorities 90 to 100 are executed last. Priorities 11 to 89 are executed in the middle using the hierarchical rules shown above. Absolute priorities allow inputs to be scheduled first and outputs last regardless of where they are in the hierarchy.

Atomic Function Blocks with the same absolute priority are scheduled in service handle order. This insures the same schedule order for DPUs that are downloaded, warmed-up or warm restarted.

The following figure and accompanying table illustrates scheduling using absolute priorities.

Figure 1-2. hierarchical scheduling using absolute priorities.

Table 1-4. Execution order of this configuration DPMS Pri 1 Atomic Function Block 6 Pri 50 Atomic Function Block 5 Pri 60 Group D Pri 1 Atomic Function Block 3 Pri 70 Group B Pri 20 Atomic Function Block 4 Pri 41 Group C Pri 40 Atomic Function Block 1 Pri 21

Root Priority 50

Group C Priority 40

Group B Priority 20

Group A Priority 50

Atom 2 Priority 99

Atom 1 Priority 21

Atom 3 Priority 70

Group D Priority 1

Atom 4 Priority 41

Atom 5 Priority 60

Atom 6 Priority 50



Group A Pri 50 Root Pri 50 Atomic Function Block 2 Pri 99

Note that the children of Group D are executed first since it has an absolute priority.

When non-absolute priorities are the same, the following are used to resolve the hierarchical execution order:

X position on the Graphical configuration sheet, then relative index, then service handle.

Using the DpuAtomList Utility Use the DPUAtomList utility to read the currently configured schedule tables of the selected maxDPU (version 2.0 or later). Atomic Function Blocks from each schedule table (critical, high, and normal) are listed in the order that they will be executed by the DPU.

To access this utility from the Windows desktop, click the Start button on the Task Bar, point to Programs, maxDNA, maxDPU Utilities and click DPUAtomList. The following dialog appears:

To view the execution rates and priorities for points within a selected DPU:

1. Click the down arrow next to the maxDPU list field to view a list of available DPUs created from the DPUlist.ini file.



2. After selecting a DPU, click the Get Block List button to start the schedule acquisition process. Since the program reads at a leisurely pace, it may take 20 or 30 seconds for the schedule data to be presented. The data is listed with the first block to be executed at the top and the last executed block at the bottom. The type of block, its tag, and service priority is shown.

3. To save the data read from a DPU, click the Write To File button. The schedule data will be written to a file in the c:\temp folder. The file will be named atomlist_[dpu ip address].txt. If a file for this DPU already exists, it is overwritten.

Using Custom blocks To Create Custom Applications Use Custom blocks to create your own custom applications that may be used multiple times in a single configuration or across multiple configurations. Once created, Custom blocks, which are named entities, are added to the list of controls where they may be selected like any other control. See Publication 278595, maxDPUTools User's Guide, Chapter 3, "Creating Custom Controls Using Custom blocks."

At its simplest, a Custom block may implement a frequently used subroutine. At its most complex, a Custom block may consist of numerous combinations of native atomic blocks (standard atomic block types that come with the maxDPU) or custom controls that implement a fully developed PID control, a multi-step sequencer, and so forth.

Custom blocks may consist of the following:

One or more custom controls with their own attributes. Combinations of existing native atomic blocks Combinations of existing native atomic blocks and custom controls. Custom controls may be nested up to four levels deep as part of a hierarchical structure.

A Custom block is defined as part of a user object, to which you assign a name during the configuration process.

When you create and name the user object, the name appears in maxDPUTools tree directory pane where you may click on it, similar to a group node, to reveal its contents.

Understanding Standard Objects When the DPU is started, it automatically creates a collection of standard objects that may be viewed using Point Browser. See Publication, 278605, maxDPU Auxiliary Functions User’s Guide, Chapter 1, for a



full of discussion of Point Browser. User objects appear in the tree directory under the Service by Station subfolder as follows:

_AlmEvtText _AlmTagText _p(BattAlarm) _p(Fan Alarm) _p(NetAlarm) _pQueOvrn) _DPMS _DPMS.Root (GRP) _Backup _Security_Custom (Security) _Security_MCS (Security) _TimeSync (TimeSync) SbpLimit These objects, which contain preconfigured values, are a standard part of all configurations. Their associated attributes should not be edited.

Objects That Monitor Functions Objects such as the following are typically used to monitor various functions and diagnose problems.

_p(BattAlarm) _p(Fan Alarm) _p(NetAlarm) _pQueOvrn) _DPMS _DPMS.Root (GRP) SbpLimit

DPU Battery Related Object (DPU4E Only) The DPU Battery Alarm block tests the DPU battery when the DPU is started/reset, and once an hour thereafter. The actual DPU battery test takes one minute to perform. During the test the DPU Battery light (LED) is set to yellow.

At the completion of the test, the DPU Battery light (LED) is set to red, if the test failed, or green if the test passed. If the test fails, the DPU Battery Alarm Block generates a “DPU Battery Problem” alarm. The point name for the DPU Battery Alarm Block consists of DPU station name (or last 2 digits of its network address) followed by “BAT” and “_s” or “_p” (for secondary or primary).

The following is a Point Browser display of a DPU Battery Alarm Block while the battery is bad.



DPU Fan Related Object (DPU4E Only) The DPU Fan Alarm block tests the DPU’s CPU Fan status to determine if it still running. If the test fails, the DPU Fan Alarm Block generates a “DPU CPU Fan Problem” alarm. The point name for the DPU Fan Alarm Block is DPU station name (or the last 2 digits of its network address) followed by “FAN” and “_s” or “_p” (for secondary or primary).

The following is a Point Browser display of a DPU Fan Alarm Block while the fan is bad.

The following is an example of the DPU Events dialog with both DPU Fan and DPU Battery alarms.



Alarm Related Objects The first two listed objects, _AlmEvtText and _AlmTagText, contain the standard message text which appears on event and alarm related displays as various events and alarms are triggered.

Security Related Objects The security related objects, _Security_Custom and _Security_MCS, contain the settings for a downloaded security schemes database. See Publication 278609, System Resources User’s Guide, Chapter 4, to learn how to set up a security schemes database.

_timesync Object The _timesync standard object is the control center of the time synchronization process. The family of utilities that support time synchronization reference attributes that are members of the _timesync object. See Publication, 278605, maxDPU Auxiliary Functions User’s Guide, Chapter 5, for a full of discussion of time synchronization.

SBPLimit Object



Starting with Release 3.4 for the DPU4E and Release 4.2 for the DPU4F, a new function was added that is called the SBPLimit atom. This new atom allows configuration, display and alarming of Software Backplane usage restrictions. The restrictions were added to preserve the functioning of control logic under any network loading conditions.

Note that the restrictions are on external accesses. Incoming subscriptions can also come from inside a DPU in the form of unoptimized subscriptions. IncomingSubs statistic includes both internal and external subscriptions. A strict priority is enforced on the usage of the DPU Central Processor:

• 50% Guaranteed to control logic • Existing Loop priority subscriptions such as peer-peer

communications • Existing Normal priority subscriptions for display update • Existing Background subscriptions • New loop subscriptions • New normal subscriptions • New background subscriptions

Some goals of the restrictions include:

• No amount of communications load will cause failover • No amount of incoming traffic can affect control logic • New incoming traffic will not interrupt peer-peer

communications • No one station can dominate the bandwidth of the DPU • No one program within a station can dominate use of station

bandwidth • Any restriction violations shall be clearly diagnosed and alarmed

There are a number of types of restrictions on incoming traffic:

• Total Incoming Subscriptions to a DPU – limits the total to a number that can be handled by the DPU under any loading conditions

• Limits by connection priority – loop (high), normal (medium), and background (low) – insures that a lower priority connection cannot consume all available bandwidth preventing higher priorities from being serviced. Each program on the software Backplane has one or more connections. By limiting connection subscriptions, more bandwidth can be offered to higher priority connections (such as maxVUE) than lower priority connections (such as maxSTORIAN).

• Limits by station – limits the number of subscriptions from any single station to the DPU.



There are a few restrictions on outgoing traffic:

• Limit to outgoing references – a restriction on the total traffic (peer-peer) that can be generated by a single DPU

• Limit to unoptimized subscriptions – a logical connection between internal objects in a DPU that take work each time the block is executed. In an optimized subscription, the destination object directly accesses the source of data. An unoptimized subscription is access to data that is not stored, but that must be computed each time it is accessed.

Setting the Limits:

• All limits can be set in maxDPUTOOLS using object \system\SBPLimit. Usable defaults are set for each parameter. NOTE: increasing the default limits can have adverse consequences to the performance of the DPU. The default parameters were tested to insure that the control algorithms have at least 50% of the CPU time available, that all communications is handled in a timely manor, and that the Sequence of Event timing meets the specification. Consult the factory if it becomes necessary to increase these limits.



The SBPLimit atom's configurable parameters are:

HiLimTotalSub Specifies the High Alarm value for total external incoming subscriptions processed by a DPU. Default Value 8000 – The DPU may be stressed at this limit.

HardLimTotalSub Specifies the Hard limit value at which any new subscription will be rejected. Default Value 10000 – a value larger than this is not recommended.

HiLimStnSub Specifies the High Alarm value for subscriptions from any particular station (DPU or maxSTATION). Default Value 4000 - No station should consume more than half the capacity of the DPU.

HardLimStnSub Specifies the Hard limit value for subscriptions from any particular station (DPU or maxSTATION). Above this level any new subscription from that station will be rejected. Default Value 5000 - No station should consume more than half the capacity of the DPU

HiLimConnLoop Specifies the High Alarm value for subscriptions from any particular SBP connection running at Loop Priority. Default Value 180 - Loop Subscriptions are used for DPU to DPU communications. The number is small since they are handled at 1/4 second resolution.

HardLimConnLoop Specifies the Hard limit value for subscriptions from any particular SBP connection running at Loop Priority. Above this level any new subscription from that station will be rejected. Default Value 200 - Loop Subscriptions are used for DPU to DPU communications. The number is small since they are handled at 1/4 second resolution.

HiLimConnNorm Specifies the High Alarm value for subscriptions from any particular SBP connection running at Normal Priority. Default Value 1500 - Normal Subscriptions are primarily used for maxVUE and browser communication.

HardLimConnNorm Specifies the Hard limit value for subscriptions from any particular SBP connection running at Normal Priority. Above this level any new subscription from that connection will be rejected. Default Value 2000 - Normal Subscriptions are primarily used for maxVUE and browser communication. 2000 values from a single DPU should be considered extreme.

HiLimConnBgnd Specifies the High Alarm value for subscriptions from any particular SBP connection running at Background Priority. Default Value 2000 - Background Subscriptions are primarily used by maxSTORIAN communication.



HardLimConnBgnd Specifies the Hard limit value for subscriptions from any particular SBP connection running at Background Priority. Above this level any new subscription from that connection will be rejected. Default Value 3000 - Background Subscriptions are primarily used by maxSTORIAN communication. 3000 values from a single DPU exceed the possible real point count by more than a factor of 2.

HiLimOutRef Specifies the High Alarm value for External References. (Those containing a '[') Default Value 450 - 1/4 second data may lag significantly if external references exceed this value.

HardLimOutRef Specifies the Hard limit value for External References. (Those containing a '[') Above this level any new outgoing requests will be set to BAD_REF quality and not processed. Default Value 500 - Values above 500 are not recommended in fully loaded DPUs.

HiLimUnOptRef Specifies the High Alarm value for Internal Unoptimized References. Default Value 720 - 1/4 second data may lag significantly if unoptimized references exceed this value.

HardLimUnOptRef Specifies the Hard limit value for Internal Unoptimized References. Above this level any new internal unoptimized reference requests will be set to BAD_REF quality and not processed. Default Value 800 - 1/4 second data may lag significantly if external references exceed this value.

The DPU will annunciate alarms for exceeding any of the above limits. The format of these alarms is: UnOpt Ref High %#22% High Alarm for Unoptimized References reached.

%#22% is substituted by the current count of Unoptimized references.

External Ref High %#21% High Alarm for External References reached. %#21% is substituted by the current count of External references.

Subs High %#23% by %#24% High Alarm for External station or connection subscriptions. %#23% is substituted by the current count of external subs from the highest user. %#24% is substituted by the name of the station or the station name and connection number (Name:##) corresponding to %#23%

Subs High %#26% High Alarm for Total Subscriptions reached. %#26% is substituted by the current count of total subscriptions.

james.r.johnson

Note

Example: Stn subs high 3976 by SH4ENG 4DPU10_p



Subs Limit %#23% by %#24% Hard Alarm for External station or connection subscriptions. %#23% is substituted by the current count of external subs from the highest user. %#24% is substituted by the name of the station or station name and connection number (Name:##) corresponding to %#23%

Lost Subs %#26% Hard Limit for Total Subscriptions reached. %#26% is substituted by the current count of total subscriptions.

UnOpt Ref Limit %#22% Hard limit for Unoptimized References reached. %#22% is substituted by the current count of unoptimized refs.

External Ref Limit %#21% Hard Limit for External References reached. %#21% is substituted by the current count of External refs.

The SBPLimit atom produces the following status information:

OutRefCnt Current Count of External Outgoing References UnOptRefCnt Current Count of Internal Unoptimized References AlmCnt Count of Subs for Current Alarm AlmId Station/Connection ID for current Alarm AlmPri Priority of Connection for current Alarm TotSubCnt Current Count of Total Incoming external subs. Stn1Cnt - Stn5Cnt Top 5 Station usage counts Loop1Cnt - Loop5Cnt Top 5 Loop Connection Usage Counts Norm1Cnt - Norm5Cnt Top 5 Normal Connection Usage Counts Bgnd1Cnt - Bgnd5Cnt Top 5 Background Connection Usage Counts Stn1Id - Stn5Id Names of Top 5 Station usage Loop1Id - Loop5Id Names and connect Ids of Top 5 Loop Connection Usage Norm1Id - Norm5Id Names and connect Ids of Top 5 Normal Connection Usage Bgnd1Id - Bgnd5Id Names and connect Ids of Top 5 Background Connection Usage Note: Only Top station statistics are visible unless expert mode is turned on in the browser. Name and connect Ids are of the form “NAME:##”.



Using Alarm-Related Atomic Blocks and Buffers to Configure Alarming

Three user added atomic block types (analog tagger, the digital tagger and the alarm reporter), and all buffer types may be used to set up alarming capabilities. Atomic Blocks and buffers configured for alarming show up on maxVUE Alarm Lists and Alarm Summary Displays by tagname if conditions trigger an alarm or event.

There are also several intrinsic atoms that alarm on detection of a problem:

1. Backup – alarms when DPU becomes inactive due to a fatal error or DPU becomes active after taking control from a failing DPU.

2. Temperature – DPU over temperature (DPU4F only) 3. Queue Overrun – DPU alarm on Normal Queue Overrun 4. Network – DPU alarm on loss of A or B Network 5. Fan – Fan Rotation too Slow (DPU4E only) 6. Battery – Battery Failure (DPU4E only) If the atomic block does not have a Tagname the alarm parent group Tagname will be used in the alarm last. Another possibility is that the HID and generic name of the point may show up in the alarm list. One atomic block capable of alarming will only have at most one entry in the alarm list. A group may present more than one alarm to the list if it has more than one un-tagged alarm reporter calling it the alarm parent.

Buffer Alarming Buffers may also produced alarms when associated I/O cards experience a problem. Each I/O buffer has a FailoverTyp attribute used to determine the action taken if the DPU can no longer communicate with the associated I/O card. Three possible FailoverTyp settings are:

non-critical (0), normal (1), critical (2). All buffers will be in one of these classifications. The default is non-critical.

Three attributes in the backup object determine what action is taken for card failures in each classification (ThreshNonCrit, ThreshNormal, and ThreshCritical). Each of these three attributes has three possible actions based on exceeding the threshold. The following are the possible codes and actions:



Threshold

Value Action Description Default for

Classification 0 Fail More Than One If two or more cards in this group fail, alert the

inactive DPU of the failed mode. The inactive DPU will take control if its state is healthy, otherwise the original DPU will remain active and control with the operational I/O.

Normal

1 Fail One If any card in this group fails, alert the inactive DPU of the failed mode. The inactive DPU will take control if its state is healthy, otherwise the original DPU will remain active and control with the operational I/O.

2 Do Nothing Take no action. Non-Critical

ThreshNonCrit (default value = 2 “Do Nothing”) can be set to one of the three threshold values shown in the above table. The action will only pertain to the I/O cards where FailoverTyp is set to the default of non-critical (0).

ThreshNormal (default value = 2 “Do Nothing”) can be set to one of the three threshold values shown in the above table. That action will only pertain to the I/O cards where FailoverTyp is set to Normal (1).

ThreshCritical (default value = 2 “Do Nothing”) can be set to one of the three threshold values shown in the above table. That action will only pertain to the I/O cards where FailoverTyp is set to Critical (2).

Viewing Alarms in a maxSTATION To view alarms in a maxSTATION environment, two OCX controls and several other alarm-related programs need to be set up.

In the maxVUE Editor, use the Alarm Lists Control and Alarm Summary Control to configure alarm displays which operators may view in maxVUE Runtime viewable from multiple maxSTATIONs.

Because the Alarm List typically appears in any number of display locations in maxVUE, it is recommended that you establish one or two maxSTATIONs as Alarm List Servers to reduce network traffic. Only these stations will collect the Alarm Lists from the active DPMSs. All other maxSTATIONs will go to these servers for Alarm Lists. Use a Registry Editor entry to designate which maxSTATIONs should be servers.

Refer to Publication 278609, System Resources User’s Guide, for details on how to set up a Workstation for viewing alarms.

Base Attributes All atomic blocks include base attributes that are generally not configurable. Attributes appearing on the following list that are



configurable are ServicePriority and ServiceTimeBase. See "Setting Atomic block and Group Execution Rates and Priorities." The base attributes are listed here for reference.

Attribute Name Data Type Description Category _COMMIT VAR_EMPTY Commit A Service Method AltDescp VAR_PCHAR Attribute Alternate Description Subattr AnyAlarm VAR_FLOAT No Alarm=0 Alarm=1 General AttrBadRef VAR_LONG Attribute has bad ref Subattr AttrBool VAR_LONG Attribute is boolean Subattr AttrCmd VAR_LONG Attribute is a command Subattr AttrCnt VAR_LONG Count of Attributes Status AttrEnum VAR_PCHAR Attribute enumerations Subattr AttrExternRef VAR_LONG Attribute has external ref Subattr AttrFlags VAR_LONG Attribute Flags: RWONXBWBSCH Subattr AttrHasRef VAR_LONG Attribute is referred to Subattr AttrMaxVal VAR_LONG Attribute maximum value Subattr AttrMinVal VAR_LONG Attribute minimum value Subattr AttrNormRef VAR_LONG Attribute has normal ref Subattr AttrOptRef VAR_LONG Attribute has optimized ref Subattr AttrOptRefCnt VAR_LONG Attribute optimized refcount Subattr AttrOptRefId VAR_PCHAR Attribute opt ref client Id Subattr AttrReadable VAR_LONG Attribute is readable Subattr AttrState VAR_LONG Attribute is stateful Subattr AttrWireable VAR_LONG Attribute is wireable Subattr AttrWriteable VAR_LONG Attribute is writeable Subattr BaseAttrCnt VAR_LONG Count of Base Attributes Status Category VAR_PCHAR Attribute Category Subattr Data VAR_LONG Attribute Data Subattr DataIdx VAR_LONG Attribute Data Index Subattr DELSVC VAR_EMPTY Delete A Service Method Descp VAR_PCHAR Attribute English Description Subattr EngrSec VAR_LONG Attr engineer security level Subattr Idx VAR_LONG Attribute Index Subattr INHERIT VAR_EMPTY Inherit Parent SvcProperties Method MARKDEL VAR_EMPTY Mark A Service for Delete Method Name VAR_PCHAR Attribute Name Subattr ObjType VAR_PCHAR Object Type Standard OperSec VAR_LONG Attr operator security level Subattr Quality VAR_LONG Attribute Quality Subattr Ref VAR_PCHAR Attribute Reference Subattr RefTurn VAR_PVARIANT Attribute Reference Turns Subattr SbpQuality VAR_LONG Attribute Quality in detail Subattr SCHEDULE VAR_EMPTY Schedule A Service Method Service VAR_PCHAR Universal name for Object Status SvcCntBrowse VAR_LONG Count of Output Members General SvcCntInputs VAR_LONG Count of Input Members General SvcCntOutputs VAR_LONG Count of Output Members General SvcHandle VAR_LONG Service Handle General SvcParent VAR_LONG Service Parent Handle General SvcPassword VAR_LONG Service Password General SvcPntTickCnt VAR_LONG Service Load Factor General SvcPriority VAR_LONG Service Priority Standard SvcRelIdx VAR_LONG Service relative ParentIndex Standard SvcSecLevel VAR_LONG Service Security Level General SvcStatus VAR_LONG Service Commited Status General SvcTimeBase VAR_LONG Service Time Base for SchdQue Standard SvcType VAR_PCHAR Service Type General SvcUpdateTime VAR_LONG Service Last Update Time General SvcVersion VAR_FLOAT Service Version General SvcX VAR_LONG Service X loc on Page General

james.r.johnson

Note

In ATag, DTag & AlmRep Defeat changes AnyAlarm to 0 while in AIB and DIB Defeat does not change AnyAlarm (which stays 1). Buffers changed in DPU4F 4.4.0.4.



SvcY VAR_LONG Service Y loc on Page General Type VAR_LONG Attribute Type Subattr UNSCHEDULE VAR_EMPTY UnSchedule A Service Method

Table 1-5. Common Abbreviations Used in Attribute Tables Abbreviations Definition Ack Acknowledge Actv Active Alm Alarm Alt Alternate Auto Automatic Bufr Buffer Cls Close Clsd Closed Cmd Command Cnt Count Ctl Control Dec Decrease Dev Deviation En Enable Fdbk Feedback Fwd Forward In Generic input Inc Increase Incr Increment Inh Inhibit, Block Inv Invert attribute value (digital only) Lim Limit Man Manual Max Maximum Min Minimum Msg Message Op Operator command Opn Open Out Generic output Pct Percent Pmt Permit Press Pressure Qual Quality Rls Release Rmt Remote Rng Range Rqd Required Rst Reset Sel Select Sev Severity SP Set Point Svc Service Temp Temperature Tgt Target Tim Time Txt Text

Documents

Atoms Ch01 Introduction